IRC logs for #openttd on OFTC at 2016-04-07
⏴ go to previous day
00:50:01 *** drac_boy has joined #openttd
01:07:43 <drac_boy> dunno what kind of nick that is
01:08:02 <drac_boy> but either way how're you? and do you have snow too?? weird that its like winter all over again here :-|
01:08:19 <sim-al2> I'm good, and lol no, 70 degrees and thunderstorms
01:08:38 <sim-al2> Crazy crazy lighting earlier, but now it's sunny again...
01:08:42 <Wolf01> quatro king maybe... but we used to misread it as quack rotting
01:09:44 <drac_boy> well its snowing nonstop for more than six hours here .. already causing weird car problems (mainly out of idiotic drivers...nothing new meh)
01:10:02 <drac_boy> and tomorrow will creep to just a little bit over 0C .. which means rain all day long too :-/
01:12:29 <sim-al2> Well it did drop a bit here, now it's 15C
01:12:42 <drac_boy> anyway anything new trains-wise?
01:18:30 <drac_boy> heh actually thats something I always never understood privately...why replace easy-to-make smooth metal front with a more complex use-more-materials front that doesn't ahve much purpose outside modifying the paint lines?
01:19:31 <sim-al2> New technology makes it cheaper, and that nose is a covering for enhanced crash protection anyway
01:20:38 <drac_boy> cheap != eco .. thats all I can say
01:21:03 <drac_boy> and I've found some photos of rather bad sideswipe crash that hadn't done much damage to the budd rdc's interior
01:21:23 <drac_boy> like I said: to our own thoughts
01:22:41 <drac_boy> come to think about it hi-beam or container wagons have caused a small but sizeable number of injuried engineers on adjacent tracks (incoming swipes at the cab window corner yep, funny how the cargo load more than often misses the entire bleeping nose anyway!)
01:30:44 <sim-al2> Well, it is built to a longer length and 4 doors like most other Toyku lines
01:50:17 <drac_boy> gone a little quiet here
02:08:03 *** sim-al2 is now known as Guest10578
02:08:04 *** sim-al2 has joined #openttd
02:08:33 <drac_boy> ah *pokes the silly guest-sim*
02:09:06 <sim-al2> Computer decided to go to sleep because I walked away for a few minutes
02:12:24 <sim-al2> Yeah, low fever again :/
02:12:44 <Eddi|zuHause> better than high fever...
02:35:00 *** Clockworker has joined #openttd
02:45:54 *** tycoondemon has joined #openttd
04:24:37 *** Supercheese has joined #openttd
04:29:04 *** Biolunar_ has joined #openttd
04:51:45 <Eddi|zuHause> Device: /dev/sdd [SAT], 648 Currently unreadable (pending) sectors ... uh-oh
05:09:20 <Eddi|zuHause> weird, it reports 0 reallocated sectors
06:23:11 *** _johannes has joined #openttd
07:21:38 *** Monkey_ has joined #openttd
07:40:16 <Eearslya> Eddi|zuHause: Probably means you caught it early enough that there's no chance of data loss, which is good
08:48:27 *** andythenorth has joined #openttd
08:57:17 *** Hiddenfunstuff has joined #openttd
09:01:16 *** I_Trump has joined #openttd
09:44:12 *** tokai|noir has joined #openttd
09:44:12 *** ChanServ sets mode: +v tokai|noir
09:50:48 *** Myhorta has joined #openttd
11:42:15 <Samu> hi, i got some results from the lzma testings yesterday
11:43:05 <Samu> nice_len: a value of 273 here yields best compression
11:44:25 <Samu> openttd lzma implementation is only single-threaded
11:44:47 <Samu> openttd lzma implementation is also only using 2 MB for dictionary
11:45:24 <Samu> dictionary size is one of the greatest contribution to the resulting compressed size
11:45:55 <Samu> the size should be based on the uncompressed size of the stream
11:47:11 *** andythenorth has joined #openttd
11:47:24 <Samu> on the example case I used a ~ 1.9MB uncompressed, a 2 MB dictionary resulted in the best compression ratio, any dictionary size higher than 2 MB was useless, it was always resulting in the same size
11:48:34 <Samu> openttd could have some code to adapt the dictionary size to be a bit more dynamic, instead of just 2 MB for every case
11:49:34 <Samu> and... pretty much that's it
12:12:56 <Wolf01> how's going with the compression?
12:15:42 <Samu> i got the results, I know what are the best parameters, i just don't know how to code this in openttd ( as usual)
12:16:47 <Samu> openttd is using an easy encoding approach, it lacks customization on the important parameters I mentioned a few minutes ago
12:17:28 <Samu> dict_size, nice_len - these are 2 of the most important ones
12:20:23 <Samu> the easy encoding approach is using pre-defined presets, from 0 to 9. Each preset has their own set of parameters
12:20:51 <Samu> openttd devs explicitly decided to use preset 2 of lzma
12:30:49 *** andythenorth has joined #openttd
12:40:32 <Samu> line 2370 sets the preset 2 for default_compression
12:41:22 <Samu> and line 2426 retrieves default_compression which is 2
12:47:46 <Samu> simply putting a 9 in there isn't enough, it doesn't necessarily lets me to chose the nice_len
12:47:59 <Samu> nice_len for preset 9 is 128.
12:48:49 <Wolf01> the problem is that I don't even understand why you need to compress more the savegames
12:50:58 *** andythenorth has joined #openttd
12:54:14 <peter1138> have you built yourself a lego particle accelerator yet andythenorth?
12:54:23 <andythenorth> hasn’t everyone?
12:54:59 <andythenorth> ha it’s pretty good
12:55:01 <Samu> well, it started when i found out that openttd savegames was only using 12-13% cpu out of my 8-core cpu, decided to investigate
12:55:45 <Samu> turns out, lzma implementation in openttd doesn't support multi-thread, so i went to find other options
12:58:25 <Samu> i guess my research is pointless
13:03:55 <Samu> the task of compressing the savegame could greatly benefit from multi-thread, especially on maps sized 4096x4096
13:04:14 <Samu> but my research went into another direction... yeah, I lost focus
13:08:16 <Wolf01> is the compression done on the "game" thread or the "save" thread?
13:11:01 <Samu> Alberth said it starts a separate thread just for the compression task, not sure what that means
13:11:59 <Samu> game keeps running, while compression does its thing
13:12:20 <Wolf01> ok, then time is not a problem here
13:12:26 <Wolf01> I think the thing that should be improved is the memory-to-memory copying, maybe it could be possible to use more threads to read from the map with 256x256 chunks each one, so you should have the same time on each map size (it depends how many threads your CPU supports)
13:17:09 *** TheMask96 has joined #openttd
13:17:35 *** Myhorta has joined #openttd
13:23:02 <Eddi|zuHause> only 200 hours :p
13:35:17 <Wolf01> heh, I still haven't beat that time, I have just 140 hours summing different savegames
13:49:49 <Wolf01> I'm in that weird part of the internet again...
14:32:12 *** Supercheese has joined #openttd
14:33:55 *** Clockworker_ has joined #openttd
15:04:01 *** supermop has joined #openttd
15:12:08 *** sla_ro|master has joined #openttd
15:18:02 *** nodownload has joined #openttd
15:18:20 <nodownload> i tried downloading openttd today but i got a timeout on the downloads for all sets
15:18:24 <nodownload> anyone have a mirror?
15:19:20 <Eddi|zuHause> mirrors are linked on the main page
15:20:46 <Eddi|zuHause> hm, no, it only lists them, not with links...
15:20:53 <Eddi|zuHause> who thought that was a bright idea?
15:22:24 <Eddi|zuHause> usually <countrycode>.binaries.openttd.org
15:25:05 <nodownload> nl did pop me the TU Twente site, but no download link, just a blank page
15:25:35 <nodownload> but it works so thanks
15:28:18 <planetmaker> The mirrors don't necessarily have a browsable website
15:28:38 <planetmaker> nodownload, can you tell *which* mirror you were directed to, which one failed?
15:29:48 <nodownload> fr.binaries.openttd.org failed or timed out
16:23:56 <Samu> do you know of a file manager that can sort a list of files by the difference of date time of creation with date time of modification?
16:24:22 <Samu> (to find out which compression method took more time)
16:24:24 *** Alberth has joined #openttd
16:24:24 *** ChanServ sets mode: +o Alberth
16:31:57 <Samu> when i click save, what happens before compression starts? I noticed some big hiccup of about 4~5 seconds before compression actually takes place
16:32:53 <Samu> this part must be synced with the game
16:33:06 <Samu> any way to speed this up?
16:33:46 <Samu> Wolf01 spoke of memory copy, chunks and stuff I don't understand
16:37:17 <Samu> after this big stall, it starts "* *saving game * *" = the compression itself
16:37:55 <Samu> i used a 4096x4096 map, the stall is very noticeable here
16:39:19 <Alberth> that's a lot of tiles
16:39:45 <Alberth> Don't know the size of a single tile
16:41:32 <Eddi|zuHause> used to be 9 bytes
16:41:58 <Alberth> it still is, according to landscape.html
16:42:00 *** sim-al2 has joined #openttd
16:42:14 <Alberth> @calc 4096 * 4096 * 9
16:42:35 <Alberth> that many bytes must be copied.
16:46:57 <Samu> 167 MB (175.625.682 bytes)
16:47:09 <Samu> what could be the other 25 mbs?
16:48:51 <Alberth> chunk headers, save game versions, newgrf lists, configuration data
16:51:58 <Samu> ok, one thing I noticed, some compression methods are faster than this copying
16:52:55 <Samu> even faster if it could be multi-threaded
16:55:28 <Samu> [12:12] <Wolf01> I think the thing that should be improved is the memory-to-memory copying, maybe it could be possible to use more threads to read from the map with 256x256 chunks each one, so you should have the same time on each map size (it depends how many threads your CPU supports)
17:06:46 <Alberth> you primed the cpu cache :p
17:07:35 <Alberth> but yeah, you could try throwing several threads at copying the map
17:08:11 <Alberth> not sure if it helps, since the slow part is the memory itself
17:08:15 <Flygon_> Remember when 64k was enough?
17:08:18 *** Flygon_ is now known as Flygon
17:08:26 <Flygon> I don't. I'm too young.
17:08:38 <Flygon> But dammit! 16mbytes should be enough for any Windows computer!
17:08:44 <Alberth> 64K?? woo, I used to have 32K including the screen
17:09:15 <Alberth> which could be 20K on its own, leaving me with a whopping 12K memory :)
17:09:21 <Flygon> Well, I'm 90% sure the GBC had 64kb <_>
17:10:01 <Alberth> I had a BBC B micro computer
17:10:12 <Alberth> nice basic, and assembly language too
17:10:14 <Samu> the copying was only using 12% cpu
17:10:29 <Alberth> Samu: yep 1 of 8 cores :p
17:11:22 <Samu> the compression also, but that's another story
17:12:28 <Alberth> one thing to keep in mind is that some computers have only a single core
17:12:56 <Alberth> openttd should work there too
17:13:18 <Alberth> possibly less fast, but it should work
17:13:42 <Samu> the only tests i could do were single-threaded
17:14:27 <Samu> some compressors methods openttd have, like lzo and zlib, are faster than the 4096x4096 map copy thing
17:14:36 *** supermop has joined #openttd
17:14:48 <Samu> that means, less than 4~5 seconds
17:15:21 <Samu> (but the resulting save file is quite large)
17:15:55 <Alberth> bad if you want to send it over the network in MP :)
17:20:55 <Samu> who has ubuntu? i dont feel like installing ubuntu for this
17:21:32 <Samu> i see that ubuntu as a "ls" command that lists up to the milisecond date time of creation and date time of modification of files
17:22:12 <Samu> windows only lists up to the minute :(
17:22:25 <Alberth> "ls" is a GNU program that all Linuces have
17:23:16 <Wolf01> install the git console tools and you have a lot of unix commands in the windows' console too
17:24:32 <Wolf01> just install git for windows and select console tools too
17:25:09 <Wolf01> it even support coloring
17:27:38 <Samu> no idea what to donwload :(
17:27:59 <Alberth> "install git for windows" I think
17:28:42 <Samu> :( install with ruin windows command prompt
17:29:01 <Alberth> Samu: it says "for windows", how can it be portable? :p
17:29:20 <Samu> Git for Windows Portable ("thumbdrive edition")
17:29:45 <Wolf01> the command prompt does not change at all
17:30:13 <Wolf01> I think it will just add the path of the commands to %PATH%
17:30:59 <supermop> guy on forum is right - not enough servers with newgrfs
17:35:53 <Wolf01> btw, does somebody knows how to change the default switches to the ls command of the git command line tools? I would like "--color --full-time -h"
17:37:21 <andythenorth> some kind of git config?
17:37:28 <andythenorth> or alias it in your bash profile?
17:37:53 * andythenorth obviously doesn’t know
17:39:08 <Alberth> afaik only by making a new command, like ln (ls nice) in an alias
17:40:01 <Wolf01> ln is already for links
17:41:10 <Wolf01> I don't mean git, I mean "ls"
17:42:31 <Eddi|zuHause> i would imagine there'd be an environment variable for that
17:43:12 <Samu> look at that last answer
17:43:37 <Wolf01> only the bin folder in %PATH%
17:44:46 <Wolf01> not applicable, samu, I'm on windows and I know how to write the switches by hand, I'm just lazy :)
17:47:43 <Samu> bah, it's the stat command?
17:50:02 <Alberth> looks like it supplies enough information :)
17:50:28 <Wolf01> it seem that the only env variables are to format dates and locale for ordering
17:51:21 <Alberth> nah, dircolor definitely works too
17:52:13 <Wolf01> yes, the switches do work, I just don't want to type them every time
17:52:47 *** andythenorth has left #openttd
17:53:22 <Wolf01> I'm used to "ls -la" not to "ls -lah --color --full-time"
17:54:06 *** Wormnest has joined #openttd
17:56:03 <Eddi|zuHause> "Time stamps are listed according to the time zone rules specified by the TZ environment variable, or by the system default rules if TZ is not set. See Specifying the Time Zone with TZ in The GNU C Library Reference Manual."?
17:56:23 *** Clockworker_ is now known as BiG_Clockie_MF
17:56:39 <Wolf01> nah, I just want --color and --full-time automatically enabled
17:57:05 <Eddi|zuHause> there is definitely a variable for colour
17:58:21 <Wolf01> isn't that to change the colors used for the different entries?
18:00:19 <Eddi|zuHause> you can also probably do dos-style macros, like linux aliases
18:02:53 *** TheMask96 has joined #openttd
18:03:44 <Samu> ok i got what i wanted, now i just have to calculate this times manually
18:04:05 <Samu> and it will result the total time it took to compress
18:06:26 <Wolf01> mmmh, I don't get how to set the env vars, it does seem to ignore everything (yes I know how to set vars and that I need to open a new terminal after that)
18:07:10 <Eddi|zuHause> i can't help you with that
18:11:57 <Wolf01> bah, on linux is easy, I'll wait for the ubuntu subsystem :P
18:18:04 <Wolf01> ok back to my brainfucking session of UWP
18:18:33 *** ChanServ sets mode: +v tokai
18:22:13 <Samu> so i was wrong about lzo and zlib about being faster than memory copy
18:22:47 <Wolf01> they both work with memory, what do you expect?
18:22:58 <Samu> still calculating the rest of zlib brb
18:28:25 *** HerzogDeXtEr1 has joined #openttd
18:32:16 *** Quatroking has joined #openttd
18:32:30 *** Quatroking_ has joined #openttd
18:40:55 *** _johannes has joined #openttd
18:42:16 <Samu> hmm how much time in seconds is a day in openttd game?
18:43:48 <peter1138> autosave has no bearing in it
18:44:04 <Samu> some servers don't pause while saving
18:44:39 <Samu> would a player that joins a server wait ~75 seconds for the server to prepare a savefile to send?
18:45:03 <Samu> and then wait even more to download it?
18:46:18 <Samu> load it, play fastforward to catch up with the server which never paused
18:46:29 <planetmaker> that's what happens normally, yes
18:46:53 <Samu> what if the client also have autosave enabled ?
18:47:41 <planetmaker> why would the server mind?
18:48:06 <Samu> when fast forwarding to catch up with the server, would it trigger the autosave?
18:49:45 <peter1138> Sensible map sizes don't have these problems.
18:49:54 <Samu> when i play single player fast-forwading games, i know autosave turns down the speed to normal
18:55:03 <Wolf01> uh oh, I've done a terrible mistake... I don't know in which order are the handlers of an event executed :/
18:55:48 <Samu> gonna try something dumb
19:00:04 <Samu> hmm this error is misleading
19:00:17 <Samu> "the last 8 seconds no data from the server bla bla"
19:05:30 <Samu> disabling the autosave from the server, removes this stalling
19:08:41 <glx> saving can take a long time
19:09:18 <Samu> the stalling only happens with autosave
19:09:24 <Samu> but not when a client joins
19:09:38 <glx> because pause on join maybe
19:09:48 <Samu> ok, let me explain better
19:10:17 <Samu> server is with disabled autosave, and with 1 client in it
19:10:25 <Samu> now the other client joins the server
19:10:38 <Samu> there is still a stall, but not as significant as the autosave stall
19:10:47 <Samu> server doesn't pause on join
19:11:24 <Samu> the first client does pause briefly, but won't trigger "the last xx seconds error"
19:12:30 <Samu> with autosave enabled on the server, "last xx seconds" pops up on the client
19:13:26 <Samu> what's different between the two save methods? autosave and a client entering the server?
19:18:31 <Samu> Client #16 is dropped because it took longer than 500 ticks to join
19:18:50 <Samu> 500 ticks in real time seconds
19:21:29 <glx> ticks/s depends on cpu and game complexity
19:26:41 <Samu> hmm, there should be a time calculator for this
19:28:27 *** frosch123 has joined #openttd
19:29:26 <Samu> if my upload is 3 Mbps, the save i have to send is about 15 MB, how many seconds does it take to upload?
19:31:09 <Alberth> Mbps is Mega bits / s, ie 0.3 MB/s
19:31:29 <planetmaker> glx, OpenTTD should run at 30ticks/s
19:31:49 <planetmaker> hm, no 0.03 seconds per tick rather
19:31:57 <DorpsGek> planetmaker: 33.3333333333
19:32:21 <glx> but add some boats or many vehicles, on a big map ;)
19:32:42 <planetmaker> it will only slow down, if the cpu is insufficient for the map. Or rather the map size and vehicle count for the cpu
19:32:56 <Samu> ok, let's put 3000 ticks for download time
19:33:19 <glx> enable pause on join can help
19:34:04 <planetmaker> pause on join is required, if your server has a slow connection
19:34:17 <planetmaker> thus if the map cannot be transferred to the clients in a timely fashion
19:34:46 <planetmaker> large maps and a server run from home likely won't do the trick without a decent join time and a pause on join
19:34:53 <Samu> i need a volunteer with big download rate to join my server, see if it's enough for him to get in
19:35:45 <Samu> can only join as spectator, too many AIs in it
19:35:47 <planetmaker> well, you should know your *upload* speed and you can do some math, can you?
19:36:27 <Samu> network.max_download_time = 3000 currently
19:36:58 <planetmaker> that map is HUGE. 3 seconds for upload? Can your line handle to upload 100MB in 3 seconds?
19:36:59 <glx> and 3Mbps upload is better than usual adsl
19:37:47 <Samu> i'm trying to figure out
19:38:04 <glx> but still slower than usual adsl download
19:40:26 <Samu> max_join_time vs max_lag_time
19:40:34 <Samu> on a server that doesnt pause on join
19:41:32 <Samu> is the stalling lag accounted?
19:41:32 <glx> join is to do all actions other clients have done after save and during download
19:41:49 <glx> stalling is the server only
19:42:26 <Samu> ok, let's try some number
19:42:30 <planetmaker> Samu, my client could receive 6 MByte from you before the connection was closed
19:42:58 <planetmaker> thus the download of that map would take FAAAAAAAAAAAR longer
19:43:16 <planetmaker> and would take a time, no client ever could catch up with
19:43:28 <Samu> the save is about 12 MB, so, 3000 ticks isnt enough
19:44:31 <Samu> ok 6500 now, the catch up time is counted as max_lag_time, right?
19:45:00 <glx> catch up time is join time
19:45:17 <glx> lag time is for after catch up
19:45:46 <DorpsGek> Commit by translators :: r27536 /trunk/src/lang (belarusian.txt malay.txt) (2016-04-07 19:45:37 +0200 )
19:45:48 <DorpsGek> belarusian: 1 change by KorneySan
19:45:49 <DorpsGek> malay: 1 change by rionix88
19:46:18 *** Progman has joined #openttd
19:46:42 <glx> that's why pause on join is highly recommended
19:47:56 <Samu> planetmaker: volunteer wanted!
19:52:10 <Birko> Hello, can somebody help me with RailPathFinder? Is it possible to have source tile or goal tile on tile, where already is rail? I am trying to build rail crossing, but railpathfinder build nothing if source tile or goal tile is on tile with some rail
19:53:20 <Samu> arf, can't simulate a 3 mbps connection
20:05:03 *** MonkeyDrone has joined #openttd
20:10:12 *** sim-al2 has joined #openttd
20:12:51 <Birko> RailPathFinder expects a tile without any rail transport type?
20:16:50 *** Progman_ has joined #openttd
20:20:29 *** andythenorth has joined #openttd
20:20:36 *** Progman_ is now known as Progman
20:21:01 <andythenorth> so FIRS should check for vehicles that can arry cargos? o_O
20:21:05 <andythenorth> not sure that’s feasible eh
20:21:46 <Alberth> I tried that once in openttd c++, and failed on "not pax" like vehicles :p
20:22:16 * andythenorth won’t be trying it
20:22:42 <andythenorth> in principle it just means running the refits for all vehicles in all newgrfs, and checking each cargo is transportable somehow
20:22:52 <Alberth> at best you can detect not a known vehicle set, and warn about it
20:23:48 <Alberth> "you are not using road hog or iron horse, we recommend you use one of those" :p
20:24:14 *** Myhorta has joined #openttd
20:25:51 <supermop> include a wheelbarrow in firs
20:26:11 <supermop> refits to one unit of any cargo, moves at 3 mph
20:27:05 *** Ketsuban has joined #openttd
20:27:08 <supermop> one pax can sit in the barrow
20:27:45 <andythenorth> _could_ refit all the default vehicles
20:30:26 <supermop> just the bus, a factory worker can buy a ticket and carry a sack of grain onboard as luggage
20:31:54 <supermop> there arent any japanese road vehicles, huh
20:32:11 <andythenorth> supermop: but where do the dog and the goose sit?
20:32:16 <supermop> other than some trams in 2cc tram set
20:34:27 <supermop> bright and lit up japanese trucks in road hog?
20:34:56 <supermop> what was your previous truck endeavor andythenorth ?
20:35:06 <andythenorth> full of bad ideas
20:37:33 <supermop> Bad Ideas Renewal Set
20:38:24 *** gelignite has joined #openttd
20:51:35 <supermop> any thoughts on crane roster?
20:53:20 <andythenorth> supermop: first thought is, I need to reinstall open office?
20:54:10 <andythenorth> nah I’ve found a text editor that can read it
20:54:51 <supermop> hah should i have saved it as xls? i didnt know if you'd have office
20:55:08 <andythenorth> I’d delete 50% of it :)
20:55:28 <supermop> i'd like to cull most of the locomotives
20:55:50 <andythenorth> 23 EMUs is about 19 too many imho :)
20:56:02 <supermop> because i find differentiation in locomotives super boring esp. in this context
20:56:15 <supermop> andythenorth: japan is EMU land?
20:56:21 <andythenorth> I know, but still
20:56:43 <supermop> what do you think abt having the different categories of MUs?
20:57:06 <supermop> and having HSR as an EMU
20:59:47 <supermop> but yeah cutting half sems reasonable any ideas as to which half?
21:02:21 *** Myhorta has joined #openttd
21:07:46 <andythenorth> supermop: try giving the commuter EMUs meaningfully different stats between 1970 and 2015, that will give you part of the answer ;)
21:08:15 <supermop> have yet to think about hp/speed/capacity yet
21:08:31 <andythenorth> it starts to become obvious if you only do meaningful upgrades
21:08:47 <andythenorth> what’s the highest plausible speed for standard EMUs?
21:09:17 <supermop> just rough qualities, category A is slower than B, category B is slower loading etc
21:09:39 <supermop> in japan idk but for gameplay in general i'd say around 100mph
21:09:54 <andythenorth> I’d guess anything up to 125, you can always cheat
21:10:21 <supermop> 200 kmh is nice round number
21:10:50 <supermop> urban emus should have similar speed but improve in capacity
21:11:08 <supermop> otherwise you have to rework very tight scheduling every decade
21:11:21 <andythenorth> lowest plausible speed is 25mph, and that’s pushing it, in 1860
21:11:26 <andythenorth> I’d say 45mph is better
21:11:54 <supermop> 80kmh is the slowest i ever tolerate in a game
21:15:08 <andythenorth> smallest worthwhile increment is 10mph, 15mph is better
21:15:22 <andythenorth> 0mph is also ok, anything less than 10mph messes your network up for no gain
21:16:14 <andythenorth> capacity increases of less than 15px are tedious
21:17:32 <supermop> idea: shinkansen emu 1 door per car, express emu 2, commuter 3, metro 5
21:18:01 <andythenorth> for Iron Horse, for MUs, I can’t imagine adding anything other than single unit railcars (preferably 8/8), or twin-unit (1 tile)
21:18:10 <andythenorth> shinkansen might be another story
21:18:24 <andythenorth> or shinkansen could work like cargo sprinter, magically grows
21:18:36 <andythenorth> cargo sprinter always has just two cabs
21:18:39 <supermop> there is a cargo sprinter in IH?
21:18:59 <andythenorth> in the brit roster
21:19:06 <andythenorth> you want to do the japanese electric version?
21:19:58 <supermop> or a fictionalized version
21:21:16 <andythenorth> what is gameplay difference between express / commuter / metro EMUs?
21:22:37 <frosch123> do you agree that it should be fine to just add the default setup, when there is no information?
21:23:01 <frosch123> i.e. no custom plural/gender/case -> eints adds default plural/gender/case for language
21:23:06 <supermop> speed+comfort vs capacity+load speed
21:24:16 <andythenorth> I’d merge at least two of those together
21:25:02 <Alberth> frosch123: seems fine to me
21:25:17 <supermop> what if first emu is "commuter" and at some point commuter forks into express vs metro
21:26:13 <andythenorth> supermop: another way to look at it….you want to get the main roster (narrow gauge) into 25 or less (preferably less)
21:26:38 <andythenorth> there are easy choices to cut: remove all the diesels
21:26:47 <supermop> yeah fuck those guys
21:26:51 <andythenorth> and don’t have express electrics if this roster prefers EMUs
21:27:26 <supermop> do players need slow cheap non-electric freight?
21:27:26 <andythenorth> how early can you electrify?
21:27:42 <supermop> 1930s earliest reasonable
21:28:14 <andythenorth> if the roster is all-electric after a certain date, it’s annoying to convert a large already-built netwotk
21:29:13 <supermop> they still were pretty heavy into steam for 5-10 years after the war
21:29:32 <supermop> diesels mostly for hokkaido and kyushu
21:31:32 <andythenorth> or can off the electric locos and keep the diesels
21:31:51 <supermop> yeah im fine with that
21:33:08 <andythenorth> for freight, from 1950-2010, you can get away with 3 large (2000HP+) and 1 small diesel (1000hp or so)
21:33:15 <andythenorth> or equivalent electrics
21:33:25 <andythenorth> possibly just 2 large ones
21:33:44 <supermop> i just worry about someone starting a game in 1960 and they need a short little cheap train to pick up a small amt of cargo from a non-gungho farm
21:34:23 <supermop> andythenorth: japan effectively only had 3 diesels in that era
21:34:56 <andythenorth> is freight fast, slow, or middling?
21:35:08 <andythenorth> fast is like Iron Pony, 85mph+
21:35:25 <andythenorth> it’s narrow gauge, I’d keep it slow
21:35:37 <andythenorth> so you only really need 2 diesels for that, a big one and a small one
21:37:00 <supermop> slow light road switcher in 1950
21:37:16 <supermop> bigger carbody or switcher in 1960
21:38:14 <supermop> then maybe a more efficient small general hybrid in 2010+
21:38:41 <andythenorth> do a bi-mode loco in 1980s+
21:38:50 <Wolf01> guru question: does a service locator makes sense with named services? or I could just rely on the service class type?
21:38:56 <andythenorth> there’s code for locos to switch power by railtype
21:39:41 <supermop> andythenorth: switch running cost?
21:40:27 <andythenorth> I would ignore DMUs
21:40:47 <andythenorth> maybe something like single-unit electric railcars, slow, 8/8 long, refittable to express cargos
21:41:01 <andythenorth> and 2 unit high capacity + high speed
21:41:32 <andythenorth> it might be interesting to make capcity and speed a tradeoff but dunno
21:41:43 <andythenorth> often it’s nice to just have a train that is clearly boss
21:42:24 <andythenorth> Iron Horse has some tradeoffs, between railtypes
21:42:24 <supermop> do people ever need single diesel railcars in late game?
21:42:58 <Samu> darn, i was never good at math
21:43:05 <andythenorth> otherwise IH works on the ‘one obvious engine choice’ idea
21:43:10 <supermop> need a "japanese" house set with both dense cities and tiny villages
21:43:28 <supermop> otherwise just metro everywhere
21:44:38 <supermop> i need to come up with cute names?
21:45:02 <andythenorth> and much less roster
21:45:14 <andythenorth> also figure out wagon generations
21:45:24 <andythenorth> we tried 2 for Iron Pony, and it wasn’t enough
21:46:52 <supermop> trade offs in wagon stats?
21:48:20 <andythenorth> just choose the one you like most for this cargo
21:48:32 <andythenorth> there are a few oddiities, like metal cars are slow, and intermodal is fast
21:48:41 <andythenorth> some types have ‘express’ speeds
21:49:00 <andythenorth> otherwise similar capacity per tile, and uniform speeds per generation
21:52:40 <supermop> thats "diesel 4" on concept list
21:53:48 <supermop> 1000 hp too low for the "big" diesel
21:55:58 <supermop> both switchers or more interesting to have one as carbody?
21:59:59 <supermop> small one 700 or 1000 hp?
22:53:35 *** Wormnest has joined #openttd
23:00:27 <Samu> after some maths, lzma at preset 2, outputs an average of 989159 bytes per second for my cpu. this is ideal for connections of about 8 Mbps
23:01:23 <Samu> my connection is 3 Mbps for upload, and that means... preset 4
23:01:50 <Samu> is it possible to allow moar server customization?
23:02:48 <Samu> preset 5 compresses slower than my upload is capable of
23:03:25 <Samu> do you understand my request?
23:06:19 <Samu> preset 4 compressed at an average of 511836 bytes per sec. 3 Mbps upload is equal to 384000 bytes per sec
23:06:46 <Samu> if talking about servers, it's a bit redundant to compress too fast if the upload rate can't keep up
23:07:16 <Samu> that in turn could be used to use a stronger compression preset
23:07:34 <Samu> ends up in a smaller file to upload
23:23:41 *** Alkel_U3 has joined #openttd
23:24:14 <Wolf01> Samu, Mbps is in bits not bytes, I'm connected at ~4Mbps and I download at 420-460KBps (bytes)
23:26:31 <Wolf01> np, I read one 0 too much, I'm tired
23:30:22 <Wolf01> I finally got rid of a stupid null reference error... it was because of self referencing code in the service instantiation :|
23:31:31 <Wolf01> because it's natural to ask for a service while you are instantiating it (it was more subtle)... I can't even understand how it didn't end in infinite recursion
23:38:28 *** Hiddenfunstuff has quit IRC
continue to next day ⏵
