Log for #openttd on 19th December 2019:
Times are UTC Toggle Colours
00:05:43  *** hythlodaeus has quit IRC
00:06:01  <planetmaker> <andythenorth> hmm I am banned from coop pastebin <-- in what way that?
00:06:39  <Eddi|zuHause> andy has the weirdest way to break things...
00: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
00:13:09  <glx> yeah it's not automatic, and it's a good thing :)
00:13:20  <planetmaker> I fully agree :)
00: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
00: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
00:15:57  <glx> I think the idea was to fix other strings too
00: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
00:22:36  *** supermop_work has joined #openttd
00: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
00:28:44  <glx> oups
00:29:19  <DorpsGek_III_> [OpenTTD/nml] glx22 updated pull request #66: Add: allow use of switches and random switches as procedures
00:34:40  <DorpsGek_III_> [OpenTTD/nml] LordAro commented on pull request #66: Add: allow use of switches and random switches as procedures
00:52:50  *** supermop_work has quit IRC
01:04:52  *** supermop_work has joined #openttd
01:05:08  <planetmaker> I think LordAro has a point with the comment
01:05:36  <glx> yes I'm looking at that
01:14:32  *** Progman has quit IRC
01:21:45  <glx> hmm but that doesn't work
01:24:33  <glx> it makes a list of lists
01:28:49  <Eddi|zuHause> yeah, you need something that appends
01:30:00  <Eddi|zuHause> lika reduce() or something
01:30:44  <planetmaker> list(v.blah for v in self.value)
01:34:15  <glx> same effect
01:37:05  *** supermop_work has quit IRC
01:42:29  *** supermop_work has joined #openttd
01:53:16  <Eddi|zuHause> functools.reduce(list.append, ...)
01:54:21  <Eddi|zuHause> or maybe append is not the right one
01:55:13  <Eddi|zuHause> hm, should be correct
02:11:13  <Eddi|zuHause> oh, extend it is
02:11:41  <Eddi|zuHause> functools.reduce(list.extend, <whatever lordaro wrote)>
02:11:59  *** Wormnest_ has quit IRC
02:12:42  *** supermop_work has quit IRC
02:18:02  *** Thedarkb-X40 has joined #openttd
02:20:24  <_dp_> sum works on lists
02:24:28  *** SpComb has joined #openttd
02:25:58  <Eddi|zuHause> yeah, that probably makes things easier
02:26:04  <DorpsGek_III_> [OpenTTD/nml] ldpl commented on pull request #66: Add: allow use of switches and random switches as procedures
02:31:56  *** Wormnest_ has joined #openttd
02:32:49  <_dp_> reduce or map(extend) should be quite efficient too though
02:34:32  <Eddi|zuHause> at that point you might question whether that is really clearer than the existing code
02:37:31  <_dp_> yeah, especially in python 3
02:37:45  <_dp_> better to do for than list(reduce()) or list(map())
02:38:18  *** supermop_work has joined #openttd
02:38:31  <glx>         from itertools import chain
02:38:31  <glx>         return list(chain.from_iterable(v.collect_references() for v in self.values))
02:38:37  <glx> that works fine
02:44:07  <glx> hmm and it seems windows "broke" my python setup again
03:08:30  *** supermop_work has quit IRC
03:19:21  *** D-HUND has joined #openttd
03:22:42  *** debdog has quit IRC
03:24:15  *** Wormnest_ has quit IRC
03:28:50  *** tokai has joined #openttd
03:28:50  *** ChanServ sets mode: +v tokai
03:35:35  *** tokai|noir has quit IRC
03:48:17  *** Thedarkb-X40 has quit IRC
03:50:17  <DorpsGek_III_> [OpenTTD/nml] glx22 updated pull request #66: Add: allow use of switches and random switches as procedures
03:51:21  <Eddi|zuHause> hey, i got my github device verification code... like 1 hour later
03:52:17  <glx> I use google authenticator for that
03: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
03:57:21  *** Wormnest_ has joined #openttd
04:07:55  *** Wormnest__ has joined #openttd
04:14:44  *** Wormnest_ has quit IRC
04:16:30  *** glx has quit IRC
04:31:07  *** snail_UES_ has quit IRC
04:44:14  *** Wormnest__ has quit IRC
05:05:26  *** HerzogDeXtEr has quit IRC
05:59:30  <Pikka> ugh
05: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
06:00:02  <Pikka> damn bad features
06:03:42  <Pikka> OR
06:03:53  <Pikka> I could just ignore it
06: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 ;)
06:16:22  *** sla_ro|master has joined #openttd
06:27:23  *** andythenorth has joined #openttd
06:27:36  *** D-HUND is now known as debdog
06:30:20  *** sla_ro|master has quit IRC
06:30:41  *** sla_ro|master has joined #openttd
06:49:18  <andythenorth> o/
08:09:01  <Pikka> o/
08:10:22  *** tokai|noir has joined #openttd
08:10:22  *** ChanServ sets mode: +v tokai|noir
08:11:17  <andythenorth> lo bob
08:11:20  <andythenorth> keeping warm
08:11:22  <andythenorth> ?
08:17:18  *** tokai has quit IRC
08:25:41  <Pikka> mildly!
08:28:56  *** andythenorth has quit IRC
09:58:08  <DorpsGek_III_> [OpenTTD/OpenTTD] tbajcsi opened issue #7865: Train auto replace and replace engine if old
10: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"
10:02:05  <Eddi|zuHause> also, cb 18(?) was only ever implemented for stations
10:02:48  <peter1138> :D
10:05:38  <DorpsGek_III_> [OpenTTD/OpenTTD] planetmaker commented on issue #7865: Train auto replace and replace engine if old
10:07:26  <DorpsGek_III_> [OpenTTD/OpenTTD] planetmaker closed issue #7865: Train auto replace and replace engine if old
10:12:21  *** Progman has joined #openttd
10:19:13  <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)
10:19:34  <Pikka> and IH and UKRS3 are the only train grfs I really care about supporting ;)
10:20:08  <Pikka> definitely a bad feature to limit consist construction (or require certain consist lengths or whatever else)
10:21:23  <Eddi|zuHause> yeah, if you care about consist length, then code it as an MU (though that has other problems)
10: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?
10:34:26  <DorpsGek_III_> [OpenTTD/OpenTTD] nielsmh commented on issue #7865: Train auto replace and replace engine if old
10:36:43  <Eddi|zuHause> Corns[m]: no, doubles are still prone to rounding differences between computer architectures
10:37:21  <Corns[m]> Eddi|zuHause: hecc, how do other lockstep games manage float/doubles?
10:37:42  <Corns[m]> Eddi|zuHause: hecc, how do other lockstep games manage float/doubles?
10:38:19  <Eddi|zuHause> dunno about other games. OpenTTD doesn't allow floats/doubles inside the game logic
10: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
10:40:48  <Eddi|zuHause> other option would be, that only the server makes game state calculations, and distributes that to the client
10:41:11  <Eddi|zuHause> which won't have restrictions on float/double, but may have bigger problems with ping times
10:42:08  <Eddi|zuHause> this is, however, impractical for games like openttd, as the game state is huge and not easily transferred
10:53:14  <Corns[m]> ah i see, but how do similar games e.g. factorio, manage to use implement movement (e.g. with vehicles)?
10:54:02  <peter1138> Check their source code.
10:54:26  <peter1138> But if they don't use floating point for it, then that particular concern is irrelevant.
10:55:16  <Corns[m]> time to crack open the *.exe and decipher some obfuscated source
10:59:06  <Corns[m]> i've dived into a rabbit hole of floating point determinism and fixed point maths
11: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
11: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
11: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
11:02:04  <Corns[m]> rubberbanding in trunk openttd :^)
11: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
11:05:18  <Eddi|zuHause> that can certainly be improved without floats
11:05:49  <Corns[m]> fixed point math?
11: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.
11:06:38  <Eddi|zuHause> that's how it is implemented currently. might get away with tweaking some dividers
11:06:59  <michi_cc> On any current CPU, integer divisions aren't much of a problem anymore.
11:07:19  <Corns[m]> ah yeah i remember reading smth about that in the source comments
11:07:49  <michi_cc> Except if you're dealing with some trimmed down embedded CPU that explicitly omits division hardware.
11: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
11: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
11:17:33  <peter1138> Haha
11:17:39  <Corns[m]> q: so the multiplayer game runs in lockstep - how is this handled with client processors of different speed?
11:17:50  <Corns[m]> yeah i heard its a huge, almost impossible undertaking
11:18:05  <Corns[m]> - to implement separate threads for that
11:18:08  <LordAro> Corns[m]: runs at the speed of the slowest client
11:18:15  <peter1138> Fast clients wait. Slow clients get dropped eventually.
11:18:34  <peter1138> All computers run at different speeds.
11:18:46  <Corns[m]> indeed
11:20:03  <peter1138> It's not like every instruction is synchronized, that's frame level.
11:20:09  <peter1138> Gametick, I suppose.
11:20:54  <Eddi|zuHause> basically the server sends out a message "it's ok now to proress to tick #X"
11:21:44  <Eddi|zuHause> and any client that lags more than Y ticks behind will have to give up
11:22:25  <Eddi|zuHause> there
11:22:41  <Eddi|zuHause> 's a net_frame_freq, but i'm not 100% sure what that does
11:52:27  <DorpsGek_III_> [OpenTTD/OpenTTD] kiwitreekor updated pull request #7575: Feature: Add industry production graph
12:01:46  <DorpsGek_III_> [OpenTTD/OpenTTD] kiwitreekor updated pull request #7575: Feature: Add industry production graph
12:19:44  <DorpsGek_III_> [OpenTTD/OpenTTD] kiwitreekor updated pull request #7575: Feature: Add industry production graph
12:21:13  *** snail_UES_ has joined #openttd
12:28:48  *** snail_UES_ has quit IRC
12:30:34  <planetmaker> Corns[m], afaik factorio handles it pretty similar to OpenTTD
12: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?
12:32:18  <Eddi|zuHause> you wouldn't want to have the display rate synchronized to the network code
12:32:58  <Corns[m]> hehe probs not
12:34:08  *** cHawk- has quit IRC
12:34:20  *** cHawk- has joined #openttd
12:36:39  <planetmaker> Corns[m], not sure it's "usual". There's the two different concepts eddi mentioned.
12:37:02  <planetmaker> But server's either send out state and in all cases have to confirm actions initiated by players
12:37:46  <planetmaker> thus updates/s is somewhat unrelated to frames/s
12:38:43  <Corns[m]> oh boy i'm trying to wrap my head around this
12: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?)
12: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.
12: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
12:42:15  <planetmaker> And only then they are executed by every client. At the exact time step (=tick)
12: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)
12:56:55  *** Samu has joined #openttd
12:58:52  *** colde_ has joined #openttd
12:58:56  *** tokai has joined #openttd
12:58:56  *** ChanServ sets mode: +v tokai
12:59:28  *** Sheogorath has joined #openttd
12:59:41  *** ToBeCloud_ has joined #openttd
12:59:41  *** ToBeCloud_ is now known as ToBeFree
13:00:08  *** y2kboy23_ has joined #openttd
13:00:15  *** innocenat__ has joined #openttd
13:01:40  *** super_sp1oky has joined #openttd
13:02:29  *** tokai|noir has quit IRC
13:02:29  *** WormnestAndroid has quit IRC
13:02:29  *** y2kboy23 has quit IRC
13:02:29  *** Jyggalag has quit IRC
13:02:29  *** Vadtec has quit IRC
13:02:29  *** colde has quit IRC
13:02:29  *** innocenat_ has quit IRC
13:02:29  *** super_spooky has quit IRC
13:02:29  *** nnyby has quit IRC
13:02:29  *** ST2 has quit IRC
13:02:29  *** mikegrb has quit IRC
13:02:29  *** ToBeCloud has quit IRC
13:02:29  *** colde_ is now known as colde
13:02:29  *** ToBeFree is now known as ToBeCloud
13:02:30  *** innocenat__ is now known as innocenat_
13:02:31  *** nnyby_ has joined #openttd
13:02:36  *** mikegrb_ has joined #openttd
13:02:59  <Corns[m]> ahh sweet :) ty for explaining
13:05:43  *** Vadtec has joined #openttd
13:06:24  <Corns[m]> at the moment, the sim updates at 30hz by default right
13:06:40  <Corns[m]> and the game renders at...60hz?
13:07:04  <Corns[m]> or at least panning the map feels like 60hz while the trains look like they move at 30hz
13:07:24  <Samu> I've been thinking wether more 'world generation' settings should be listed under settings
13:07:40  <Samu> sometimes I wish they were there
13:07:59  *** ST2 has joined #openttd
13:08:24  <Arveen2> like ?
13:08:47  <Samu> map size, number of towns, sea level
13:08:56  <Samu> start date
13:09:26  <Corns[m]> oh yeah why are some world gen settings in one place and some are in another?
13:09:35  <Samu> map edges would be tricky
13:10:37  <Eddi|zuHause> hysterical raisins
13:11:02  <Arveen2> hmmmm
13:11:13  <Corns[m]> hysterical....raisins
13:11:14  <Corns[m]> oh
13:11:16  <Corns[m]> historical reasons
13:12:29  <Samu> custom number of towns would also be a bit tricky
13:12:52  <Samu> custom sea level
13:21:15  *** WormnestAndroid has joined #openttd
13:30:51  <planetmaker> @Corns[m], unless something dramatically changed, then with OpenTTD the game renders at the same speed as the updates per second
13:31:22  <Corns[m]> oh, even GUI and panning? so 30fps?
13:32:49  <Corns[m]> nvm it is indeed 30fps
13:32:54  <Corns[m]> i've been deluding myself
13: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
13:33:16  <planetmaker> there's a fps viewer ingame
13:34:23  <Corns[m]> yeah - i noticed on win10 that changing the blitter seems to help drastically with render speed
13:34:46  <Corns[m]> also disabling animations - are animations tied to sim speed as well?
13: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
13:35:35  <planetmaker> ... ok, you know :D
13:35:36  <milek7_> actually I think that all relevant architectures implement IEEE754
13:35:52  <milek7_> the problem is only with compiler reordering operations, intermediary register precision, etc.
13:35:55  <planetmaker> so actually OpenTTD's default fps is 33/s
13:36:10  <planetmaker> or rather: one update every 30ms
13:36:14  <Eddi|zuHause> milek7_: that's not the point. IEEE754 allows for some leeway, which is the problem
13:37:47  <planetmaker> yes, animations are tied to sim speed
13:38:10  <planetmaker> it's a bad design choice IMHO. But hard to reverse for what is there now
13:38:32  <Corns[m]> what has to be done to resolve that?
13:38:46  <Eddi|zuHause> nothing will ever be done to resolve that
13:38:54  <Corns[m]> i'd like to see openTTD @ 60fps, but that's a broad goal with lots of implications
13:39:16  <milek7_> leeway in what? reordering, register size selection, are compiler job
13:39:17  <Eddi|zuHause> because things like newgrf callbacks cannot be decoupled from sim speed
13:39:18  <planetmaker> I'm pretty convinced that eddi is right there... animation is partially tied to game state
13: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
13: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
13:40:00  <Corns[m]> oh boy
13:40:18  <Corns[m]> so...newGRFs animations are tied to sim state?
13:40:24  <Eddi|zuHause> yes
13: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
13:40:30  <planetmaker> yes
13:40:33  <Corns[m]> holy
13:40:46  <Eddi|zuHause> animation state gets abused for arbitrary storage in some places
13:40:47  <Corns[m]> -and some rely on that for whatever they need
13:40:55  <Corns[m]> oh my god
13:41:01  <Eddi|zuHause> exactly
13:41:11  <planetmaker> houses being build or changing over time. That's animation states being used
13:41:11  <Eddi|zuHause> nobody will ever touch that with a long pole
13:41:38  <planetmaker> (or it's an option which is being exercised by various newgrfs)
13:41:38  *** Flygon has quit IRC
13:41:39  <LordAro> good ol hysterical raisins
13:41:40  <Corns[m]> house build progress is tied to its animation state....
13:41:52  <Corns[m]> instead of being internally stored
13:41:57  <Corns[m]> oh fair, for storage efficiency
13:41:59  <Corns[m]> jesus
13: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"
13:42:25  <milek7_>
13:42:32  <Corns[m]> oh yeah i skimmed through that
13:42:33  <LordAro> such is the way when you have a game with 25 years of history
13:42:44  <planetmaker> ^^ yeah
13:43:34  <Corns[m]> would we lose anything by changing that convention?
13:43:34  <LordAro> and perhaps mostly, it was originally programmed in assembly, and initial modifications only built on that, rather than started from scratch
13:43:48  <Corns[m]> i.e. decoupling animations from sim state
13:43:53  <Corns[m]> or decoupling render from sim
13: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)
13: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
13:44:31  <LordAro> but you'd still need some sort of translation layer
13:45:01  <planetmaker> Adding a new animation option which does not influence state would not hurt and definitely is an option
13: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
13:45:09  <Corns[m]> yeah for save transition
13:45:09  <planetmaker> which would also not be too terribly difficult.
13:45:21  <planetmaker> But removing the existing... would break things in various places
13:45:32  *** sla_ro|master has quit IRC
13:45:35  <planetmaker> and thus won't happen
13:45:52  <planetmaker> OpenTTD never transitions anything... it only adds.
13:45:58  <Corns[m]> -unless somebody really tries
13: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
13: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
13:48:05  <planetmaker> Removing that feature of existing animation: that won't fly, however you try
13:57:03  <Eddi|zuHause> milek7_: so far i read nothing in there that would change my mind
13:57:27  <Corns[m]> planetmaker: oh boy but id only want to implement that as a stepping stone to decoupled render
13:58:28  <Corns[m]> Unless u do the classic microsoft embrace, extend, exterminate
13:58:32  *** Samu has quit IRC
13:59:08  <Corns[m]> I guess I'll look at something that i can at least fit on my plate
13: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
14:00:14  <Corns[m]> Wait like, having different colour palettes per wagon? Or company colours
14:00:16  <Eddi|zuHause> so, treat an animation step the same way as you would treat a movement step
14:00:31  <Corns[m]> Oh boy
14:00:34  <Eddi|zuHause> Corns[m]: like palette animation
14:00:41  <Eddi|zuHause> Corns[m]: like water/fire animation
14:00:56  <Corns[m]> Oh right
14:01:04  <Corns[m]> I...kinda understand
14:01:50  <Eddi|zuHause> there's also a per-sprite colour remap in some places, that is not what i mean
14:02:30  <Corns[m]> Is that like, how some newGRFs have random wagon cosmetics?
14:02:52  <Eddi|zuHause> that is like whe draw company colours
14:03:47  <Eddi|zuHause> wagon cosmetics are usually completely different sprites
14:04:13  <Eddi|zuHause> but they can also have palette remaps
14:04:20  <Corns[m]> Oh
14: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
14:06:32  <Corns[m]> I
14:07:15  <Corns[m]> I'll try to understand what palette remaps are
14:07:28  <Corns[m]> Ok so i vaguely understand sprites as individual images
14:07:34  <Corns[m]> And they can have one or more areas for colour mapping, e.g. train engines with company colours
14:07:36  <Corns[m]> Um idk the openttd specific jargon for each thinh
14:07:39  *** HerzogDeXtEr has joined #openttd
14: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
14:10:24  <Eddi|zuHause> the palette remap can change "instead of entry 28, draw 35 instead"
14:10:56  <Eddi|zuHause> in 32bpp mode, each sprite has a separate layer, which defines which areas can be recoloured
14:13:06  <Eddi|zuHause> i've never looked at any of these processes in detail, though
14:14:29  <Corns[m]> Oh i see (re 8bpp mode)
14: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
14:16:32  <Corns[m]> 32bpp,layers like in photoshop? And then the recolour just applies to an entire layer?
14:16:50  <Eddi|zuHause> Corns[m]: yeah, pretty much
14:17:17  <Corns[m]> Oh nice, so like those buildings with flashing signs?
14:17:48  <Eddi|zuHause> yes, the theatore, stadium, etc.
14:18:05  <Corns[m]> Thats a neat trick :)
14:18:09  <Eddi|zuHause> airport runways
14:18:50  <Eddi|zuHause> that's a fairly standard trick in the late 80s/early 90s, before GPUs and shaders were a thing
14:21:47  *** Samu has joined #openttd
14:23:49  <Corns[m]> Thats pretty cool :)
14:24:16  <Corns[m]> Would a conventional modern equivalent just be to draw a new sprite for each frame?
14:24:44  <Corns[m]> And just...bake it into the texture, or smth
14:25:46  *** frosch123 has joined #openttd
14:26:13  *** supermop_work has joined #openttd
14:27:53  <supermop_work> yo
14:30:16  <Corns[m]> Wait so whats most responsible for the holdup with fast forward + all animations?
14:31:35  <Eddi|zuHause> Corns[m]: mostly that palette animation is not supported by hardware these days, and needs to be reimplemented with shaders
14:38:10  <Corns[m]> The more i learn, the less i feel like i know about graphics in game dev
14:40:11  <planetmaker> that's a good sign :)
14:41:05  <frosch123> the factorio blog writes about graphics every now and then
14:41:23  <frosch123> but that is very different to ottd's 90's stuff
14:43:01  <FLHerne> Corns[m]: Have you seen ?
14:43:46  <FLHerne> That sort of implementation would be the way to give OTTD 'modern' graphics
14:44:25  <Corns[m]> Ooo tytyty FLHerne
14:44:45  <Corns[m]> OMG
14:44:46  <FLHerne> Actually, reading the blurb, I'm not sure it works how I'd expected
14:44:47  <Corns[m]> We need this
14:45:15  <Corns[m]> How recent is this?
14:45:24  <Corns[m]> Also didnt TTD for PS1 have 3d graphics?
14:47:51  <FLHerne> Weirdly, yes
14:47:53  *** nielsm has joined #openttd
14:48:04  <FLHerne> I've seen screenshots, but no idea how that worked
14:49:12  <Eddi|zuHause> probably just cheap and dirty conversion
14:49:27  <Eddi|zuHause> it's not like we could use any of that for anything
14:55:49  <Corns[m]> The assets would be useful at least, right
14:57:54  <Eddi|zuHause> unlikely
14:58:18  <Eddi|zuHause> we have no license to redistribute them anyway
14:58:37  <Eddi|zuHause> and they don't cover all the TTD stuff, i believe
14:58:54  <Eddi|zuHause> and they look horrible by todays standards
14:59:52  <Eddi|zuHause> between pixel-retro and ultra-realistic, they fall in the uncanny valley
15:01:27  <Samu> I have a string problem
15:01:41  <Samu> how to display 2^8
15:01:44  <Samu> 64
15:01:46  <Samu> 256
15:01:48  <Samu> 512
15:01:51  <Samu> etc, for map sizes
15:03:39  <Corns[m]> Hehe ps1 graphics
15:03:42  <Corns[m]> Early 3d
15:03:55  <Corns[m]> Yeah youre right, it is indeed a really crude time
15:08:03  *** WormnestAndroid has quit IRC
15:09:05  <Samu>
15:09:16  <Samu> this in unelegant :(
15:09:25  *** WormnestAndroid has joined #openttd
15:09:57  *** WormnestAndroid has joined #openttd
15:10:12  *** WormnestAndroid has quit IRC
15:10:47  <Samu> not stored in saves is a lie
15:11:50  <Corns[m]> I guess its only used at world gen, and you cant change it mid save
15:12:46  <Corns[m]> So it belongs in the same category as, say, tree generation?
15:15:02  *** WormnestAndroid has joined #openttd
15:15:15  <Eddi|zuHause> what?
15:16:15  *** WormnestAndroid has quit IRC
15:16:21  <planetmaker> Samu, write the real value, thus 256 instead of 2^8
15:16:28  *** WormnestAndroid has joined #openttd
15: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
15:20:50  <planetmaker> samu, that is: apply identical treatment like the minimum and maximum zoom levels are being treated
15:21:33  *** sla_ro|master has joined #openttd
15:25:01  <milek7_> gamepad controls are pain to use in TT..
15:36:31  <Eddi|zuHause> suggest better ones?
15: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
15:39:39  <milek7_> i mean these in PSX port
15:42:06  <frosch123> wait, you have tt for ps?
15:42:41  <milek7_> just downloaded iso, on emulator
15:42:53  <frosch123> what do industries look like?
15:43:12  <frosch123> i always wondered how they rotate the non-square irregular industry shapes
15:43:20  <frosch123> or whether they are entirely different
15:50:13  <milek7_>
15:52:32  <frosch123> thanks, so i actually made separate 3d models for everything
15:52:52  <frosch123> i definitely did not expect that
15:53:10  <frosch123> *they made separate models
15:55:14  <frosch123> the stadium looks just fine, way more vertices than i expected
15:56:13  <Samu> there's a weird bug with custom sea level
15:56:21  <Samu> default value is 1%
15:56:27  <Samu> but the minimum value is 2%
15:56:48  <Samu> how does openttd decides then?
16: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
16:01:00  <frosch123> i think i got 4 mails in 6 days about that
16:01:35  <Samu> According to static const uint CUSTOM_SEA_LEVEL_MIN_PERCENTAGE = 1;    ///< Minimum percentage a user can specify for custom sea level.
16:01:41  <Samu> default of 1 is correct
16:01:46  <Samu> minimum of 2 is wrong then
16:13:51  *** Wormnest__ has joined #openttd
16:39:01  <DorpsGek_III_> [OpenTTD/OpenTTD] James103 commented on pull request #7730: Change: Use vehicle model age for station rating calculation
16:43:07  <nielsm> I don't dislike that idea ^^
16:44:01  <frosch123> hmm, i wanted to write down a newgrf proposal
16:44:22  <frosch123> idea was to allow newgrf to set the coolness of a vehicle independent of speed
16:44:36  <frosch123> which would include control over the 2 year thing
16:44:48  <Eddi|zuHause> how silly
16:45:10  <nielsm> a callback for a vehicle to return its awesome-factor?
16: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
16:46:11  <frosch123> yes, but it could also do stuff like "salon van available in train"
16:46:36  <frosch123> or safety supplied by proper caboose van
16:46:50  <nielsm> yeah
16: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
16:50:53  <Eddi|zuHause> so for mixed local and long-distance stations, only the stupid frequent local trains count
16: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
16:53:24  <nielsm> and then either average or max
16:53:47  *** glx has joined #openttd
16:53:47  *** ChanServ sets mode: +v glx
16: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?
16:59:20  <FLHerne> I can see from parser.out that it's something to do with the precedence of binops
16:59:51  <FLHerne> But none of the changes I thought would fix it did :P
16:59:54  <frosch123> i know that message from using flex&bison, but i never noticed it in nml
17:00:58  <frosch123> how do i make nml show that warning?
17:01:39  <glx> you need to modify the source
17:03:06  <frosch123> i get no message when running the nml tests
17:03:10  <glx> I think
17:03:47  <Eddi|zuHause> FLHerne: usually means there's some unintended ambiguity in the grammar
17:04:59  <FLHerne> Eddi|zuHause: I know what it means, I just can't pin it down :P
17:05:04  <frosch123> i set "debug" to True, but still no message
17:05:19  <FLHerne> Eddi|zuHause: I tried changing the precedence of various ops, but that just shuffles the problem
17:05:22  <glx> hmm you need to force rebuild of the parser
17:06:29  <FLHerne> I think also set `optimize=False` if that's not set?
17:06:51  <FLHerne> (sorry, afk for a while)
17:06:51  <glx>
17:07:01  <Samu>
17:07:20  <glx> yes optimize=False will rebuild I think
17:09:10  <Samu> okay, i only have a problem with map size
17:09:40  <Samu> it's not stored in saves, which isn't true, but it's also true
17:09:45  <frosch123> i also need write_tables=False apparently
17: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
17:11:00  <Samu> what I get displayed, the map loads correctly
17:12:18  <DorpsGek_III_> [OpenTTD/nml] glx22 updated pull request #71: Add: nmlc option to force regeneration of parser tables
17:13:57  <glx> maybe we can also add an option to enable parser debug
17:15:51  <frosch123> it's related to "spritegroup"
17:18:39  <frosch123> now at "spriteview"
17:18:52  <frosch123> maybe i should look up what that actually is :p
17:19:04  <Eddi|zuHause> the main problem is that this error probably doesn't show up at the point where it is caused
17: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
17:20:47  <glx> what's the nml to test ?
17:21:08  <glx> (to see if the option I'm adding works)
17: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
17:23:38  <frosch123> aw, coop paste does not work for me either
17:24:26  <frosch123> <- FLHerne, glx: adding that "COLON" removes the error
17:24:41  <planetmaker> hm... how does "does not work" materialize?
17:25:05  <frosch123> can you create a new paste?
17:25:11  <frosch123> just try anything
17:25:39  <planetmaker> hm... funky, no
17:26:07  <frosch123> FLHerne: glx: however, i do not see how expression can start with LBRACKET
17:34:05  <frosch123> oh it can
17:34:09  <frosch123> p_array
17:36:54  <glx> hmm I can't trigger the warnings
17:37:18  <frosch123> +                                debug=True, optimize=False,
17:37:20  <frosch123> +                                write_tables=False,
17:37:25  <frosch123> ^ i have those values
17:42:37  <frosch123> FLHerne: <- that fixes it, but it's ugly :)
17:44:12  <frosch123> i do not know enough about nml's parsertree
17:44:25  <glx> oh I needed to delete
17:44:28  <frosch123> so not sure whether SpriteView should learn about Array
17:45:03  <frosch123> glx: i also did that somewhen, but hard to tell what finally triggered it :p
17:45:51  <glx> basically it uses unless something changed in parser, so I couldn't trigger it
17:52:41  <glx> now my option works
17:55:02  <DorpsGek_III_> [OpenTTD/nml] glx22 updated pull request #71: Add: nmlc option to force regeneration of parser tables
17:57:27  *** supermop_work has quit IRC
18:02:31  <glx> frosch123: I don't see an other possible solution, because 'LBRACKET expression_list RBRACKET' is an expression
18:02:51  <Samu> Your IP address is listed as a malicious IP.
18:02:57  <Samu> i can't use pastebin
18:03:09  <glx> coop pastebin ?
18:03:18  <Samu>
18:03:20  <Samu> ya
18:03:23  <glx> yeah it's broken
18:03:29  <frosch123> yes, for the production rule it is the right solution, i am just not happy about the isinstance
18:03:44  <frosch123> first creating an array and then disassembling it again
18:04:57  <glx> other option would be to split p_array I guess
18:05:29  <frosch123> or to make SpriteView accept an Array
18:05:41  <Samu> - how ugly is this?
18:06:21  <glx> seems very complex Samu
18:07:01  <glx> probably better to use a group and set each side separately
18:07:19  <Samu> it's a bitset :(
18:07:36  <milek7_> curious, emulators can render with resolution higher than native
18:07:41  <milek7_>
18:08:02  <glx> you can dissociate the container and the display
18:09:04  <Eddi|zuHause> other solution would be to exclude array literals from expression
18:09:58  <Eddi|zuHause> and then re-add them to the places that actually accept them
18:10:22  <Eddi|zuHause> which might be somewhat more involved than those 5 lines
18:10:34  <frosch123> grammars with less rules are better :)
18:10:36  <Eddi|zuHause> but a lot cleaner overall
18:11:23  <frosch123> no, adding type information (array, not array) into the grammar makes it a lot less cleaner
18:11:31  <glx> yeah the grammar is already complex with () used for function_call and template_usage
18:11:45  <Eddi|zuHause> frosch123: essentially what you're doing is doing something that would now be semantic analysis in the syntactic analysis
18:12:21  <frosch123> no, i replaced a special array into a standard array
18:12:48  <Eddi|zuHause> yes, but you're deconstructing that array again
18:13:03  <frosch123> i already said that
18:13:07  <Eddi|zuHause> which would be better suited in the semantical analysis
18:13:51  <Eddi|zuHause> anyway, gtg
18:14:12  <glx> oh I think the parser does that in other places
18:14:57  <milek7_> no MIDI on PS, it plays PCM audio from disc
18:15:38  <frosch123> from what year is that ps port? why does rct not use that tech
18:16:15  <nielsm> because chris sawyer is (was?) a person who insisted on writing all game code himself, in assembly
18:16:20  <glx> probably an outsourced port
18:16:33  <nielsm> the psx port is really a complete reimplementation
18:16:45  <nielsm> (unless they wrote a transpiler from x86 to mips)
18:17:00  <milek7_> "PLAYSTATION VERSION by Digital Amusement Ltd"
18:17:47  <frosch123> so they reimplemented the whole code, and they recreated all the artwork in the same style?
18:17:55  <nielsm> yeah
18:18:15  <nielsm> the tree sprites in that screenshot seem to perhaps be copied
18:18:23  <nielsm> along with the sprite font
18:18:40  <frosch123> check the video from earlier, the trees change when rotating
18:18:49  <frosch123> the only "sprite" i noticed was the oil refinery flame
18:19:23  <nielsm> ah, the trees seem to be two billboards perpendicular (X shape from above)
18:26:33  <Samu> STR_CONFIG_SETTING_TERRAIN_TYPE_HELPTEXT                        :(TerraGenesis only) Hilliness of the landscape
18:26:40  <Samu> this is not entirely true
18:27:10  <Samu> original landscape can change terrain type of temperate and toyland, but not select alpinist
18:27:40  <Samu> tropical and arctic have this setting locked
18: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
18:46:26  <Samu> muy english
18:46:43  <Samu> Starting year needs a description
18:46:46  <Samu> who can help
18:46:50  <Samu> :p
19:02:05  *** supermop_work has joined #openttd
19:10:19  *** Maarten has joined #openttd
19:24:25  *** Wolf01 has joined #openttd
19:41:40  <Samu> nobody wants to describe starting year?
19:45:31  <Wolf01> Hmmm, no man's sky 19.49€, good price?
19:56:53  <Samu>
19:57:44  <Samu> map size x and map size y are bugged
19:58:01  <frosch123> it contains neither lego nor trains
19:58:07  <Samu> don't know how to fix it
19:58:19  <Samu> map edges is just too ugly :(
19:58:35  <Samu>
19:59:21  <Samu> map_x and map_y aren't stored as a game setting :(
19:59:44  <Samu> they're stored in a different way that can't be retrieved via settings.cpp
20:00:08  <nielsm> yes they are just a property of the loaded world
20:00:22  <nielsm> and parameters given to the world gen routines
20:02:59  <Wolf01> Ha, patch for transport fever 2
20:05:06  <nielsm> "Fixed modern headquarters appearing too early" oh
20:06:34  <Samu> what would happen if I force map_x and map_y to be saved?
20:09:58  <Wolf01> "Added Set line - New line feature" backported from TF1
20:10:20  <Wolf01> Also cargo load ratio IIRC
20:10:28  <nielsm> I think they had that as early as in train fever at launch
20:10:37  <Wolf01> Why not put them directly from the beginning
20:10:56  <Wolf01> "Improved in-game settings (show all options)" ha!
20:11:38  <Wolf01> Maybe now you should be able to change the hotkeys without quitting and reloading
20:13:43  *** Samu_ has joined #openttd
20:18:36  *** Samu has quit IRC
20:25:04  *** gelignite has joined #openttd
20:51:09  *** nielsm has quit IRC
21:18:51  *** supermop_work has quit IRC
21:29:49  *** hythlodaeus has joined #openttd
21:29:53  <hythlodaeus> hi guys
21: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
21:30:49  <hythlodaeus> is this string still being used?
21:31:00  <hythlodaeus> i cannot find it anywhere. not in-game, not in the editor
21:32:11  *** sla_ro|master has quit IRC
21:33:03  <frosch123> it's in the scenario editor
21:33:30  <hythlodaeus> where exactly?
21:34:21  <frosch123> toolbar -> waterway -> first button from left
21:36:08  <frosch123> the tooltip of the toolbar button is a bit silly though :p "build ship docks" should be "build waterways"
21:36:31  <frosch123> both construction bars in game and in editor use "waterway" in their caption
21:36:44  <frosch123> hythlodaeus: can you add that to your english-review pr?
21:38:56  <hythlodaeus> thanks!
21:39:30  <hythlodaeus> will do
21:39:41  <hythlodaeus> I'm also thinking of renaming ship depots as shipyards
21:39:50  <hythlodaeus> because there's no such thing as ship depots
21:40:03  <hythlodaeus> or rather, there are, and they're named shipyards
21:40:32  <frosch123> shipyards is weird, it's not only for construction
21:40:40  <frosch123> boathouse only works for small ships
21:40:49  <frosch123> drydock would be on land
21:40:54  <planetmaker> Boats are build and serviced at shipyards. IMHO
21:41:10  <planetmaker> which... have wet- and drydocks :)
21:43:27  <hythlodaeus> planetmaker: exactly
21:44:01  <hythlodaeus> hence why I think shipyard is a better name than ship depot
21:44:42  <planetmaker> I'd leave that change out from that PR for now, though
21:44:50  <planetmaker> even though I agree
21:47:14  <hythlodaeus> man, capitalization is all over the place in the english original
21:47:53  <hythlodaeus> Sometimes you have stuff like Build roads written as Build Roads and vice versa
21:48:03  <hythlodaeus> there's little coherence
21:52:58  <Samu_> can you take a look at this, before i do a pull request
21:54:43  <Samu_> map edges is still too ugly, I'm unsure yet how to solve that
21: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
21:55:31  <Samu_> oh, sorry, i can fix that
21: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
21:56:47  <hythlodaeus> I don't like this description
21:57:18  <frosch123> yeah, looks like some "newer" texts forgot that rule
21:57:41  <frosch123> "newer" meaning "for 7 years" :p
22:00:42  <hythlodaeus> "Set the frequency of hills on the terrain." would be enough for the description
22:00:55  <hythlodaeus> everything else is sort of self-evident
22:01:32  <frosch123> i think that was the text in the past, but noone understood what it did. thus it was made more explicit
22:04:02  <hythlodaeus> Let me make it more explicit: Terrain Roughness - Sets the amount of hills on the map
22:06:24  <frosch123> why do you avoid the explicit warning about the extreme values?
22: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
22:10:37  *** Wolf01 has quit IRC
22:15:00  <hythlodaeus> what warning?
22:15:15  <frosch123> in this case "repetitive"
22:17:15  <hythlodaeus> Because that's more of an aesthetic thing than necessarily a game changing/game breaking effect
22:17:26  <hythlodaeus> at least from what I understand
22:17:53  <hythlodaeus> terrain being a little repetitive wouldn't warrant a warning IMO
22:18:38  <frosch123> well, i consider the "very rough" terrain so terrible, that one could argue to remove that setting value :p
22:19:00  <hythlodaeus> then that's what should be done
22:19:24  <frosch123> the helptext is the compromise :)
22:19:34  <hythlodaeus> if a setting makes the game unplayable, it shouldn't really be allowed to be taken that far
22:19:46  <hythlodaeus> I have similar feelings towards snow lines, given they prevent farms
22:20:43  <planetmaker> and allow forests
22: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
22:20:56  <hythlodaeus> forests do grow on the snowline IIRC
22:21:22  <planetmaker> no land on level 0 :)
22:21:58  <hythlodaeus> ah you mean sea level?
22: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
22: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
22: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
22:24:49  <planetmaker> That's why we have zillions of settings :)
22:26:31  <milek7_> these helptexts are not shown in new game window anyway ;P
22:26:38  <hythlodaeus> that's very bad for polishing and presentation though and it makes customising ultimately more confusing
22:26:54  <planetmaker> milek7_, mouse-over?
22:27:21  <frosch123> quite likely that the newgame window never made it that far
22: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
22:27:27  <frosch123> many attempts, none finished
22:27:48  <milek7_> planetmaker: nothing shows up
22:28:11  *** gelignite has quit IRC
22:28:32  <planetmaker> right click? There's a setting how they are triggered :)
22:29:04  <frosch123> planetmaker: not all buttons have tooltips in that gui
22:29:46  <milek7_> seems that only climate miniatures and map size shows tooltip
22:30:00  <frosch123> it was probably in some wip, that never made it
22:31:17  <planetmaker> possible
22:32:44  *** t4 has joined #openttd
22:33:16  *** tyteen4a03 has quit IRC
22:35:13  <Samu_> any ideas how to present the map edges
22:35:29  <planetmaker> you mean water vs. free-form?
22:35:31  <Samu_> the real value is a number from 0 to 16
22:35:32  <Samu_> yes
22:37:05  <Samu_> a dropdown with 17 items, all reading alike, is very confusing
22:37:36  <Samu_>
22: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
22:38:07  <planetmaker> like... done in newgame UI
22:38:39  <Samu_> but that settings_gui.cpp is very general
22:38:50  <Samu_> abstract or whatever
22:39:13  <Samu_> i would have to treat the reading of some settings differently
22:39:29  <planetmaker> yes
22:40:02  <Samu_> and the 4 settings would have to exist in settings.ini
22:40:12  <Samu_> it's only 1
22:40:41  <planetmaker> it would be sufficient to do something special for the UI
22:40:49  <planetmaker> no need for separate settings
22:41:19  <planetmaker> after all: it works that way in the new map UI :) So... why not elsewhere?
22:42:22  <hythlodaeus> omg that dropdown
22:43:01  <frosch123> hehe, there is a reason why not all settings are in the tree :p
22:43:08  <frosch123> all the difficult ones were left out
22:43:31  <planetmaker> yep :P
22:43:42  <planetmaker> and the newgame ones are the ones which suck
22:44:36  <frosch123> there are also some from the game options
22:44:41  <frosch123> like basesets
22:44:44  <planetmaker> yes
22:44:54  <frosch123> and of course gs and newgrf settings are also separate
22:45:04  <frosch123> though they could be added as top-level nodes
22:45:07  <glx> only 1 setting is ok, it can be split on display
22:45:10  <planetmaker> nevertheless, I share the desire to actually consolidate them into one settings screen
22: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'
22: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
22:47:10  <planetmaker> currently you need to have done 90% config in 4 other windows before hitting new game on main screen
22: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
22:47:25  <planetmaker> yes
22:48:35  <glx> map edge should be representable as a subtree
22:53:59  <Samu_> gonna sleep, will continue tomorrow
22:54:05  *** Samu_ has quit IRC
22:54:14  *** nielsm has joined #openttd
23:03:39  *** frosch123 has quit IRC
23:35:05  *** Flygon has joined #openttd

Powered by YARRSTE version: svn-trunk