Times are UTC Toggle Colours
05:58:32 *** Alberth has joined #openttd.dev 05:58:32 *** ChanServ sets mode: +v Alberth 09:32:16 <fonsinchen> https://github.com/ulfhermann/openttd/commit/68a1d97a4a7ae83169d56aa17f0d519a9082cf9b for FS#6006 09:51:25 <Rubidium> seems okay to me 09:59:31 *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r26574 || 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:18:01 <fonsinchen> https://github.com/ulfhermann/openttd/commit/d357f8e15f7b8c999623d97be0768bf749034a1d to catch something like FS#5995 when it actually happens 10:26:11 <Rubidium> fine by me, but be aware that stable releases (excluding RCs and betas) do not have assertions enabled 11:02:43 <fonsinchen> The station refit logic doesn't take other_multiheaded_part into account while the actual RefitVehicle() does 11:04:04 <fonsinchen> So one part of a multiheaded train may have some cargo scheduled for unloading and the other one can still be refitted which affects both. That's bad 11:31:10 *** Supercheese has quit IRC 11:31:44 *** Supercheese has joined #openttd.dev 11:31:44 *** ChanServ sets mode: +v Supercheese 12:12:26 <Rubidium> http://rbijker.net/openttd/fs6003.diff <- most of it is just moving stuff to a more appropriate file and removing a kinda pointless comment 12:28:29 <Alberth> resetting the "months_empty" and "password" of an invalid company is not a problem I guess. Can you rename the president in such a case during replay? If so, it seems fine 12:30:42 <Rubidium> Alberth: before code that I split off, there is a DoStartupNewCompany with a NULL check. DoStartupNewCompany should never return a company with an invalid ID 12:31:36 <Alberth> hammered closed properly thus, nice 12:31:42 <Alberth> and thanks for explaining 12:47:16 <fonsinchen> Let's introduce some civilization into that whole station-refit thing, shall we? https://github.com/ulfhermann/openttd/commit/b660c82063ff1c2e37f6be089e06c6a6ec7899b9 12:48:39 <fonsinchen> Oh, that's 5995, not 6006 12:49:52 *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r26575 || Logs: http://webster.openttdcoop.org/?channel=openttd.dev || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking" 12:49:58 <Rubidium> http://rbijker.net/openttd/fs6001.diff <- simple solution; more complex one is not really worth the effort 12:51:07 <Rubidium> mostly because it's meaning yet another location where network code creeps in for a quite insignificant corner case 12:52:22 *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r26576 || Logs: http://webster.openttdcoop.org/?channel=openttd.dev || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking" 12:57:19 <fonsinchen> Enough for today. Time for barbecue 12:57:39 <fonsinchen> I don't really understand that network code, so whatever ... 12:58:24 <Alberth> Rb: looks like a simplification of the problem at least, but I don't understand the details 13:01:56 <Rubidium> well, much later... after map generation the non-dedicated server client is pushed into the first company regardless of what state it was in before 13:02:19 <Rubidium> as a result, it makes no sense to not do the same when starting the server 13:03:35 <Rubidium> "starting" being the step happening after "stopping" it and before mapgen 13:04:03 <Rubidium> so the life cycle of a game in network is: "start", "newgame" / "loadgame", "play", "stop" (repeat) 13:06:14 <Rubidium> at "start" the network code looks at the company associated with the (server) client, and says that it plays as that client (in the bug report that's spectator) because there has not been a reset of it, then at the end of "newgame" the (server) client is moved to company #1 without updating that tidbit that was set during "start" 13:07:37 *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r26577 || 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:17:16 <Alberth> the simple solution would be to construct the first player after map generation, but that fails on not serving the network at all times 13:17:22 *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r26578 || 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:18:19 <Rubidium> any idea why player was 'banned' from the source code? 13:18:27 <Rubidium> is it the company? or is it the client? 13:19:27 <Alberth> sorry no idea, hacking in nml atm 13:19:41 <Rubidium> the first company is created after map generation, but having an uninitialised client will break things, which is why it needs to be created during startup of the network 13:23:57 <Alberth> not having a client while the network runs is theoretically be possible I think, but it makes life a lot more complicated in not having a server user? 17:17:34 *** frosch123 has joined #openttd.dev 17:17:34 *** ChanServ sets mode: +v frosch123 17:45:51 *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r26579 || Logs: http://webster.openttdcoop.org/?channel=openttd.dev || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking" 18:02:12 *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r26580 || Logs: http://webster.openttdcoop.org/?channel=openttd.dev || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking" 18:17:20 <planetmaker> Rubidium, 'player' was used ambiguously previously. Client or company are more clear 18:17:56 <Rubidium> yay answering rhetorical questions 18:17:58 <planetmaker> hm, ancient time tag on the conversation. Sorry :) 18:31:40 *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r26581 || Logs: http://webster.openttdcoop.org/?channel=openttd.dev || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking" 18:35:35 *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r26582 || Logs: http://webster.openttdcoop.org/?channel=openttd.dev || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking" 18:46:43 *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r26583 || 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:08:11 <Rubidium> regarding FS#5942; should we force the SQInteger to be always int64 or int32? 19:08:26 <Rubidium> so regardless of platform you always have the same result? 19:10:11 <Alberth> sounds useful 19:10:40 <Alberth> and not to have trouble with large amounts of money, perhaps int64 is the only useful choice 19:14:13 <planetmaker> I agree 19:42:05 <planetmaker> is http://bugs.openttd.org/task/6014 something we want (from the principle - the patch needs cleanup)? 19:43:53 <frosch123> what does your cpu usage say if you run it on a devzone game? 19:44:52 <frosch123> no idea what that sorting is useful for, but i would expect it to seriously lag a bigger game 19:48:26 <planetmaker> well, would only be called when you actually use that function, would it? 19:48:37 <planetmaker> i.e. show your station list sorted by vehicle usage 19:48:43 <frosch123> yes, when the station gui is open and sorted that way 19:49:22 <planetmaker> I'll ask him about values :) 19:49:36 <planetmaker> his patch, his work 19:49:49 <frosch123> well, i still wonder about the use case 19:50:04 <frosch123> sorting stations by waiting cargo and stuff is fine 19:50:06 <planetmaker> stations you built and forgot 19:50:11 <frosch123> but by number of visiting vehicles? 19:50:58 <frosch123> hmm, does that catch implicit orders as well? 19:51:13 <frosch123> let's check that, i have no idea 19:53:41 <frosch123> yeah, indeed implicit orders are listed in station lists 19:57:23 <Rubidium> that looks pretty O(N**3) or so to me 19:58:13 <Rubidium> or even O(n**3 log n)-ish 20:00:38 <planetmaker> hm... 20:01:05 <frosch123> different ns though: stations, vehicles, orders 20:01:38 <Alberth> only useful usecase can be 0 visiting vehicles 20:02:01 <Alberth> or rather 0 stopping vehicles 20:02:06 <frosch123> maybe you want to maintain your airports at 10 aircraft, and use it to monitor crashes 20:02:37 <Alberth> good idea :) 20:02:55 <planetmaker> or RV being eaten by "enemy" trains on level crossings 20:16:38 *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r26584 || Logs: http://webster.openttdcoop.org/?channel=openttd.dev || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking" 20:25:27 *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r26585 || Logs: http://webster.openttdcoop.org/?channel=openttd.dev || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking" 20:26:41 <Rubidium> there... 10 closed bug reports today (UTC) 20:26:52 <Supercheese> noice 20:29:58 <frosch123> i should travel more often 20:30:09 <frosch123> iirc the same happened last time when i was travelling 20:30:55 <Rubidium> well... don't think I'll be as productive the next weekends 20:32:45 <Rubidium> anyhow... where are the days with < 40 or even < 20 open bugs? 20:53:44 *** frosch123 has quit IRC 21:30:48 *** Alberth has left #openttd.dev