IRC logs for #openttd on OFTC at 2024-01-03
โด go to previous day
00:14:31 <truebrain> Happens when you optimized based on code instead of performance ๐
00:15:00 <truebrain> But I guess I am starting to become a broken record ๐
00:26:55 <truebrain> Crosslink for visibility. Older AIs rendering strings wrong .. sounds we should address that. Maybe a compat-fix, or at least reject the string. But showing wrong information sounds like we kinda broke shit to me ๐
00:28:50 <truebrain> (Caused by 14.x string related changes / fixes; now location strings show the wrong location with AIs)
00:29:16 <truebrain> Guess it should be a bug-report ๐
00:29:59 <truebrain> AI -> GS, but whatever .. tomato tomato ๐
00:47:38 <peter1138[d]> Okay, so is this STRING instead of STRING1,2,3 etc?
00:48:43 <peter1138[d]> It's so easy to fix the GS, but...
01:05:46 <peter1138[d]> Ummm. not ideal ๐
01:09:16 <_glx_> yeah most GS don't follow the param rules, and it's enforced now
01:17:09 <peter1138[d]> Doesn't really fix the problem but at least it doesn't just show industry 0.
01:19:55 <peter1138[d]> But that error doesn't pop up the console, so players don't see a problem.
01:21:14 <_glx_> the parameter should still be present somewhere
01:22:15 <peter1138[d]> Funny how the GS log shows the correct name, cos it's built differently ๐
01:27:19 <peter1138[d]> I wonder if we can 'modify' the STRING to the correct form, by checking if the parameter... has parameters.
01:29:12 <peter1138[d]> I suspect it is all too far disconnected.
01:38:33 <_glx_> hmm the value is actually present
01:42:24 <peter1138[d]> Yeah it will be.
01:51:37 <_jgr_> Changing the subspans passed to STRING/STRINGN to include all the remaining the parameters, but only advancing the parent offset by the correct number of parameters should be enough for it to work, as that's essentially the old behaviour
02:02:20 *** herms has quit IRC (Quit: bye)
02:21:33 <_glx_> I was looking at ScriptText, but it does the right thing, the parameters are properly encoded to say "Deliver {GOLD}[oil, 1050] {ORANGE}to {YELLOW}[Rodez Oil Refinery]"
02:22:46 <peter1138[d]> `GetnExtParameterPointer()` returns nullptr if the parameter number is out of range.
02:22:49 <_glx_> at least the param is properly passed to openttd
02:23:22 <peter1138[d]> `GetNextParameter<>()` returns 0 if `GetNextParameterPointer()` returns nullptr.
02:23:39 <peter1138[d]> So instead of showing nothing, or an error, it shows industry 0.
02:24:07 <_glx_> yeah I was not looking at the right place ๐
02:24:50 <_glx_> I was focused on `for (int i = count; i < cur_param.consumes; i++) fmt::format_to(output, ":0");`
02:24:51 <peter1138[d]> We could do what JGR suggests so that the parameters are accessible.
02:25:01 <peter1138[d]> You did a Xarick? ๐
02:25:25 <peter1138[d]> Or we could be properly strict, and not turn a missing parameter into 0.
02:25:41 <_glx_> I forgot I properly did support "broken" GS when adding the validation on GSText side
02:26:21 <peter1138[d]> To be properly strict is really easyโinstead of returning nullptr, throw an exception, and then catch it in FormatString.
02:26:27 <_glx_> the 0 here is for when the script forgot to add it
02:26:49 <_glx_> but in busybee case it's present
02:45:36 *** herms has quit IRC (Ping timeout: 480 seconds)
02:54:06 *** Wormnest has quit IRC (Quit: Leaving)
03:06:10 <_glx_> actually ScriptText makes sure the string has enough parameters for the used STRING/STRINGN, so always passing the full span if `game_script` should be fine
03:07:58 <_glx_> even if the wrong type was used in the string
03:09:16 <peter1138[d]> Mostly indentation changes :/
03:11:29 <_glx_> but yeah your change also works for openttd strings
03:12:32 <peter1138[d]> Yup. The issue with returning 0 is it's not actually obvious. You might see the debug message, but it doesn't have anything to correlate it.
03:36:19 <peter1138[d]> Hehe, yeah I bet it does ๐
03:58:33 *** debdog has quit IRC (Ping timeout: 480 seconds)
04:00:39 *** D-HUND is now known as debdog
04:15:27 *** Smedles has joined #openttd
06:42:59 *** nightingale33 has joined #openttd
06:42:59 <nightingale33> I'm on JGR 1.52, with this issue.
06:42:59 <nightingale33> I've got a local copy of the GS repo, I'll have a closer look at the string handling part of the API and maybe I can make the fix for my own one (and offer a PR back to the unupdated GS). By the sounds of it, incomplete parameterization. Given the issue appears as the wrong town/industry. Must be missing a parameter on that fetch and its defaulting
07:30:55 *** ChanServ sets mode: +v tokai
07:37:51 *** tokai|noir has quit IRC (Ping timeout: 480 seconds)
07:41:52 <andythenorth> so...how do livery overrides work?
07:42:04 <andythenorth> the actual question is "can I abuse them?"
07:44:58 <locosage> "and in the future, the look of train visual effects such as steam and diesel smoke." xD
07:48:18 <andythenorth> anyway it's not going to do what I want ๐
07:48:39 <andythenorth> I want to chain from an action 2 to the **action 3** of another vehicle
07:49:35 <andythenorth> although chaining action 2 is possible across the grf, it requires manually managing action 2 IDs, which is not favourable in nml
07:50:12 <andythenorth> there are 2 use cases
07:51:01 <andythenorth> - vehicles that have separate IDs, but use identical sprites e.g. (railcars + their unpowered trailers)
07:51:01 <andythenorth> - 'randomised' wagons, that 'build' a random choice from a subset of real wagons
07:51:30 <andythenorth> the first case is currently handled by copying everything (including the spritesheet)
07:52:08 <andythenorth> the second case is handled by some elaborate re-ordering of the grf at compile time, to ensure that vehicles can chain to other vehicles action 2 chain without running out of ID
08:12:16 <truebrain> peter1138[d]: Nice fix! Now the question remains .. can we patch up older GSes to still work ๐
08:34:06 *** ahyangyi has joined #openttd
08:34:06 <ahyangyi> andythenorth: The realsprites in the first case is already automagically deduplicated if you use grf-py ๐ฎ
08:37:55 <peter1138[d]> truebrain: truebrain probably. I think the main issue of the game crashing when trying to access out-of-bounds parameters is resolved, so being slightly lenient with incorrect strings from GS should be "okay", if not ideal.
08:38:53 <peter1138[d]> It might be preferable to only allow it for scripts using a compatibility layer below 14.
08:38:59 <truebrain> We can be strict if compat 14 is loaded, and relaxed if 13 or older?
08:39:28 <peter1138[d]> I'm not sure how that can be done though ๐
08:41:12 <peter1138[d]> Yeah, outputting the string with an error isn't useful: `Trying to read invalid string parameter in "๎๎"` ๐
08:47:55 <peter1138[d]> Oh crap, nearly 9am already ๐ฆ
08:51:59 <_zephyris> cappuccino, nice dark Ethiopian roast
08:52:32 <_zephyris> How do I enter arbitrary unicode characters in OTTD?
08:52:47 <_zephyris> I want to play with bitcoin as currency...
08:53:14 <peter1138[d]> If you have a compose key that should work.
08:53:35 <peter1138[d]> Or copy & paste?
08:53:46 <peter1138[d]> Not sure if we support that ๐
08:57:19 <_zephyris> I'm trying alt+code and copy paste, but by remote desktop from my phone on a bus! Not sure where the weak link is
08:58:10 <peter1138[d]> Ah the weakest link in the chain...
08:58:53 <peter1138[d]> I don't think alt+code will work.
09:16:59 <_zephyris> Ctrl+C Ctrl+V works ๐คฃ
09:17:23 <_zephyris> Now I'm confused by my laptop keyboard for trying Alt+numpad
09:23:28 <peter1138[d]> > Floating editor windows - Drag and drop editors onto your desktop.
09:23:35 <peter1138[d]> Because code isn't already on my desktop ๐ฎ
09:23:57 <nightingale33> Looking through the GS that was causing me issues. I noticed that I can't spot an issue with the calling convention, at least as per the official docs.
09:23:57 <nightingale33> Best I can tell, that is perfectly valid usage.
09:24:38 <nightingale33> The only swap aspect that could help, is using the other convention of "AddParam"
09:26:31 <nightingale33> destination = accept.town;
09:26:31 <nightingale33> destination_string = GSText(GSText.STR_TOWN_NAME).AddParam(destination);
09:26:31 <nightingale33> destination_string_news = GSText(GSText.STR_TOWN_NAME_NEWS).AddParam(destination);
09:26:31 <nightingale33> ``` is the alternate form, is this liable to work better?
09:28:10 <peter1138[d]> No, the issue is we require {STRING1} instead of {STRING} in the language file.
09:28:31 <truebrain> peter1138[d]: to make a variable available which gives compat mode, I can arrange that. As for the string-stuff .. I have no clue ๐
09:28:31 <truebrain> It always puzzled me a bit why the DParam stuff is not more stack-lack, which would kinda invalidate the need of STRING1 etc. But that is unfixible now ๐
09:28:55 <nightingale33> peter1138[d]: Ah, I see, so `STR_TOWN_NAME :{WHITE}{TOWN1}` is the intended correct usage?
09:29:12 <peter1138[d]> No, literally there's a {STRING} which should be {STRING1}
09:29:21 <peter1138[d]> It's a string that includes another string which uses a parameter.
09:29:40 <peter1138[d]> STRING mean no parameters, STRING1 means 1 parameter.
09:30:02 <peter1138[d]> This used to work because OpenTTD didn't do bounds checking here (and this could/would result in crashes)
09:30:03 <nightingale33> Gotcha, so I need to update this line (and all similar)`STR_COMPANY_GOAL :Deliver {GOLD}{CARGO_LONG} {ORANGE}to {STRING}`
09:31:53 <peter1138[d]> truebrain: I don't think it's unfixable, but it's as far as I can tell it's there deliberately to ensure that the correct number of parameters is consumed.
09:32:33 <peter1138[d]> nightingale33: Yes
09:32:56 <truebrain> peter1138[d]: I guess that is fair too. Just compat-fixing things seems a bit tricky in the way it is currently setup ๐
09:33:00 <peter1138[d]> The issue is "this used to work" so we are trying to come up with a way of allowing older scripts to "break the rules"
09:33:25 <nightingale33> From a definition stand-point. It definitely feels like something the "user" writing the mod shouldn't have to deal with.
09:33:25 <nightingale33> But regardless,
09:33:25 <nightingale33> Just to check I fully understand it.
09:33:25 <nightingale33> If the expected substitution string was something like `{TOWN}-{COMPANY}` then I would replace `{STRING}` with `{STRING2}`?
09:34:26 <peter1138[d]> Yes. I'm not entirely sure what happens when consume a substring that could be different number of parameters. Seems a bit awkward ๐
09:35:01 <truebrain> peter1138[d]: Ironically I do that with social presence ๐
09:35:05 <nightingale33> I doubt there are any instances of `{STRING2}` in this GS. But it's worth checking I understood it.
09:35:19 <peter1138[d]> truebrain: imo the main issue (crashing) is solved by StringParameters doing bounds checking.
09:36:18 <peter1138[d]> Oh, and it's not just a GS issue. This trips us up on our own strings too, and the only way to know is by trying to format a string.
09:37:06 <peter1138[d]> Given it's a runtime problem, and the number of strings and all the combinations, that makes a unit-test a bit hard ๐
09:40:52 <truebrain> static code analysis ๐
09:41:10 <peter1138[d]> You can try? ๐
09:41:25 <truebrain> it will be able to detect a lot, but not all; which makes false positives very likely
09:41:31 <truebrain> we are not that clean in where we do a DParam
09:44:39 <peter1138[d]> All those str + x would be interesting.
09:44:59 <truebrain> at least I marked them all ๐
09:45:23 <peter1138[d]> Yeah, but SAST validating that x is in range?
09:45:39 <truebrain> we need to customly feed every string to it
09:45:42 <truebrain> it won't be easy ๐
09:46:04 <truebrain> I guess I should have added a /s instead of a ๐ ๐
09:46:52 <truebrain> main issue btw is windows .. where what STR used is miles away from where the DParams are set
09:46:56 <truebrain> correlating that is hard
09:51:41 <peter1138[d]> Oh don't mind me, I aware you were not serious ๐
09:52:04 <peter1138[d]> I'm not American, I don't need sarcasm to be explicitly pointed out ๐
09:55:33 <peter1138[d]> I'm not falling for that trap.
09:56:26 <nightingale33> Ahah, Numbers are not parameters. I think, somehow
09:57:41 <andythenorth> peter1138[d]: "really?"
09:58:40 <andythenorth> truebrain: can you explain Dutch sarcasm to me?
09:59:04 <truebrain> wait, that was Dutch rudeness, my mistake
09:59:21 <andythenorth> there's Dutch rudeness? ๐ฎ
09:59:24 <osswix> andythenorth: Dat gaat niet.
09:59:54 <truebrain> these things translate so lovely ๐
10:00:46 <andythenorth> some things are probably universal
10:01:13 <truebrain> dunno; do Brits just reply with "Your mother" to a question?
10:02:18 <andythenorth> at a certain level of emotional maturity, definitely
10:02:24 <andythenorth> absolutely the default answer
10:02:34 <andythenorth> except it's "Your mum"
10:03:33 <andythenorth> today is therapist day, I can discuss this with them
10:04:40 <truebrain> I also cannot be wrong in how things sound to me ๐
10:04:44 <truebrain> which is just a lovely concept ๐
10:05:00 <andythenorth> ask your therapist about it
10:05:22 <andythenorth> ok it's now time for my daily chat with GPT
10:05:33 <andythenorth> "hello GPT, how you today?"
10:05:38 <andythenorth> oh, wrong window
10:06:23 <truebrain> ah, yes, a world where we have better emotional connections with an AI than with humans ๐
10:10:53 <andythenorth> well they're trained to give the socialised responses ๐
10:11:07 <andythenorth> because we write the world as it should be or how we want it to be, using neat and tidy words
10:11:29 <andythenorth> which have no real relation to actual human interactions, which are mostly grunting
10:22:10 <peter1138[d]> Right, where was I, apart from over 30 years ago...
10:28:55 <nightingale33> Woo, looks like I've fixed it up. Very satisfying
10:29:13 <andythenorth> what even is? That's not a Jazz drive
10:53:47 <xarick> CheckClickOnVehicle, can I assume effect vehicles and disaster vehicles, free wagons, are always unclickable
10:54:04 <xarick> I'm about to give it the group treatment
10:54:57 <peter1138[d]> Can you get it reduced from 6ms to 35ยตs on Wentbourne?
10:55:26 <reldred> andythenorth: Looks like early DVD cassettes
10:55:40 <reldred> DVD-RAM was supposed to be like that
10:55:47 <peter1138[d]> It says what it is in the picture ๐
10:55:49 <peter1138[d]> It's a CD Caddy.
10:56:15 <reldred> peter1138[d]: I didnโt zoom in ๐
10:56:23 <reldred> I just knew it wasnโt a minidisc
10:56:51 <xarick> peter1138[d]: I doubt it will be reduced that much
10:57:44 <andythenorth> this is a CD caddy ๐
10:57:46 <peter1138[d]> Okay, then don't bother ๐
10:59:45 <peter1138[d]> > dbg: [misc] [CheckClickOnVehicle] 21 us [avg: 21.0 us]
11:04:52 <georgevb> _zephyris: Letter ะ is missing in cyrillic
11:07:30 <peter1138[d]> > dbg: [misc] [CheckClickOnVehicle] 9 us [avg: 9.0 us]
11:07:34 <peter1138[d]> Oh, that's not bad.
11:13:09 <peter1138[d]> Ah shit I didn't extend my API with some new reports ๐ฆ
11:15:58 <peter1138[d]> Okay, release build is not that impressive :p
11:17:12 <peter1138[d]> Fairly constant 1100ยตs to 5-20ยตs
11:18:26 <peter1138[d]> I wonder why ๐
11:18:47 <peter1138[d]> That's slower than iterating all vehicles.
11:18:59 <xarick> not sure, will test that now
11:19:01 <peter1138[d]> Unless it's a debug build.
11:20:10 *** thelounge345 has joined #openttd
11:25:29 <_zephyris> georgevb: That's just a preview, I promise they are there ๐ Should be full coverage for all Cyrillic translations for OpenTTD.
11:26:22 <peter1138[d]> Here's a tip. If you need to iterate all vehicles, then the best thing to do is to iterate all vehicles.
11:27:21 <andythenorth> it's funny how doing the thing is often the thing you need to do
11:27:38 <andythenorth> took me too long to learn that in software ๐
11:27:47 <andythenorth> "just do the thing and stop fucking around"
11:28:55 <_glx_> peter1138[d]: For now the validation is skipped for all extra parameters, like in busy bee case the town/industry id from substring could be consumed by next command (if there was any), but the type check is disabled
11:28:59 <peter1138[d]> Can you perhaps stop pushing to your branch if you haven't even verified your changes are more performant?
11:29:25 <_glx_> I started to look at how to improve the function to not disable the check
11:30:06 <_glx_> Anyway the number of parameters is still validated
11:30:09 <peter1138[d]> Perhaps at the parent string check if there are excess parameters.
11:30:54 <peter1138[d]> If there are excess parameters for the parent string, then pass them to the child. But only in GS-compatibility-level mode?
11:33:16 <_glx_> The child already checks it has the minimum required number for itself, and throw if there's not enough
11:34:05 <peter1138[d]> In GS-land or FormatString-land?
11:34:54 <_glx_> Then parent string handling adds more to match the command, or use extra params before continuing to use it's own
11:35:30 <_glx_> But when using extra it doesn't type check
11:35:48 <peter1138[d]> Okay, so if GS can change STRING to be STRING1/2/3 as needed, then it would work. But it might not do what is wanted.
11:35:57 <peter1138[d]> And it probably can't ๐
11:36:28 <_glx_> GS validation tries to simulate FormatString
11:37:45 <_jgr_> The script end can't correct the string codes because only the string ID is passed via SCC_ENCODED
11:37:45 <_glx_> But it's not complete for extra params, and I think I can improve it
11:39:48 <xarick> sorry, I don't get why some times there's an improvement and some other times there isn't.
11:40:36 <xarick> the total sum of vehicles is less, just slightly though, but still I expecteded an improvement
11:41:30 <LordAro> xarick: trying to optimise without understanding what exactly is slow is a waste of time
11:41:36 <LordAro> i.e. do profiling first
11:41:43 <peter1138[d]> I reckon we can change FormatString to just allow use of the remaining parameters in {STRING}, if it's game-script below 14.0.
11:42:26 <LordAro> and perhaps more relevantly, test locally rather than pushing to your PR every 5 minutes and abusing our CI resources
11:42:33 <peter1138[d]> LordAro, I finally fixed the spoke... only to find another one. (It was still in the nipple, but not attached...)
11:42:59 <peter1138[d]> Fortunately *before* I put everything back together ๐
11:43:15 <LordAro> it's a pull *request* - if you don't have anything ready, or any idea of what you're doing, don't waste our time
11:43:21 <LordAro> peter1138[d]: oh well done
11:44:19 <peter1138[d]> And I mastered the art of not allowing the nipple to fall between the rim layers. That cost me about an hour last time...
11:44:58 <peter1138[d]> I don't want to imagine the annoyance of a nipple rattling around in the rim while riding ๐
11:45:00 <andythenorth> I am a bad person. I would have bought a new wheel
11:45:05 <LordAro> maybe i've misunderstood the changes, but don't invalid GS strings just result in "invalid parameter" being used, rather than any GS crashes? given previously the values were garbage anyway, i don't really see the issue?
11:45:16 <andythenorth> I will spend time fixing many silly things, but I've done my time fixing bikes
11:45:19 <LordAro> or taken it somewhere and thrown money at it
11:45:28 <peter1138[d]> LordAro, with my most recent PR, yes.
11:45:47 <peter1138[d]> The issue is that pre 14.0, the strings used to work because we didn't validate the parameters.
11:45:57 <peter1138[d]> So we've "broken" the scripts by fixing it.
11:46:11 <LordAro> you mean the values weren't garbage before?
11:46:26 <LordAro> that does feel like a regression
11:46:36 <peter1138[d]> The values are there, but the StringParameter system now range checks and prevents access to them.
11:47:10 <peter1138[d]> Given we do know now the parameter bounds, it should be safe to allow GS to use up to the full range anyway. It still can't go out of bounds.
11:47:43 <LordAro> not wanting to be all project-manager, but can this get written up into an actual issue, rather than just being here?
11:48:08 <peter1138[d]> We've got 2TallTyler for the PM role ๐
11:48:29 <peter1138[d]> There might even be an open issue.
11:48:41 <LordAro> we tell people off for not doing things in the right place, should exercise good practices ourselves
11:55:01 <_jgr_> At the time of that issue, the fix did resolve the problem
11:55:24 <_jgr_> String parameter subspans was added afterwards
12:01:11 *** thelounge345 has joined #openttd
12:01:17 <xarick> I know I shouldn't say this but I'm surprised you care about old scripts not crashing
12:01:58 <peter1138[d]> The script does not crash here.
12:02:45 <peter1138[d]> Eh, I guess it did. I thought it was a game crash ๐
12:03:03 <_jgr_> xarick: Having every existing script not work when 14.0 comes out seems likely to lead to user support issues
12:03:06 <peter1138[d]> But there's a difference between scripts crashing, and scripts that used to work no longer working.
12:18:17 <LordAro> ld-elf.so.1: Shared object "libcrypto.so.111" not found, required by "sudo"
12:23:56 *** LordAro has joined #openttd
12:24:51 <xarick> ohh, I knew you were up to something
12:28:31 *** LordAro has joined #openttd
12:32:18 <xarick> I'm going to report everything I measured (profiled?) to see if there are regressions in performance. I was under the wrong expectations there would always be a gain. But I'm scared it might make the PR unreadable
12:34:02 <peter1138[d]> It's already unreadable.
12:41:16 <merni> Oh man the latest jgrpp without the pressed-button-shifting looks so weird
12:41:23 <merni> No doubt I'll get used to it but it's a bit of a shock
12:41:57 <truebrain> lol @ remark in 11675 ๐
12:42:29 <LordAro> right, that's router, fileserver & both VPSes upgraded
12:43:17 <merni> > Clicking on a vehicle in a vehicle
12:43:17 <merni> should this be "in a vehicle viewport"?
12:47:30 <_glx_> Hmm are aircraft in viewport hash ?
12:49:04 <_jgr_> Yes, they wouldn't be drawn otherwise
12:57:59 <peter1138[d]> Weird, someone called our home phoneโwhich only has VoIP-voicemail service, and hasn't been used for inbound or outbound calls for about 10 yearsโlooking for my partner's employer...
13:00:11 <merni> Btw, does a VoIP-landline work when you don't have electricity at home, like a normal landline does?
13:01:27 <merni> Recently we had a cyclone that knocked out power to home and many cell towers, so we were relying on landline (which worked perfectly throughout) for a day or two... that makes me rather worried about the phone provider's VoIP switchover plan
13:02:41 <peter1138[d]> If you have a UPS running your modem, router and phone, sure.
13:06:06 <merni> does UPS run for two days though
13:06:19 <merni> I have a UPS for my internet router but it lasts a few hours tops
13:07:50 <_glx_> Often when power lines are down there's a huge probability for telephone lines to be affected by the same trees
13:08:18 *** herms has quit IRC (Ping timeout: 480 seconds)
13:09:37 <peter1138[d]> Well, I could get a generator, I guess ๐
13:10:09 <peter1138[d]> Our phone lines are being phased out, so it'll be VoIP over fibre as the only option soon.
13:10:26 <peter1138[d]> Hmm, how do I rip a Bluray? I guess I'd need a Bluray drive.
13:17:36 <peter1138[d]> Oh, I didn't realise that cargo icons are resolved in act 3/2/1 every time. I hope nobody uses a long complex chain now that they appear in more places ๐
13:22:23 <merni> _glx_: Maybe we wete just lucky with the phone lines this tike then, though I live in a city and many of the lines are underground
13:23:42 <merni> Also the power supply was turned off because of the massive flooding, even if lines weren't actually broken
13:27:52 <_glx_> here only power lines are underground, fibre is aerial on the same poles as copper
13:29:15 <_zephyris> Hmm, how does mono sprite font sizing work? It seems to ignore the sprite sizes...
13:29:20 <merni> Internet/fibre is a huge mess here between different providers
13:29:29 <_glx_> btw most modern phones won't work without power (DECT needs power to the base)
13:30:05 <merni> Base -> cordless phone?
13:30:24 <merni> Bc my landline phone has no wire for power, only a phone line
13:31:05 <merni> But yes to charge the wireless handset it needs power, but you can still use the actual landline phone
13:32:43 <merni> I also have a faux-antique rotary phone which uses pulse dialling which also worked, so perhaps our landline networks are just old fashioned lol
13:35:26 <goddess_ishtar> Is city placement exposed to NewGRFs at all, or is that patch territory?
13:38:46 <brickblock19280> no only somewhat within a town
13:38:49 <peter1138[d]> _zephyris: What did you do to get that?
13:39:40 <goddess_ishtar> I wanted to make the game place towns in a slightly more regular manner instead of just randomly wherever
13:40:02 <peter1138[d]> You'll need to patch for that.
13:40:18 <locosage> gs can probably do that too
13:40:42 <peter1138[d]> Oh right, I guess you could start with 1 town and let GS create the rest.
13:40:43 <_glx_> GS will need to remove towns first
13:41:11 <peter1138[d]> This goes back to "create methods to let GS set up the map"
13:41:15 <_glx_> because it runs after the map is fully generated with towns and industries
13:41:21 <peter1138[d]> andy was probably going to do it ๐
13:41:26 <andythenorth> GS can set up the map
13:41:41 <peter1138[d]> No, it can only change the map after it's been created.
13:41:49 <andythenorth> oh yes, I see ๐
13:42:10 <andythenorth> GS can *pretend* to set up the map, post-hoc
13:42:21 <andythenorth> just look away while it does it
13:42:26 <andythenorth> and don't read the news history
13:43:14 <peter1138[d]> Allow GS to do things without creating a news entry was probably also part of that...
13:46:38 <peter1138[d]> _zephyris: Also "I have a patch" that lets the text file viewer switch between normal and mono font.
13:46:59 <peter1138[d]> For most documents, line-wrapped proportional works just fine.
13:48:28 <peter1138[d]> We could also reformat line-breaks as per markdown spec.
13:50:37 <_zephyris> peter1138[d]: I gave it a sprite font where every character is 18x20px
13:51:19 <peter1138[d]> Not unless you want to draw a 2x sprite font ๐
13:51:23 <merni> peter1138[d]: India moment
13:51:30 <merni> though 300 is a bit high
13:51:55 <peter1138[d]> monospace font should be 8 pixels of ascender, 2 pixels of descender, although with offsets you can go outside that bounds a little if needed.
13:52:04 <peter1138[d]> (Same as normal font)
13:52:31 <_zephyris> Yeah, I know I was pushing it by giving it double height. But it seems to ignore the sprite width, hardcoded to expect 7px(?)
13:53:04 <merni> Wonder if anyone will create an RV set with the ability for pax to ride on top of lorries
13:54:51 <peter1138[d]> _zephyris: I don't think there's anything that hardcodes a width.
13:55:55 <peter1138[d]> In fact width-wise your screenshot looks fine.
13:56:44 <merni> Spaces seem to be missing
13:59:10 <peter1138[d]> Perhaps it's been auto-cropped by the GRF build.
14:07:14 <_zephyris> Ah, I'll give that a go
14:07:44 <peter1138[d]> Nothing will make the wrong height work though ๐
14:09:44 <peter1138[d]> Hmm, should fixing this string issue still produce a warning?
14:10:14 <peter1138[d]> I think that's harder to do.
14:11:07 <goddess_ishtar> patches require making changes to the C++ directly and compiling it yourself, right?
14:20:29 <peter1138[d]> So it would be nice if it could be properly delegated to GS. Almost downloading a map generator from bananas....
14:20:55 <goddess_ishtar> how much of a pain is that for someone who doesn't know much C++?
14:24:19 <andythenorth> peter1138[d]: Ship it as a GS lib ๐
14:27:53 <_zephyris> peter1138[d]: Thanks, dumb mistake!
14:28:11 <_zephyris> peter1138[d]: Thanks, dumb mistake
14:32:27 <peter1138[d]> Hmm, is squirrel compatibility done entirely in squirrel?
14:33:24 <_glx_> yes redefinition of squirrel functions in squirrel
14:33:48 <peter1138[d]> Hmm, not sure how to do thing thing to only allow older scripts to bypass the string formatting restriction then.
14:35:46 <peter1138[d]> Could add a method that says provides a compatibility level to OpenTTD, alongside the GSLog.Info(), and then rely on that to determine behaviour. But that's a bit prone to abuse.
14:35:57 <_glx_> I think if validation is complete (meaning only properly drawable strings are passed to OpenTTD) there's no need to check API version but only `game_script` bool
14:36:22 <peter1138[d]> The idea is to allow old scripts to work, but require new scripts to be properly formed.
14:37:15 <_jgr_> I started writing an issue on this, but briefly there appears to be no documentation to tell script authors what "properly formed" is
14:37:41 <peter1138[d]> You found documentation at all? ๐
14:38:13 <_jgr_> There is plenty of stuff on the wiki and in doxygen
14:38:25 <_glx_> yeah the doc only says "in the same format as OpenTTD does, including tags like {BLACK}, {STRING1}"
14:38:41 <_glx_> without details on the commands themselves
14:39:25 <peter1138[d]> By the argument that there is no document to say what is properly formed, we should just accept anything.
14:39:30 <_jgr_> None of it says anything about STRING vs STRINGN and the text APIs by themselves don't suggest why authors should care about how parameters are mapped internally
14:39:48 <peter1138[d]> It's not mapped internally though.
14:40:18 <peter1138[d]> The expectation is they get a string. And can put that string in somewhere else.
14:40:36 <_glx_> anyway the validation ensure the param count is correct for the substring even if the parent string is not using the correct command
14:40:39 <peter1138[d]> But it seems what actually happens is they get a reference to a string that'll be built later.
14:41:22 <peter1138[d]> destination_string = GSText(GSText.STR_INDUSTRY_NAME, destination);
14:41:53 <_glx_> yes string are built when passed to openttd
14:42:03 <peter1138[d]> Translations I suppose.
14:42:21 <peter1138[d]> If it was made concrete during that call then it would be stuff forever ๐
14:42:50 <_glx_> not translations (that's handled by openttd when drawing), but encoding of parameters
14:43:28 <peter1138[d]> Yes, it's handled by OpenTTD -- but if it was made into a concrete string at that point then it couldn't be translated. That was my point ๐
14:43:42 <peter1138[d]> std::string I mean.
14:43:48 <peter1138[d]> Sorry I missed that.
14:44:12 <_jgr_> Script authors effectively provide parameters as a tree, not as a linear sequence
14:44:39 <_jgr_> So the parameter count stuff doesn't really make sense unless you know about that linearisation
14:46:08 <peter1138[d]> Okay, well it's a one-liner to allow it and not care about versions.
14:47:27 <_glx_> I think authors won't like the errors in scriptlog when writing new GS, so they do the "right" thing ๐
14:49:05 <_glx_> a missing param is auto fixed with a 0 (which won't display the expected string) so they will most likely fix their code
14:49:22 <peter1138[d]> No, if we allow it, then there are no errors in scriptlog.
14:49:31 <_jgr_> It seems like setting up script authors to fail when they won't understand what they're supposed to do
14:50:03 <_glx_> extra params will offset the params, and is not fully validated now
14:50:22 <LordAro> documentation definitely needs improving
14:50:36 <LordAro> but can we keep the warning in the log but carry on regardless?
14:52:33 <peter1138[d]> Hmm, let me see.
14:53:05 <peter1138[d]> The Debug() message is goen, but the gamescript log is still validated.
14:53:36 <peter1138[d]> But if we're going to allow it... why have the log?
14:54:25 <_glx_> because the strings are incorrect, but validation makes them safe for openttd
14:55:13 <_glx_> and the drawn string might not be what they expected
14:59:48 <LordAro> same reason we (used to?) warn about strings not fitting in buffers
14:59:56 <LordAro> it works, but might not be what you expect
15:06:06 <xarick> fake news! a human player beat Tetris!
15:06:36 <xarick> making it crash, what an achievement
15:08:16 <xarick> the local radio station spreading this as news every hour is cringe
15:25:58 <peter1138[d]> Hmm, I guess a USB Bluray drive makes most sense.
15:26:31 <peter1138[d]> Or at least as much sense as Bluray can make in 2024.
15:42:44 <peter1138[d]> For some reason OpenTTD debug messages are appearing in... my /var/log/syslog !?
15:42:54 <peter1138[d]> > # grep "Trying to read invalid string parameter" /var/log/syslog | wc -l
15:45:52 <peter1138[d]> At least my sudo still works for now ๐
15:46:09 *** Wormnest has joined #openttd
16:11:59 <xarick> SLV_25 - were the already articulated road vehicles in this version?
16:13:51 <peter1138[d]> (svn r10097) -Feature: Add support for articulated road vehicle
16:14:04 <peter1138[d]> SLV_25, ///< 25 4259 (svn r4259)
16:14:25 <peter1138[d]> Articulated rail vehicles were still new at that point ๐
16:30:37 *** thelounge345 has quit IRC (Ping timeout: 480 seconds)
16:50:16 <peter1138[d]> Hmm, game seems to be waiting in NetworkShutDown() for quite a long time.
16:51:17 <peter1138[d]> Still waiting ๐ฎ
16:55:11 <goddess_ishtar> xarick: don't worry I do to
16:59:57 <peter1138[d]> Hmm, 3893ยตs -> 1431ยตs
17:00:06 <peter1138[d]> Not a huge saving, but...
17:14:07 *** gelignite has joined #openttd
17:18:51 <andythenorth> why bother with a patch? ๐
17:26:20 <xarick> I'm assuming so many things in afterload
17:26:56 <xarick> I didn't live the history of OpenTTD, I know little about how things were back
17:30:28 <Eddi|zuHause> just don't touch it.
17:30:53 <andythenorth> don't even look ๐
17:31:09 <andythenorth> data migrations are never anything but procedural string
17:31:17 <Eddi|zuHause> you can look, but sanity not guaranteed.
17:47:36 <Eddi|zuHause> inbetween conversions the game is in all kinds of invalid states
17:58:19 <peter1138[d]> Larger number is master, smaller number is patched.
17:59:35 <xarick> what are you working on?
18:08:06 <andythenorth> persistent storage for trains?
18:17:11 <xarick> What do trains and aircraft have in common?
18:17:43 <Rubidium> xarick: I wouldn't touch afterload for science. Maybe if you're doing a PhD in history...
18:19:18 <peter1138[d]> dbg: [misc] [VL_STATION_LIST] 2134 us [avg: 2134.0 us]
18:19:18 <peter1138[d]> dbg: [misc] [VL_STATION_LIST] 364 us [avg: 364.0 us]
18:19:41 <peter1138[d]> That's Wentbourne...
18:19:57 <_glx_> so high number of things
18:20:09 <truebrain> is it executed once every game? ๐
18:20:56 <_glx_> only if you open some windows I think
18:21:14 <truebrain> so I am not far off ๐
18:21:38 <Rubidium> xarick: they both carry only one cargo type, but further vehicles can increase the number of cargo types that can be carried?
18:21:41 <peter1138[d]> Vehicle lists of stations and depots, but also same treatment for the gamescript versions of those.
18:21:50 <peter1138[d]> Which is the one that Xarick abuses ๐
18:27:22 <locosage> peter1138[d]: can you maybe fix #7247 while at it? ;)
18:29:34 <truebrain> is frosch123 now going against his own documentation? ๐
18:30:24 *** frosch123 has joined #openttd
18:30:24 <frosch123> i see no contradiction to the documentation
18:30:47 <frosch123> the docs do not forbid mass changes, they only list some limitations for them
18:30:55 <truebrain> it says eints will overwrite them
18:31:06 <truebrain> otherwise, it needs a bit of rewording ๐
18:33:13 <frosch123> feel free to reword, i have no idea which statement is ambiguous
18:33:32 <truebrain> that is very ... unambigious ๐
18:33:45 <truebrain> it leaves no room ๐
18:33:47 <frosch123> yes, that one should stay, just to discourage people
18:33:52 <peter1138[d]> xarick: so not as fast as your change in that area, but still an improvement.
18:33:53 <frosch123> it's a fake fact :p
18:34:00 <frosch123> like "we reed the suggestion forum"
18:34:02 <truebrain> and ... how do we know, as mere mortals? ๐
18:34:05 <_glx_> did a quick GS test with `STR_TEST :{STRING} - {COLOUR}{STRING}`
18:34:34 <frosch123> all other sections give reasons, this one does not ๐
18:34:59 <peter1138[d]> ^ Now includes the one-liner to allow GSText strings to work.
18:35:09 <peter1138[d]> But I need to modify to remove the redundant code.
18:35:17 <_glx_> so {COLOUR} used the extra param from first string and second string received the colour
18:36:09 <frosch123> yes, as i wrote in the PR, the PR will work, reverting the PR with another PR won't ๐
18:36:27 <frosch123> PRs only work for new translations, they cannot handle edit wars
18:36:31 <truebrain> yeah ... I still wouldn't know how we would know that ๐ Happy you know, don't get me wrong, but .. ๐
18:38:09 <xarick> i recommend using dummyAIs
18:39:24 <DorpsGek> - Update: Translations from eints (by translators)
18:41:08 <truebrain> at least some snippets for future-us ๐
18:41:12 <truebrain> for over .. 10 years ๐
18:41:47 <peter1138[d]> I never believed it wasn't... never had a problem every time I've done it ๐
18:43:38 <truebrain> yet you didn't say anything ๐
19:01:34 <peter1138[d]> I always assume you know more than me ๐
19:01:49 <truebrain> lolz; that is a terrible assumption to have ๐
19:01:52 <andythenorth> I do that tooooo
19:02:18 <truebrain> but granted, I assume the same about you peter1138[d] , so we created a cycle! ๐
19:07:19 <_jgr_> I have an idea to make this all less painful, I'll see if I can make a draft PR in a day or two
19:09:08 *** Flygon has quit IRC (Quit: A toaster's basically a soldering iron designed to toast bread)
19:12:06 <peter1138[d]> So coping from StringParameters modifies the original parameters? Or something else is going on...
19:12:21 <peter1138[d]> It seemed to work considering it's meant to not work.
19:12:47 <_jgr_> It's in the destructor when parent is non-null
19:13:35 *** gelignite has quit IRC (Quit: Stay safe!)
19:19:50 <_zephyris> Why are original graphics signals different to OpenGFX1 signals? Is there a logic/realism argument/something behind that?
19:54:32 <frosch123> huh? i don't understand the question. what is different?
19:59:29 <xarick> I don't understand consts
20:00:18 <xarick> let me expose my problem with gist
20:04:32 <xarick> it's in another bracket!
20:05:57 <xarick> openttd crashes obivously, it's iterating trains!
20:06:08 <Rubidium> const is basically a "contract" that you're not going to modify it
20:07:00 <xarick> but it's in another bracket, why doesn't that matter?
20:07:15 <xarick> another scope?! or wtv..
20:08:59 <Rubidium> then for some reason trains have been added to the aircraft vehicle list in between
20:09:22 *** gelignite has joined #openttd
20:10:34 <xarick> when i revert the changes for SLV_136, the one at SLV_146 will work correctly
20:12:10 <Rubidium> oh, line 19 writes the train list into the aircraft list
20:13:12 <LordAro> it assigns, rather than gives a name to
20:13:41 <Rubidium> as in, you got two envelopes. One with the aircraft and one with the trains, at line 19 you open the envelope remove all the aircraft and put copies of the trains into that envelope. Now you got two envelopes with trains (and none with aircraft)
20:14:04 <LordAro> you've effectively got `c->group_all[VEH_AIRCRAFT].vehicle_list = c->group_all[VEH_TRAIN].vehicle_list;`
20:16:17 <_glx_> hehe the joy of references
20:19:15 <_glx_> line 13 says use vehicle_list as a short name for c->group_all[VEH_AIRCRAFT].vehicle_list
20:20:02 <LordAro> i'm not immediately seeing a good solution. different scopes, perhaps?
20:20:07 <_zephyris> frosch123: Original at the top, OpenGFX1 at the bottom. The electric entry/exit and path signals have totally different light layouts...
20:21:01 <_glx_> easier to directly use the long version in range-for
20:22:03 <xarick> I'm going with 2 different names
20:22:36 <_glx_> why use a variable when you access it only once ?
20:23:50 <xarick> for readability I thought
20:24:51 <_glx_> I see 2 for (const Vehicle *v : vehicle_list) but each vehicle_list is different
20:25:11 <_glx_> so effectively each list is used only once
20:26:01 <xarick> I could do (const Vehicle *v : c->group_all[VEH_TRAIN].vehicle_list) all this time?
20:26:45 <_glx_> when you don't need c->group_all[VEH_TRAIN].vehicle_list later in the scope yes
20:27:42 <xarick> I thought that it was helping perform better
20:27:53 <_glx_> compiler is smart enough
20:28:06 <frosch123> _zephyris: ah, no idea. i never understood why they were taller at all. only the yellow/white bar mattered, but the lights only know two states
20:29:15 <xarick> there are only a few cases I've found where the vehicle is deleted, how do I handle those?
20:29:24 <xarick> the list contents is changed
20:30:03 <_glx_> if anything modifies your list you can't use the list
20:31:15 <xarick> I was simply omiting the &vehicle_list, but if I'm to do it in that manner const Vehicle *v : c->group_all[VEH_TRAIN].vehicle_list, I wonder if it's gonna work
20:33:25 <_glx_> `VehicleList &vehicle_list = c->group_all[VEH_AIRCRAFT].vehicle_list;` vehicle_list is a reference to c->group_all[VEH_AIRCRAFT].vehicle_list, `VehicleList &vehicle_list = c->group_all[VEH_AIRCRAFT].vehicle_list;` vehicle_list is a copy of c->group_all[VEH_AIRCRAFT].vehicle_list
20:33:53 <_glx_> forgot to edit the second one
20:34:54 <_glx_> IIRC this one was also incorrect ๐
20:35:44 <_glx_> ha no the removed ++ was fine
21:06:10 *** nielsm has quit IRC (Ping timeout: 480 seconds)
21:09:24 <Rubidium> wow... you found one. There are at least three dozen similar cases ;)
21:11:27 *** gelignite has quit IRC (Quit: Stay safe!)
21:19:28 <_zephyris> Niche question: Has anyone actually seen the endgame magazine in TTD? Or in OTTD? Half of the front cover is #0000FF transparent blue in the original graphics.
21:20:19 <frosch123> ogfx had a bug for 10 years: most of the score-1000 screen were flashy water
21:20:35 <frosch123> noone reported it, just nml reported it somewhen
21:20:54 <frosch123> i did not even know there was a different screen for score=1000
21:24:50 <frosch123> hmm, i just tried in dosbox: there is a fade-through-black transition to the endgame and highscore screens
21:32:50 <frosch123> ah, the transparent blue also affects the only the score=1000 screen
21:36:13 <xarick> yay, finished science on AfterLoadGame(), that massive function
21:36:44 <frosch123> _zephyris: openttd with original DOS graphics, score=1000:
21:37:03 <frosch123> harder to test with TTDP
21:37:48 <_zephyris> frosch123: Yeah... I'd love to know the intended behaviour!
21:37:53 <frosch123> it's possible that it is just black in TTD
21:38:04 <frosch123> there used to be an extra sprite flag to apply transparency
21:38:15 <frosch123> but ottd probably got rid of that
21:38:30 <frosch123> without that flag, colour 0 is pure black
21:39:32 <frosch123> but i cannot even get that info out of grfcodec anymore
21:43:05 <xarick> the moment of truth... TICC TOCC AfterLoadGame
21:47:38 *** Wormnest has quit IRC (Ping timeout: 480 seconds)
21:50:23 <xarick> wow, you found that many
22:01:45 <kuhnovic> 9 scripts died unexpectedly in a fireball
22:03:16 <xarick> okay, i found some savegames where I get some gains
22:04:40 <_jgr_> The saveload conversion code is quite subtle and serious rigour is required
22:04:50 <_jgr_> I'd suggest that you leave it alone
22:05:02 <xarick> I'm going to, I was just curious
22:07:14 <frosch123> looks like it was uniniitialised-memory-colour before?
22:07:51 <frosch123> either way, TTDP works entirely different with that fade-to-black transition
22:07:59 <frosch123> and TTDP has no signcheat for scores
22:08:05 <frosch123> so, no way to really check
22:10:56 <xarick> what's the biggest oldest savegame you have out there?
22:16:41 <xarick> some of the savegames here have an error
22:27:16 <_glx_> if it loads in 13.4 but doesn't in master it's a regression, and you should file a bug report
22:38:14 *** Wormnest has joined #openttd
22:43:42 <peter1138[d]> Hmm so my 'fix' only worked because it was the last item
23:05:58 *** keikoz has quit IRC (Ping timeout: 480 seconds)
23:24:52 <peter1138[d]> Could the recent http changes be causing my OpenTTD to hang when closing...
23:39:22 <peter1138[d]> _zephyris: "nice" etc etc
23:39:48 <peter1138[d]> Also the original game does a palette fade-to-black, and then fade-in to the screen.
23:40:18 <peter1138[d]> I wonder if I shoud... ๐
23:41:31 <_zephyris> Hehe, I say yes ๐
23:43:11 <_zephyris> Annoying as splash screens can be, they do add an air of professionality, and a big OpenTTD logo then fade into the title screen would be fun. (skipped by any interaction of/c)
23:52:32 *** Wormnest has quit IRC (Ping timeout: 480 seconds)
continue to next day โต
