IRC logs for #openttd on OFTC at 2024-02-01
⏴ go to previous day
00:14:49 <wensimehrp> truebrain: thank you for the tip, it is working right now
00:23:53 <wensimehrp> hmm it tells me to login
00:35:29 <_glx_> I think I listed all cases
00:35:35 *** olionkey has quit IRC (Quit: User went offline on Discord a while ago)
00:51:47 <belajalilija> You might wanna get that checked out
00:51:47 <belajalilija> It is I who should make you feel uncomfortable :psychosmile: :psychosmile: :psychosmile:
00:54:16 <reldred> Truebrain is chill, just doesn't tollerate bullshit. And who can blame them to be honest.
00:56:05 <belajalilija> I can’t remember any experiences with them
00:56:19 <belajalilija> Though I’m sure we have interacted
00:56:58 <belajalilija> Which just means I found him thoroughly inoffensive
00:57:57 <belajalilija> Most people in this server are cool anyway
00:58:31 <belajalilija> There’s like 2-3 at most i feel negatively towards
00:59:21 <belajalilija> People probably dislike me more than I dislike them here because i am very enthusiastic about certain topics and bring them up a lot lmao
01:03:03 *** Wormnest has quit IRC (Ping timeout: 480 seconds)
01:03:16 <reldred> I figure you can disagree with people as much as you want, just don't make it personal.
01:03:29 <reldred> TallTylerviaGitHub: oh god oh god oh god yes
01:06:53 <emperorjake> Oh it forces you to have depot orders if you want to auto separate?
01:07:46 <reldred> Hey I'm autistic as fuck, I just had it beat into me (physically) when I was young that you don't name names unless you consciously want to pick a fight >:D
01:09:43 <reldred> Requiring depots for autoseperation in vanilla without drive through depots is a bit of a shame, if PR8480 was marged and you could do roll on roll off depots it would be a bit easier to build a network around.
01:10:13 <reldred> (or the cut down pr that allows joining depots)
01:10:48 <emperorjake> I agree, if auto separation has to happen at a single point in the order list, I'd at least line to be able to build yards
01:11:35 <reldred> Or a station instead of a depot, build a station as a yard that's big enough to act as a buffer.
01:12:16 <reldred> We've got a lot of grf's already to build yards as stations
01:13:46 <reldred> talltyler: happy to chat here about the pr or move discussion to grubhub?
01:15:24 <reldred> I'll put some dot points on github
01:40:37 *** Wormnest has joined #openttd
02:21:06 *** wallabra has quit IRC (Ping timeout: 480 seconds)
02:25:41 *** wallabra has joined #openttd
02:47:40 *** Wormnest has quit IRC (Quit: Leaving)
03:16:02 <rau117> TallTylerviaGitHub: The only question is will it be possible to disable the automatic activation of autoseparation?
03:26:39 <talltyler> It’s not automatically activated
03:26:45 *** debdog has quit IRC (Ping timeout: 480 seconds)
03:26:49 <talltyler> You can try the preview 😉
03:30:02 *** gnu_jj_ has joined #openttd
03:32:07 <reldred> I'm excited for this talltyler, one of my biggest stumbling blocks to testing PR's has always been actually sitting down and *playing* regular OpenTTD. You could say I've bought far too many shares in JGRPP :P. Having autoseperation is just one of those little conveniences that I don't realise how much I rely on until it's not there and I ragequit
03:33:10 *** gnu_jj has quit IRC (Ping timeout: 480 seconds)
03:36:01 <rau117> talltyler: Hmm, some PRs have a clearly visible preview button (as I remember, it's called view deployment), but there is no such button on this pr yet. *Or it's well hidden.*
03:55:31 <_glx_> somehow there was a bug when building the preview, it should be available soon
04:00:50 <rau117> By the way, if the depot becomes a little more useful even without breakdowns, why not increase the max. speed for trains inside the depot?
04:00:50 <rau117> For example, up to 1.5x and 2x on mono and maglev, just like curve speed limits
04:00:50 <rau117> Slow entry/exit of the depot is not a such large problem at low speeds like a "realistic freight" 120 km/h, but for long passenger maglevs at 600 km/h, or even more for 4k km/h vactrain, a speed of 61 km/h is something very strange.
04:07:22 <_glx_> preview is now available
04:28:21 <rau117> By the way, about the “cycle through a group of signals”.
04:28:21 <rau117> Why not add 2 more parameters - scrolling only through the block / pbs group, regardless of what is visible on the screen? (in total: all visible / current group / block group / pbs group)
04:28:21 <rau117> You will get a little more parameters, but this configuration will suit almost 100% of cases.
06:00:38 *** Webster has joined #openttd
06:24:45 *** keikoz has quit IRC (Ping timeout: 480 seconds)
07:55:14 *** johnfranklin has joined #openttd
07:55:14 <johnfranklin> what about a multi-airport station? This can partially solve the “plane jam” problem.
07:55:52 <johnfranklin> Currently there can only be 1 airport in 1 station
08:03:10 <peter1138[d]> Okay, still tired.
08:03:40 <truebrain> Did you go to bed on time?
08:04:12 <truebrain> Well, I guess that is an achievement on its own!
08:15:53 <truebrain> #11945 is surprisingly clean; it seems we all taught mister Tall well over the last few months 🙂
08:20:54 <_zephyris> TallTylerviaGitHub: Looks great. I like the simplicity if the depot idea. Also allows simple control of where the separation is introduced - I'll always put a depot by my RV cargo pickup!
08:22:45 <_zephyris> Key comment (from reading, pre testing): why "auto-separate"? Seems like "unbunch" is used more in general in the media. Auto-separate is internal jargon/slang for how it's achieved.
08:23:41 <emperorjake> Auto-separate is what JGRPP calls it so that's what everyone's used to
08:24:11 <_zephyris> That's not a good reason IMO. This is introducing a feature to a more general audience, so think hard about the name
08:24:11 <emperorjake> but I agree that "unbunch" could be a better term, I've seen other games use it
08:24:26 <_zephyris> Cities skylines uses it, for example. BBC news too.
08:24:45 <truebrain> never read that term 😄
08:25:31 <_zephyris> Try googling "bus auto separate" vs "bus unbunch"
08:25:53 <truebrain> first search term, first hit, OpenTTD
08:26:00 <truebrain> so that sounds a commonly used term in OpenTTD 🙂
08:26:34 <_zephyris> Yeah, that's my argument. It's the term in openttd, and nowhere else!
08:28:49 <_zephyris> LordAro: LordAro wait to separate is better, but still a bit unclear. Wait to separate _what_?
08:30:26 <rau117> JGR does the separation truly automatically at the station.
08:30:26 <rau117> But the vanilla version requires sending vehicle to the depot. Remembering the experience of breakdowns, organizing a depot is far from the most convenient and simple part of the game. It's quite difficult to call it «auto-[something]».
08:31:21 <rau117> For minor transport such as ships or depot cars, this is not such a big problem, but what about trains or planes?
08:32:12 <_zephyris> This is experience from my job leaking through. In communicating, picking terms well is a critical step, and "well, the team always uses it" is never the right answer.
08:32:31 <_zephyris> Anyway, I'll stop spamming and pontificating, but do think about it 😉
08:33:29 <johnfranklin> I think “bunch” is more oral and casual
08:33:41 <emperorjake> truebrain: I'm a little confused, where exactly do I put that line?
08:34:22 <rau117> It might be a good solution to just remove the "auto-" particle. The feature will not lose so much clarity, and there will be no overlap with the simpler and more convenient JGR's autoseparation.
08:43:17 <truebrain> emperorjake: `cmake .. -D....`
08:43:36 <truebrain> `cmake .. -DOPTION_ALLOW_INVALID_SIGNATURE`
08:44:08 <truebrain> otherwise you can edit your `CMakeOptions.txt` in your build folder for that flag to become `ON`
09:05:59 <truebrain> that might influence your take on #11937 peter1138[d] 🙂
09:14:53 <_zephyris> Ummm, am I being dumb? Shouldn't these auto-separate (unbunch 😉 )
09:15:11 <truebrain> did they make a round-trip already?
09:16:41 <_zephyris> Yeah, lots. Been running since my terminology pontification!
09:17:28 <peter1138[d]> Hmm, try moving the depot order to the start, as that's where it is in the screenshots.
09:18:02 <peter1138[d]> I don't mean that as a solution, just a diagnostic step 🙂
09:23:59 <truebrain> so if I make my Teams screen smaller when in a call, my audio quality improves
09:24:05 <truebrain> that is ...... well, it is
09:25:40 <peter1138[d]> I don't even try using Teams on my computer any more. It does not like Firefox.
09:25:53 <truebrain> no, had to install Chrome for it 😦
09:32:05 <_zephyris> peter1138[d]: Bingo
09:36:33 <peter1138[d]> Oops, at 1x that becomes a bit... blurred 😄
09:36:52 <truebrain> just look at it from a distance and it will be fine
09:38:02 <peter1138[d]> Also SVG antialiasing makes it a bit thicker.
09:38:46 <_zephyris> I guess your diagonals cross all the pixel centres? Shift the vertices by 0.5 (0.25?).
09:42:52 *** thelounge345 has joined #openttd
09:43:25 <peter1138[d]> "But woe! It's not perfectly aligned at 4x"
09:45:30 <_zephyris> Welcome to the world of pixel-perfect font recreation
09:45:39 <emperorjake> truebrain: This is what I got
09:45:49 <truebrain> emperorjake: awesome, that is perfect
09:46:54 <emperorjake> is the final version going to say "GOG not running" to match the steam one?
09:48:01 <truebrain> no; GOG doesn't implement that
09:48:27 <peter1138[d]> Wondering about ripping nanosvg apart to add 8bpp functionality...
09:48:49 <peter1138[d]> It's only 3000 loc 🙂
09:51:09 <_zephyris> What would you want to add specifically?
09:51:14 *** thelounge345 has joined #openttd
09:55:23 <peter1138[d]> 11944 supercedes 11937 right?
09:55:38 <truebrain> I still think 11937 can be very useful, to initialize the seed at a sane moment
09:55:43 <truebrain> but it does remove the priority of the PR
09:57:27 <truebrain> emperorjake: in a bit more detail; the other SDKs allow us to prope before we initialize whether the platform is online. What GOG did, is set a timeout on that of 30s
09:57:37 <truebrain> so GOG we just assume to be always online, and unload when it turns out it isn't
09:57:40 <truebrain> bit sad, but .. yeah
10:04:26 <truebrain> I might make an API change to still allow GOG to say: platform not running .. hmm .. something for this weekend 🙂
10:05:46 <peter1138[d]> _zephyris: Some way to directly specify a palette palette index, or perhaps a range. Mapping from rgb to 8bpp is too limited.
10:11:21 <peter1138[d]> Something like `data-palette="CC1"` or `data-palette="239"`
10:18:26 <v453000[d]> feature request: expose the Control modifier key to hotkeys.cfg please :d
10:19:07 <locosage> oh, I have a patch for that xD
10:19:51 <emperorjake> Yes please, it's annoying as a Mac user who swapped around his modifier keys to make it more normal
10:19:55 <locosage> though kinda going nowhere atm unfortunatelly
10:20:32 <locosage> but already available in citymania client ;)
10:20:48 <v453000[d]> citymania client for mac where 😛
10:21:11 <v453000[d]> sure already there, just asking 🙂
10:21:36 <locosage> it probably even works xD
10:24:41 <truebrain> v453000[d]: How to tell you are a Mac user without telling you are a Mac user 😛
10:24:41 <v453000[d]> it's a little special though
10:24:53 <truebrain> ah, the lovely blue 🙂
10:24:59 <locosage> ugh, it's something about hardware acceleration iirc
10:25:02 <truebrain> think we fixed that with the 13 series 🙂
10:25:12 <truebrain> but clearly we did not 😛
10:25:21 <v453000[d]> can I toggle something to fix this?
10:25:47 <locosage> try game options -> hardware acceleration
10:25:49 <v453000[d]> ah yes hardware acceleration
10:25:55 <truebrain> ah, yes, fixed with nightly 🙂
10:25:57 <truebrain> will be fixed in 14 🙂
10:26:07 <v453000[d]> well next step have a look at the hotkeys :))
10:26:38 <truebrain> that was really only in August I fixed that? Damn ... time is a weird thing
10:27:32 <locosage> hotkeys.cfg don't quite understand modifier-only bindings
10:28:00 <peter1138[d]> truebrain: Someone's been messing with daylength.
10:28:29 <v453000[d]> Problem is I need to switch the ctrl and the apple key :d
10:28:32 <v453000[d]> or whatever that's called
10:29:23 <v453000[d]> oh that might be Alt
10:29:26 <emperorjake> I did a similar thing, I remapped fn to command because that's where the ctrl key should be
10:29:26 <v453000[d]> christ this is a ride
10:29:29 *** tabytac has quit IRC (Quit: User went offline on Discord a while ago)
10:29:49 <locosage> I don't have mac so I've no idea how are those keys mapped unfortunately
10:29:53 <truebrain> I haven't touched a Mac in a while, why isn't the control available / possible? (I just don't have a clue)
10:30:43 <v453000[d]> Hmm, well it's an improvement to set Alt instead of Ctrl, but to really restore the Proper behavior I'd have to map it to the Option
10:31:31 <emperorjake> In MacOS, the Command key does what the Control key normally does. But in MacOS settings you can remap modifier keys to different ones but OpenTTD doesn't seem to recognise that for some reason
10:31:57 <locosage> well, it should be pretty simple patch to add option key but needs mac for testing
10:32:03 <emperorjake> so in hotkeys.cfg I was able to change all the key comninations to adapt, but it doesn't apply to the modifier keys
10:32:08 <truebrain> Isn't on a Mac the keys also: "control", "option", "command", similar to my "CTRL", "Windows key", "ALT"?
10:32:47 <truebrain> (sorry, I just always hear MacOS users complain about it; just never understood what the problem is 😄 #dare-to-ask)
10:32:58 <emperorjake> the tricky part is the Mac "control" key isn't equivalent to other OSes
10:33:16 *** ahyangyi has joined #openttd
10:33:16 <ahyangyi> The "right click" on Windows is often emulated by "ctrl+click" on Mac, especially when their mice had only one key
10:33:20 <emperorjake> because Mac "command" is equivalent to control, and is used for cmd-c, cmd-v etc.
10:33:55 <truebrain> emperorjake: owh, yes, I remember I had to retrain my mussle memory there
10:33:59 <v453000[d]> Basically in MacOS settings, I have flipped Control and Option in order to get basically everything to work consistently with how windows did it. However, openttd doesn't let me do the reverse switch back 🙂
10:34:10 <emperorjake> hence why the fn-key on my Mac is remapped to Command, so I can use the usual key combinations the same way as ctrl-c, ctrl-v etc.
10:34:11 <locosage> v453000[d]: btw, while at it try mapping remove and function to different keys, you can remove signals and stations that way ;)
10:34:13 <v453000[d]> Yeah I don't see replacing my muscle memory with ctrlC/V
10:34:21 <emperorjake> because hitting command-C is awkward and hurts my linky
10:35:43 <v453000[d]> also the symbols are impossible to remember which is which
10:35:54 <v453000[d]> DP: if you'd figure it out, I can offer testing it :)))
10:36:13 <truebrain> tnx for explaining; I understand a lot more what is happening 😄
10:36:15 <emperorjake> on my old Mac I physically swapped the fn- and control keys lol
10:36:40 <emperorjake> the new one is much thinner and I didn't want to break it
10:37:04 <locosage> but I'll look into mapping option
10:38:29 <locosage> is it possible to get mac vm on linux host btw?
10:38:53 <peter1138[d]> So many modifiers 😮
10:39:46 <ahyangyi> TBH globe is the only one where the name matches the icon
10:39:56 <ahyangyi> even if I also don't know what it does
10:40:13 <emperorjake> It can do stuff like change language input or bring up an emoji menu
10:40:18 <lamarr> option is like a railway switch :D
10:40:49 <emperorjake> My fn-key has the globe icon on it but I think that's a relatively new thing
10:41:07 <v453000[d]> oh this kind of globe
10:43:49 <truebrain> `_settings_client.gui.right_mouse_btn_emulation != RMBE_CONTROL ? NSEventModifierFlagControl : NSEventModifierFlagCommand`
10:44:00 <truebrain> seems you can enable mouse emulation to switch Control with Command
10:44:16 <truebrain> no clue why that depends on that settings, but ...... yeah ...... OpenTTD 😛
10:45:14 <locosage> and alt seems to check option flag
10:46:45 <xarick> 11944 breaks "restart" feature 😦
10:51:50 <truebrain> would be appreciated locosage ; keeps things revieable 😄
10:52:01 <truebrain> (and I am not joining the bikeshed)
10:52:20 <locosage> at the very least keep them rebaseable xD
10:55:18 <truebrain> I like the string-commit, to make it visible to the user how they mapped things
10:57:11 <_glx_> xarick: Will need more details, and probably shows how inconsistent random deviation was
10:57:53 <rau117> v453000[d]: Oh, by the way, what do you think about this PR? I think your opinion on this matter will be more valuable and important than mine.
11:05:20 <peter1138[d]> Remove non-path signals, problem solved.
11:07:24 <_glx_> Yeah, I think it's kinda expected, will see if it's possible to catch `restart` case
11:08:20 <_glx_> But it really shows how random random deviation was applied
11:11:16 <locosage> oh ffs, was looking for that right mouse emulation in the game but it's a macos-exclusive option apparently
11:24:35 <_glx_> We should let the system handle it
11:24:56 <_glx_> I think it comes from old macos version
11:25:32 <_zephyris> peter1138[d]: I still suspect equivalent behaviour achievable by XML pre-processing. Pre-process to change the colour of all objects with a data-palette XML tag to the corresponding RGB, anything without to solid blue, then rasterise non-anti-aliased. You'll need to handle stroke and fill separately BTW, so data-palette-stroke and data-palette-fill.
11:27:04 <rau117> peter1138[d]: *jokes aside, but everyone who really doesn’t like these signals can simply accept the fact that they are useful on some other gameplay mode and simply hide them*
11:27:56 <peter1138[d]> _zephyris: I'm not sure what converting TO RGB would achieve. We need the palette index when drawing the sprites.
11:28:31 <xarick> checking stuff from my old code... it deals with random deviation / restart better for some reason, the only part that failed was the start_date, which is no longer relevant today
11:28:36 <locosage> ideally you need rgb at the moment of drawing...
11:28:56 <_zephyris> peter1138[d]: Well, then convert back again, and you know that all pixels will exactly match palette entries. So simple nearest colour.
11:29:22 <_zephyris> pre-process XML -> rasterize non-anti-aliased to RGB -> 8bpp
11:29:42 <_zephyris> A workaround I admit, but presumably the intended result
11:30:45 <locosage> A wholly alternative approach would be to not involve palettes and 8bpp at all and convert palette animation to 32bpp LUT tables.
11:36:53 <_glx_> The only "wrong" thing I can see with restart is not the random deviation (which I think should be applied for reproducibility of OWNER_NONE random calls), but the "non reset" of settings when restarting
11:37:53 <truebrain> that only works if the old ai settings are still stored somewhere where it can be restored from 😄
11:39:19 <_glx_> Anyway if you really want a reproducible test, the ideal way is newgame->save->load
11:40:04 <truebrain> _glx_: btw, what does `newgame 1` running twice do
11:40:18 <truebrain> (sorry, can't test myself atm, so just being plain lazy)
11:41:29 <xarick> I also made random ai slots to go back to their Random AI status when doing restart, instead of remaining whatever AI it randomized to.
11:41:29 <_glx_> Events should be the same with `newgame 1` except the deviated settings
11:42:12 <truebrain> yeah, so when a settings was value A, after the first game start it gets A +/- B, and the next game it gets A +/- B +/- B
11:42:30 <truebrain> I should just look at the code btw, and not bug you with it 😄
11:42:44 <_glx_> That's what is happening yes
11:43:07 <_glx_> Maybe random AIs are no longer random too
11:43:34 <_glx_> But really it's not my change, it was broken before I think
11:43:41 <truebrain> owh, yes, absolutely
11:44:25 <truebrain> but that also means that if you start a game, and go back to the main menu, the settings of your AI are changed 😛
11:44:48 <_glx_> Hmm not in main menu I think
11:45:29 <_glx_> Because on start there's settings_newgame->settings_game
11:45:50 <_glx_> Dunno if it's applied on restart
11:46:40 <truebrain> oof, didn't know it was this tricky to get to the settings of an AI after start
11:46:47 <truebrain> needs to be done via the Debug window? 😄 Funny 🙂
11:47:30 <truebrain> _glx_: running `newgame 1` twice gives the same deviation 🙂
11:47:56 <truebrain> so indeed, `restart` should restore settings before restarting 😄
11:48:40 <truebrain> very odd it doesn't, tbh .. goes for any settings, that `restart` doesn't restore it
11:48:49 <truebrain> so it is more a `rebuild_terrain`
11:49:10 <truebrain> _zephyris: owh no you didn't!
11:58:43 <_glx_> I see nothing about that in this commit
12:03:37 <peter1138[d]> Random AI status is different from the random derivation stuff.
12:04:10 <peter1138[d]> The reason Random AI status is not reset is because "restart" does not apply new-game settings, and without that being applied, the AI set up is not changed from the existing running set up.
12:04:53 <peter1138[d]> But you kinda said that in all the scrollback I didn't read 😄
12:05:06 <truebrain> at least we agree 🙂
12:05:17 <_zephyris> Now I'm just being mean
12:05:46 <truebrain> stop breaking stuff ffs 😛
12:11:51 <xarick> I think I know where it is... it's in /* static */ void AI::Stop(CompanyID company)
12:15:21 <xarick> doing restart command kills all AIs, so AI::Stop is called and changes the config slot back to displaying random ai
12:15:58 <xarick> now as to whether this does repeat the same actions...
12:20:19 <xarick> yes! same random AI started! it works 🙂
12:20:56 <xarick> and I got like 50 Ais in the folder
12:24:36 <peter1138[d]> That'll happen if it doesn't switch back to Random AI too 🙂
12:28:05 <xarick> not exactly... the config slot remains that of the AI it randomized to
12:28:40 <xarick> I should make a PR... just need to do a few more tests
12:32:06 <talltyler> Thanks for the testing zephyris ❤️
12:32:27 <_zephyris> talltyler: No problem! Sorry for breaking things
12:32:44 <_zephyris> Best guess, I think your timing calculation for trains must be off
12:32:53 <truebrain> he wrote something about idiots and breaking stuff in his PR, so .... 😛
12:33:11 <_zephyris> I'm a perfect test idiot 🙂
12:33:11 <talltyler> No, it’s exactly what I need. I suspect it’s something to do with getting a signal out of the depot, actually.
12:33:23 <_zephyris> Yeah, that'd make sense
12:33:51 <_zephyris> Oh, could work out as a ~60 sec extra time in the depot
12:34:34 <talltyler> The “calculate departure” function assumes the vehicle will successfully leave the depot immediately, so if something else prevents it from doing so (like not getting a signal) it’ll lose its departure time and have to wait until the time it just set 🙂
12:35:01 <_zephyris> Ah, that explains the instant deadlock in my train reversal scenario too
12:35:31 <talltyler> Reversing a train should also reset the separation data, I think. Forgot that case.
12:35:43 <truebrain> talltyler: ghehe; that that is a fun little bug 😄
12:35:54 <_zephyris> Does a vehicle being lost also reset the separation data?
12:35:58 <talltyler> And thanks for the wording suggestions too, it’s very appreciated
12:36:12 <talltyler> _zephyris: Not yet! I’ll add that too.
12:36:46 <talltyler> truebrain: You should have seen the infinite while loop caused by a crashed vehicle… that was not such a fun bug 😛
12:36:47 <_zephyris> That was my other pathological case. If one of a vehicle gets lost/stuck, then when it's route is restored and it gets back to the depot then the whole vehicle group end up with a massive wait.
12:37:25 <talltyler> Yeah, best to avoid that 😄
12:38:06 <_zephyris> (Not sure if deadlocked train signals count as lost - you'd also get the case that a signal deadlock would trap trains, then when you release them they'd end up waiting in the depot forever)
12:38:32 <_zephyris> Figuratively forever 🙂
12:39:05 <_zephyris> Anyway, last little comments were: Vehicles should probably say "Wait & service at X depot" for their destination, currently they say "Service at X depot". Ungrouped vehicles with identical orders don't unbunch (which is reasonable as intended behaviour).
12:39:21 <_zephyris> And I should probably stop my extended bugfix lunchbreak and do some work!
12:40:20 <_zephyris> I hope it's all useful, I'd love to see this in vanilla
12:45:19 <talltyler> _zephyris: I don’t consider this a measurable status, unlike a vehicle that is lost. Trying to detect outliers in travel time sounds like a good way to introduce corner case bugs 🙂
12:46:20 <talltyler> _zephyris: Yeah, I will add something to the vehicle status as it’s headed for the unbunching depot. Vehicles without shared orders do bot interact, by design. That’s a player skill issue 😛
12:46:55 <_zephyris> talltyler: Yeah. Any manual intervention (turn around, go to depot, ignore signal). I'm sure you're already thinking that though!
12:47:31 <_zephyris> talltyler: Totally reasonable IMO. Just wanted to point it out.
13:10:46 <peter1138[d]> talltyler: You could have it so that if ever a vehicle has the lost flag, its journey time doesn't count that round. Not sure if that's feasible or necessary.
13:12:12 <talltyler> That's my plan, yeah. Invalidating a vehicle's travel time isn't particularly disruptive (if the vehicles are already spread out, you won't even notice it) so I am quite liberal with that hammer
13:12:57 <talltyler> I quite like "wait for unbunching." I bet translators will have issues with it, but we'll burn that bridge when we get to it
13:21:30 <peter1138[d]> Of course IRL they can unbunch anywhere, but...
13:21:53 <peter1138[d]> In the interests of dead-lock reduction.
13:22:10 <truebrain> Maybe in the future an advanced setting that also allows unbunching at stations
13:22:14 <truebrain> with a I KNOW WHAT I AM DOING toggle 😛
13:24:03 <talltyler> Real drivers are smarter than OpenTTD vehicles 😄
13:31:49 <emperorjake> truebrain: Yes please
13:31:57 <_jgr_> Using "unbunch" as a verb like this feels very weird to me, but I can't really think of anything better
13:32:48 <_jgr_> As for stations, if the user explicitly sets that tag on a station order, presumably thr intent is clear without a setting
13:33:53 <emperorjake> Giving it a test right now with ekranoplans on Mars, but it seems to be having a little trouble keeping them well separated
13:35:07 <truebrain> _jgr_: I was more thinking about a setting whether to allow that or not .. although that might be a bit childish, it might help new players to not do something stupid 🙂
13:36:46 <peter1138[d]> Yeah because none of them add every single NewGRF they can find to a new game 😉
13:37:21 <emperorjake> Unbunching used in Cities Skylines
13:38:07 <locosage> wth is even going on there xD
13:39:08 <_jgr_> emperorjake: I'm not saying it's wrong, it just sounds strange to my ears, it may be a regional thing. I've never heard it used like this
13:39:13 <emperorjake> it goes over 100% because that's the extra time that it takes to unbunch
13:39:20 <truebrain> peter1138[d]: NEVAH
13:40:30 <emperorjake> It's one of those words that looks weirder the longer you look at it
13:41:33 <talltyler> Yeah I've already been looking at it too long this morning 😄
13:42:30 <_jgr_> I'd tend to go for spread out as the opposite of bunch up, but that is prime bike shed territory, and doesn't really neatly go in a button
13:42:53 <talltyler> `Distribute` is another synonym
13:43:53 <truebrain> Distribute, as in, cargo distribution? 😛
13:44:44 <talltyler> Making this action work at stations is probably "future PR" territory. It will never work for road vehicles without pathfinder improvements, and I'm hesitant to introduce an inconsistency like that
13:45:02 <truebrain> how is the PF involved?
13:45:29 <talltyler> Road vehicles stack up behind each other in the same platform and don't spread themselves out nicely
13:45:45 <truebrain> sounds like a completely unrelated problem 🙂
13:45:48 <Eddi|zuHause> overtaking at stations
13:45:56 <talltyler> Oh agreed, unrelated but would block this 🙂
13:45:58 <_jgr_> talltyler: I thought that was resolved already?
13:46:01 <Eddi|zuHause> or flipping two vehicles in the sequence
13:46:30 <talltyler> Not resolved in my experience 🤷
13:47:10 <talltyler> Anyway, it's safe for ships because they don't collide, but airplanes could potentially be a problem if they get out of order.
13:47:32 <talltyler> Same goes for trains
13:48:27 <talltyler> "Out of order" breaking things would be an algorithm bug to be sure, but potentially a hard one to reproduce 🙂
13:48:56 <_jgr_> I've previously had issues with that in my implementation
13:49:32 <talltyler> I play on some JGRPP servers and use yards and Scheduled Dispatch, sometimes with a 24-hour timetable and Peaks & Troughs, so I totally get the "I want to store my trains in yards" desire. But I don't see why you can't send a train to a depot, then have a timetabled wait in the yard 🙂
13:50:14 <talltyler> Alternatively, I use yards for timetabled separation in vanilla right now. They already work 😄
13:50:50 <_jgr_> You can get around ordering issues my taking into account the current order index as the first part of the sort key
13:52:56 <truebrain> Drive-through depots when?
13:54:36 <truebrain> somehow the +6070 / -1401 makes that a bit scary 😛
13:54:55 <truebrain> but I assume talltyler fixes that before this Saturday
13:59:45 <peter1138[d]> So is 78 commits.
14:00:40 <peter1138[d]> Smaller chunks needed 🙂
14:01:07 <Eddi|zuHause> talltyler: i'm always building my tram terminals in a way the trams can unbunch, but that doesn't work with halftile-vehicles, only fulltile articulated trams.
14:01:15 <peter1138[d]> Phew, fixed my CI 😄
14:02:02 <Eddi|zuHause> otherwise you get a late tram stuck behind an on-time one quite frequently
14:11:22 <talltyler> #9577 is an intermediate step torward drive-through depots, and would be a big improvement by itself for a number of reasons including upgrading from rail->monorail->maglev
14:12:35 <talltyler> Like most big projects it can be broken into smaller chunks, like #10691
14:12:56 <xarick> 11937 was closed? 😦 that was the correct fix
14:13:02 <talltyler> I am working with J0anJosep on these, but obviously not before Saturday 😛
14:24:35 <talltyler> It's funny how much you don't notice until you are forced to look at it. Pop quiz: Which vehicles have "turn around" buttons on their GUIs?
14:25:31 <Eddi|zuHause> i think all of them except planes?
14:25:46 <talltyler> Planes do not...but there's one more
14:25:59 <Eddi|zuHause> i'm unsure about ships
14:26:22 <talltyler> I went searching for the command to turn a ship around, couldn't find it, then booted up OpenTTD to discover that yeah, there isn't one
14:27:01 <Eddi|zuHause> i was leaning towards they have one
14:28:55 <peter1138[d]> xarick: 11944 was merged though which made 11937 moot.
14:33:55 <_glx_> And the real issue is starting an AI affects the game settings, while the running AI should have it's own copy
14:56:34 <peter1138[d]> oof, house cold.
15:00:59 <locosage> does anyone see the difference?
15:04:02 <locosage> well, nvm, that's not how it looks on screen at all
15:04:43 <xarick> looks like I was wrong
15:05:07 <xarick> restart doesn't preserve random deviation even before 11944
15:05:35 <xarick> let me see 13.4, what it did
15:06:21 <peter1138[d]> As I understand it, 11944 does random deviation when the script starts, rather than when the script initialises?
15:06:54 <xarick> 13.4 apparently works the intended way
15:07:58 <xarick> I don't know why, it just works
15:08:14 <xarick> load save game, same values, type restart, same values
15:08:15 <peter1138[d]> Probably due to the start date system being different.
15:09:20 <xarick> rerolls the same values for random deviation
15:09:40 <xarick> it's what I expect from doing "restart"
15:17:08 <locosage> locosage: oh,lol, there is no difference, I compiled the same code by accident xD
15:17:17 <peter1138[d]> I have an idea that means that setting up random deviation needs to happen after map generation is complete.
15:18:09 <peter1138[d]> I guess setting up the randomizer can still be done before, so it won't really affect anything. Hmm.
15:30:29 <locosage> ok now the difference is visible but can anyone spot it?
15:30:34 <locosage> and I don't mean farm fields :p
15:36:49 <peter1138[d]> Well the tiles switch to grass in a different order.
15:37:09 <peter1138[d]> And it's weirdly jumpy at the end.
15:38:01 <locosage> well, yeah, it's different order and would even be different in two masters as I didn't start at the same tick
15:38:09 <locosage> but is in noticeably different? ;)
15:39:24 <locosage> well, procedural trees branch PR actually but it's the same
15:52:52 <peter1138[d]> Main issue with procedural trees is it's adding quite a lot of code.
15:53:25 <locosage> 150 lines isn't exactly a lot ;p
15:54:19 <peter1138[d]> Would be more if you properly wrapped the tables.
15:54:27 <peter1138[d]> Do they need to manually built?
15:54:49 <peter1138[d]> How are the values derived?
15:55:07 <peter1138[d]> And... why are there two tables.
15:55:44 <locosage> it mainly just iterates tree growth algo with some adjustments
15:56:05 <locosage> and two tables because two different growth modes
15:58:28 <locosage> trees grow differently when they can spread and when they can't
15:58:35 *** Wormnest has joined #openttd
15:59:50 <locosage> it's possible to build these tables on start or smth but that would be even more code than tables
15:59:57 <locosage> and way more potential bugs
16:00:16 <locosage> and needs to be mp synced
16:31:35 <xarick> I wish I was good at this. Solve the problem on my own 😐
16:34:58 <merni> `struct Order` has a member `uint16_t max_speed`. What unit is this in?
16:40:17 <Rubidium> I'd reckon the vehicle type's units
16:41:24 <Rubidium> though I might be wrong
16:41:38 <Rubidium> in which case it could also be km-ish/h
16:42:18 *** simonmb has joined #openttd
16:42:18 <simonmb> locosage: The right version creates grass next to existing grass?
16:45:33 <locosage> on the right side there is a pattern, left is fully random
16:46:44 <merni> Rubidium: how would vehicle type's units work in case of shared orders?
16:46:59 <merni> between different types of vehicle (possibly between different newgrfs)
16:47:12 <peter1138[d]> You can't share orders between different vehicle types.
16:47:26 <merni> maybe that is a jgr feature
16:48:00 <Rubidium> JGRPP allows ships and trains to share orders?
16:48:30 <merni> I haven't tried such a thing
16:49:00 <merni> but you can share orders between different kinds of trains from different newgrfs
16:49:08 <merni> is that not what you meant by "vehicle type"?
16:49:15 <peter1138[d]> They aren't different vehicle types.
16:49:22 <merni> what's a vehicle type then
16:49:32 <Rubidium> no, it's the distinction between aircraft, trains, road vehicles, ships, disaster vehicles
16:49:47 <merni> what are the units each has?
16:50:22 <merni> hm I guess I could find out with printf
16:53:21 <peter1138[d]> There's some functions to convert internal to display speed.
16:53:21 <merni> kind of weird that this is stored in a plain uint16 without any info about the unit
16:54:09 <merni> feels like a place for a typedef
16:57:15 <Rubidium> something like DestinationID ;)
16:57:20 <_jgr_> The GetMaxSpeed/SetMaxSpeed wrappers of struct Order say what the unit is
16:58:18 <_jgr_> For the most part you're not meant to use the internal fields directly
16:58:33 <merni> I didn't look at that comment closely enough
16:58:52 <merni> _jgr_: I wasn't trying to; but I saw that the function just returned the value of the field
17:10:38 <_jgr_> They're a pain in the rear, even if they do make it easier to get started in the game
17:12:01 <merni> is there a full list of conditions under which they are created?
17:13:02 <_jgr_> The GVF_SUPPRESS_IMPLICIT_ORDERS flag is to place to look
17:15:38 <_jgr_> Broadly they're disallowed for go to depot orders, and conditional orders
17:16:27 <_jgr_> Otherwise they're added as necessary when calling at a station when the non-stop flag hasn't been set on the order, for ground vehicles
17:17:43 <merni> and for timetables they are completely ignored right?
17:18:07 <merni> ie. the travel time before the next manual order is used as the travel time for the whole section between manual orders?
17:20:00 <_jgr_> That sounds about right
17:21:06 <merni> hm. Then it makes sense to me to exclude all implicit orders from an export
17:22:24 <_jgr_> Seems reasonable, they're not really useful for any kind of timetable analysis
17:24:55 <talltyler> Now open for testing, round two! 😄
17:25:18 <talltyler> Big thanks for _zephyris for all the bugs you found, and good suggestions. ❤️
17:25:32 <xarick> turns out random deviation isn't entirely perfect in 13.4 either when using restart
17:25:41 <xarick> in the case of random ai
17:26:59 <peter1138[d]> Sleepy again, bed time?
17:27:22 <merni> in my time zone at least :P
17:29:18 <_zephyris> talltyler: Awesome. Let's see if I can break anything 😉
17:39:06 *** HerzogDeXtEr has joined #openttd
17:40:34 <_glx_> xarick: as I said in the PR description, random deviation was inconsistent
17:41:51 <_glx_> now it happens only at one predictable point
17:42:22 <_glx_> of course it's still not perfect due to how settings are handled, but it's still better
17:44:11 <xarick> there is one point where interactiverandom needs to be used
17:45:21 <xarick> i'm looking at some of the positive things of 13.4
17:46:02 <xarick> "newgame" vs "newgame" results in different deviation values
17:46:20 <_glx_> that's because game settings are modified
17:46:25 <xarick> however "newgame 1" vs "newgame 1" should result in equal deviation, nevermind 😦
17:47:03 <_glx_> deviation is the same, what's different is the value before deviation
17:48:26 <xarick> borderline complexity to reproduce these steps
17:49:15 <_glx_> using `start_ai <AI>` before `newgame` will also change the game settings
17:51:11 <xarick> I'm starting to take notes, because it's very easy to lose train of thought
17:52:24 <_glx_> say you configured "simpleAI" in slot 1, with some delay before start, if you type `start_ai AdmiralAI` before "simpleAI" start, the slot 1 will be overwritten by AdmiralAI
17:52:47 <_glx_> same happens with random deviation
17:53:27 <_glx_> and when a RandomAI starts, its slot is overwritten too
17:54:13 <_glx_> because ai_config handling is a mess
18:00:37 <peter1138[d]> Gradient is a bit bland but... smooth at least :p
18:13:07 <andythenorth> FWIW, I've found that using a single roadstop can force unbunching
18:13:12 <andythenorth> as it rate limits
18:13:35 <andythenorth> requires a timetable order with 'wait 10 days' or so, and a queue of vehicles will form behind the stop
18:16:28 <belajalilija> peter1138[d]: May i suggest shading it in the same way the floppy disk is shaded, it would make them look like pleasant little golden ingots
18:36:12 <DorpsGek> - Update: Translations from eints (by translators)
18:36:53 <peter1138[d]> My First Wrench, lol. Terrible drawing.
18:41:49 <Eddi|zuHause> dunno, looks a bit narrow?
18:46:57 <peter1138[d]> I think it'd definitely break :p
18:48:51 <locosage> oh, I know a perfect icon for settings...
18:52:18 <locosage> symbolizes NewGRFs, GS and game settings working perfectly together 🤭
18:57:12 <peter1138[d]> These ones are just for testing anyway.
18:57:24 <peter1138[d]> The main target for me is window decorations.
19:03:59 <merni> locosage: is this one of those gear layouts which cannot physically move :p
19:04:33 <merni> ldplviaGitHub: Because the save format is astronomically more complex...
19:05:34 <Eddi|zuHause> locosage: a classic.
19:08:41 <locosage> merni: it was kinda designed to be read by external tools
19:08:50 <locosage> there was even a script to convert it to json somewhere
19:12:40 <_zephyris> talltyler: I don't think this unbunches correctly. It's quite contrived though
19:20:28 <talltyler> _zephyris: It’s hard to tell at such a small scale. I’d suggest making the loop bigger so you can see if the trains are bunched.
19:33:20 <_zephyris> I haven't managed to break anything yet...
19:53:27 <andythenorth> drive through depots next? 😛
20:01:08 <wensimehrp> peter1138[d]: I think the outline is too thick...
20:01:44 <peter1138[d]> 1 scaled pixel wide at 45° does that.
20:02:23 <andythenorth> fish pie for tea?
20:24:10 <_zephyris> talltyler: looks great 🙂
20:34:11 *** nielsm has quit IRC (Ping timeout: 480 seconds)
20:46:00 <peter1138[d]> What is this meant to be...
20:47:33 <_glx_> picture is too small for the actual context
20:48:27 <peter1138[d]> Global autoreplace protect. I think it's a shield.
20:49:20 <_glx_> ah yeah most likely a shield
21:01:00 *** Flygon has quit IRC (Quit: A toaster's basically a soldering iron designed to toast bread)
21:08:49 <peter1138[d]> Might be helpful to explain what everything else if you want someone else to look at it.
21:19:22 <xarick> reproduction steps summarised. Step 1, you're in the main menu and configure 3 AIs like described, you look at the 2 settings that have random_deviation != 0. They're on their defaults: 100 / 100
21:20:24 <xarick> Step 2, start a new game with seed 1
21:21:04 <xarick> wait for the first 2 AIs to start. take notes of their deviated values, then create a savegame
21:21:57 <peter1138[d]> You can add comments to your gist you know 🙂
21:23:01 <_glx_> nice you just confirmed what we were saying 😉
21:25:46 <truebrain> So, this weekend beta1 or RC1? 🙂
21:28:09 <_glx_> at least your gist seems to confirm the fixed place for random deviation is an improvement, for a given config you always get the same result, while before it was les predictible
21:28:48 <truebrain> talltyler: would you say you still plan for JSON Town import for 14.0? Might be good to postpone that?
21:28:53 <talltyler> Rubidium suggested beta1 to avoid having to backport bugfixes, if I recall correctly
21:29:17 <truebrain> Yeah, but with all the automation backporting isn't all that difficult anymore
21:29:37 <truebrain> More the question is: feature freeze or not 🙂
21:29:45 <_glx_> yeah beta makes more sense, lot of new features not really tested because people don't use nightlies
21:29:47 <talltyler> JSON town import needs a bit of help answering review questions. I could get it done pretty quickly if those were resolved 🙂
21:30:12 <truebrain> I would not add it in 14.0 as it had very low testing
21:31:10 <truebrain> The advantage of branching is that we can continue with features in master, without adding even more last minute features in 14.0 😄
21:31:27 <truebrain> But we can also hold off merging features till we branch
21:33:36 <_glx_> see how long it took to get enough nightly surveys
21:33:38 <xarick> i think i made a few typos with 13.4, maybe I should retest
21:33:41 <truebrain> What are the odds we finish that for 14.0?
21:34:26 <truebrain> _glx_: Last 2 weeks we actually had enough nightly users 🙂
21:35:14 <truebrain> Same question, will we do that for 14.0? 😄
21:35:38 <_glx_> hmm isn't that abusing the spec ?
21:36:10 <truebrain> And is there any issue/PR not marked 14.0 that we should do in 14.0?
21:36:13 <belajalilija> truebrain: It would be so nice to see this fixed
21:36:28 <peter1138[d]> I can dig out my patch that I started for 11470.
21:36:37 <truebrain> belajalilija: Nice is not the question, sadly. Anyone actually doing the work is 😄
21:37:05 <truebrain> peter1138[d]: Sounds good. Someone marked it 14.0, so making that goal would be good 🙂
21:37:07 <belajalilija> They’d be a very nice person then xd
21:38:57 <truebrain> We do need some reviewers for a few bugs I fixed if we can
21:39:22 <truebrain> Relatively trivial PRs, I think 😛
21:39:52 <truebrain> Other than that .. just matter of getting the unbunching or what is it called in, and prepping changelogs
21:40:17 <truebrain> I will take care of the latter on Saturday
21:40:55 <truebrain> Maybe someone can already give some thought on the news post .. do we want to spoil 14.0 and list all features we added? 😄
21:42:44 <_glx_> don't we just destroy the game ?
21:44:14 <peter1138[d]> Don't forget we also never add anything.
21:44:18 <truebrain> Only when I am here 😛
21:45:47 <xarick> i would like to see some... nvm
21:49:54 <xarick> I ask too much, but: 10490 and 11840 at least
21:53:45 <locosage> hm, I mark tile dirty but it gets drawn 5-10 ticks later is that how it's supposed to work?
21:53:58 <locosage> with 165hz I'd think it would be next tick
21:55:19 <peter1138[d]> That one was waiting on its dependent PR but best off being available at least, I guess.
21:55:51 <_glx_> tiles are not all redrawn in the same tick
21:57:28 <truebrain> locosage: To remember, viewport sorting etc is still done in the game thread
21:58:04 <truebrain> I do have a patch for that .. just never finished the bugs in it 😄
21:58:47 <_jgr_> I've got viewport sorting and sprite blitting in threads in my branch
21:59:23 <truebrain> Guess we need to steal that 😛
21:59:24 <_jgr_> One of the few useful things I've been able to move to threads
21:59:47 <_glx_> yeah it's hard to use threads with openttd
22:00:04 <truebrain> I remember it was a bit tricky with some assumptions when things were done etc .. but if you solved that, sounds great
22:00:46 <peter1138[d]> Could be, 2 months to iron it out.
22:01:05 <locosage> it being in one thread is even more reason to expect next tick
22:01:07 <LordAro> 2 months to discover if it breaks one of mb's GRFs
22:01:11 <locosage> how would it even get out of order
22:01:24 <locosage> also it's a tiny game, it renders a frame under 1ms
22:03:16 <truebrain> peter1138[d]: any other PRs from you that you would like done for 14.0?
22:03:39 <peter1138[d]> I've kinda given up on that.
22:04:43 <peter1138[d]> Wentbourne begs to differ on 1ms.
22:04:57 <truebrain> I notice it is sometimes a bit easy to miss one of your older PRs 🙂 will give it a look this weekend 🙂
22:05:04 <locosage> well, I'm not talking wentbourne :p
22:05:14 <locosage> I'm talking this tiny test game I have
22:05:58 <peter1138[d]> Anyway, marking tiles dirty will wait for the end of the game tick at least.
22:06:20 <peter1138[d]> Partially drawing during the current tick doesn't seem like a good idea.
22:06:58 <locosage> actually, that's not 1ms, that's 0.01 ms
22:07:55 <locosage> and somehow this averages to 0.06 xD
22:08:31 <locosage> though that's 1ms peak
22:08:39 <locosage> well, whatever, it's pretty freaking fast xD
22:08:48 <locosage> it's not paused but it's 128x128
22:09:12 <_glx_> hey is it a feature of new ship pf to not move the ship if it has no orders ?
22:11:00 <_glx_> ah no, same happens in 13.4
22:11:18 <peter1138[d]> That might not be entirely intended 🙂
22:11:43 <truebrain> The captain just gives up "I am done with this crap, I want block signals"
22:14:37 *** gwyd4016 has joined #openttd
22:14:37 <gwyd4016> What would be the expected behaviour?
22:14:56 *** keikoz has quit IRC (Ping timeout: 480 seconds)
22:15:02 <LordAro> fire, brimstone, cats and dogs living together
22:15:14 <truebrain> And ofc the opportunity to bring it up over and over and over again 🙂
22:15:48 <andythenorth> pitchforks, using the animated fire cycle
22:15:55 <LordAro> store a copy on andy's MBP
22:16:14 <truebrain> On his DHCP server?
22:16:21 <truebrain> (Did we miss any meme?)
22:16:30 <locosage> pitchfork as disaster vehicle!
22:17:31 <LordAro> i always get them and voxels muddled
22:18:33 *** Wormnest has quit IRC (Ping timeout: 480 seconds)
22:22:23 <talltyler> truebrain: I still need to write the in-game helptext about our time system that you requested. (We can backport it to the help menu, since it probably won’t happen before Saturday). It might be nice to also publish that as a news post before April 1st as a bit of a deep dive. 🙂
22:23:23 <truebrain> Sounds good. But what do we do on the beta1 post?
22:24:26 <talltyler> I also added #11917 to the milestone, but with that the resolution might be “no” or “not in its current form” and not “merged before Saturday” 🙂
22:25:00 <talltyler> truebrain: Well, if we’re looking to get stuff beta-tested, we need to tell people what’s new so they can test it 😄
22:25:07 <talltyler> No point worrying about spoilers
22:25:24 <truebrain> Makes for a massive post 😛
22:25:40 <peter1138[d]> Surely the post is "we didn't add anything"
22:25:52 <truebrain> peter1138[d]: For the memes!
22:25:54 <_jgr_> So long as the more important stuff is towards the top it shouldn't be a big problem
22:26:03 <talltyler> “We didn’t add anything, here’s our empty changelog to prove it”
22:26:29 <truebrain> Maybe call out a few features we want tested
22:26:47 <truebrain> ShipPF, unbunching, daylength, ..
22:26:58 <talltyler> Unbunching can is sort of already written, we can copy a lot from the PR
22:26:59 <truebrain> Just a short list without a lot of context
22:27:35 <_jgr_> The font stuff is worth highlighting
22:27:48 <_glx_> oh yeah that's a nice feature
22:28:03 <talltyler> I can write something about the time changes, not the full deep dive or in-game helptext but enough to explain it in the news post
22:28:10 <truebrain> _jgr_: But doesn't really need testing? So maybe more for the 14.0 post?
22:28:46 <truebrain> We have a weird issue this release that there are just too many new features 😛
22:29:47 <_glx_> hmm GS and the improved text handling
22:29:59 <talltyler> Something I’ve seen other games do is break up the features with a series of deep dive posts. But of course those people get paid to do the unfun job of writing 😉
22:30:16 <_jgr_> _glx_: Ideally the user shouldn't see anything different at all there
22:30:18 <peter1138[d]> _glx_: "we fixed the thing we broke last time"?
22:30:46 <_glx_> I think some GS are still being killed by it
22:30:53 <talltyler> We absolutely don’t need it explained in depth, but if zephyris actually wanted to write about the new font and its design process, I bet people would read it
22:31:16 <truebrain> The 14.0 post is up and accepting updates 🙂
22:31:35 <truebrain> But for the beta1 we just list what we want tested
22:31:47 <talltyler> Oh, and did we ever discuss when we might switch the bundled graphics set from OpenGFX 1 to OpenGFX 2? Is there more to do?
22:32:06 <talltyler> truebrain: I will add my time stuff tomorrow or Saturday
22:32:14 <truebrain> talltyler: Unrelated to releases btw; can be changed at any time
22:32:17 <peter1138[d]> It needs more bug reported because there are definitely visual glitches still 🙂
22:32:30 <truebrain> talltyler: No rush; you have 2 months
22:32:39 <peter1138[d]> (And the scrollbar buttons are too big/too much padding)
22:32:54 <talltyler> Don’t you want to do the beta1 post Saturday though…?
22:33:19 <talltyler> Oh, you mean the full release post
22:33:37 <talltyler> I will write something for beta1 tomorrow or Saturday then 😄
22:34:08 <talltyler> I expect GRF and GS authors will be wondering how to adapt their stuff for the new time changes
22:34:28 <truebrain> Make that an unrelated post then
22:34:47 <talltyler> FIRS helptexts are inaccurate now, for example… sorry andythenorth 🙂
22:35:12 <truebrain> Sounds better in general, just a post about how it works etc
22:35:31 <truebrain> So we can point to it from different places in the release cycle
22:36:00 <xarick> I will take a better look at the time features post launch
22:36:01 <talltyler> “What NewGRF and AI/GS authors need to know about OpenTTD 14”
22:36:23 <truebrain> "What you need to know ..." 😛
22:36:25 <talltyler> Then for beta1 I will focus on what players need to know
22:36:33 <_glx_> I think in most cases AIs don't need to care
22:36:34 <truebrain> Combine players andnl authors in 1?
22:37:16 <truebrain> Well, just cook something up talltyler ; it will be pretty 🙂
22:37:18 <xarick> and that big list of order/group additions to GS'es
22:37:37 <talltyler> _glx_: Most cases, yes. But CivilAI at least has brake vans until a certain year, and that will never happen in wallclock mode because the game starts at period 1 🙂
22:37:50 <truebrain> _glx_: unrelated to 14.0 stuff, got anywhere with UI changes for AI config? 🙂
22:38:08 <_glx_> still thinking about how it should look
22:38:53 <xarick> perhaps the removal of start_date worth mentioning?
22:40:42 <_glx_> like showing the value as [entered_value - deviation, entered_value + deviation] with accounting for min_value and max_value when script is not running, and just the actual value when it's running
22:41:13 <truebrain> Just know that small changes already help
22:41:23 *** Wormnest has joined #openttd
22:41:32 <_glx_> so when you enter a value during config it shows you it will be in that range
22:41:33 <truebrain> Like that to get into settings ingame via the debug window is just weird 😛
22:41:45 <truebrain> _glx_: Does sounds really nice 🙂
22:44:04 <_glx_> oh indeed the config slot is disabled once the script is running
22:44:31 <_glx_> maybe it should change the color and disable select script only
22:47:11 <_glx_> oh and it's also disabled if you used `start_ai` for more than max_no_competitors
22:47:37 <truebrain> It needs a polish 😄
22:54:12 <xarick> can I really beg something?
22:56:42 <peter1138[d]> You're begging us to forget you?
22:57:07 <xarick> my disturbing thoughts getting the best out of me
22:58:48 <xarick> I fear anything I say is gonna be irrelevant, and I struggle to overcome it
22:59:53 *** HerzogDeXtEr has quit IRC (Read error: Connection reset by peer)
23:08:17 <xarick> just got one other fmt crash. I was exiting OpenTTD
23:09:17 <xarick> crashed when trying to send survey stuff
23:10:00 <LordAro> xarick: did you report that as a bug yet?
23:10:05 <LordAro> looks like the same as the other one
23:10:15 <LordAro> (underlying cause of the HTTP error not clear, of course)
23:10:36 <xarick> no, I haven't. maybe i should
23:12:29 <xarick> it doesn't exactly crash. I can click continue and it still runs fine enough, exits cleanly
23:19:13 <xarick> it's a semi-crash, feels like a forced breakpoint when a problem is detected, but still lets me continue without abruptly exiting.
23:20:14 <_glx_> then I can put my findings from the other time in it
23:20:21 <_glx_> else it will be lost again
23:24:49 <xarick> terrible, I'm so bad at this 😦
23:26:28 <LordAro> issues do not need detailed analysis
23:26:34 <LordAro> that's what makes them issues rather than solutions
23:29:41 *** ChanServ sets mode: +v tokai
23:31:07 <_glx_> I have a feeling using FormatMessageA() might not be a wise idea
23:31:22 <_glx_> and we use it at least 3 times
23:33:17 <_glx_> but I failed to reproduce the issue (I think it should also crash with my french windows)
23:33:37 *** Wormnest has quit IRC (Ping timeout: 480 seconds)
23:34:05 <_glx_> I mean I can't reproduce the http failure which triggers the crash
23:34:08 <xarick> try going to main menu but have a breakpoint somewhere is makesettingslive or so, wait before continuing to give it time to drop connections
23:34:20 <xarick> then continue and it should pop
23:34:50 <xarick> i think it is attempting to send the survey
23:36:25 *** tokai|noir has quit IRC (Ping timeout: 480 seconds)
23:40:04 <truebrain> Oof, fmt does utf8 decoding. Oof, errors from FormatMessageA are in the local codepage, and should just be forward as is to the console (which is in the same codepage)
23:40:12 <truebrain> Did not expect fmt to do decoding
23:45:42 <_glx_> HTTP request failed: Le délai imparti à l’opération est dépassé
23:46:08 <truebrain> I think FormatMessageW returns an utf16 string; might help
23:46:17 <LordAro> but yeah, better solution would be to use the W variants
23:46:46 <_glx_> or just FormatMessage (which is the W for us)
23:46:58 <_glx_> but then we need to convert
23:47:17 <_glx_> like we do everywhere else when talking to windows
23:47:19 <truebrain> The W is easier, as you know you gave to digest the wstring
23:47:55 <truebrain> But glad your console is also in a weird code page 😛 means you can test is 😄
23:48:02 <_glx_> though fmt might understand wstring directly
23:48:12 <truebrain> It was noted a few times over the years this might be an issue 🙂
23:48:25 <truebrain> What is the http error btw in English?
23:49:07 <truebrain> I expected as much 😛
23:49:38 <truebrain> But yeah, please fix it in all 3 places while at it 🙂
23:50:43 <truebrain> Silly windows still isn't utf8 or utf16 .. but okay
23:54:22 <LordAro> needs more chcp 65001
23:59:38 <_glx_> I think they default to utf8 now, but the API is still weird
continue to next day ⏵
