IRC logs for #openttd.dev on OFTC at 2013-09-19
⏴ go to previous day
02:28:34 *** JGR has joined #openttd.dev
07:59:21 *** Zuu has joined #openttd.dev
08:00:56 *** Zuu has joined #openttd.dev
09:45:41 *** LordAro has joined #openttd.dev
09:45:41 *** ChanServ sets mode: +v LordAro
14:08:01 *** LordAro has joined #openttd.dev
14:08:01 *** ChanServ sets mode: +v LordAro
15:58:10 *** Zuu has joined #openttd.dev
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: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:24 <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: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: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: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: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: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:24:00 <frosch123> hmm, there are @game and @ai doxygen commands to make stuff only appear in one of the docs
18:24:09 <frosch123> i wonder whether that can be chained with @pre
18:24:19 <frosch123> @game @pre No company mode active
18:24:29 <frosch123> @ai @pre ScriptSettings.GetValue("economy.found_town") != 0.
18:24:56 <Zuu> @game and @ai does in general make the whole method unavailable for the other API
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: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:44:13 <Zuu> Thanks for your help with review and the doxygen trick :-)
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:49 <Rubidium> though that will give you one of the "undefined" errors
continue to next day ⏵