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 https://git.io/JePq0 00: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 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 https://git.io/Je5BQ 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 https://git.io/JePq0 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 https://git.io/Je525 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 https://git.io/Je525 10:07:26 <DorpsGek_III_> [OpenTTD/OpenTTD] planetmaker closed issue #7865: Train auto replace and replace engine if old https://git.io/Je525 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 https://git.io/Je525 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 https://git.io/fjc3i 12:01:46 <DorpsGek_III_> [OpenTTD/OpenTTD] kiwitreekor updated pull request #7575: Feature: Add industry production graph https://git.io/fjc3i 12:19:44 <DorpsGek_III_> [OpenTTD/OpenTTD] kiwitreekor updated pull request #7575: Feature: Add industry production graph https://git.io/fjc3i 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> https://devs.openttd.org/~planetmaker/patches/ottd_upsfps.png ... 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_> https://randomascii.wordpress.com/2013/07/16/floating-point-determinism/ 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 https://www.tt-forums.net/viewtopic.php?f=33&t=86412 ? 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> https://i.imgur.com/Ne2I59g.png 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_> https://milek7.pl/.stuff/tt-psx.mp4 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 https://git.io/Je51b 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> parser.py:37 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> https://github.com/OpenTTD/nml/pull/71 17:07:01 <Samu> https://i.imgur.com/VrEbviU.png 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 https://git.io/Jeyxo 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> https://pastebin.com/xAZAfLY2 <- 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: https://pastebin.com/hVpEVL5S <- 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 parsetab.py 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 parsetab.py 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 https://git.io/Jeyxo 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> https://paste.openttdcoop.org/ 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> https://i.imgur.com/3ZO7sHO.png - 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_> https://imgur.com/BBKBchD.png 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> https://i.imgur.com/QfCua9l.png 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> https://i.imgur.com/3ZO7sHO.png 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 https://github.com/OpenTTD/OpenTTD/compare/master...SamuXarick:List-more-world-generation-settings?expand=1 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_> https://i.imgur.com/3ZO7sHO.png 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