Log for on 21st September 2013:
Times are UTC Toggle Colours
00:12:13  *** LordAro has quit IRC
07:29:47  *** ntoskrnl has joined
07:47:51  *** Zuu has joined
07:47:51  *** ChanServ sets mode: +v Zuu
08:51:20  *** Alberth has joined
08:51:20  *** ChanServ sets mode: +v Alberth
08:52:10  *** LordAro has joined
08:52:10  *** ChanServ sets mode: +v LordAro
09:43:10  <Zuu> Fixes doxygen comment of CmdMoneyCheat:
09:53:39  <Alberth> lol a negative number with an uint32 :)
09:54:09  <Zuu> A int32 is casted to uint32 when using that command.
09:54:29  <Alberth> yeah, but the doc string is a bit weird :)
09:54:54  <Alberth> patch looks fine, I assume you tested it :)
09:55:14  <Zuu> Actually not alone. Only with my following patch :-)
09:55:49  <Zuu> Which adds a GS command to take/give money to companies.
09:57:01  <Zuu> But I did execute that using a debugger and noticed that when p1 transforms into a negative value (uint32 -> int32) the company is not given money, but rather deduced money.
10:00:39  <Zuu> The actual feature patch:
10:02:00  <Zuu> I have extended the CmdCheatMoney command to allow giving the expenses type which should register the cost/income. An alternative solution would be to add a new CmdChangeBankBalance in this patch.
10:02:40  <Alberth> doc change makes sense, negative EXPENSES should add money :)
10:03:11  <Zuu> Indeed, and that is how the command works. Which I agree to make more sense than how it is documented.
10:05:01  <Zuu> Is a doc fix a -Fix or a -Codechange, or even a -Doc?
10:06:06  <Alberth> I'd make it a -Doc
10:06:24  *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r25787 || Logs: || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking"
10:06:26  <Alberth> CmdMoneyCheat  needs an updated doxygen, since you add p2 values
10:07:03  <Zuu> Ah yes, that change got lost when I solved the conflict with the doc patch. I'll add back that :-)
10:08:11  *** frosch123 has joined
10:08:11  *** ChanServ sets mode: +v frosch123
10:08:51  <Zuu> Patch updated (same URL)
10:11:01  <Alberth> you can add @see ExpensesType    at the end of p2 doc to point to the values you expect
10:12:27  <Zuu> Hmm, and I should validate the expenses type value.
10:13:28  <Zuu> (  if (expenses_type >= EXPENSES_END) return CMD_ERROR; )
10:14:00  <Zuu> Patch updated
10:17:37  <Alberth> I am not sure you actually want to give money to companies, in particular without a news message, but otherwise it looks ok
10:19:44  <Zuu> The doxygen of the GS command document that it is up to the GS to provide a news message. We could enforce it by add a text parameter to the command which will be used as a news message.
10:19:53  <frosch123> +	 * Changes the bank balance by a delta value. This method do not affect the loan but instead <- does
10:20:15  <Zuu> However, for some scripts, that make small but frequent money transfers, a news message for each transfer may be too much.
10:20:21  <frosch123> +	 * @param company The company to change the bank balance for. <- s/for/of/ ?
10:21:52  <Zuu> I'm not sure 'for' is right there but have no idea if 'of' is better.
10:21:53  <frosch123> hmm, can gs somehow read the current inflation level?
10:22:10  <frosch123> i guess they can read the base costs or something like that
10:22:18  <LordAro> of/for: both are probably acceptable, but imo 'of' is better
10:23:17  <Zuu> I'm not sure that the GS can read base costs and/or inflation. IIRC there has been some discussion about that in the API suggestion thread but I don't remember the details. It is probably best to look what the API actually offer.
10:26:04  <Zuu> From what I can see we don't offer access to base costs nor inflation rate. AIs that care about it probably has to register the cost of one rail tile at the game start and then see how the cost increases over time.
10:26:12  <frosch123> well, inflation is likely weird anyway for any gs that grants/takses money
10:26:44  <frosch123> i guess they would want to use "rounded" values, like charging a million, but not 1000123 :p
10:27:06  <Zuu> :-)
10:27:14  <frosch123> so, i guess adding a parameter to optionally add inflation itself is no solution
10:27:31  <Rubidium> with currencies you can't quite force a particularly nice number
10:27:42  <frosch123> hmm, also true
10:28:03  <Zuu> It is probably better to offer the inflation rate as an API as then both AIs+GSes can use it if they need in any use case.
10:28:07  <Rubidium> e.g. 10 million with Italian Lira is going to be kinda a pita
10:28:17  <Rubidium> @calc 10000000/3873
10:28:17  <DorpsGek> Rubidium: 2581.97779499
10:28:29  <Rubidium> @calc 2582*3873
10:28:29  <DorpsGek> Rubidium: 10000086
10:29:10  <Zuu> Hmm, do we have a {MONEY} for GSes to show costs in local currency?
10:30:16  <frosch123> CURRENCY_LONG and CURRENCY_SHORT
10:30:46  <Zuu> Good
10:32:04  <frosch123> hmm, CURRENCY_SHORT uses SI prefixes
10:32:22  <frosch123> at least here that's fairly uncommon
10:32:38  <frosch123> people who deal with money have no idea about SI prefixes
10:33:05  <Rubidium> they do at the company I work...
10:33:25  <frosch123> ok, i have never seen k€, only T€
10:34:12  <Zuu> Ah, those. Yes kkr can be seen here (where "kr" is the base money).
10:34:12  <Rubidium> I've even seen k€ in documents my German boss wrote
10:34:17  <frosch123> but well, i cannot think about a better solution than using SI prefixes
10:34:40  <Rubidium> 1e5€
10:34:52  <frosch123> really? :o
10:35:10  <frosch123> expoential notation is even more weird :)
10:35:14  <Zuu> Another way to write 5 kkr is to write 5'
10:37:27  <frosch123> is ' your thousand separator?
10:37:30  <Zuu> But apart from the language issues that frosch123 mentioned, does the patch look good? Assuming the conclusion is to not include a inflation parameter?
10:37:45  <frosch123> yes, patch looked fine
10:37:49  <frosch123> oh wait
10:37:50  <frosch123> changelog?
10:37:58  <Zuu> No, ' is not the thosand separator. For that we use a dot.
10:38:08  <Zuu> Yes, the changelog.. I forgot that
10:42:28  <Zuu> Now its in the changelog too :-)
10:44:21  <frosch123> :)
10:47:25  <Zuu> I just realized that the current implementation do not allow a GS to charge costs when the bank balance will end up lower than 0. This may be a problem for some use cases.
10:48:29  <frosch123> hmm, good point
10:48:38  <Zuu> Hmm, a test proved me wrong.
10:48:57  <Zuu> I now have - 20 000 000 :-)
10:50:05  <Zuu> So that means that the money cheat bank balance check is made at a higher level than the actual DoCommand.
10:51:23  <frosch123> hmm, ok, so it's some magic with the script command execution :p
10:51:49  <frosch123> eh, but are ais able to buy stuff when they have no money?
10:52:16  <Zuu> Hmm, actually I've broken that check for the money cheat.
10:52:53  <Zuu> AIs cant buy things when they have no money.
10:54:33  <Zuu> I have changed the command from CMD_OFFLINE to CMD_SERVER. Will change that back to see if there is some magic with that.
10:55:45  <frosch123> it looks like CMD_SERVER affect _current_company
10:57:00  <Zuu> Yes, changing back to CMD_OFFLINE changes the money cheat so that you can (as in trunk) not deduce money when you don't have enough.
10:57:20  <frosch123> CMD_SERVER seems to set _current_company = COMPANY_SPECTATOR
10:57:37  <frosch123> so, i why it affects the bank balance at all
10:57:45  <frosch123> or whether there is some overflow somewhere
10:57:54  <frosch123> which makes it affect a different company
10:58:32  <Zuu> Maybe this is solved best by creating a new CmdChangeBankBalance for the new usage and not extend the CmdMoneyCheat command.
10:59:10  <frosch123> yeah, one which is executed as DEITY, not in company mode
11:00:12  <Zuu> I'll look into that. It will probably need to return a zero cost (for deity) and just adjust the balance for a company given in p2.
11:01:37  <Zuu> But first, lets make some lunch :-)
11:08:19  *** ntoskrnl has quit IRC
11:31:50  *** Supercheese has quit IRC
11:32:22  *** Supercheese has joined
12:19:47  <Zuu> Updated patch ( ) so that it now uses a separate DoCommand proc which execute as deity and take the company to modify as parameter.
12:20:39  <Zuu> I have verified that the command can charge costs beyond negative bank balances while the cheat still cannot do this.
12:24:34  <frosch123> CMD_SERVER <- i think that should not be there
12:24:44  <frosch123> it changes _current_company to specator, which is likely wrong
12:25:13  <frosch123> instead the command should check for _current_comapny == COMPANY_DEITY
12:25:38  <frosch123> 16 bit for company id? :p
12:31:25  <planetmaker> +	DEF_CMD(CmdChangeBankBalance,         CMD_DEITY | CMD_SERVER, CMDT_MONEY_MANAGEMENT      ), // CMD_CHANGE_BANK_BALANCE <-- why 'CMD_SERVER'?
12:34:53  <planetmaker> +	SQGSCompany.DefSQStaticMethod(engine, &ScriptCompany::ChangeBankBalance,             "ChangeBankBalance",             4, ".iii"); <-- just for curiosity, what do the 'iii' stand for?
12:35:04  <frosch123> integer
12:35:11  <frosch123> but it's generated anyway
12:35:51  <Zuu> planetmaker: I want to ensure that a modified client don't use this command to cheat.
12:36:05  <frosch123> Zuu: yes, but CMD_SERVER does way more
12:36:15  <frosch123> so, you should instead check _current_company in the cmd function
12:37:01  <frosch123> just like the other deity-only commands do it, like creating goals or subsidies
12:38:38  <Zuu> The docs of CMD_SERVER did indicate to me that it would be useful:  CMD_SERVER    = 0x001, ///< the command can only be initiated by the server
12:38:50  <Zuu> But apparently that is not the right thing to do.
12:40:12  <frosch123> it looks like a thing for commands which are executed by noone
12:40:27  <frosch123> but the money thingie is executed by the deity "company"
12:40:38  <frosch123> CMD_SERVER is for changing game settings and stuff
12:41:33  <Zuu> I see your point and agree that if the suggested way is used by other commands that is how I should do it. It was just that I had a though that this command must not be allowed to be used by a modified client to cheat and had a look on the command modifiers to see what applies to that.
12:42:11  <planetmaker> well. modified clients must not execute GS stuff in any case :-)
12:42:20  <frosch123> CMD_SERVER is for sure a weird thingie :)
12:42:31  <Zuu> Especially when the CmdMoneyCheat was used, I didn't want to completly remove the protection that looked to be in place with CMD_OFFLINE.
12:43:09  <Zuu> planetmaker: There is no such thing like a CMD_ modifier that mark a command as GS only.
12:43:30  <Zuu> CMD_DEITY only enables a command for GS, not restrict it to GS-only.
12:58:17  <Zuu> Patch updated to not use CMD_SERVER anymore (but check _local_company), and so that only 8 bits are used for company in p2.
13:01:33  <frosch123> + *           (bit 7-16) - the expenses type which should register the cost/income @see ExpensesType. <- 8-15
13:02:08  <Zuu> of course. I wonder what I was thinking ...
13:02:35  <frosch123> +		/* Change company bank balance of compnay. */ <- company
13:02:59  <frosch123> looks fine :)
13:03:19  <planetmaker> yup
13:07:43  *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r25788 || Logs: || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking"
13:11:02  <Zuu> Regarding inflation rate, SuperLib contains a method to get the inflation rate:
13:11:34  <Zuu> (the method originate from SimpleAI by Brumi)
13:12:28  <frosch123> ah, using the max loan is not the worst thing to do
13:14:46  <frosch123> i was wondereing abuot building road and stuff, but they would break with basecosts. using loan is more clever :)
13:20:40  <Rubidium> I wonder why the inflation is interesting
13:24:50  <Zuu> Some costs like eg. station maintainence fee is hidden for AIs. With help of knowing the inflation, an AI can estimate it if it assumes that no BaseCost NewGRF is used.
15:00:39  <Zuu> <--- Fix: calling GSTown.FoundTown in world gen caused world gen to terminate and start the game
15:02:34  <frosch123> interesting :)
15:02:47  <frosch123> looks fine to me
15:02:53  <Zuu> Reported here btw:
15:03:32  <Zuu> The reporter claim that the game is laggy in non-fastforward with many towns. I haven't yet tried to reproduce this.
15:04:18  <frosch123> afaik towns do not grow if not specifically triggered
15:04:19  <Zuu> But that should be addressed in a different patch if there is anything that can be done against it.
15:04:30  <frosch123> so, i can only think about newgrf or scripts causing lag
15:04:43  <Zuu> He is using a script that call FoundTown.
15:05:28  <Zuu> According to his report using his script on a large map will cause OpenTTD to lag in non-fast forward. But I'll test it and see if that is true or if he misunderstood my question about fast forward.
15:09:00  *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r25789 || Logs: || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking"
15:33:32  *** LordAro has quit IRC
15:33:50  *** LordAro has joined
15:33:50  *** ChanServ sets mode: +v LordAro
16:51:32  *** ntoskrnl has joined
17:25:23  <Zuu> Ok, in a game with 15 milion world population the game runs OK with FoundTown calls turned off. When I enable frequent calls to FoundTown the game becomes laggy on my i7 3.6 Ghz - if the town directory window is open. If I close the town directory window and have frequent calls to FonudTown, there is no lag.
17:27:05  <Zuu> If I have calls to FoundTown disabled and have the town directory window open, there is no lag. So the lag comes possible by that OnInvalidate of the town directory is not efficent enough to work with a densly populated very large map.
17:27:33  <Zuu> (I don't know the number of towns as my GS don't log that and they are way to many to count by hand :-) )
17:28:42  <Zuu> But let say the average town size is in order of 3000 inhabitants. And there is now 16 milion towns. That give ~5300 towns in the game.
17:29:29  <Zuu> Hmm the average town size is probably more like 2400 or so.
17:33:47  <Zuu> That sorting by population is quick is no surprise. But I'm surprised that sorting by rating is noticable slower than sorting by population.
17:36:07  <frosch123> if you have an easy testcase i can run it with callgrind
17:43:42  <Zuu> I'll upload my test GS
17:43:50  <Zuu> + save if you like
17:44:25  <Zuu> It uses some NewGRFs. I can produce a new one in 5-10 minutes without NewGRFs if that helps.
17:45:19  *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r25790 || Logs: || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking"
17:47:35  <Zuu> I'm making a new save w/o any NewGRFs.
17:53:15  <Zuu> The GS is found here:
17:53:27  <Zuu> Despite the name, this version builds Towns - not industries.
17:54:04  <Zuu> The save game can be found here:
17:54:08  <Zuu> It is about 6 MB
17:54:30  <Zuu> 2048x2048
17:57:25  <Zuu> Ouch, running the town generator for enough time on that map cause OpenTTD to die. (with a windows dialog saying that the program died) From the task manager I can see that it used about 1/5 of 8 GB of ram.
17:57:28  <Rubidium> Zuu: wouldn't is be better to expose the station maintenance (and other non-exposed) costs?
17:58:39  <Zuu> Rubidium: than providing a current inflation rate API? - Yes it would solve the real probem and not just helping with a work around.
17:59:34  <Rubidium> exactly, though we'd need to find a granularity that's useful, and decide what to and not to expose
18:24:27  <frosch123> forgot debug symbols :(
18:28:02  <Alberth> Zuu
18:29:00  <Zuu> Oh, that needs an explicit cast then.
18:29:18  <Zuu> I'll fix that.
18:49:26  <frosch123> yawn, a problem with valgrnid is that stuff takes so long that you forget stuff inbetween
18:54:41  <Alberth> :)
19:08:44  <frosch123> so, 23% is on GetString in the townname sorter
19:09:34  <frosch123> hmm, there's already some weird one-item cache
19:10:56  <frosch123> ok, quite a lot of towns there
19:11:12  <frosch123> 50 times sorting the list results in 1.56Mcalls of the sort comparator
19:17:10  <frosch123> 5700 towns
19:17:32  <frosch123> so, i guess replacing the one item cache with something else might solve the issue
19:18:46  <Zuu> In the forum thread (not sure if you read it) the guy who reported the lag has concluded that the lags that he observed is related to a TownName NewGRF. I guess that is due to the fact that it needs to draw many random numbers before it finds a new unique name.
19:19:12  <frosch123> the script isn't even running
19:19:20  <frosch123> it's just sorting the names in the list
19:19:41  *** ntoskrnl has quit IRC
19:24:58  <Zuu> Alberth: Does this fix the warning?
19:26:47  <Alberth> it does
19:35:50  *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r25791 || Logs: || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking"
19:45:10  <frosch123> <- replace the one item cache with a complete cache
19:45:37  <frosch123> reduced the 23% on getString to 4%
20:04:20  <Alberth> I wonder whether it should not be done globally
20:05:09  <Alberth> patch seems ok to me otherwise
20:05:53  <Alberth> good night
20:06:27  *** Alberth has left
20:13:45  <frosch123> hmm, globally
20:13:59  <frosch123> one could add the cache to the townname generator
20:58:13  <Rubidium> just cache it once at town name generation ;)
20:59:01  <Rubidium> in the same variable as for the custom name, and ditch the newgrf/townnameparts from the savegame
20:59:20  <Rubidium> then you can just sort the string pointers
20:59:24  <frosch123> that breaks the "reset to default" thingie
21:00:15  <Rubidium> then don't trash them from the savegame ;)
21:00:43  <frosch123> yeah, might work
21:35:39  *** LordAro has quit IRC
21:52:54  *** Zuu has quit IRC
23:52:31  *** frosch123 has quit IRC

Powered by YARRSTE version: svn-trunk