Times are UTC Toggle Colours
02:28:34 *** JGR has joined #openttd.dev 02:33:05 *** JGR_ has quit IRC 07:59:21 *** Zuu has joined #openttd.dev 07:59:21 *** ChanServ sets mode: +v Zuu 08:00:31 *** Zuu has quit IRC 08:00:56 *** Zuu has joined #openttd.dev 08:00:56 *** ChanServ sets mode: +v Zuu 09:45:41 *** LordAro has joined #openttd.dev 09:45:41 *** ChanServ sets mode: +v LordAro 12:44:54 *** LordAro has quit IRC 14:08:01 *** LordAro has joined #openttd.dev 14:08:01 *** ChanServ sets mode: +v LordAro 14:27:11 *** Zuu has quit IRC 15:58:10 *** Zuu has joined #openttd.dev 15:58:10 *** ChanServ sets mode: +v Zuu 16:47:44 *** Alberth has joined #openttd.dev 16:47:44 *** ChanServ sets mode: +v Alberth 17:43:41 *** frosch123 has joined #openttd.dev 17:43:41 *** ChanServ sets mode: +v frosch123 17:51:06 <Zuu> I've now updated my Found Town patch so that it compiles. I also noticed that the doxygen was missing a few pre conditions so I've added those as well. http://devs.openttd.org/~zuu/found_town4.patch 17:51:39 <Zuu> I have also tested the patch with a GS that builds towns randomly on the map. Though I haven't tested all different parameters. 18:01:23 <frosch123> you do not check the value of the "size" parameter 18:01:38 <frosch123> if an ai passes 4, it gets a city 18:02:04 <frosch123> similar for layout 18:02:26 <frosch123> unless that stuff is handled nowhere in the scriptapi and it just relies on the command failing 18:03:06 <Zuu> EnforcePrecondition(false, size != TOWN_SIZE_LARGE || ScriptObject::GetCompany() == OWNER_DEITY); 18:03:28 <Zuu> For an AI the company will not be OWNER_DEITY 18:03:41 <frosch123> how does that trigger on size == 123456 ? 18:04:11 <Zuu> 123456? 18:04:34 <frosch123> exactly, just a random number 18:04:49 <frosch123> can't ais just pass any number to the command? 18:05:11 <Zuu> Enum parameters in the API are only checked for values defined in the enum. The API interafece methods do generally not protect against random numbers. 18:06:36 <frosch123> why do you disallow cities for ais? 18:07:09 <Zuu> Because humans are neither allowed to do that if I understand the DoCommand proc correctly. 18:07:59 <frosch123> i just did it in game 18:08:06 <frosch123> and where does the command check it? 18:08:29 <frosch123> i cannot build large towns, but i can build cities 18:08:54 <Zuu> Ah right. I confused the large town check with the city check. 18:09:03 <Zuu> I'll correct that. 18:09:53 <Zuu> The size parameter is 4 bytes. When passed to the do command, it will at the receiving side only read 4 bytes and use for the size parameter. What an evil AI can do at worst is to affect some other parameter in p1. However all input checks that are done using EnforcePrecondition is also done by the DoCommand. 18:10:21 <Zuu> s/4 bytes/4 bits/ 18:10:46 <frosch123> well, the command has to check everything, because it also has to deal with modified clients 18:11:02 <frosch123> i don't know how much the api checks in advance 18:11:16 <Zuu> The API checks quite a lot in advance. 18:12:01 <Zuu> Basically everything that is mentioned in the API as a pre condition is checked in code before the DoCommand is requested. 18:12:41 <frosch123> well, i thought it would also check for valid enum values 18:14:30 <frosch123> actually, the functions i looked at, all do check enum values for validness 18:17:13 <Zuu> That is the same observation as I see now that I've looked more closely too it. The reason why I probably wasn't aware of it is that there is actually not that many methods that accept enum input parameters. Most enums are used for output values from the API. 18:22:07 <Zuu> Updated patch: http://devs.openttd.org/~zuu/found_town5.patch 18:22:35 <Zuu> (AIs can build cities, enforced enum check) 18:23:49 <Zuu> hmm, though I guess the layout check is not 100% confirming with the doc saying that the parameter is ignored in some condition. 18:23:53 <Zuu> So I better fix that. 18:24:00 <frosch123> hmm, there are @game and @ai doxygen commands to make stuff only appear in one of the docs 18:24:08 <Zuu> Yes 18:24:09 <frosch123> i wonder whether that can be chained with @pre 18:24:17 <Zuu> I don't know 18:24:19 <frosch123> @game @pre No company mode active 18:24:29 <frosch123> @ai @pre ScriptSettings.GetValue("economy.found_town") != 0. 18:24:38 <frosch123> that kind of stuff 18:24:42 <frosch123> let's try :) 18:24:56 <Zuu> @game and @ai does in general make the whole method unavailable for the other API 18:25:10 <frosch123> that's @api 18:25:20 <Zuu> Oh yes 18:27:04 <frosch123> hmm, i cannot remember how to generate api docs :p 18:28:10 <Zuu> I never tried. I doubt that I have all the tools installed to do it. 18:28:54 <frosch123> found it 18:29:38 <frosch123> yay, chaining @game @pre and @ai @pre works :) 18:30:15 <Zuu> And it is actually used at some places already. 18:35:39 <Zuu> New patch with @game @pre etc. and when the layout parameter is ignored, don't enforce the enum : http://devs.openttd.org/~zuu/found_town6.patch 18:37:53 <frosch123> looks nice :) 18:44:13 <Zuu> Thanks for your help with review and the doxygen trick :-) 18:53:03 <frosch123> you're welcome :) 18:53:28 <frosch123> @services op 18:53:28 *** ChanServ sets mode: +o DorpsGek 19:18:12 <Rubidium> hitting a "is client sending bad data check" usually triggers an "unknown" error. Since that's not really nice for an AI/GS (got some complaints about getting those unknown-ish errors), you might need to test and document that 20:03:17 *** Supercheese has joined #openttd.dev 20:55:45 *** Alberth has left #openttd.dev 21:10:26 <Zuu> That is what I guessed to be one of the reasons why all checks are duplicated to also occur in the API. Another being that the error can be generated before the DoCommand is called and thus the AI can get it directly without having to wait until next tick. 21:11:22 <Rubidium> isn't the test DoCommand executed immediately? 21:12:38 <Rubidium> seems like it 21:12:49 <Rubidium> though that will give you one of the "undefined" errors 21:52:46 *** Zuu has quit IRC 21:56:51 *** frosch123 has quit IRC