IRC logs for #openttd on OFTC at 2026-01-10
⏴ go to previous day
01:57:30 *** blathijs has quit IRC (Ping timeout: 480 seconds)
01:59:03 *** blathijs has joined #openttd
01:59:03 *** ChanServ sets mode: +o blathijs
02:05:13 *** MinchinWeb[m] has quit IRC (Read error: Connection reset by peer)
02:05:24 *** MinchinWeb[m] has joined #openttd
02:59:09 *** Wormnest has quit IRC (Quit: Leaving)
04:00:37 *** ChanServ sets mode: +v tokai
04:07:35 *** tokai|noir has quit IRC (Ping timeout: 480 seconds)
04:46:51 <DorpsGek> - Update: Translations from eints (by translators)
05:02:44 *** Flygon_ has quit IRC (Read error: Connection reset by peer)
06:52:58 *** MinchinWeb[m] has quit IRC (Ping timeout: 480 seconds)
06:56:40 *** MinchinWeb[m] has joined #openttd
07:30:41 *** blathijs has quit IRC (Ping timeout: 480 seconds)
07:36:04 <emperorjake> What is it with feature requests as bug reports lately
07:38:57 <andythenorth> Template discourages feature requests?
07:52:19 <ahyangyi> There are indeed quite a few feature requests on tt-forums 🤔
08:04:39 <andythenorth> implementation would be 🤷 though
08:31:16 *** blathijs has joined #openttd
08:31:16 *** ChanServ sets mode: +o blathijs
08:39:18 *** blathijs has quit IRC (Ping timeout: 480 seconds)
08:50:41 *** blathijs has joined #openttd
08:50:41 *** ChanServ sets mode: +o blathijs
09:04:26 *** blathijs has quit IRC (Ping timeout: 480 seconds)
09:28:19 *** blathijs has joined #openttd
09:28:19 *** ChanServ sets mode: +o blathijs
10:26:41 <xarick> crap, compat code needs to go to 16
10:30:58 <xarick> this stuff should have been added to 15...
10:31:24 <xarick> makes little sense to have some parts at 15 and others at 16
10:37:14 <xarick> i really should stop splitting my changes into multiple PR's when they're related to each other
10:38:29 <xarick> what happened: we added a waypoint function to get a list of vehicles going to it with the goal of making the station function to stop working for waypoints...
10:38:54 <xarick> this was merged... the others are on hold
10:39:28 <xarick> so now 2 functions do the same job for waypoints... feels wrong
10:40:22 *** gelignite has joined #openttd
10:53:10 <xarick> #13457, #13455, #13409, #13408 should have been merged alongside #13456
10:54:20 <xarick> only #13456 was merged, it's in 15
10:55:44 <michi_cc[d]> Then propose complete, consistent, self-contained PRs, not random shotgun spray.
10:58:00 <xarick> damned if I do, damned if i notg
11:07:02 <rito12_51026> Should #14848 be closed as #14855 has been merged?
11:15:15 <_zephyris> I suspect it's not about whether PRs or split or merged, its about communicating what you're trying to do.
11:15:26 <_zephyris> "Follow the suggestion in #13408 (comment)" is not a useful PR description
11:16:54 <_zephyris> To me, I can't work out what you're trying to do with those PRs - they are a random collection of stuff to do with scripts and stations, but why?
11:20:07 <xarick> I'm trying to separate waypoints from stations, since there are dedicated ScriptStation and ScriptWaypoint
11:20:23 <michi_cc[d]> Yes, the missing Why has been very consistent over the years.
11:20:54 <xarick> only ScriptBaseStation is allowed to mix those together
11:21:16 <_zephyris> Don't write that here
11:22:00 <_zephyris> Make an issue on github with a clear overall problem, a clear list of sub problems, and a checklist of steps to the solution and corresponding PRs
11:22:09 <michi_cc[d]> Even that isn't a Why. The answer to Why would be why this is an advantage for script authors, to have them separated.
11:38:46 <xarick> ok, gonna think what to do
11:53:15 <xarick> doesn't fit the criteria of a "bug" report
11:53:41 <xarick> there is no bug, only inconsistency
12:12:40 *** firepup650 has quit IRC (Ping timeout: 480 seconds)
13:20:01 <_zephyris> If it's not a bug, then why are you trying to fix it?
13:20:08 <_zephyris> Is it a lack of functionality?
13:20:45 <_zephyris> If it's only an inconsistency, then changing it might be nice, but would presumably break backwards compatibility?
13:28:12 <andythenorth> let's try a different tack
13:28:25 <andythenorth> peter1138 how many branches have you got? 👀
13:28:37 <andythenorth> and how many are PRed against OpenTTD repo?
13:46:08 <andythenorth> my point is some people write a lot of code without PRing every test and commit against the main project
13:47:22 <michi_cc[d]> I don't have that many branches, but newmap/yacd/consist/other unspoke stuff are many, many commits 🙂
13:47:36 <_glx_> and if different changes are interdependent they should go in a single PR
13:47:43 <andythenorth> maybe we should just start closing the ones that aren't appropriate
13:53:40 <andythenorth> "lack of coherence"
14:00:10 <peter1138> They just make new ones.
14:00:37 <xarick> hold on, im making a discussion topic about these PRs
14:01:41 <andythenorth> we can close the new ones
14:01:56 <andythenorth> there are more people who can close than open?
14:04:49 <ahyangyi> _glx_: Interdependent, yes. But if it's just one-way dependencies, e.g., PR A depends on PR B but PR B doesn't "fix" anything besides making PR A possible, I think it's usually preferred to be two PRs?
14:04:55 <ahyangyi> Linked to one issue, probably.
14:05:38 <_glx_> in the Waypoint/Station case they affect each other in the end
14:26:43 *** Wormnest has joined #openttd
15:08:53 *** gelignite has joined #openttd
15:20:07 <_glx_> hmm fullscreen and alt-tab, a pain since the win9x era
15:48:37 <jfkuayue> Why people would trust £2.99 kebab?
15:49:14 <definitelynotcheese_> People trust free giveaway link credit card sites.
15:58:00 <jfkuayue> Okay. Long time not openttd… 15 come out ;D
16:57:02 <definitelynotcheese_> Ooh i like what i see
16:59:27 <talltyler> Converting setting values to scoped enums is exposing a lot of implicit conversions. Feels like when we made dates strongly-typed. 😄
17:00:27 <michi_cc[d]> Scoped enums you mean 😛
17:01:05 <talltyler> Must have just been reading an error message, not sure where I got that wording from
17:01:34 <talltyler> Heheh, this saveload conversion no longer works...
17:01:34 <talltyler> if (_settings_game.difficulty.industry_density > 0) {
17:01:34 <talltyler> _settings_game.difficulty.industry_density++;
17:01:59 <LordAro> to_underlying all the things
17:04:42 <talltyler> Doesn't work in reverse, it seems 🙁
17:06:21 <talltyler> This comment isn't even right. Position 1 is Minimal.
17:06:21 <talltyler> `Setting difficulty industry_density other than zero get bumped to +1 since a new option (very low at position 1) has been added`
17:06:45 <talltyler> Oh, there's another bump later in saveload
17:07:42 <talltyler> I would ask "who wrote this damn code?" if it wasn't likely to be someone still here 😛
17:09:40 <_glx_> the >0 check means something was added between 0 and 1
17:10:08 <talltyler> Right, "very low" got added between "funded only" and "low"
17:10:13 <_glx_> so everything above 0 is shifted
17:10:22 <talltyler> The same is repeated later when "minimal" got added
17:10:40 <_glx_> and you have version guard
17:11:06 <talltyler> I just can't think of a nice way to shift it, besides a switch that checks the old value
17:11:48 <_glx_> the error is on ++ or comparison ?
17:12:52 <talltyler> The comparison is easy to fix, the ++ is the issue
17:13:15 <LordAro> density = (enum)((int)density + 1)
17:13:33 <_glx_> temp var for old underlying, increase and store back
17:13:46 <talltyler> Oh, I forgot you can cast back to the enum 🙂
17:14:26 <_glx_> or yeah all-in-one with casts where needed
17:14:36 <talltyler> `static_cast<IndustryDensity>(to_underlying(_settings_game.difficulty.industry_density) + 1);`
17:14:48 <talltyler> Looks goofy but it doesn't complain
17:15:08 <_glx_> at least everything is explicit
17:19:18 <Rubidium> might be worth to check whether something like IndustryDensity{to_underlying...} works
17:22:34 <talltyler> Not sure what you mean. The full line is:
17:22:34 <talltyler> `_settings_game.difficulty.industry_density = static_cast<IndustryDensity>(to_underlying(_settings_game.difficulty.industry_density) + 1);`
17:23:56 <Rubidium> it might look nicer if you replace `static_cast<IndustryDensity>(...)` with `IndustryDensity{...}`, though I'm not sure whether it'll work
17:24:43 *** MinchinWeb[m] has quit IRC (Ping timeout: 480 seconds)
17:26:11 *** MinchinWeb[m] has joined #openttd
17:26:50 <Rubidium> although... DECLARE_INCREMENT_DECREMENT_OPERATORS(IndustryDensity) and then just retaining the ++ operator might even be better
17:27:39 <LordAro> feels unnecessary just for saveload stuff
17:29:29 <talltyler> I agree, it's only used twice, both in saveload
17:29:52 <Rubidium> it could be declared only in afterload.cpp
17:30:11 <Rubidium> but... it's just an idea. The casting's fine as well
17:34:54 <_glx_> saveload requiring casts doesn't feel wrong, it's basically hacking the data 🙂
17:38:44 <talltyler> Goes it remove high score because the code is hard? 😛
17:43:01 <talltyler> Eh, I just won't change SettingsProfile to an enum class
17:58:09 <xarick> there was an oreshnik strike again...
17:58:31 <xarick> In Lviv, that's like next door to Poland
18:02:10 *** Wormnest has quit IRC (Ping timeout: 480 seconds)
18:18:07 *** firepup650 has joined #openttd
18:22:48 *** WormnestAndroid has quit IRC (Ping timeout: 480 seconds)
18:23:52 *** WormnestAndroid has joined #openttd
18:33:08 <Borg> oh hello my C++ fanatics [;
18:33:14 <Borg> src/safeguards.h:#define snprintf SAFEGUARD_DO_NOT_USE_THIS_METHOD
18:33:24 <Borg> anyway.. what is safe alternative?
18:35:16 <ahyangyi> I think the answer is a few lines above
18:35:35 <ahyangyi> Are we looking at the same code?
18:35:41 <ahyangyi> /* Use std::string/std::string_view instead. */
18:35:41 <ahyangyi> #define strdup SAFEGUARD_DO_NOT_USE_THIS_METHOD
18:35:41 <ahyangyi> #define strndup SAFEGUARD_DO_NOT_USE_THIS_METHOD
18:35:41 <ahyangyi> #define strcpy SAFEGUARD_DO_NOT_USE_THIS_METHOD
18:35:41 <ahyangyi> #define strncpy SAFEGUARD_DO_NOT_USE_THIS_METHOD
18:35:43 <ahyangyi> #define strcat SAFEGUARD_DO_NOT_USE_THIS_METHOD
18:35:43 <ahyangyi> #define strncat SAFEGUARD_DO_NOT_USE_THIS_METHOD
18:35:45 <ahyangyi> #define sprintf SAFEGUARD_DO_NOT_USE_THIS_METHOD
18:35:45 <ahyangyi> #define snprintf SAFEGUARD_DO_NOT_USE_THIS_METHOD
18:35:47 <ahyangyi> #define vsprintf SAFEGUARD_DO_NOT_USE_THIS_METHOD
18:35:47 <ahyangyi> #define vsnprintf SAFEGUARD_DO_NOT_USE_THIS_METHOD
18:36:00 <Rubidium> ahyangyi: you're not looking at 1.8
18:36:32 <ahyangyi> Rubidium: I know, but Borg was asking about safe alternatives in C++ 😛
18:37:15 <Borg> anyway.. whats wrong with snprintf?
18:38:32 <Borg> okey. lets google for C++ snprintf() alternative
18:39:04 <Rubidium> there's nothing inherently wrong with it, but it's easy to make mistakes
18:39:30 <Borg> so best for me is to remove that #define from my fork
18:39:35 <LordAro> (and C++ provides better alternatives)
18:39:55 <Borg> really? can you hand one? im googling.. and first hint is Boost.. (yuck!)
18:40:10 <LordAro> perhaps you should look at literally any other code in OTTD
18:40:10 <Borg> I need to fill in char tmp[32]
18:40:17 <LordAro> or perhaps code that removed it in the first place
18:40:26 <Borg> lets try to find JUST_RAW_STRING
18:40:30 <Borg> maybe I will find some formatting
18:40:59 <LordAro> the (UI) string system does not seem all that appropriate
18:41:07 <LordAro> but maybe that's what you're trying to format, who knows
18:41:55 <Borg> no need to waste time with strings
18:42:31 <LordAro> sounds like you should use the Debug() stuff ;)
18:43:23 <Borg> yeah I use it.. but its for widget newgrf debug
18:44:07 <Borg> I noticed that when you loading old scenario.. layout_number is uninitialized
18:44:43 <Borg> so an idea sparked that I can use grf debug window and reuse 0x60 paramter withget text box to actually edit layout_number by hand in Scenario Editor
18:45:04 <Borg> then save scenario and vioala :>
18:45:16 <Rubidium> if you use it to populate string in steps, you'd need to manage both the location where to start writing and the remaining length. Then it becomes easy to not do it quite correctly. For example, if an error occurs it returns a negative number which could lead you before the buffer. Furthermore, it returns how much would have been written. So if you use a snprintf-length-type, i.e. size_t, and the first
18:45:22 <Rubidium> string is too long, you'll underflow the size_t and the next step will write beyond the buffer. Enough foot-guns for you?
18:45:57 <Borg> 2G string formating w/ snprintf() ?
18:47:07 <Rubidium> Borg: from the printf(3) man page: The functions snprintf() and vsnprintf() do not write more than size bytes (including the terminating null byte ('\0')). If the output was truncated due to this limit, then the return value is the number of characters (excluding the terminating null byte) which would have been written to the final string if enough space had been available. Thus, a return value of
18:47:09 <Borg> xarick: no offence mate :)
18:47:13 <Rubidium> size or more means that the output was truncated.
18:50:17 <Borg> Rubidium: no worries, I can handle sprintf/snprintf
18:50:33 <Borg> anyway... now im kinda waste time looking for anternatives..
18:50:45 <Borg> I see some weird std::format() and std::snprintf()
18:51:55 <Borg> Rubidium: hah.. you see it by MILE that its going to crash
18:52:04 <Borg> buf[4] and hell<too much bytes>
18:52:10 <Borg> I have C scares you know
18:52:20 <LordAro> contrived example is contrived
18:52:31 <Rubidium> for OpenTTD we used to have seprintf, where you pass the pointer to the end of the buffer and it'll return the pointer to the '\0' in the written buffer.
18:52:33 <LordAro> now find it in 500 lines of unfamiliar code and off-by-one errors
18:53:10 <Borg> Rubidium: instead of really wasting mine and yours.. trying to proove weird point... instead of just providing me one line single answer like.. use std:format() it will accept char * and len and do like snprintf()
18:53:13 <Rubidium> Borg: just comment line 13 and 14, and it won't SIGSEGV!
18:54:20 <Rubidium> Borg: what was the reason you're still on 1.8?
18:54:28 <ahyangyi> Rubidium: That's definitely an option.
18:55:17 <Rubidium> I vaguely remember it as being something compiler related, in which case std::format won't do you any good as it's way too new.
18:55:26 <Borg> Rubidium: few reasons.. I use old OS.. older compiler chain.. but most importantly.. its easier for me to work w/ 1.8 also
18:55:26 <_glx_> Anyway 1.8 most likely have seprintf
18:55:40 <Borg> and from googling around for a few minutes
18:55:52 <Borg> im going to do best and easiest solution.. remove that stupid #define snprintf
18:55:53 <Rubidium> but... char buf[16]; seprintf(buf, endof(buf), ....);
18:56:17 <ahyangyi> std::format is a C++20 thing, probably too new.
18:56:25 <Borg> LordAro: well, this is just OpenTTD.. not termonuclear reactor control program...
18:56:37 <LordAro> but let's not pretend
18:57:09 <Borg> and there is NO FUCKING way to exploit it.. as it will just display Enter layout number:
18:57:38 <ahyangyi> Just comment that macro, seriously.
18:57:59 <Borg> I see there is C++11 std::string_format() but it uses snvprintf() internally
18:59:24 <Borg> now.. long time waiting.. make clean and recompile
19:00:27 <ahyangyi> Probably still faster than my grf build process 😛
19:02:14 <Borg> ahyangyi: hmm? what are you using? :)
19:06:28 <ahyangyi> Decent PC but that doesn't help with my problematic coding.
19:07:26 <Borg> yeah, but curious what tools.. and your grf must be huge :)
19:13:06 <ahyangyi> Python code calling `grf-py`.
19:13:21 <Borg> yeah. but not due to snprintf
19:13:31 <Borg> I forgot that all NIH helper are const void *
19:13:41 <Borg> so my plan aint that good after all
19:20:51 <Borg> heh its actually crashing on ShowQueryString()
19:21:29 <peter1138> Update to 15.0, the string handling is way more robust.
19:22:07 <Borg> right.. I got carried away
19:22:18 <Borg> ShowQueryString cannot accept RAW_STRING as second parameter
19:28:22 <Borg> just warining on compilation.. unfortunately
19:28:41 <Borg> c:/DEVEL/OpenTTD/src/newgrf_debug_gui.cpp:650:66: warning: cast from type 'const void*' to type 'Industry*' casts away qualifiers [-Wcast-qual]
20:09:17 <Borg> okey managed to get rid the warning
20:09:27 <Borg> const NIHIndustry *nih = static_cast<const NIHIndustry *>(nif->helper);
20:09:27 <Borg> Industry *ind = static_cast<Industry *>(nih->GetInstanceW(GetFeatureIndex()));
20:19:26 *** SigHunter has joined #openttd
20:22:11 <_zephyris> So, I'm poking to see if it's easy to set a minimum width for the main menu window
20:22:22 <_zephyris> (and getting nowhere fast)
20:23:01 <_zephyris> Feels like it should be easy, but the `WindowDesc` only has default width/height - is that right?
20:48:59 <peter1138> Well... it's intended to be the width required for the text.
20:49:32 <peter1138> Different languages have different length strings, trying to impose a minimum width means means that either has no effect, or it's very wide for no reason.
20:50:22 <peter1138> I moved the version number string to the viewport from the window title to ensure that didn't affect the width as well.
20:51:33 <peter1138> So I say, no. Don't try to give it a minimum width.
21:13:45 <peter1138> It does not look better.
21:14:21 <Borg> oh.. I see pitchforks... for main menu [;
21:17:15 <Borg> ahyangyi: I wrote some nfo compiler-validator myself in Ruby :)
21:17:35 <Borg> so I dont need to do NFO directly.. works pretty nicely :)
21:18:58 <peter1138> Not pitchforks, just explaining the width is intentional.
21:19:34 <Borg> peter1138: im talking about tt-forums :) I noticed some post..
21:30:40 <_zephyris> Well, yeah, but I was going to suggest a min width of only 180px.
21:36:11 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
21:36:30 *** WormnestAndroid has joined #openttd
21:37:16 *** Wormnest has joined #openttd
21:39:55 <peter1138> A more algorithm approach is to apply the width of the image (and spacer) to the right hand size of the buttons too.
21:42:04 <peter1138> Doing it this way means it doesn't matter what your font size is, there'll be some spacing.
21:43:05 <_zephyris> That was my second suggestion too 🙂
21:43:20 <_zephyris> Though I'd suggest left/right padding rather than margin (using CSS terminology(
21:43:52 <peter1138> CSS doesn't mean anything here, and padding vs margin is box-model weird shit.
21:44:10 <peter1138> And no, applying spacing between the image and the text does not look good.
21:44:28 <peter1138> (Nor moving the image in from the left)
21:48:01 *** Borg has quit IRC (Quit: gooood nite)
21:57:38 <_zephyris> Around-image padding works OK
21:58:26 *** MinchinWeb[m] has quit IRC (Read error: Connection reset by peer)
21:59:18 <peter1138> _zephyris, you already get that with non-power-of-2 interface scaling, don't see a need to add more.
22:00:40 <_zephyris> Slightly different, but I get your point
22:05:24 *** MinchinWeb[m] has joined #openttd
22:05:28 <peter1138> Benefit of #15077 is, while it's arbitrary, it applies equally to all img-text buttons (there aren't any anywhere else, mind you), and doesn't require creating new NWidgetParts to set arbitrary padding.
22:06:22 <_zephyris> I suspect the negative space matching the image is hitting a symmetry bit of my brain
22:06:46 <peter1138> So the thing I tried to achieve is bad.
22:06:47 <_zephyris> It does look more balanced, the text is left aligned within a centred sub-region of the button
22:07:58 <peter1138> Making the space match is triggering.
22:08:37 <_zephyris> But the space doesn't match, for all except the longest string
22:08:57 <peter1138> Well, true. It would if they were all variable length :)
22:09:36 <peter1138> The bottom end of the menu is pretty close though, mind you.
22:13:12 <_zephyris> Which reminds me. Some other useful feedback was that "Game Options" should probably be "Options", because it's not game specific, it's OpenTTD-wide.
22:13:21 <_zephyris> I realise a similar conversation happened before
22:14:01 <peter1138> And confuse Master Hellish even more?
22:14:13 <peter1138> (It's okay to keep calling things advanced settings ;-))
22:14:15 <_zephyris> I missed that one 🙂
22:16:46 <Rubidium> advanced settings are those in the advanced tab of the game options when the advanced category is selected, excluding those visible when the basic category is selected. Right?
22:31:24 *** Wolf01 has quit IRC (Quit: Once again the world is quick to bury me.)
22:36:53 *** MinchinWeb[m] has quit IRC (Read error: Connection reset by peer)
22:37:30 *** MinchinWeb[m] has joined #openttd
22:41:26 <peter1138> My favourite was converting an enum to enum class but forgetting to add class :)
22:41:42 <peter1138> andythenorth, more variants o'clock.
23:01:14 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
23:01:16 *** WormnestAndroid has joined #openttd
23:01:22 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
23:01:38 *** WormnestAndroid has joined #openttd
23:55:30 *** danp142 has quit IRC (Quit: User went offline on Discord a while ago)
continue to next day ⏵
