IRC logs for #openttd on OFTC at 2018-05-06
⏴ go to previous day
01:28:45 *** chomwitt has joined #openttd
02:07:48 *** rocky1138 has joined #openttd
02:15:10 *** ArtemVorotnikov[m] has joined #openttd
02:16:49 *** ArtemVorotnikov[m] is now known as vorot93
02:26:01 <vorot93> I've started skimming through the code and what strikes me is how modern C++ features and stdlib are underused. For instance, an otherwise simple `GRFText` class which is full of custom allocation code for dealing with underlying `char[]`. Is there a particular reason for this except for the code having been written in pre-modern C++ era?
02:36:10 <Eddi|zuHause> mostly it's because the code is old
02:57:58 <vorot93> (also the fact that a class is both declared and defined in .cpp)
03:03:57 *** ToBeFree has joined #openttd
04:32:23 *** Thedarkb-X40 has joined #openttd
04:43:24 *** muffindrake3 has joined #openttd
07:15:17 *** sla_ro|master has joined #openttd
07:22:47 *** Wacko1976 has joined #openttd
08:28:26 *** andythenorth has joined #openttd
08:40:11 *** sla_ro|master2 has joined #openttd
08:50:50 *** HerzogDeXtEr has joined #openttd
09:54:52 *** Progman has joined #openttd
09:56:43 *** gelignite has joined #openttd
10:02:55 <Pikka> "when the train stops at a signal, something is happening, but the running cost is weirdly blinking between smoe two values"
10:04:23 <Pikka> but who uses non-path signals anyway? ;)
10:05:26 <nielsm> standard block signals sort-of make sense to use along a line without junctions? and just use path signals when you have splits
10:05:41 <nielsm> at least I've seen claims that using path signals for that uses more cpu
10:06:08 <nielsm> (which matters if you're on a server on a cheap shared hosting)
10:07:39 <LordAro> well they're definitely "more expensive"
10:07:58 <LordAro> but i've never seen any actual evidence that they're a significant factor
10:09:36 *** Maraxus has joined #openttd
11:10:51 *** Wacko1976 has joined #openttd
11:16:14 <Eddi|zuHause> i don't think that claim has ever been conclusively proven
11:30:45 *** Wormnest has joined #openttd
12:00:04 *** andythenorth_ has joined #openttd
12:02:03 *** chomwitt has joined #openttd
12:16:48 *** andythenorth_ has joined #openttd
13:08:49 <Pikka> it's not sunny here but
13:16:51 <michi_cc> Hmm, slight bummer with low-level DirectMusic... Feeding raw MIDI was actually easier than expected (except some tiny hickups with stopping), but the whole point would be to allow the DMusic synth to be used.
13:17:46 <michi_cc> And that synth is a DLS synth which needs a DLS download. And the DLS loading code is not part of the low-level stuff, which means a custom DLS file parser. Joy.
13:18:40 <nielsm> I think you still wouldn't get the reverb effects either
13:19:00 <nielsm> I think you need to manually insert and control some effect DMOs in the sound path for those
13:19:46 <michi_cc> Otherwise, the raw DirectMusic API is probably the superior MIDI API as it works with timestamped midi messages.
13:20:14 <nielsm> hm well winmm also has the midiStreamOut API which takes timestamped messages
13:20:24 <nielsm> but the docs for it confused me
13:20:41 <nielsm> so was easier to use the direct
13:21:15 <michi_cc> nielsm: Nope, that seems to be the synth itself. You can use the low-level API and only the high-level DLS reader and get the same sound. It's just not part of 64-bit windows or the current SDK headers.
13:21:45 <nielsm> but I think it's better to just make an open source softsynth work properly on windows
13:22:04 <nielsm> since MS is still marking all of dmusic as deprecated and threatening with removing it
13:24:44 <michi_cc> Yeah, but it can't be that deprecated. DirectMusic was initially not implemented at all for 64-bit, but MS then later added parts of with Windows 7. You wouldn't do that just for fun.
13:35:43 *** andythenorth has joined #openttd
13:42:28 <nielsm> the drums are cleaner and the slapped bass better defined than the MS synth DLS recordings, but mostly the effects on the MS synth are actually excessive IMO
13:42:46 <nielsm> so no need to be that much up in arms over it ;)
13:45:50 <andythenorth> I love it when people obsess over details :)
13:47:09 <nielsm> nobody who isn't obsessive over details would still bother with TT :)
13:50:34 *** Stimrol has joined #openttd
14:07:00 *** sla_ro|master2 has quit IRC
14:16:34 *** chomwitt has joined #openttd
14:38:35 <Eddi|zuHause> midi sounded really awesome on my SoundBlaster AWE32 back then
14:39:24 <Eddi|zuHause> unfortunately i have no computer where it fits in anymore
14:39:54 <Eddi|zuHause> i don't suppose there's PCI-E to ISA adapters?
14:42:18 <peter1138> Back in the day you'd have multiple audio channels for mixing, wavetable synth, OPL FM synth, digital effects...
14:42:38 <peter1138> Now they just expect the CPU to do it all.
14:43:00 <Eddi|zuHause> back in the day you'd have to manually fiddle with IRQ settings
15:37:52 <andythenorth> Wolf01: rebase NRT? o_O
15:38:03 <andythenorth> or one giant patch?
15:38:51 <Wolf01> New repo + one giant patch could help to clean up things
15:39:49 <andythenorth> have you got a new Openttd/Wolf?
15:40:31 <Wolf01> Yes, but I rebased every branch I had
15:41:57 <Wolf01> I was working on a new repo for NRT to make it like in 2-3 distinct commits, so it could be merged to master in different steps
15:42:13 <andythenorth> would be stupid to delete that :)
15:42:26 <Wolf01> You could rename it NRT-depr
15:42:41 <andythenorth> well I'll at least add notes
15:46:02 *** frosch123 has joined #openttd
15:50:27 <Wolf01> So, I think it's time to have a breakfast... I ate too much yesterday and only now I can feel again I'm hungry
15:53:53 <andythenorth> @calc (119/2)/24
15:53:53 <DorpsGek> andythenorth: 2.47916666667
15:54:10 <andythenorth> I can draw 2 trains per hour, Horse will take time :P
16:04:30 <peter1138> Is that including \ | and / views? :p
16:04:53 <peter1138> Plus doubling up for assymmetric wagons.
16:08:30 <andythenorth> it's including all of that
16:09:30 <andythenorth> it also includes all of the time restarting openttd :)
16:09:40 <andythenorth> and rebuilding my lost saves
16:31:33 *** Wacko1976 has joined #openttd
16:42:56 <Eddi|zuHause> why restart? isn't it enough to reload_newgrfs?
16:46:44 <andythenorth> it crashes a lot
16:46:49 <andythenorth> either cleanly, or not
16:47:15 <andythenorth> ottd really hates the grf changing on disk under it
16:48:28 <Eddi|zuHause> yeah, if you let the game unpaused while you change it.
16:48:55 <Eddi|zuHause> but if you reload_newgrf, and didn't change any vehicle lengths or whatnot, it should work
16:50:08 <Eddi|zuHause> (that implies a few assumptions like stable vehicle IDs between compiles)
16:50:52 <Eddi|zuHause> but that should cover all your drawing concerns
16:55:05 <LordAro> feel like it should be able to cope a bit better than hard crashing anyway
16:57:20 <frosch123> nml unlinks the file, before writing the new grf
16:57:38 <frosch123> so unless andy has a custom cp/install in place, i have no idea why ottd should crash
16:58:48 <andythenorth> I have a make install target
16:59:00 <frosch123> then i would blame it on that one :)
16:59:01 <andythenorth> which might be exactly the cause
16:59:16 <andythenorth> it crashes hard, even sometimes when the change is just a pixel
17:00:46 <frosch123> andythenorth: try adding "--remove-destination" to the cp
17:00:53 <frosch123> but no idea how standard that is
17:00:57 <frosch123> it may be a gnu extension
17:01:05 * andythenorth reading about it
17:02:45 <Eddi|zuHause> andythenorth: i just have a symlink to my development file
17:03:08 <andythenorth> seems --remove-destination isn't in macOS cp
17:03:25 <Eddi|zuHause> then add "rm $destination"
17:03:44 <andythenorth> might not be what I want
17:03:45 <Eddi|zuHause> that sounds wrong
17:04:03 <Eddi|zuHause> that's probably "ignore readonly" and stuff
17:05:53 <andythenorth> so what's the underlying reason to rm first?
17:06:01 <andythenorth> I don't like cargo culting stuff :)
17:06:21 <frosch123> the difference is between replacing the file with a new one
17:06:39 <frosch123> or replacnig the content of the file
17:06:41 <andythenorth> is someone about to say 'inode'? o_O
17:06:42 <Eddi|zuHause> openttd will not try to read the changed file, but will retain a (hidden) link to the old file, while you write the new file
17:07:06 <Eddi|zuHause> the old file will be deleted when openttd drops the file handle (on "reload_newgrf") or close
17:07:45 <Eddi|zuHause> i wasn't going to, the concept of inode is even another level deeper
17:07:58 <andythenorth> we have similar issues with web apps on production servers
17:08:09 <andythenorth> they don't always release a file cleanly, with varying results
17:09:06 <Eddi|zuHause> well, you could have all sorts of fractal problems there :p
17:10:34 <andythenorth> occasionally a file looks released, but some process is still writing to it, so the disk fills
17:11:08 <Eddi|zuHause> you know about "lsof"?
17:11:21 *** Thedarkb has joined #openttd
17:11:23 <Eddi|zuHause> might help debugging that problem
17:11:43 <andythenorth> I only have to witness it being solved :)
17:11:54 <andythenorth> other people know about lsof
17:12:10 *** synchris has joined #openttd
17:15:44 <andythenorth> I've made that change in makefiles ,thanks
17:22:31 <andythenorth> should help a lot
17:55:02 <DorpsGek> andythenorth: 5.33333333333
18:01:17 *** nahkiss has joined #openttd
18:29:17 *** Guest1915 has joined #openttd
18:29:22 <Guest1915> who ruined this game?
18:29:32 <Guest1915> by ruined, I mean, implemented terraforming limits
18:29:53 <Guest1915> how do I turn this bs off?
18:30:04 <LordAro> it's been there for at least 5 years
18:30:17 <LordAro> and pretty sure there's a setting anyway
18:30:19 <Guest1915> strange because I haven't noticed in 2015
18:30:37 <Guest1915> I typed in "terraforming" in settings search and it's not popping up
18:31:48 <Guest1915> <Guest1915> by ruined, I mean, implemented terraforming limits
18:31:55 <Guest1915> I can't level a mountain
18:31:57 <nielsm> I've never bumped into anything limiting how much landscaping I can do
18:32:38 <LordAro> yeah, looks like it's not in the gui
18:33:00 <LordAro> terraform_frame_burst
18:33:07 <LordAro> alternatively, just wait a bit
18:33:26 <LordAro> or do it in smaller chunks
18:34:47 <Guest1915> I can't wait 543980 years before I make 1 train line, cmon :/
18:35:05 <nielsm> then change the limit in the config file
18:35:25 <nielsm> I think it's a setting to limit griefing potential in multiplayer games, mainly?
18:36:40 <Guest1915> terraform_per_64k_frames, is that it?
18:36:57 <LordAro> or just wait 64k frames :p
18:37:05 <Guest1915> I will set this to -1
18:37:10 <nielsm> 64k frames is how much...
18:37:15 <Guest1915> I will write a patch set that removes this bs
18:37:16 <DorpsGek> LordAro: 864.864864865
18:37:29 <LordAro> Guest1915: yoi're being silly
18:38:00 <Guest1915> sorry if I came up rough, but this is majorly griefing my openttd experience
18:38:19 <Guest1915> rest asured the patch will be just for myself
18:38:36 <LordAro> why on earth do you need a patch then?
18:38:41 <LordAro> it's got a config setting
18:38:49 <LordAro> surely that is simpler
18:40:59 <LordAro> not sure i've ever actually seen anyone (who wasn't griefing) hit that limit before anyway
18:41:46 <Guest1915> me trying to level a mountain just so I can establish a maglev that doesn't have to ride up and down has hit that limit
18:43:32 <LordAro> doesn't look like a huge mountain, i wonder if that setting hadn't been set to a lower value than default
18:43:34 <nielsm> (not like the maglev train would actually be slowed by the presence of the mountain)
18:43:52 <LordAro> ^ unless original acceleration model
18:44:49 <Guest1915> I am on the original accel model
18:46:18 <nielsm> anyway, as far as I can tell, the terraform_frame_burst setting in the cfg file controls how many tiles-permitted-to-modify you get per tick
18:47:30 <nielsm> but just be aware that internally it's handled as an uint32 and for some reason values are shiftes 16 bits left
18:48:18 <LordAro> Rubidium was original implementer, iirc
18:49:14 <nielsm> introduced between version 1.0 and 1.1
18:50:20 <Rubidium> nielsm: easy, values are 'per 64k ticks', so shift back by 16 bits and you got the value per tick
18:50:38 <Rubidium> after all 64k (in this instance) == 2**16
18:51:44 <Rubidium> also, with both settings at their maximum value you have to be really really good at your "job" to even trigger it
18:52:43 <LordAro> nielsm: ah, 7 years then :p
19:07:03 <Borg> Orginal accel model?!!! wtf?!!
19:48:40 <peter1138> How dare you ruin the game!
20:04:43 *** Progman has joined #openttd
20:08:06 *** andythenorth has joined #openttd
20:15:36 <Eddi|zuHause> yeah, how dare you ruin the game retroactively 7 years ago, and nobody, even him, noticed
20:22:22 <andythenorth> otherwise ignore :P
20:28:35 <peter1138> Shows you how much I play the game, cos I've never seen it.
20:28:44 <peter1138> Mind you I don't flatten mountains.
20:29:34 <andythenorth> and I play maybe 10 games per year
21:10:32 * andythenorth wonders how long narrow gauge wagons should be
21:10:56 <andythenorth> 'small' standard gauge are 4/8
21:14:45 <andythenorth> probably not good in corners though
21:29:43 *** sla_ro|master has joined #openttd
21:32:52 *** gelignite has joined #openttd
21:46:49 <andythenorth> 3/8 is kind of nice
21:46:55 <andythenorth> but doesn't make nice integer lengths
21:50:18 <V453000> well then I guess if NG has to be smaller, 3/8 it iz
21:50:30 <V453000> that's crazy small though, make sure you start with \ / :P
21:50:55 <andythenorth> 2/8 is even worse
21:51:07 <frosch123> make wagons with 3 articualted parts
21:51:15 <frosch123> than fake the 9/8 into 8/8
21:51:35 <andythenorth> because capacity per wagon is so low
21:58:56 <andythenorth> 10t per wagon eh
22:14:16 <V453000> Pikka: moar trainz? :)
22:14:56 <Pikka> if I can stop fiddling with the AI for ten minutes
22:16:16 <andythenorth> is it done yet? o_O
23:14:22 <andythenorth> it's also untidy :P
23:30:21 <Pikka> 4/8 makes better integer trains? :P
23:31:25 <andythenorth> I just need to draw better
23:31:31 <andythenorth> so it looks nice
continue to next day ⏵
