IRC logs for #openttd on OFTC at 2023-03-28
⏴ go to previous day
01:53:53 *** _aD has quit IRC (Quit: leaving)
02:06:07 *** Wormnest has quit IRC (Quit: Leaving)
02:12:11 *** debdog has quit IRC (Ping timeout: 480 seconds)
02:27:29 *** D-HUND is now known as debdog
03:14:59 *** Wuzzy has quit IRC (Remote host closed the connection)
05:03:49 *** keikoz has quit IRC (Ping timeout: 480 seconds)
05:24:56 *** snypermc[m] has joined #openttd
05:57:39 <andythenorth> I don't understand what 'wants to go to C' means there
05:57:51 <andythenorth> cargo doesn't 'want' to go anywhere afaict
05:57:52 <Rubidium_> sittinbythefire: 1) game scripts build as towns. 2) for towns (and thus GS) there used to be no validation whatsoever. 3) GS could therefor build roads with non-existing types, which do not support standard road vehicles. 4) I implemented the check, where 'can be built as town' overrides 'hide from building'. 5) I got told off that 'can be built as town' does not override 'hide from building',
05:57:58 <Rubidium_> resulting in #10546
06:00:26 *** snypermc[m] has left #openttd
06:26:28 <petern> But yes, towns building road types that players can't is weird. Like AIs having special vehicles that players can't use...
06:30:55 *** sla_ro|master has joined #openttd
06:45:26 <Eddi|zuHause> the important part is what is written in the specs
06:46:19 <Eddi|zuHause> the implementation must follow the specs, not the other way around.
06:48:24 <Rubidium_> it's not fully explicit, so it's all in how you interpret it
06:51:59 <Rubidium_> after all, a GS has a proxy for the "construction menu", i.e. GSRoadTypeList, and it builds as town. So, which one wins... disabling the road type or enabling it for building by towns?
06:53:01 <Eddi|zuHause> intuitively i'd favour disabling wins
06:56:19 <Eddi|zuHause> so we're back to the original question. do we go with the more logical approach, or do we keep NewGRFs "working" relying on unspecified behaviour
07:19:50 <JGR> Prior to the recent spec change, NewGRFs were relying on the specified behaviour. It seems unhelpful to change the spec in the way that is explicitly not compatible with existing users.
07:22:14 *** Extrems has joined #openttd
07:26:27 <Rubidium_> JGR: but what is actually specified? That's the point. There is effectively a disable and an enable flag, which takes precedence? That's unspecified.
07:27:59 <petern> I don't believe there was a spec change.
07:30:05 <petern> The spec is actually "hide ... from construction menu" rather than disabled.
07:30:41 <petern> But that's copied over from rail types, where only players can build rails.
07:49:26 *** HerzogDeXtEr has joined #openttd
07:55:31 <JGR> Given that GRF authors are encouraged to use NML, it does not seem unreasonable for them to use the flag as it is documented?
07:55:56 <andythenorth> we don't use the NML docs as spec
07:56:01 <andythenorth> quite often they're just a guess
07:56:18 <JGR> GRF authors do, otherwise what is the point of them being there?
07:56:20 <andythenorth> it is not unreasonable, but the NML wiki is wrong
07:56:24 <andythenorth> which is my error
07:56:33 <JGR> " Hide this road type from construction menu "
07:56:35 <andythenorth> the NML wiki is often wrong
07:57:05 <andythenorth> I couldn't be arsed to write the NML docs for NRT, and when someone else volunteered I encouraged them
07:57:22 <andythenorth> then I failed to check their contributions for accuracy
07:58:57 <Rubidium_> JGR: in other words, in the scenario editor there is a chance that towns can build roads that you are not allowed to while making the scenario
07:59:40 <Rubidium_> or even "worse": a game script has essentially the "construction menu", and if it's close enough to a town it builds as town. But it may not use the road type that the town is using
08:01:27 <Rubidium_> (which was why I initially let the scenario editor/GS build anything for which the "enable for town" bit is set)
08:01:40 <JGR> GRFs with previously worked now don't work at all because there are no town buildable roads, and in existing savegames which use them town growth no longer works
08:02:41 <Rubidium_> previously a GS could also build non-existing road types, as there simply was not a check at all
08:02:43 <JGR> I'm just looking at it from the point of view where regressions are not helpful to users
08:03:50 <JGR> The user isn't going to understand the spec minutiae of why not working is the correct state
08:16:51 <petern> And maybe one of those red warnings but 1) I don't know how to do that off the top of my head 2) it's probably not that serious.
08:45:46 <petern> Which'll win, msys2 or codeql...
09:19:02 *** crem has quit IRC (Ping timeout: 480 seconds)
10:00:19 <pickpacket> petern: what are those? 🤔
10:14:38 *** yubvin[m] has joined #openttd
10:27:45 <petern> The two longest running CI checks.
10:28:28 <petern> msys2 was 32 minutes, CodeQL was 43 minutes, oof.
11:31:12 *** GeorgeVB has joined #openttd
11:31:12 <GeorgeVB> Is it possible to check railtype of the depot in the build vehicle menu in variations?
11:32:28 <Brickblock1> you could try checking tracktype but other than that I don't know
11:39:12 <Brickblock1> I guess it isn't possible then
11:39:34 <Brickblock1> But maybe you could test compatible railtypes
11:40:41 <GeorgeVB> They are also unsupported in purchase list
12:04:51 <petern> You can get the railtype once the vehicle is purchased. Before that it an engine doesn't exist, it's just the type design details you can see.
14:32:04 *** clark[d] has joined #openttd
14:32:04 <clark[d]> Hello, Where do I start if I am interested to contribute to the code?
14:34:58 <LordAro> Depends what you want to do!
14:35:21 <LordAro> or where your experience lies
14:35:32 <GeorgeVB> petern: When the vehicle has been built already, displaying any information in the purchase list is no longer actual, unfortunately.
14:37:14 <petern> The vehicle is exactly the same regardless of what rail type its constructed on, so any information shouldn't be affected by the depot rail type.
14:41:15 <clark[d]> LordAro: I guess it does doesn't it! I'm experienced enough within some object orientated programming languages but this would be new for me.
14:41:55 <GeorgeVB> > shouldn't be affected by the depot rail type.
14:41:55 <GeorgeVB> That's correct unless we a speaking about vehicles' groups, that can't be build. It consists of several vehicles, that are available on different railtracks types.
14:41:55 <GeorgeVB> And for that I'd like to provide different information in different depots.
14:42:24 <GeorgeVB> Let me provide some more information about the case
14:44:25 <TallTyler> I suspect many people get started by fixing or adding something that scratches a personal itch. That’s what I did, anyway. If you don’t have one of those, you could look at the GitHub issues tagged “good first issue” for some straightforward bugfixes and feature requests.
14:45:20 <GeorgeVB> I want o make a E series EMU group, that consists of Sv, Sd, Sm, Sr, Sr3 and Sn
14:45:20 <GeorgeVB> Sv and Sd are for 1,5kV electrified rails, Sr3 and Sn are for 3kV, and Sm and Sr can run on both.
14:45:59 <clark[d]> TallTyler: Good idea. I'll have a think if I have a personal itch.
14:46:34 <LordAro> may give you some ideas
14:46:44 <GeorgeVB> So, in 1,5kV depot first 4 would be available, and in the 3kV one the last 4.
14:46:56 <LordAro> ("good first issue" is fairly arbitrary and problem may actually be very difficult :D )
14:48:03 <GeorgeVB> I can't make 2 groups (one for 1,5kV depot and one for 3kV depot), because I can't put Sm and Sr in both groups.
14:51:19 <GeorgeVB> And I want to have a group name something like "1,5kV EMU S series" in 1,5kV depot and something like "3kV EMU S series" in 3kV depot
14:56:12 <GeorgeVB> I hope I have explained my case clearly, if not please ask.
14:59:47 <Brickblock1> why not make three groups, that way it is also clearer that it can run on both types
15:03:23 <Brickblock1> you can have groups within other groups
15:04:51 <GeorgeVB> Yes, but sorting happens according on the top level first, regardless the groups inside
15:06:20 <Brickblock1> Do you need the 1,5 kv prefix?
15:06:37 <Brickblock1> you already know it is that from the depot window
15:07:07 <Brickblock1> or you probably don't care since you don't have a compatible trackset
15:10:05 <GeorgeVB> xUSSR set is intended to be used with xUSSR rails, but it is nod mandatory. In case some other rails set would provide difference between 1,5kV and 3kV DC it should become meaningful.
15:14:41 <Brickblock1> they would still probably say that in the depot
15:15:33 <Brickblock1> and it is the depots job to tell you what track it is you are buying a vehicle for not the trainsets
16:41:41 <dP> what a lovely weather today...
16:59:07 <petern> Trying to judge weather, MET office says dryish weds, wet thursday, BBC says opposite :/
17:05:18 *** gelignite has joined #openttd
17:05:59 *** gelignite has quit IRC (Read error: Connection reset by peer)
17:06:26 *** gelignite has joined #openttd
17:06:30 <_aD> petern: ah, another Brit who has both apps installed
17:06:50 <_aD> here darn sarf I find Met Office more accurate.
17:07:23 <petern> If browsing a website counts as an app...
17:08:34 <dP> well, it sure is simple to judge when roofs are flying 😅
17:14:19 <petern> As apps go, Google's says wet on both
17:24:14 *** tokai|noir has joined #openttd
17:24:14 *** ChanServ sets mode: +v tokai|noir
17:31:06 *** tokai has quit IRC (Ping timeout: 480 seconds)
17:37:16 *** _aD has quit IRC (Quit: leaving)
17:51:24 <LordAro> i think i have 3 weather apps installed
17:51:30 <LordAro> usually go with met office though
17:53:47 <ag> I used to think BBC was accurate about weather reports
17:54:25 <LordAro> BBC moved away from the met office a few years ago
17:59:59 <LordAro> petern: i bought 5 last week
18:00:36 <petern> My MTB front is pretty worn, slipping a bit
18:00:46 <LordAro> both bikes have managed to wear out at approximately the same time, and i need an extra one for the dynamo wheel
18:00:47 <petern> Probably just my lack of skills
18:01:20 <LordAro> still need to buy the lights and things for dynamo as well..
18:01:28 <LordAro> and probably other stuff too
18:08:09 <petern> Dynamo by itself is not that useful no 🙂
18:14:43 <TallTyler> A couple questions about settings, for my ongoing NoDL 2 project:
18:14:43 <TallTyler> 1. For integer settings with left/right buttons to change the value, where do I set the delta for each click?
18:14:43 <TallTyler> 2. Service intervals won't be able to use a sensible default value, since it will depend on the real-time setting (e.g. 150 days or 5 minutes). Is there a way to get the default value from a function instead of the ini file?
18:26:46 <frosch> TallTyler: (1) there is an "interval" in the .ini files
18:26:46 <frosch> (2) don't store the default value then. instead add a value like "0" or "-1" with meaning "default". if there is a limited number of units, you could also consider adding separate settings for each unit, of which only one is used in a game
18:32:24 <TallTyler> Ah, thanks, now I see the code for dynamically setting the interval if not given. 🙂
18:35:39 <TallTyler> I'm not understanding what happens after your suggestion to use 0 or -1 as a default. How does this get resolved into the correct value when starting a new company? (or opening the settings, although that's _settings_client, and I'm not sure where that's set)
18:43:42 <DorpsGek> - Update: Translations from eints (by translators)
18:48:23 <frosch> i don't know what values your service setting will have 🙂
18:49:04 <frosch> what is supposed to happen with the default value, if you change DL?
18:49:14 <TallTyler> I mean, if I use 0 as the default and then open the settings, does it say 0?
18:51:07 <TallTyler> So there are two settings: whether to use real-time units or stick with calendar dates, and how fast calendar time progresses. Anything other than 100% progression requires real-time mode, but that’s not important to service intervals.
18:52:10 <TallTyler> Service intervals only care about the first setting: do they show minutes or days? The default for trains is 150 days, but if we are using real-time mode (and can look at that setting to tell), the default should be 5 minutes.
18:53:45 <TallTyler> I’ve got the callbacks working to change the defaults when you change real-time mode, but if you just start a game without changing settings, it uses 150 no matter the setting.
18:54:52 <frosch> ok, if you switch between days/minutes in main menu, it will convert the service-interval setting value?
18:56:23 <frosch> and when you then start a game, it will use that value?
18:56:52 <TallTyler> I guess that’s theoretically enough, since there shouldn’t be a way to get into real-time mode without changing the setting
18:57:17 <TallTyler> Let me reset my config file and try to start a new game to see if I can sneak past it
19:08:35 <TallTyler> Hmm, keeping things straight between `_settings_newgame` and `_settings_game` is annoying, but in other news I broke the subartic intro game to use temperate ground sprites 🙃
19:28:04 <Kuhnovic> Looks much more cheerful!
19:48:23 <TallTyler> Ugh, at least every other time I try to reference a function defined in another file I forget something and get unresolved externals while building, even though Intellisense can find it. It's declared in the header which is #included in the file where I need it, I removed the static keyword...what am I missing?
19:52:32 <dP> check that function signature in hpp matches cpp including const if it's a class method
19:52:42 <dP> also cpp is in cmake lists xD
19:53:20 <TallTyler> It's not a new file, but it is a strange one -- trying to reference `settings_table.cpp` from `genworld_gui.cpp`
19:53:27 <TallTyler> So perhaps it's weird
19:55:04 <TallTyler> Nope, it's just `void ChangeCalendarProgressSpeed(int32 new_value)`
20:01:19 *** Wormnest has joined #openttd
20:16:47 *** gelignite has quit IRC (Quit: Stay safe!)
20:19:41 <TallTyler> Hmm, still can't figure it out 🫠
20:19:54 <TallTyler> I've done this a million times, something must be weird here
20:22:16 <Kuhnovic> try "extern void ChangeCalendarProgressSpeed(int32 new_value)". This essentially tells the compiler "this thing is defined somewhere in the current binary".
20:23:01 <Kuhnovic> Definitely preferrable to do it via regular header includes though
20:23:13 <TallTyler> Yeah, I've tired that too, both with and without a header declaration
20:24:46 <Kuhnovic> Hmm, strange. When I run into something like this I often just do a clean build to make sure I'm not crazy.
20:25:04 <TallTyler> I'll give that a try
20:25:52 <Kuhnovic> The sad thing is that it has helped more than once 😛
20:29:35 <TallTyler> What if I reboot my entire computer?
20:31:29 <andythenorth> reinstall windows
20:32:29 <dP> jokes aside doing a clean build may worth a try in case something bugged out
20:34:24 *** discord_user_f4a0790 has joined #openttd
20:34:24 <discord_user_f4a0790> delete system 32
20:35:51 <dP> dP: what I sometimes do is just take function signature from cpp and copy-paste it into hpp just to make sure I didn't make a typo or smth.
20:36:13 <TallTyler> I did that, it is an .h header if that makes a difference
20:38:11 <TallTyler> Intellisense can find the definition from `genworld_gui.cpp` when I use it. It's just the compiler that totally chokes.
20:41:24 <glx[d]> don't trust intellisense 😉
20:41:28 <Kuhnovic> I've had intellisense jump to entire different files containing functions with the same names
20:42:29 <glx[d]> oh isn't settings_table.h a generated file ?
20:43:44 <Kuhnovic> It is in the src folder
20:43:48 <TallTyler> It doesn't say so, are you thinking of `settings.h`?
20:44:18 <TallTyler> `settings_table.cpp` is for setting change callbacks, which I'm trying to use in a different file
20:45:01 <Kuhnovic> Looking at the header file now, did you add "extern <yourfunction>" to the header or to the cpp file?
20:45:51 <TallTyler> I added `void ChangeCalendarProgressSpeed(int32 new_value);` to `settings_table.h` and `#include "settings_table.h"` to `genworld_gui.cpp`
20:47:10 <glx[d]> but settings_table.h is not really the location for that
20:47:21 <Kuhnovic> And you do have an implementation of ChangeCalendarProgressSpeed(int32 new_value) somewhere right?
20:47:52 <TallTyler> The implementation is in `settings_table.cpp`, which is why I used that header
20:48:26 <michi_cc[d]> Post the diff to a gist, much easier than guessing.
20:49:56 <glx[d]> setting callbacks seem to be static in settings_table.cpp
20:51:19 <glx[d]> ok check the .ini I think it's also defined static there
20:52:35 <TallTyler> That was the mistake I made last time 🤦
20:52:44 <TallTyler> Maybe I'll learn for next time
20:54:30 <TallTyler> Thanks all for the help 🙏
20:55:11 <TallTyler> I'm also getting a strange intermittent crash that I can't figure out, if anyone wants to take a look. I can't reproduce it on master, so it's something I changed...I just don't know what.
20:56:14 <TallTyler> Actually, it's two different crashes, now that I'm reading the logs
20:56:51 <TallTyler> That crash is when exiting the game, and happens both from the main menu and from in-game (both intermittently). I also get this crash occasionally when starting a new game:
21:00:17 *** keikoz has quit IRC (Ping timeout: 480 seconds)
21:00:26 *** nielsm has quit IRC (Ping timeout: 480 seconds)
21:00:50 <glx[d]> you can open the dmp in visual studio
21:01:29 <TallTyler> `The thread tried to read from or write to a virtual address for which it does not have the appropriate access.`
21:01:40 <TallTyler> I'm not sure what I broke, though
21:01:47 <glx[d]> you just need the same source, the exe and the corresponding pdb (generated with the exe)
21:02:09 <glx[d]> once dmp is open you can "start" it
21:05:02 <glx[d]> crash seems related to settings
21:07:42 <glx[d]> maybe _settings_newgame.ai_config[c] is not null but also contains garbage
21:13:28 <glx[d]> both crash are related to AIConfig though
21:14:42 <TallTyler> I still haven't figured out starting it, but that's concerning
21:15:16 <TallTyler> Isn't AI totally inactive in the main menu? How could it cause a crash when exiting the game?
21:15:53 <glx[d]> this->name = (config->name == nullptr) ? nullptr : stredup(config->name); <-- crashes in strdup, means config->name is not null but contains garbage
21:16:41 <glx[d]> AI don't run, but the config contains AI settings
21:17:25 <TallTyler> Okay, so I'm polluting the config somehow? Maybe by adding something unsafely?
21:17:55 <glx[d]> and the second crash happens during newgame to game copy
21:19:33 <glx[d]> so both crash seems to be _settings_newgame.ai_config[c] contains garbage
21:21:23 <TallTyler> Could the StartNext enum be overflowing?
21:34:03 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
21:34:09 *** WormnestAndroid has joined #openttd
21:43:52 <glx[d]> don't think it's caused by that
22:01:55 <JGR> Those crash logs look bizarre, RSP and the raw stack values don't look sensible at all
22:02:09 <JGR> However it's managed to get a sensible enough stack trace
22:03:32 <JGR> Hmm, seems I'm misreading things
22:12:37 *** Flygon has quit IRC (Quit: A toaster's basically a soldering iron designed to toast bread)
22:14:46 <JGR> Adding _settings_game = _settings_newgame in UseRealtimeUnits is the problem
22:15:28 <JGR> This structure contains owning pointers so you get a use after free or double free
22:15:39 <TallTyler> Any thoughts on a better way to do that?
22:17:21 <JGR> You should probably use GetGameSettings() instead
22:18:42 <JGR> The settings window should only edit the relevant set of settings, instead of both
22:19:17 <TallTyler> Hmm, why am I even doing that? There's clearly a reason but I can't figure it out...
22:19:58 <TallTyler> It might be leftover from when I had some other newgame/game mixups going, and that fixed it accidentally
22:21:02 *** Wolf01 has quit IRC (Quit: Once again the world is quick to bury me.)
22:22:06 <TallTyler> Oh, I remember. The {RTS} string code only checks _settings_game
22:22:20 <TallTyler> Probably should fix that to check the game mode properly, instead of this hack
22:23:15 *** sla_ro|master has quit IRC ()
22:26:26 <JGR> Seems that that is what was clobbering the climate setting for the title save as well
22:28:55 <TallTyler> Yep, that sounds like a suitable disaster
22:29:29 <TallTyler> I've fixed it, let's see if the crashes stop 🙂
22:35:26 <TallTyler> Right, I've fixed the global variable addresses too, that's my limit for today 🙂
22:58:37 *** HerzogDeXtEr has quit IRC (Read error: Connection reset by peer)
continue to next day ⏵
