IRC logs for #openttd on OFTC at 2016-04-14
⏴ go to previous day
00:01:11 <supermop_> ok what to name maglevs
00:02:33 <sim-al2> I mean, present, future, etc
00:03:04 <sim-al2> The new Chuo shinkansen maglev has been named L0
00:05:12 <supermop_> all names need to be fake, whimsical, and relevant to prototypes
00:05:52 <supermop_> as everything is fictionalized drawing inspiration from various prototypes but in the style of original TT vehicles
00:07:09 <supermop_> i have "yamanashi" and "kofu" now, but i might name them Shinji and hideo / shima and sogo
00:07:30 <supermop_> after engineers who worked on the original tokaido shinkansen
00:09:31 <supermop_> idk if i will give all the SG shinkansens place names, or train names, or concept names
00:10:13 <supermop_> maybe i switch all of the monorails to food names
00:15:32 <supermop_> currently i dont use nozomi or hikari for any train
00:24:42 <Samu> you guys like to draw a lot of grfs
00:26:17 *** Zeetherdroid has joined #openttd
00:27:52 <Samu> im experimenting with zlib preset 2
00:28:02 <Samu> seems the ideal candidate for autosaves
00:28:57 <Samu> zlib preset 1 is as fast as zlib preset 2, but compresses less
01:09:59 <Flygon__> sim-al2: Sounds like the 0-series Shinkansen
01:10:05 *** Flygon__ is now known as Flygon
01:10:53 <Samu> I'm gonna study a feasible solution tomorrow for tackling this autosave stuff, there must be a way to optimize this without having the clients drop from the game
01:12:16 <Samu> i count 4 ways to trigger the encoding/decoding function with just the server
01:13:14 <Samu> 1. manual load/save, 2. autosave, 3. sending a map to client, 4 - click on a savegame from a list
01:13:53 <Samu> autosave is definitely the number 1 culprit
01:17:36 *** tokai|noir has joined #openttd
01:17:36 *** ChanServ sets mode: +v tokai|noir
01:40:40 *** Bowen is now known as BowenC2C
01:43:10 <BowenC2C> is... anyone ever here
01:43:40 <sim-al2> Just a slow time right now
01:43:47 <BowenC2C> sorry, ive never got an answer here lol
01:44:01 <sim-al2> It's dinner or approaching dinner in the Americas, and around midnight in Europe
01:44:06 <BowenC2C> whats up with server 2?
01:44:16 <BowenC2C> yeah its 00:44 here in the uk
01:44:32 <sim-al2> Oh damn. Are you on #/r/openttd?
01:45:11 <sim-al2> Yeah, so that we don't spam up this channel
01:46:23 <sim-al2> Errr, I don't see you?
03:44:09 *** TrueBrain has joined #openttd
04:19:32 *** tycoondemon2 has joined #openttd
04:51:12 *** LongyanG has joined #openttd
04:53:50 *** ConductorCat has joined #openttd
05:35:43 *** Supercheese has joined #openttd
06:45:41 *** circ-user-jr62P has joined #openttd
06:46:10 *** circ-user-jr62P is now known as kamnet
07:44:03 *** Ketsuban has joined #openttd
08:22:10 *** Hiddenfunstuff has joined #openttd
08:30:38 *** Biolunar has joined #openttd
08:42:26 *** sla_ro|master has joined #openttd
09:00:32 *** supermop has joined #openttd
10:07:44 *** OsteHovel has joined #openttd
10:20:20 *** Speedy` has joined #openttd
10:20:27 *** OsteHovel has joined #openttd
10:20:39 *** Speedy` is now known as Speedy
10:31:38 <Samu> Error! Out of memory: Cannot allocate 2359304 bytes.
10:42:27 <Samu> emergency save also crashes
10:43:07 <Wolf01> I think you are pushing it to the limits
10:43:27 <Samu> I wanted to find out the barrier
10:43:39 <Samu> i can screenshot this for proof
10:48:40 <Samu> the answer i was looking for
10:48:53 <Samu> 2 GB is the barrier for the entire openttd.exe process
10:53:17 <Samu> start it 15x times on a giant map
10:53:27 <Samu> wait a few seconds, crash with out of memory
10:54:19 <Samu> on the 64-bit, memory rises up to about 5.5 GB
10:55:00 <Wolf01> there might be a memory leak
10:55:21 <Samu> I don't think so, it's how terron works
11:02:46 *** Quatroking has joined #openttd
11:03:13 <Samu> it stops, but requires huge amounts
11:14:14 *** OsteHovel has joined #openttd
11:43:48 *** JacobD88 has joined #openttd
12:09:21 <peter1138> have you finished yet? :p
12:28:11 <Eddi|zuHause> for weeks now i have been pondering whether i should remove people from my ignore list, but i think it's still correct that they are on it...
12:29:19 <Samu> if (!_networking) const SaveLoadFormat *def = lastof(_saveload_formats); else const SaveLoadFormat *def = &_saveload_formats[2];
12:30:13 <Samu> that asterisk is ruining the next code lines with def
12:33:16 <Samu> original code is: SaveLoadFormat *def = lastof(_saveload_formats)
12:33:26 <Samu> i want to add a condition
12:33:58 <Samu> if not networking, i want it to pick up another format
12:35:00 <Samu> or actually, if networking, pick up a different format than that of original code
12:45:06 <Samu> Run-Time Check Failure #3 - The variable 'def' is being used without being initialized.
13:02:47 <peter1138> It means the variable 'def' is being used without being initialized.
13:05:19 <Samu> lzma preset 0 is considerably slower for what I'm intending to do
13:05:58 <Samu> lzma is format _saveload_formats[3], the last available format also
13:06:21 <Samu> i want to switch to zlib which is _saveload_formats[2]
13:06:26 <Samu> how do I make this switch?
13:39:10 <Wolf01> Eddi|zuHause: once I had an idiot on my ignore list, but then the replies of other people started to get interesting and I removed him from the list, and started to flame with him again
13:39:29 *** Nothing4You has joined #openttd
13:42:07 <Eddi|zuHause> that's usually why i don't have a lot of people on there as well
13:42:51 <Eddi|zuHause> but i still think i should keep this one, for my own sanity
13:43:18 <Wolf01> just ignore it.. oh wait
13:44:08 <Wolf01> btw... who's ddossing everything in europe?
13:45:15 <Eddi|zuHause> peter1138: all other conditions being equal, i'd go with the not-facebook one
13:45:51 <Eddi|zuHause> but i don't know if the conditions are equal
13:46:03 <Wolf01> iirc the vive costs 100€ more
13:46:23 <Wolf01> but it's less picky about the hardware
13:56:03 *** tycoondemon has joined #openttd
14:04:30 <peter1138> funny how rift was going to be all opensource (software-wise) and support linux etc...
14:11:16 <Ketsuban> €100 sounds reasonable for not having unknown data being sent to Facebook's servers whenever the device is plugged in.
14:11:57 <Ketsuban> Though I'm not convinced VR in general is ready yet.
14:31:19 *** Supercheese has joined #openttd
14:32:30 *** sla_ro|master has joined #openttd
14:34:31 *** tycoondemon has joined #openttd
14:35:39 *** Klanticus has joined #openttd
14:48:59 <Samu> what's the difference betwen _network_server and _networking?
14:49:43 <planetmaker> one only relates to a server, the other to client and server
15:21:08 <Samu> _networking means the host of the server
15:34:19 <Samu> nope, i didn't understand the difference
15:53:38 <Samu> _do_autosave is returning false when a client in a server starts autosaving?
16:17:04 *** Alberth has joined #openttd
16:17:04 *** ChanServ sets mode: +o Alberth
16:25:48 <Samu> why is _do_autosave = false when a client in a server starts autosaving?
16:25:48 *** sim-al2 has joined #openttd
16:26:27 <Samu> what is _do_autosave supposed to mean after all?
16:26:32 <Alberth> I didn't know that was the case
16:26:42 <Alberth> nor do I know what the variable does
16:27:07 <Alberth> my first guess is to prevent starting another save before this one ends
16:27:46 <Samu> but _do_autosave = true when the server starts autosaving
16:28:49 <Samu> bool _do_autosave; ///< are we doing an autosave at the moment?
16:30:54 <Alberth> really, you have seen more about _do_autosave than I have
16:36:14 <Samu> client on a server starting autosave: _do_autosave = false, _network_server = false, _networking = true
16:40:22 *** supermop has joined #openttd
16:41:18 <Alberth> so look for the code that uses that variable
16:42:05 <Alberth> it probably protects something, so find out what it protects
16:44:22 <Samu> what led me to checking this was because when the server was too fast at autosaving, the client wasn't keeping up, because it was using a different saving encoder. I don't really get this stall though, there's either something wrong in the code, or I don't get it
16:45:52 <Samu> this is when both server and client have autosave enabled
16:46:43 <Samu> the client has to wait for the entire saving process to finish before it un-stalls
16:48:23 <Samu> i thought the encoding was processed in a separate thread
16:48:47 <Alberth> you need a copy of the map too
16:49:53 <Samu> yes, both get to that part at nearly the exact time, given I'm testing both server and client on the same rig
16:50:09 <Samu> but the encoding part.... is behaving different
16:56:17 <Samu> what I've solved so far was, getting rid of the encoding stall for the server, I picked no compression for server autosaves. The memory copy stall that you mention is before it sends it to the "no compression" filter. When it gets to this part, it basically just writes to the file in the disk. This is the where it should start a different thread, right?
16:57:34 <Samu> better double check again,
17:06:51 <Samu> i get different autosave behaviours, depending on the game mode
17:07:14 *** Hiddenfunstuff has quit IRC
17:07:55 <Samu> in single player, autosave stalls for the memcopy part, but then for the encoding part, it does not stall. it keeps encoding while the game still runs
17:08:54 <Samu> in a server game, as a server, autosave stalls for the memcopy part, and is still stalling for the encoding part, it only un-stalls when the encoding finishes. This is bad especially if the encoder is slow.
17:09:35 <Samu> in a server game, as a client doing autosave, I am not sure... must check
17:12:46 <Alberth> stalling server isn't bad, clients will pause too
17:16:13 <Samu> it's bad when the encoder takes like 20+ seconds, clients will drop because it didn't receive answer from the server ( server was still encoding)
17:18:03 <Samu> and dont' get confused, this is autosave, not about sending the map to client. it's a server with autosave enabled
17:23:59 <Samu> in a server game, as a client doing autosave, it stalls for the memcopy part, it unstalls for the encoding part. client is still saving while the game is running
17:24:07 <Samu> so, the issue is indeed autosave for the server only
17:25:30 <Samu> save completed, client didn't drop from the game
17:25:51 <Samu> i've even set the strongest compression method just to be sure
17:27:38 *** Wormnest has joined #openttd
17:31:37 *** MonkeyDronez has joined #openttd
17:36:02 *** CompuDesktop has joined #openttd
17:40:20 *** Compu is now known as Guest506
17:40:21 *** CompuDesktop is now known as Compu
17:41:30 <Samu> if (_network_server || !_settings_client.gui.threaded_saves) threaded = false;
17:42:27 <Samu> it's a network server, it's setting threaded = false for some reason, I wonder why is it being forced to false
17:46:47 <Samu> must investigate this better
17:47:25 *** TheMask96 has joined #openttd
17:49:47 <Rubidium> to prevent client-join-save and autosave from interfering?
17:52:23 <Samu> i see, so autosave must be interrupted when a client joins
17:52:51 <Rubidium> or it should wait till autosave completed
17:53:02 <Samu> yes that's what I was thinking too
17:54:26 <Rubidium> though technically it should not be needed anymore since the rewrite I did to send the savegame data before compression finished
17:55:20 <Rubidium> but that still requires some work and checking I guess, as you want to prevent a sort of fork-bomb with saving (if saving, i.e. compressing, takes longer than processing a month of game state)
17:57:30 <Samu> the idea i initially had for server autosaving was using the fastest compression method possible, until I found this
18:00:26 <Samu> maybe the idea could still be applied here
18:01:50 <Samu> in my rig, saving with zlib preset 2 takes 6 seconds, after the memcopy part, on a map sized 4096x4096
18:02:16 <Samu> should be fast enough for monthly autosaves
18:02:41 <Samu> memcopy is about 4-5 seconds
19:03:55 *** Progman has joined #openttd
19:06:41 <Wolf01> so, I just resurrected one pc with ubuntu... as every time forcing the update of the packages resolved the problem
19:13:40 *** Wolf01 is now known as Guest512
19:13:40 *** Wolf03 is now known as Wolf01
19:13:59 <Wolf01> and for the second time today, the router decides to cut off the lan
19:14:27 <Alberth> you ceased to exist for just a moment!
19:14:52 <Alberth> maybe the world re-aligned with you :)
19:19:32 *** sim-al2 has joined #openttd
19:36:55 *** andythenorth has joined #openttd
19:45:44 <DorpsGek> Commit by translators :: r27539 trunk/src/lang/hebrew.txt (2016-04-14 19:45:35 +0200 )
19:45:46 <DorpsGek> hebrew: 66 changes by dnd_man
19:51:01 *** frosch123 has joined #openttd
19:54:37 <supermop> work making it had to concentrate on this podcast
19:55:59 *** sim-al2 has joined #openttd
20:04:31 *** HerzogDeXtEr has joined #openttd
20:08:25 <Eddi|zuHause> i can never listen to anything without concentrating on it completely
20:08:52 <Eddi|zuHause> as soon as i focus on somehting else, it turns into unintelligible blahblah
20:11:56 *** sla_ro|master has joined #openttd
20:34:55 *** zeknurn` has joined #openttd
20:37:26 <Wolf01> "Man accidentally 'deletes his entire company' with one line of bad code"... rm -rf, not code but command, bad article is bad
20:38:28 <andythenorth> could happen to anyone
20:39:01 <andythenorth> better avoided though :P
20:39:56 *** zeknurn` is now known as zeknurn
20:42:02 <Wolf01> "Mr Marsala confirmed that the code had even deleted all of the backups that he had taken in case of catastrophe." <- is he an evil genius?
20:44:31 <frosch123> maybe he just likes to talk about the empty set
20:45:33 <andythenorth> he had the backup volumes mounted
20:45:58 <andythenorth> I don’t want to tempt fate here, but the story I read, he is running some kind of backup maintenance / pruning script
20:46:48 <Eddi|zuHause> that looks rather fake to me
20:46:48 <andythenorth> I have learnt the hard way that ‘backup maintenance’ is a synonym for ‘backup loss'
20:47:12 <andythenorth> I thought it was fake, but he has other postings
20:47:24 <Wolf01> I can do only one of these things: nuke my machine | nuke the backups... if I manage to do them both at the same time I'm the king of idiots
20:47:26 <andythenorth> and with ansible, what he describes is highly plausible
20:47:38 <andythenorth> Wolf01: don’t tempt fate :P
20:48:00 <Wolf01> my machine doesn't do backups, it's another machine which logs to my machine and backups everything
20:48:16 <Wolf01> so I can't nuke the backup while nuking my machine
20:48:49 <Eddi|zuHause> there are lots of cases where the backup ticked in after wiping everything, wiping also the (non-incremental) backups
20:48:56 <andythenorth> unless you write a script to ‘maintain’ the backup Wolf01 :P
20:49:23 <Wolf01> yes, in that case I'll nuke the backups, but not my machine
20:49:43 <Eddi|zuHause> andythenorth: what broke the story for me is the comment at the bottom where he says "i switched if and of"... that can only be a troll...
20:49:47 <Wolf01> you can't nuke something which is readonly
20:49:58 <Wolf01> and indeed, that's a troll :)
20:50:00 <andythenorth> Eddi|zuHause: it did seem to go from bad to worse :)
20:50:13 <andythenorth> Wolf01: some people don’t have readonly or append only backups :P
20:50:29 <andythenorth> they go in and selectively delete, according to rules
20:52:30 <Eddi|zuHause> there was one time where i mistyped "cmp" as "cp" and only noticed halfway through... but i don't think it destroyed any data, since they were meant to be the same anyway
20:53:22 <andythenorth> sync with src and dst swapped is the mistake I have made more than once :P
20:55:56 <Wolf01> I dd'ed the boot partition from HDD the wrong way... the destination to the source, but I had a backup file
20:57:25 *** gelignite has joined #openttd
20:59:59 <glx> luckily not backuped the wrong way ;)
21:18:26 <andythenorth> that is quite novel
21:38:03 *** Myhorta has joined #openttd
21:42:32 <supermop> new shinkansen idea:
21:50:35 *** sim-al2 has joined #openttd
22:10:03 <Samu> some help needed.openttd can't have more than 1 DoSave running at the same time
22:10:16 <Samu> it could, if i knew how to code lol
22:11:59 <Samu> saves for the autosave and saves for the client joining, do both at the same time
22:12:44 <Samu> and could even save for the manual save, a 3rd instance
22:15:17 *** Biolunar has joined #openttd
22:18:27 <Samu> network is immediately sending a DoSave directly without checking if a save is currently occurring :(
22:19:04 <Samu> guess it needs some coding here
22:24:31 *** andythenorth has left #openttd
22:25:49 *** strohalm has joined #openttd
22:26:17 *** ConductorCat has joined #openttd
22:26:57 *** Extrems has joined #openttd
22:27:15 *** sim-al2 has joined #openttd
22:27:27 *** Smedles has joined #openttd
22:30:52 *** Speedy` has joined #openttd
22:31:05 *** Speedy` is now known as Speedy
22:33:03 *** Belugas has joined #openttd
22:33:03 *** ChanServ sets mode: +o Belugas
22:47:29 <Samu> NetworkRecvStatus ServerNetworkGameSocketHandler::SendMap()
22:48:15 <Samu> this function must force the client to wait in the queue if the server is currently performing a save
22:49:09 <Samu> wait for the save to end, then once it gets there, start sending the map
23:46:17 *** JacobD88 has joined #openttd
continue to next day ⏵
