Log for on 19th September 2013:
Times are UTC Toggle Colours
02:28:34  *** JGR has joined
02:33:05  *** JGR_ has quit IRC
07:59:21  *** Zuu has joined
07:59:21  *** ChanServ sets mode: +v Zuu
08:00:31  *** Zuu has quit IRC
08:00:56  *** Zuu has joined
08:00:56  *** ChanServ sets mode: +v Zuu
09:45:41  *** LordAro has joined
09:45:41  *** ChanServ sets mode: +v LordAro
12:44:54  *** LordAro has quit IRC
14:08:01  *** LordAro has joined
14:08:01  *** ChanServ sets mode: +v LordAro
14:27:11  *** Zuu has quit IRC
15:58:10  *** Zuu has joined
15:58:10  *** ChanServ sets mode: +v Zuu
16:47:44  *** Alberth has joined
16:47:44  *** ChanServ sets mode: +v Alberth
17:43:41  *** frosch123 has joined
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.
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:
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 :
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
20:55:45  *** Alberth has left
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

Powered by YARRSTE version: svn-trunk