Times are UTC Toggle Colours
00:12:13 *** LordAro has quit IRC 07:29:47 *** ntoskrnl has joined #openttd.dev 07:47:51 *** Zuu has joined #openttd.dev 07:47:51 *** ChanServ sets mode: +v Zuu 08:51:20 *** Alberth has joined #openttd.dev 08:51:20 *** ChanServ sets mode: +v Alberth 08:52:10 *** LordAro has joined #openttd.dev 08:52:10 *** ChanServ sets mode: +v LordAro 09:43:10 <Zuu> Fixes doxygen comment of CmdMoneyCheat: http://devs.openttd.org/~zuu/money_cheat_doc_fix.patch 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: http://devs.openttd.org/~zuu/give_money.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: http://webster.openttdcoop.org/?channel=openttd.dev || 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 #openttd.dev 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 #openttd.dev 12:19:47 <Zuu> Updated patch ( http://devs.openttd.org/~zuu/give_money.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: http://webster.openttdcoop.org/?channel=openttd.dev || 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: http://dev.openttdcoop.org/projects/superlib/repository/entry/money.nut#L272 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> http://devs.openttd.org/~zuu/town-fix.patch <--- 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: http://www.tt-forums.net/viewtopic.php?p=1097450#p1097450 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: http://webster.openttdcoop.org/?channel=openttd.dev || 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 #openttd.dev 15:33:50 *** ChanServ sets mode: +v LordAro 16:51:32 *** ntoskrnl has joined #openttd.dev 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: http://webster.openttdcoop.org/?channel=openttd.dev || 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: http://junctioneer.net/openttd/town/IndustryGS.tar 17:53:27 <Zuu> Despite the name, this version builds Towns - not industries. 17:54:04 <Zuu> The save game can be found here: http://junctioneer.net/openttd/town/gs-test.sav 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 http://paste.openttdcoop.org/show/2650/ 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? http://devs.openttd.org/~zuu/fix-warning.patch 19:26:47 <Alberth> it does 19:35:50 *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r25791 || Logs: http://webster.openttdcoop.org/?channel=openttd.dev || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking" 19:45:10 <frosch123> http://paste.openttdcoop.org/show/2651/ <- 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 #openttd.dev 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