IRC logs for #openttd on OFTC at 2019-12-19
⏴ go to previous day
00:00:03 <hythlodaeus> well what I'm gonna do is to download the english language file, do all the fixes there and then submit a PR with it
00:00:33 <Eddi|zuHause> hythlodaeus: to make a PR, you have to make a github account, and clone the repository
00:00:44 <hythlodaeus> i have a github account
00:01:25 <Eddi|zuHause> you can then edit your clone of the repository, and then push that as a PR
00:01:51 <hythlodaeus> btw, my suggestion is we change all "Ctrl/Shift toggles" to "Ctrl/Shift+Click" since the latter is more specific
00:02:40 <Eddi|zuHause> sounds fine to me
00:07:48 * andythenorth wonders whether to drop randomised cargo sprites for, e.g. flat wagons
00:07:48 <andythenorth> they're not actually used currently, just supported in code
00:07:51 <andythenorth> with no negative effect on current gameplay :P
00:09:15 <Eddi|zuHause> 0.5MB source code or compiled grf?
00:09:58 <Eddi|zuHause> doesn't sound like a useful metric
00:10:11 <andythenorth> it's a vanity project
00:10:27 <glx> usually smaller nfo means smaller grf
00:10:30 <andythenorth> so far it has not reduced compile time or compiled grf size
00:10:50 <andythenorth> but I think it's worth continuing
00:11:18 <glx> but you have many nfo files merged for you grf IIRC
00:20:25 <andythenorth> ok bedtime, thanks for help glx
00:20:37 <glx> thanks for the real testing :)
00:22:02 *** asymptotically has quit IRC
00:22:44 <hythlodaeus> STR_RAIL_TOOLBAR_TOOLTIP_BUILD_RAILROAD_SIGNALS :{BLACK}Build railway signals. Ctrl toggles semaphore/light signals{}Dragging builds signals along a straight stretch of rail. Ctrl builds signals up to the next junction or signal{}Ctrl+Click toggles opening the signal selection window. Shift toggles building/showing cost estimate
00:22:46 *** supermop_work has joined #openttd
00:22:59 <hythlodaeus> good example of poor writing IMO
00:23:13 <hythlodaeus> I think this should be something like
00:23:57 <glx> this string has been updated multiple times I think
00:30:27 <hythlodaeus> {BLACK}Build railway signals.{}When a signal type is selected, ctrl+click switches between semaphore/light versions respectively{}Click+Drag builds signals along a straight stretch of rail.{}Ctrl+Click+Drag builds signals up to the next junction or signal{}Ctrl+Click on a placed signal switches between signal types. Shift+click shows costs estimate without making a purchase.
00:30:37 <hythlodaeus> this is my proposed edit
00:58:59 <glx> what slow stuff are you doing Eddi|zuHause ?
00:59:23 <Eddi|zuHause> it's rebuilding the raid, for some reason
01:06:01 <planetmaker> <andythenorth> hmm I am banned from coop pastebin <-- in what way that?
01:06:39 <Eddi|zuHause> andy has the weirdest way to break things...
01:12:16 <planetmaker> <glx> we delete the old translation if it's really incompatible <-- indeed. But that's always a complete manual thing done by the PR authors or committers
01:13:09 <glx> yeah it's not automatic, and it's a good thing :)
01:14:06 <planetmaker> as to the english string of STR_RAIL_TOOLBAR_TOOLTIP_... the suggestion sounds better to me. But... I'm not a native speaker
01:15:33 <planetmaker> While possible to make a PR for a single string, including some more nice-to-have changes (if there are any) to the English lang file might be desirable
01:15:57 <glx> I think the idea was to fix other strings too
01:17:02 <planetmaker> Once upon a time I made that more consistent for German, too... gotta check... and German still needs translations for some strings for 1.10
01:22:36 *** supermop_work has joined #openttd
01:28:18 <Eddi|zuHause> oh damn, i realized why it made a full rebuild... i told it to add /dev/sdf, instead of /dev/sdf1
01:29:19 <DorpsGek_III_> [OpenTTD/nml] glx22 updated pull request #66: Add: allow use of switches and random switches as procedures https://git.io/JePq0
01:34:40 <DorpsGek_III_> [OpenTTD/nml] LordAro commented on pull request #66: Add: allow use of switches and random switches as procedures https://git.io/Je54g
02:04:52 *** supermop_work has joined #openttd
02:05:08 <planetmaker> I think LordAro has a point with the comment
02:21:45 <glx> hmm but that doesn't work
02:28:49 <Eddi|zuHause> yeah, you need something that appends
02:30:00 <Eddi|zuHause> lika reduce() or something
02:30:44 <planetmaker> list(v.blah for v in self.value)
02:42:29 *** supermop_work has joined #openttd
02:53:16 <Eddi|zuHause> functools.reduce(list.append, ...)
02:54:21 <Eddi|zuHause> or maybe append is not the right one
02:55:13 <Eddi|zuHause> hm, should be correct
03:11:13 <Eddi|zuHause> oh, extend it is
03:11:41 <Eddi|zuHause> functools.reduce(list.extend, <whatever lordaro wrote)>
03:18:02 *** Thedarkb-X40 has joined #openttd
03:25:58 <Eddi|zuHause> yeah, that probably makes things easier
03:26:04 <DorpsGek_III_> [OpenTTD/nml] ldpl commented on pull request #66: Add: allow use of switches and random switches as procedures https://git.io/Je5BQ
03:31:56 *** Wormnest_ has joined #openttd
03:32:49 <_dp_> reduce or map(extend) should be quite efficient too though
03:34:32 <Eddi|zuHause> at that point you might question whether that is really clearer than the existing code
03:37:31 <_dp_> yeah, especially in python 3
03:37:45 <_dp_> better to do for than list(reduce()) or list(map())
03:38:18 *** supermop_work has joined #openttd
03:38:31 <glx> from itertools import chain
03:38:31 <glx> return list(chain.from_iterable(v.collect_references() for v in self.values))
03:44:07 <glx> hmm and it seems windows "broke" my python setup again
04:28:50 *** ChanServ sets mode: +v tokai
04:50:17 <DorpsGek_III_> [OpenTTD/nml] glx22 updated pull request #66: Add: allow use of switches and random switches as procedures https://git.io/JePq0
04:51:21 <Eddi|zuHause> hey, i got my github device verification code... like 1 hour later
04:52:17 <glx> I use google authenticator for that
04:55:01 <Eddi|zuHause> glx: i set it up so if i click on random linkx in chat, it opens in a private window, meaning no login cookies and stuff
04:57:21 *** Wormnest_ has joined #openttd
05:07:55 *** Wormnest__ has joined #openttd
06:59:59 <Pikka> I just realised I'm going to have to go through a whole "can wagon be attached" rigmarole for AI newgrf passenger trains
07:04:16 <Pikka> and say that allowing vehicles which won't connect to each other to be built in the same depot is a bug in the grf ;)
07:16:22 *** sla_ro|master has joined #openttd
07:27:23 *** andythenorth has joined #openttd
07:27:36 *** D-HUND is now known as debdog
07:30:41 *** sla_ro|master has joined #openttd
09:10:22 *** tokai|noir has joined #openttd
09:10:22 *** ChanServ sets mode: +v tokai|noir
11:01:02 <Eddi|zuHause> <Pikka> I just realised I'm going to have to go through a whole "can wagon be attached" rigmarole for AI newgrf passenger trains <-- there's an AI role property, but when i pointed to that during NoAI development, they just told me off like "we don't need that stuff, our AIs should be intelligent enough"
11:02:05 <Eddi|zuHause> also, cb 18(?) was only ever implemented for stations
11:05:38 <DorpsGek_III_> [OpenTTD/OpenTTD] planetmaker commented on issue #7865: Train auto replace and replace engine if old https://git.io/Je525
11:07:26 <DorpsGek_III_> [OpenTTD/OpenTTD] planetmaker closed issue #7865: Train auto replace and replace engine if old https://git.io/Je525
11:12:21 *** Progman has joined #openttd
11:19:14 <Pikka> Eddi|zuHause, well I checked and IH doesn't actually have connection limits (although it looks a bit funny putting full-sized coaches behind metro locos)
11:19:34 <Pikka> and IH and UKRS3 are the only train grfs I really care about supporting ;)
11:20:08 <Pikka> definitely a bad feature to limit consist construction (or require certain consist lengths or whatever else)
11:21:23 <Eddi|zuHause> yeah, if you care about consist length, then code it as an MU (though that has other problems)
11:27:09 <Corns[m]> curious: i heard floats are danger zone for lockstep multiplayer since theres different standards for float math, but aren't doubles fine?
11:34:26 <DorpsGek_III_> [OpenTTD/OpenTTD] nielsmh commented on issue #7865: Train auto replace and replace engine if old https://git.io/Je525
11:36:43 <Eddi|zuHause> Corns[m]: no, doubles are still prone to rounding differences between computer architectures
11:37:21 <Corns[m]> Eddi|zuHause: hecc, how do other lockstep games manage float/doubles?
11:37:42 <Corns[m]> Eddi|zuHause: hecc, how do other lockstep games manage float/doubles?
11:38:19 <Eddi|zuHause> dunno about other games. OpenTTD doesn't allow floats/doubles inside the game logic
11:40:24 <Eddi|zuHause> in openttd, every client calculates the game state on its own, and occasionally a checksum is shared which should detect whether the game state is still the saem
11:40:48 <Eddi|zuHause> other option would be, that only the server makes game state calculations, and distributes that to the client
11:41:11 <Eddi|zuHause> which won't have restrictions on float/double, but may have bigger problems with ping times
11:42:08 <Eddi|zuHause> this is, however, impractical for games like openttd, as the game state is huge and not easily transferred
11:53:14 <Corns[m]> ah i see, but how do similar games e.g. factorio, manage to use implement movement (e.g. with vehicles)?
11:54:02 <peter1138> Check their source code.
11:54:26 <peter1138> But if they don't use floating point for it, then that particular concern is irrelevant.
11:55:16 <Corns[m]> time to crack open the *.exe and decipher some obfuscated source
11:59:06 <Corns[m]> i've dived into a rabbit hole of floating point determinism and fixed point maths
12:00:32 <Eddi|zuHause> there's some other options, like you could pick a programming language that guarantees that floats are always rounded the same, but that means their compiler probably won't actually generate floating point operations as it cannot rely on the FPU
12:00:45 <Corns[m]> okay so, from what i've gathered, there is a deterministic IEEE754-compliant mode for some compilers but the performances is much worse
12:01:17 <Eddi|zuHause> or you can live with a certain amount of desync, as long as you have some metric of how big this desync is, and implement rubberbanding if it gets too large
12:02:04 <Corns[m]> rubberbanding in trunk openttd :^)
12:04:37 <Corns[m]> just asking 'cause i'm curious about the imprecision with diagonal vehicle movement - whether it can be fixed or improved, or even if it needs to be fixed/improved at all
12:05:18 <Eddi|zuHause> that can certainly be improved without floats
12:06:36 <michi_cc> Corns[m]: The values used in original TT might have been chosen so you can calculate the movement just with shifts and adds/subs in a time when division was expensive.
12:06:38 <Eddi|zuHause> that's how it is implemented currently. might get away with tweaking some dividers
12:06:59 <michi_cc> On any current CPU, integer divisions aren't much of a problem anymore.
12:07:19 <Corns[m]> ah yeah i remember reading smth about that in the source comments
12:07:49 <michi_cc> Except if you're dealing with some trimmed down embedded CPU that explicitly omits division hardware.
12:08:29 <Eddi|zuHause> michi_cc: it'll probably be division by constant, though, and modern compilers won't really generate division operations for those
12:15:54 <Corns[m]> oh, i'm also curious about separating sim/render thread, although i'm probably far from knowing enough to wrap my head around that
12:17:39 <Corns[m]> q: so the multiplayer game runs in lockstep - how is this handled with client processors of different speed?
12:17:50 <Corns[m]> yeah i heard its a huge, almost impossible undertaking
12:18:05 <Corns[m]> - to implement separate threads for that
12:18:08 <LordAro> Corns[m]: runs at the speed of the slowest client
12:18:15 <peter1138> Fast clients wait. Slow clients get dropped eventually.
12:18:34 <peter1138> All computers run at different speeds.
12:20:03 <peter1138> It's not like every instruction is synchronized, that's frame level.
12:20:09 <peter1138> Gametick, I suppose.
12:20:54 <Eddi|zuHause> basically the server sends out a message "it's ok now to proress to tick #X"
12:21:44 <Eddi|zuHause> and any client that lags more than Y ticks behind will have to give up
12:22:41 <Eddi|zuHause> 's a net_frame_freq, but i'm not 100% sure what that does
12:52:27 <DorpsGek_III_> [OpenTTD/OpenTTD] kiwitreekor updated pull request #7575: Feature: Add industry production graph https://git.io/fjc3i
13:01:46 <DorpsGek_III_> [OpenTTD/OpenTTD] kiwitreekor updated pull request #7575: Feature: Add industry production graph https://git.io/fjc3i
13:19:44 <DorpsGek_III_> [OpenTTD/OpenTTD] kiwitreekor updated pull request #7575: Feature: Add industry production graph https://git.io/fjc3i
13:21:13 *** snail_UES_ has joined #openttd
13:30:34 <planetmaker> Corns[m], afaik factorio handles it pretty similar to OpenTTD
13:31:32 <Corns[m]> so the usual multiplayer scenario is that the clients wait - in that case it would be detrimental to halve the sim step to 16ms? for 60hz?
13:32:18 <Eddi|zuHause> you wouldn't want to have the display rate synchronized to the network code
13:36:39 <planetmaker> Corns[m], not sure it's "usual". There's the two different concepts eddi mentioned.
13:37:02 <planetmaker> But server's either send out state and in all cases have to confirm actions initiated by players
13:37:46 <planetmaker> thus updates/s is somewhat unrelated to frames/s
13:38:43 <Corns[m]> oh boy i'm trying to wrap my head around this
13:39:11 <Corns[m]> when does the server send out state updates? (and the updates are just a list of actions made since the last state?)
13:41:02 <planetmaker> for OpenTTD: you only get the full state once (when joining the server via savegame). Then you only get input as in what is action is initiated by what company at which time. All the rest is deterministic.
13:41:53 <planetmaker> thus every player sends his commands (intended actions) to the server. Which sends them back to every connected client with the timestamp (tick) at which they are being executed
13:42:15 <planetmaker> And only then they are executed by every client. At the exact time step (=tick)
13:43:01 <planetmaker> To ensure that everyone always has the same state, a checksum is sent by the client regularily to the server. It will check that checksum to match its own. And it will kick the client when it does not match (desync error)
13:58:56 *** ChanServ sets mode: +v tokai
13:59:28 *** Sheogorath has joined #openttd
13:59:41 *** ToBeCloud_ has joined #openttd
13:59:41 *** ToBeCloud_ is now known as ToBeFree
14:00:08 *** y2kboy23_ has joined #openttd
14:00:15 *** innocenat__ has joined #openttd
14:01:40 *** super_sp1oky has joined #openttd
14:02:29 *** WormnestAndroid has quit IRC
14:02:29 *** colde_ is now known as colde
14:02:29 *** ToBeFree is now known as ToBeCloud
14:02:30 *** innocenat__ is now known as innocenat_
14:02:36 *** mikegrb_ has joined #openttd
14:02:59 <Corns[m]> ahh sweet :) ty for explaining
14:06:23 <Corns[m]> at the moment, the sim updates at 30hz by default right
14:06:40 <Corns[m]> and the game renders at...60hz?
14:07:04 <Corns[m]> or at least panning the map feels like 60hz while the trains look like they move at 30hz
14:07:24 <Samu> I've been thinking wether more 'world generation' settings should be listed under settings
14:07:40 <Samu> sometimes I wish they were there
14:08:47 <Samu> map size, number of towns, sea level
14:09:26 <Corns[m]> oh yeah why are some world gen settings in one place and some are in another?
14:09:35 <Samu> map edges would be tricky
14:10:37 <Eddi|zuHause> hysterical raisins
14:11:13 <Corns[m]> hysterical....raisins
14:12:29 <Samu> custom number of towns would also be a bit tricky
14:21:15 *** WormnestAndroid has joined #openttd
14:30:51 <planetmaker> @Corns[m], unless something dramatically changed, then with OpenTTD the game renders at the same speed as the updates per second
14:31:22 <Corns[m]> oh, even GUI and panning? so 30fps?
14:32:49 <Corns[m]> nvm it is indeed 30fps
14:32:54 <Corns[m]> i've been deluding myself
14:33:01 <planetmaker> I'd believe so, yes. Maybe in some cases GUI is de-coupled from ups. But definitely fps are not higher than 30fps
14:33:16 <planetmaker> there's a fps viewer ingame
14:34:23 <Corns[m]> yeah - i noticed on win10 that changing the blitter seems to help drastically with render speed
14:34:46 <Corns[m]> also disabling animations - are animations tied to sim speed as well?
14:35:28 <milek7_> Eddi|zuHause: >but that means their compiler probably won't actually generate floating point operations as it cannot rely on the FPU
14:35:36 <milek7_> actually I think that all relevant architectures implement IEEE754
14:35:52 <milek7_> the problem is only with compiler reordering operations, intermediary register precision, etc.
14:35:55 <planetmaker> so actually OpenTTD's default fps is 33/s
14:36:10 <planetmaker> or rather: one update every 30ms
14:36:14 <Eddi|zuHause> milek7_: that's not the point. IEEE754 allows for some leeway, which is the problem
14:37:47 <planetmaker> yes, animations are tied to sim speed
14:38:10 <planetmaker> it's a bad design choice IMHO. But hard to reverse for what is there now
14:38:32 <Corns[m]> what has to be done to resolve that?
14:38:46 <Eddi|zuHause> nothing will ever be done to resolve that
14:38:54 <Corns[m]> i'd like to see openTTD @ 60fps, but that's a broad goal with lots of implications
14:39:16 <milek7_> leeway in what? reordering, register size selection, are compiler job
14:39:17 <Eddi|zuHause> because things like newgrf callbacks cannot be decoupled from sim speed
14:39:18 <planetmaker> I'm pretty convinced that eddi is right there... animation is partially tied to game state
14:39:42 <Corns[m]> e.g. 15ms sim step is twice as much effort to calculate and will be detrimental for slower clients or more complex games
14:39:48 <planetmaker> thus in order to de-couple that you'll need to introduce the possibility for NewGRFs to show animation which has no gamestate influence
14:40:18 <Corns[m]> so...newGRFs animations are tied to sim state?
14:40:25 <planetmaker> which in turn means that you never know at which state in an animation you are... you loose the option to query it
14:40:46 <Eddi|zuHause> animation state gets abused for arbitrary storage in some places
14:40:47 <Corns[m]> -and some rely on that for whatever they need
14:41:11 <planetmaker> houses being build or changing over time. That's animation states being used
14:41:11 <Eddi|zuHause> nobody will ever touch that with a long pole
14:41:38 <planetmaker> (or it's an option which is being exercised by various newgrfs)
14:41:39 <LordAro> good ol hysterical raisins
14:41:40 <Corns[m]> house build progress is tied to its animation state....
14:41:52 <Corns[m]> instead of being internally stored
14:41:57 <Corns[m]> oh fair, for storage efficiency
14:42:06 <milek7_> "Some of the things that are guaranteed are the results of addition, subtraction, multiplication, division, and square root. The results of these operations are guaranteed to be the exact result correctly rounded"
14:42:32 <Corns[m]> oh yeah i skimmed through that
14:42:33 <LordAro> such is the way when you have a game with 25 years of history
14:43:34 <Corns[m]> would we lose anything by changing that convention?
14:43:34 <LordAro> and perhaps mostly, it was originally programmed in assembly, and initial modifications only built on that, rather than started from scratch
14:43:48 <Corns[m]> i.e. decoupling animations from sim state
14:43:53 <Corns[m]> or decoupling render from sim
14:44:00 <milek7_> (I'm not actually arguing that using determinism in floats is actually easy, just to point out that compilers are causing most problems, not FPU itself)
14:44:07 <LordAro> could leave animation state as is (just don't use it for drawing anything) and add a no_really_this_draws_pictures state
14:44:31 <LordAro> but you'd still need some sort of translation layer
14:45:01 <planetmaker> Adding a new animation option which does not influence state would not hurt and definitely is an option
14:45:07 <Eddi|zuHause> milek7_: "the C/C++ standards don’t actually mandate IEEE floating-point math." <-- and with that sentence your whole argument collapses
14:45:09 <Corns[m]> yeah for save transition
14:45:09 <planetmaker> which would also not be too terribly difficult.
14:45:21 <planetmaker> But removing the existing... would break things in various places
14:45:35 <planetmaker> and thus won't happen
14:45:52 <planetmaker> OpenTTD never transitions anything... it only adds.
14:45:58 <Corns[m]> -unless somebody really tries
14:46:19 <Eddi|zuHause> also "IEEE 754-2008" <-- 11 years isn't really a timeframe where i expect a standard to be widely enough adopted to rely on it
14:47:45 <planetmaker> Corns[m], I don't think you can actually remove the existing animation. Not sure one can actually turn it into visual-only animation... I haven't looked at it close enough. A very hard feat at least, though
14:48:05 <planetmaker> Removing that feature of existing animation: that won't fly, however you try
14:57:03 <Eddi|zuHause> milek7_: so far i read nothing in there that would change my mind
14:57:27 <Corns[m]> planetmaker: oh boy but id only want to implement that as a stepping stone to decoupled render
14:58:28 <Corns[m]> Unless u do the classic microsoft embrace, extend, exterminate
14:59:08 <Corns[m]> I guess I'll look at something that i can at least fit on my plate
14:59:41 <Eddi|zuHause> Corns[m]: i'm fairly convinced that anything other than palette animation will have to stay on the simulation side of that divide
15:00:14 <Corns[m]> Wait like, having different colour palettes per wagon? Or company colours
15:00:16 <Eddi|zuHause> so, treat an animation step the same way as you would treat a movement step
15:00:34 <Eddi|zuHause> Corns[m]: like palette animation
15:00:41 <Eddi|zuHause> Corns[m]: like water/fire animation
15:01:03 <Corns[m]> I...kinda understand
15:01:50 <Eddi|zuHause> there's also a per-sprite colour remap in some places, that is not what i mean
15:02:30 <Corns[m]> Is that like, how some newGRFs have random wagon cosmetics?
15:02:52 <Eddi|zuHause> that is like whe draw company colours
15:03:47 <Eddi|zuHause> wagon cosmetics are usually completely different sprites
15:04:13 <Eddi|zuHause> but they can also have palette remaps
15:05:08 <Eddi|zuHause> e.g. the GermanRV set has different sets of colour remaps for various cargos, so coal and ore use the same sprite, but different colours
15:07:15 <Corns[m]> I'll try to understand what palette remaps are
15:07:28 <Corns[m]> Ok so i vaguely understand sprites as individual images
15:07:34 <Corns[m]> And they can have one or more areas for colour mapping, e.g. train engines with company colours
15:07:36 <Corns[m]> Um idk the openttd specific jargon for each thinh
15:07:39 *** HerzogDeXtEr has joined #openttd
15:09:54 <Eddi|zuHause> in 8bpp mode, the sprites are "indexed", so instead of "this pixel is red", the sprite knows "this pixel has the palette index 28". before rendering, this palette entry 28 is mapped to an RGB value
15:10:24 <Eddi|zuHause> the palette remap can change "instead of entry 28, draw 35 instead"
15:10:56 <Eddi|zuHause> in 32bpp mode, each sprite has a separate layer, which defines which areas can be recoloured
15:13:06 <Eddi|zuHause> i've never looked at any of these processes in detail, though
15:14:29 <Corns[m]> Oh i see (re 8bpp mode)
15:15:29 <Eddi|zuHause> Corns[m]: the palette animation, however, works on the other part, it changes index 28 to be different RGB values at different times. the sprite won't be told about this
15:16:32 <Corns[m]> 32bpp,layers like in photoshop? And then the recolour just applies to an entire layer?
15:16:50 <Eddi|zuHause> Corns[m]: yeah, pretty much
15:17:17 <Corns[m]> Oh nice, so like those buildings with flashing signs?
15:17:48 <Eddi|zuHause> yes, the theatore, stadium, etc.
15:18:05 <Corns[m]> Thats a neat trick :)
15:18:50 <Eddi|zuHause> that's a fairly standard trick in the late 80s/early 90s, before GPUs and shaders were a thing
15:23:49 <Corns[m]> Thats pretty cool :)
15:24:16 <Corns[m]> Would a conventional modern equivalent just be to draw a new sprite for each frame?
15:24:43 <Corns[m]> And just...bake it into the texture, or smth
15:25:46 *** frosch123 has joined #openttd
15:26:13 *** supermop_work has joined #openttd
15:30:16 <Corns[m]> Wait so whats most responsible for the holdup with fast forward + all animations?
15:31:34 <Eddi|zuHause> Corns[m]: mostly that palette animation is not supported by hardware these days, and needs to be reimplemented with shaders
15:38:10 <Corns[m]> The more i learn, the less i feel like i know about graphics in game dev
15:40:11 <planetmaker> that's a good sign :)
15:41:05 <frosch123> the factorio blog writes about graphics every now and then
15:41:23 <frosch123> but that is very different to ottd's 90's stuff
15:43:46 <FLHerne> That sort of implementation would be the way to give OTTD 'modern' graphics
15:44:46 <FLHerne> Actually, reading the blurb, I'm not sure it works how I'd expected
15:45:24 <Corns[m]> Also didnt TTD for PS1 have 3d graphics?
15:48:04 <FLHerne> I've seen screenshots, but no idea how that worked
15:49:12 <Eddi|zuHause> probably just cheap and dirty conversion
15:49:27 <Eddi|zuHause> it's not like we could use any of that for anything
15:55:49 <Corns[m]> The assets would be useful at least, right
15:58:18 <Eddi|zuHause> we have no license to redistribute them anyway
15:58:37 <Eddi|zuHause> and they don't cover all the TTD stuff, i believe
15:58:54 <Eddi|zuHause> and they look horrible by todays standards
15:59:52 <Eddi|zuHause> between pixel-retro and ultra-realistic, they fall in the uncanny valley
16:03:55 <Corns[m]> Yeah youre right, it is indeed a really crude time
16:08:03 *** WormnestAndroid has quit IRC
16:09:25 *** WormnestAndroid has joined #openttd
16:09:57 *** WormnestAndroid has joined #openttd
16:10:47 <Samu> not stored in saves is a lie
16:11:50 <Corns[m]> I guess its only used at world gen, and you cant change it mid save
16:12:46 <Corns[m]> So it belongs in the same category as, say, tree generation?
16:15:02 *** WormnestAndroid has joined #openttd
16:16:15 *** WormnestAndroid has quit IRC
16:16:21 <planetmaker> Samu, write the real value, thus 256 instead of 2^8
16:16:28 *** WormnestAndroid has joined #openttd
16:17:28 <planetmaker> even when the stored value is 8. There can be a difference between display and value. If need be, make it a selection list with like 7:128, 8:256, 9: 1024 etc
16:20:50 <planetmaker> samu, that is: apply identical treatment like the minimum and maximum zoom levels are being treated
16:21:33 *** sla_ro|master has joined #openttd
16:25:01 <milek7_> gamepad controls are pain to use in TT..
16:36:31 <Eddi|zuHause> suggest better ones?
16:37:14 <Samu> there's some weird settings, map x and map y for example, aren't stored in saves as a game setting, but it's still stored as a load_check chunk
16:39:39 <milek7_> i mean these in PSX port
16:42:06 <frosch123> wait, you have tt for ps?
16:42:41 <milek7_> just downloaded iso, on emulator
16:42:53 <frosch123> what do industries look like?
16:43:12 <frosch123> i always wondered how they rotate the non-square irregular industry shapes
16:43:20 <frosch123> or whether they are entirely different
16:52:32 <frosch123> thanks, so i actually made separate 3d models for everything
16:52:52 <frosch123> i definitely did not expect that
16:53:10 <frosch123> *they made separate models
16:55:14 <frosch123> the stadium looks just fine, way more vertices than i expected
16:56:13 <Samu> there's a weird bug with custom sea level
16:56:27 <Samu> but the minimum value is 2%
16:56:48 <Samu> how does openttd decides then?
17:00:44 <frosch123> oh dear, ever since 1&1 was fined for weak data security on their phone hotline, they keep sending mails telling everyone about their new password schema
17:01:00 <frosch123> i think i got 4 mails in 6 days about that
17:01:35 <Samu> According to static const uint CUSTOM_SEA_LEVEL_MIN_PERCENTAGE = 1; ///< Minimum percentage a user can specify for custom sea level.
17:01:46 <Samu> minimum of 2 is wrong then
17:13:51 *** Wormnest__ has joined #openttd
17:39:01 <DorpsGek_III_> [OpenTTD/OpenTTD] James103 commented on pull request #7730: Change: Use vehicle model age for station rating calculation https://git.io/Je51b
17:43:07 <nielsm> I don't dislike that idea ^^
17:44:01 <frosch123> hmm, i wanted to write down a newgrf proposal
17:44:22 <frosch123> idea was to allow newgrf to set the coolness of a vehicle independent of speed
17:44:36 <frosch123> which would include control over the 2 year thing
17:45:10 <nielsm> a callback for a vehicle to return its awesome-factor?
17:45:41 <nielsm> then the vehicle can decide whether it's awesine because it was introduced recently, or because it was built recently, or because the player painted it gold
17:46:11 <frosch123> yes, but it could also do stuff like "salon van available in train"
17:46:36 <frosch123> or safety supplied by proper caboose van
17:50:20 <Eddi|zuHause> what this doesn't address is the thing about coolness station rating, where only the last vehicle counts, not the best one
17:50:53 <Eddi|zuHause> so for mixed local and long-distance stations, only the stupid frequent local trains count
17:53:15 <nielsm> yeah you'd have to make the station use the last perhaps 10 vehicles to visit within the last 3 months, or something like that
17:53:24 <nielsm> and then either average or max
17:58:51 <FLHerne> Does anyone know what's responsible for the "WARNING: 1 shift/reduce conflict" message when generating the nml parser in debug mode?
17:59:20 <FLHerne> I can see from parser.out that it's something to do with the precedence of binops
17:59:51 <FLHerne> But none of the changes I thought would fix it did :P
17:59:54 <frosch123> i know that message from using flex&bison, but i never noticed it in nml
18:00:58 <frosch123> how do i make nml show that warning?
18:01:39 <glx> you need to modify the source
18:03:06 <frosch123> i get no message when running the nml tests
18:03:47 <Eddi|zuHause> FLHerne: usually means there's some unintended ambiguity in the grammar
18:04:59 <FLHerne> Eddi|zuHause: I know what it means, I just can't pin it down :P
18:05:04 <frosch123> i set "debug" to True, but still no message
18:05:19 <FLHerne> Eddi|zuHause: I tried changing the precedence of various ops, but that just shuffles the problem
18:05:22 <glx> hmm you need to force rebuild of the parser
18:06:29 <FLHerne> I think also set `optimize=False` if that's not set?
18:06:51 <FLHerne> (sorry, afk for a while)
18:07:20 <glx> yes optimize=False will rebuild I think
18:09:10 <Samu> okay, i only have a problem with map size
18:09:40 <Samu> it's not stored in saves, which isn't true, but it's also true
18:09:45 <frosch123> i also need write_tables=False apparently
18:10:31 <Samu> if i load a savegame, the map size x and map size y that I get is that of my newgame settings, and not what's in the save
18:11:00 <Samu> what I get displayed, the map loads correctly
18:12:18 <DorpsGek_III_> [OpenTTD/nml] glx22 updated pull request #71: Add: nmlc option to force regeneration of parser tables https://git.io/Jeyxo
18:13:57 <glx> maybe we can also add an option to enable parser debug
18:15:51 <frosch123> it's related to "spritegroup"
18:18:39 <frosch123> now at "spriteview"
18:18:52 <frosch123> maybe i should look up what that actually is :p
18:19:04 <Eddi|zuHause> the main problem is that this error probably doesn't show up at the point where it is caused
18:19:43 <frosch123> yes, that's why you remove random stuff until it no longer shows up, and then readd stuff until it shows up again
18:21:08 <glx> (to see if the option I'm adding works)
18:21:38 <frosch123> i use the regression tests, but i think that stuff is run before the nml file is read, so it does not matter
18:23:38 <frosch123> aw, coop paste does not work for me either
18:24:41 <planetmaker> hm... how does "does not work" materialize?
18:25:05 <frosch123> can you create a new paste?
18:26:07 <frosch123> FLHerne: glx: however, i do not see how expression can start with LBRACKET
18:36:54 <glx> hmm I can't trigger the warnings
18:37:18 <frosch123> + debug=True, optimize=False,
18:37:20 <frosch123> + write_tables=False,
18:37:25 <frosch123> ^ i have those values
18:44:12 <frosch123> i do not know enough about nml's parsertree
18:44:25 <glx> oh I needed to delete parsetab.py
18:44:28 <frosch123> so not sure whether SpriteView should learn about Array
18:45:03 <frosch123> glx: i also did that somewhen, but hard to tell what finally triggered it :p
18:45:51 <glx> basically it uses parsetab.py unless something changed in parser, so I couldn't trigger it
18:55:02 <DorpsGek_III_> [OpenTTD/nml] glx22 updated pull request #71: Add: nmlc option to force regeneration of parser tables https://git.io/Jeyxo
19:02:31 <glx> frosch123: I don't see an other possible solution, because 'LBRACKET expression_list RBRACKET' is an expression
19:02:51 <Samu> Your IP address is listed as a malicious IP.
19:03:29 <frosch123> yes, for the production rule it is the right solution, i am just not happy about the isinstance
19:03:44 <frosch123> first creating an array and then disassembling it again
19:04:57 <glx> other option would be to split p_array I guess
19:05:29 <frosch123> or to make SpriteView accept an Array
19:07:01 <glx> probably better to use a group and set each side separately
19:07:36 <milek7_> curious, emulators can render with resolution higher than native
19:08:02 <glx> you can dissociate the container and the display
19:09:04 <Eddi|zuHause> other solution would be to exclude array literals from expression
19:09:58 <Eddi|zuHause> and then re-add them to the places that actually accept them
19:10:22 <Eddi|zuHause> which might be somewhat more involved than those 5 lines
19:10:34 <frosch123> grammars with less rules are better :)
19:10:36 <Eddi|zuHause> but a lot cleaner overall
19:11:23 <frosch123> no, adding type information (array, not array) into the grammar makes it a lot less cleaner
19:11:31 <glx> yeah the grammar is already complex with () used for function_call and template_usage
19:11:45 <Eddi|zuHause> frosch123: essentially what you're doing is doing something that would now be semantic analysis in the syntactic analysis
19:12:21 <frosch123> no, i replaced a special array into a standard array
19:12:48 <Eddi|zuHause> yes, but you're deconstructing that array again
19:13:03 <frosch123> i already said that
19:13:07 <Eddi|zuHause> which would be better suited in the semantical analysis
19:14:12 <glx> oh I think the parser does that in other places
19:14:57 <milek7_> no MIDI on PS, it plays PCM audio from disc
19:15:38 <frosch123> from what year is that ps port? why does rct not use that tech
19:16:15 <nielsm> because chris sawyer is (was?) a person who insisted on writing all game code himself, in assembly
19:16:20 <glx> probably an outsourced port
19:16:33 <nielsm> the psx port is really a complete reimplementation
19:16:45 <nielsm> (unless they wrote a transpiler from x86 to mips)
19:17:00 <milek7_> "PLAYSTATION VERSION by Digital Amusement Ltd"
19:17:47 <frosch123> so they reimplemented the whole code, and they recreated all the artwork in the same style?
19:18:15 <nielsm> the tree sprites in that screenshot seem to perhaps be copied
19:18:23 <nielsm> along with the sprite font
19:18:40 <frosch123> check the video from earlier, the trees change when rotating
19:18:49 <frosch123> the only "sprite" i noticed was the oil refinery flame
19:19:23 <nielsm> ah, the trees seem to be two billboards perpendicular (X shape from above)
19:26:33 <Samu> STR_CONFIG_SETTING_TERRAIN_TYPE_HELPTEXT :(TerraGenesis only) Hilliness of the landscape
19:26:40 <Samu> this is not entirely true
19:27:10 <Samu> original landscape can change terrain type of temperate and toyland, but not select alpinist
19:27:40 <Samu> tropical and arctic have this setting locked
19:46:16 <Samu> STR_CONFIG_SETTING_NUMBER_TOWNS_CUSTOM_HELPTEXT :When the setting above is set to 'Custom', the value set here is the tentative number of towns that are generated
19:46:43 <Samu> Starting year needs a description
20:02:05 *** supermop_work has joined #openttd
20:10:19 *** Maarten has joined #openttd
20:41:40 <Samu> nobody wants to describe starting year?
20:45:31 <Wolf01> Hmmm, no man's sky 19.49€, good price?
20:57:44 <Samu> map size x and map size y are bugged
20:58:01 <frosch123> it contains neither lego nor trains
20:58:07 <Samu> don't know how to fix it
20:58:19 <Samu> map edges is just too ugly :(
20:59:21 <Samu> map_x and map_y aren't stored as a game setting :(
20:59:44 <Samu> they're stored in a different way that can't be retrieved via settings.cpp
21:00:09 <nielsm> yes they are just a property of the loaded world
21:00:22 <nielsm> and parameters given to the world gen routines
21:02:59 <Wolf01> Ha, patch for transport fever 2
21:05:06 <nielsm> "Fixed modern headquarters appearing too early" oh
21:06:34 <Samu> what would happen if I force map_x and map_y to be saved?
21:09:57 <Wolf01> "Added Set line - New line feature" backported from TF1
21:10:20 <Wolf01> Also cargo load ratio IIRC
21:10:28 <nielsm> I think they had that as early as in train fever at launch
21:10:37 <Wolf01> Why not put them directly from the beginning
21:10:56 <Wolf01> "Improved in-game settings (show all options)" ha!
21:11:38 <Wolf01> Maybe now you should be able to change the hotkeys without quitting and reloading
21:25:04 *** gelignite has joined #openttd
22:29:49 *** hythlodaeus has joined #openttd
22:30:41 <hythlodaeus> STR_WATERWAYS_TOOLBAR_CREATE_LAKE_TOOLTIP :{BLACK}Define water area.{}Make a canal, unless Ctrl is held down at sea level, when it will flood the surroundings instead
22:30:49 <hythlodaeus> is this string still being used?
22:31:00 <hythlodaeus> i cannot find it anywhere. not in-game, not in the editor
22:33:03 <frosch123> it's in the scenario editor
22:34:21 <frosch123> toolbar -> waterway -> first button from left
22:36:08 <frosch123> the tooltip of the toolbar button is a bit silly though :p "build ship docks" should be "build waterways"
22:36:31 <frosch123> both construction bars in game and in editor use "waterway" in their caption
22:36:44 <frosch123> hythlodaeus: can you add that to your english-review pr?
22:39:41 <hythlodaeus> I'm also thinking of renaming ship depots as shipyards
22:39:50 <hythlodaeus> because there's no such thing as ship depots
22:40:03 <hythlodaeus> or rather, there are, and they're named shipyards
22:40:32 <frosch123> shipyards is weird, it's not only for construction
22:40:40 <frosch123> boathouse only works for small ships
22:40:49 <frosch123> drydock would be on land
22:40:54 <planetmaker> Boats are build and serviced at shipyards. IMHO
22:41:10 <planetmaker> which... have wet- and drydocks :)
22:43:27 <hythlodaeus> planetmaker: exactly
22:44:01 <hythlodaeus> hence why I think shipyard is a better name than ship depot
22:44:42 <planetmaker> I'd leave that change out from that PR for now, though
22:44:50 <planetmaker> even though I agree
22:47:14 <hythlodaeus> man, capitalization is all over the place in the english original
22:47:53 <hythlodaeus> Sometimes you have stuff like Build roads written as Build Roads and vice versa
22:48:03 <hythlodaeus> there's little coherence
22:54:43 <Samu_> map edges is still too ugly, I'm unsure yet how to solve that
22:55:20 <hythlodaeus> STR_CONFIG_SETTING_SEA_LEVEL_HELPTEXT has a period on the final sentence. I thought the standard is that periods never go into the final sentence
22:55:31 <Samu_> oh, sorry, i can fix that
22:56:42 <hythlodaeus> STR_CONFIG_SETTING_ROUGHNESS_OF_TERRAIN_HELPTEXT :(TerraGenesis only) Choose the frequency of hills: Smooth landscapes have fewer, more wide-spread hills. Rough landscapes have many hills, which may look repetitive
22:56:47 <hythlodaeus> I don't like this description
22:57:18 <frosch123> yeah, looks like some "newer" texts forgot that rule
22:57:41 <frosch123> "newer" meaning "for 7 years" :p
23:00:42 <hythlodaeus> "Set the frequency of hills on the terrain." would be enough for the description
23:00:55 <hythlodaeus> everything else is sort of self-evident
23:01:32 <frosch123> i think that was the text in the past, but noone understood what it did. thus it was made more explicit
23:04:02 <hythlodaeus> Let me make it more explicit: Terrain Roughness - Sets the amount of hills on the map
23:06:24 <frosch123> why do you avoid the explicit warning about the extreme values?
23:06:57 <frosch123> ottd has many settings and players often pick extreme values (like 4kx4k maps), which often result in the game not working as well
23:15:15 <frosch123> in this case "repetitive"
23:17:15 <hythlodaeus> Because that's more of an aesthetic thing than necessarily a game changing/game breaking effect
23:17:26 <hythlodaeus> at least from what I understand
23:17:53 <hythlodaeus> terrain being a little repetitive wouldn't warrant a warning IMO
23:18:38 <frosch123> well, i consider the "very rough" terrain so terrible, that one could argue to remove that setting value :p
23:19:00 <hythlodaeus> then that's what should be done
23:19:24 <frosch123> the helptext is the compromise :)
23:19:34 <hythlodaeus> if a setting makes the game unplayable, it shouldn't really be allowed to be taken that far
23:19:46 <hythlodaeus> I have similar feelings towards snow lines, given they prevent farms
23:20:43 <planetmaker> and allow forests
23:20:46 <hythlodaeus> it's impossible to play on a fully ice covered environment because cities need food to grow and there's no farms
23:20:56 <hythlodaeus> forests do grow on the snowline IIRC
23:21:22 <planetmaker> no land on level 0 :)
23:21:58 <hythlodaeus> ah you mean sea level?
23:22:35 <planetmaker> Yet I'm with frosch: leaving out descriptions and warnings just because it seems evident to you... sounds dangerous. Evident to one is opaque to another
23:23:13 <planetmaker> And settings may usually be ... undesirable but useful for edge cases. Thus a word of warning w/o removing its existence is useful
23:24:18 <planetmaker> It's generally very dangerous to assume that ones view is universal and should account for what other people please should like, too. And consider sane, too
23:24:49 <planetmaker> That's why we have zillions of settings :)
23:26:31 <milek7_> these helptexts are not shown in new game window anyway ;P
23:26:38 <hythlodaeus> that's very bad for polishing and presentation though and it makes customising ultimately more confusing
23:26:54 <planetmaker> milek7_, mouse-over?
23:27:21 <frosch123> quite likely that the newgame window never made it that far
23:27:22 <hythlodaeus> I'm more for keeping options sane and help texts concise but clear. a player should not have to warned about every little thing that might go wrong
23:27:27 <frosch123> many attempts, none finished
23:27:48 <milek7_> planetmaker: nothing shows up
23:28:32 <planetmaker> right click? There's a setting how they are triggered :)
23:29:04 <frosch123> planetmaker: not all buttons have tooltips in that gui
23:29:46 <milek7_> seems that only climate miniatures and map size shows tooltip
23:30:00 <frosch123> it was probably in some wip, that never made it
23:35:13 <Samu_> any ideas how to present the map edges
23:35:29 <planetmaker> you mean water vs. free-form?
23:35:31 <Samu_> the real value is a number from 0 to 16
23:37:05 <Samu_> a dropdown with 17 items, all reading alike, is very confusing
23:37:43 <planetmaker> it's a 4-times yes/no value. Saved in one var. Either as enumeration with like Freeform: - | N | NW | NWS | NE | NES | ... or better as separate buttons yes/no
23:38:07 <planetmaker> like... done in newgame UI
23:38:39 <Samu_> but that settings_gui.cpp is very general
23:39:13 <Samu_> i would have to treat the reading of some settings differently
23:40:02 <Samu_> and the 4 settings would have to exist in settings.ini
23:40:41 <planetmaker> it would be sufficient to do something special for the UI
23:40:49 <planetmaker> no need for separate settings
23:41:19 <planetmaker> after all: it works that way in the new map UI :) So... why not elsewhere?
23:42:22 <hythlodaeus> omg that dropdown
23:43:01 <frosch123> hehe, there is a reason why not all settings are in the tree :p
23:43:08 <frosch123> all the difficult ones were left out
23:43:42 <planetmaker> and the newgame ones are the ones which suck
23:44:36 <frosch123> there are also some from the game options
23:44:54 <frosch123> and of course gs and newgrf settings are also separate
23:45:04 <frosch123> though they could be added as top-level nodes
23:45:07 <glx> only 1 setting is ok, it can be split on display
23:45:10 <planetmaker> nevertheless, I share the desire to actually consolidate them into one settings screen
23:46:32 <planetmaker> or maybe it's not necessary to consolidate them into one. But to offer a more streamlined new-game flow where you can configure everything when you hit 'new game'
23:46:37 <frosch123> i think there was the idea to allow "custom widgets" in the tree, like the 4 button-thingie for water edges, but a lot of work to support that
23:47:10 <planetmaker> currently you need to have done 90% config in 4 other windows before hitting new game on main screen
23:47:15 <frosch123> planetmaker: i think the conclusion was, that the tree should feature all settings, while the mapgen gui duplicates those that need to be set at game start
23:48:35 <glx> map edge should be representable as a subtree
23:53:59 <Samu_> gonna sleep, will continue tomorrow
continue to next day ⏵
