IRC logs for #openttd on OFTC at 2021-12-11
⏴ go to previous day
00:03:03 <peter1138> Yeah, stuck at 2/6 sounds like a network issue not a performance issue.
00:22:05 *** HerzogDeXtEr has quit IRC (Read error: Connection reset by peer)
00:30:55 *** Kitrana has joined #openttd
00:33:20 *** Kitrana1 has joined #openttd
00:39:00 *** Kitrana has quit IRC (Ping timeout: 480 seconds)
00:41:42 *** jottyfan has joined #openttd
00:44:59 *** Wolf01 has quit IRC (Quit: Once again the world is quick to bury me.)
01:03:12 *** jottyfan has quit IRC (Quit: jottyfan)
01:26:27 *** D-HUND is now known as debdog
01:55:03 *** WormnestAndroid has quit IRC (Ping timeout: 480 seconds)
01:55:46 *** WormnestAndroid has joined #openttd
02:38:31 *** roadt__ has joined #openttd
02:45:08 *** roadt_ has quit IRC (Ping timeout: 480 seconds)
03:07:45 *** Wormnest has quit IRC (Quit: Leaving)
03:25:08 *** _aD has quit IRC (Quit: leaving)
03:27:22 *** Kitrana1 has quit IRC (Ping timeout: 480 seconds)
03:27:25 *** debdog has quit IRC (Ping timeout: 480 seconds)
03:31:43 *** Kitrana has joined #openttd
03:35:02 *** Kitrana1 has joined #openttd
03:39:45 *** Kitrana has quit IRC (Ping timeout: 480 seconds)
04:33:59 *** D-HUND is now known as debdog
06:26:16 *** Tirili has quit IRC (Quit: Leaving)
07:34:57 *** Speedyn has quit IRC (Ping timeout: 480 seconds)
08:16:41 *** andythenorth has joined #openttd
08:36:41 *** WormnestAndroid has quit IRC (Remote host closed the connection)
08:45:28 *** sla_ro|master has joined #openttd
08:54:37 *** jottyfan has joined #openttd
09:29:32 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain commented on issue #9742: [Bug]: "Your PC is too slow to keep up with this server" https://git.io/JDOMg
09:42:35 *** andythenorth has quit IRC (Quit: andythenorth)
09:46:09 *** jottyfan has joined #openttd
09:47:17 *** andythenorth has joined #openttd
09:55:22 *** andythenorth has quit IRC (Ping timeout: 480 seconds)
10:11:23 *** jottyfan has quit IRC (Quit: jottyfan)
10:18:49 <TrueBrain> action0::write(output, Feature::Cargoes, cargo_id, action0::Property::Cargo(action0::Cargo::Bitmask), &[b"\xff"]);
10:18:56 <TrueBrain> a tiny bit more readable than just random bytes, I guess ..
10:18:59 <TrueBrain> I wonder if I can do this smarter ...
10:21:39 *** Speedy` has joined #openttd
10:28:33 <TrueBrain> action0::write(output, Feature::Cargoes, cargo_id, action0::Cargo::Bitmask.into(), &[b"\xff"]);
10:28:35 <TrueBrain> tiny bit smaller :P
10:35:46 *** andythenorth has joined #openttd
10:37:47 *** Etua has quit IRC (Quit: Etua)
10:38:42 <TrueBrain> action0::write(output, Feature::Cargoes, cargo_id, action0::Cargo::Bitmask(0xff).into());
10:38:45 <TrueBrain> Rust is pretty cool :)
10:41:24 <TrueBrain> action0::write(output, cargo_id, action0::Cargo::Bitmask(0xff).into());
10:41:41 <TrueBrain> (that it is the feature cargoes can be deduced by the fact you say action0::Cargo)
10:43:51 *** andythenorth has quit IRC (Ping timeout: 480 seconds)
11:06:02 <Rubidium> can't you make a action0::Cargo::Disable, so you do not actually specify a bitmask? It's a few characters shorter here, and more meaningful
11:09:24 <TrueBrain> that line happens to be a very specific case, which are the exception more than the rule :) But possible, for sure
11:09:26 <TrueBrain> write(output, action0::Cargo::Bitmask { id: cargo.id, bitmask: cargo.id }.into());
11:09:33 <TrueBrain> I wonder if that is an improvement to the earlier statement or not ..
11:18:28 <TrueBrain> write(output, action0::Cargo::Disable { id: cargo_id }.into());
11:18:33 <TrueBrain> to apply the earlier suggestion
11:24:11 <TrueBrain> no, I am writing TrueGRF
11:24:41 <TrueBrain> still sad I can't use NML, but what can you do .. it is nice to do stuff in Rust, so there is that
11:27:01 <LordAro> what's stopping you using nml?
11:27:13 <TrueBrain> running Python in a browser is not realistic
11:32:56 *** HerzogDeXtEr has joined #openttd
11:33:57 *** WormnestAndroid has joined #openttd
11:34:03 <TrueBrain> this now became a game of: how far can I abstract everything away :P
11:53:38 *** jottyfan has joined #openttd
11:58:06 <peter1138> Abstract the abstractions
12:05:31 <TrueBrain> Action0::Cargo::Bitmask { id: cargo.id, bitmask: cargo.id }.write(output);
12:05:34 <TrueBrain> I think I can get that to work :D
12:08:38 *** andythenorth has joined #openttd
12:16:42 *** andythenorth has quit IRC (Ping timeout: 480 seconds)
12:34:55 *** virtualrandomnumber has joined #openttd
12:35:33 *** virtualrandomnumber has quit IRC ()
12:38:04 <TrueBrain> action0::Cargo::Enable { id: cargo.id }.write(output);
12:51:40 *** frosch123 has joined #openttd
12:53:53 *** roadt__ has quit IRC (Ping timeout: 480 seconds)
12:57:31 <frosch123> TrueBrain: the biggest problem with nfo abstractions is that every number you put into an action may become a parameter later
12:57:32 <Eddi|zuHause> whatever you're doing, sounds extremely talkative
12:57:58 <TrueBrain> frosch123: what do you mean, sorry?
12:58:15 *** roadt__ has joined #openttd
12:58:27 <Eddi|zuHause> TrueBrain: i think he means that an action 6 can change it
12:58:28 <frosch123> say, you set an industry to produce 90 units/month via the property
12:58:49 <frosch123> it is possible to replace the 90 with a computation/condition at grf-load-time
12:59:15 <frosch123> once you want to support that, a lot of "constants" can suddenly become "variables"
12:59:51 <TrueBrain> ah, like that. Exactly why I was doing this :)
13:00:21 <TrueBrain> I was looking into adding climate support for cargo types :P
13:01:17 <TrueBrain> I should now be able to nest this stuff how-ever I feel like .. I think ..
13:01:31 <TrueBrain> then again, what ever you do, you have to rewrite this 5 times at least anyway :D
13:04:32 *** andythenorth has joined #openttd
13:17:36 <frosch123> is there an easy way to disable ipv6 on linux? some software fails pretty hard if ipv6 does not connect, and does not seem to try ipv4
13:19:23 <frosch123> let's paste random things from the internet into a root shell
13:19:51 <TrueBrain> sounds like shitty software btw :P
13:19:51 <michi_cc> What could go wrong? Just log it first :p
13:22:49 <frosch123> worked, i just piped it through log4j
13:23:39 <TrueBrain> meh, I want to implement a trait on a variant of an enum .. and you cannot do that in Rust :P
13:23:44 <TrueBrain> so how do I fix that ...
13:27:54 *** jottyfan has joined #openttd
13:32:53 *** roadt__ has quit IRC (Ping timeout: 480 seconds)
13:36:06 *** roadt__ has joined #openttd
13:37:30 *** gelignite has joined #openttd
13:50:32 <TrueBrain> lol, vectors in Rust can be a bit annoying .. at least, the syntax :)
13:50:45 <TrueBrain> I want a list of lists, where the inner list can be of any dimensions
13:50:54 <TrueBrain> but Rust is telling me: nope, they have to be of the same size
13:52:08 <frosch123> sounds like it can be solved with an extra level of indirection
13:52:30 <TrueBrain> buffer.push(Vec::from([0x09].iter().chain(string_id.to_le_bytes().iter()).collect()));
13:52:34 <TrueBrain> that doesn't read nice
13:52:51 <TrueBrain> buffer.push(vec![0x09, &string_id.to_le_bytes()]);
13:52:52 <TrueBrain> does, but is not allowed :P
14:08:49 <TrueBrain> nothing a macro can't solve, lol
14:09:39 <frosch123> rust has macros? i hope not like cpp
14:10:03 <TrueBrain> no, they are proper things
14:11:10 <TrueBrain> right, now I got this working, thinking back about what you said frosch123 .. is it really likely you want the value "90" to be depending on some information?
14:11:18 <TrueBrain> or just the execution of the action itself?
14:11:31 <TrueBrain> I would think that if you want 90 to be dynamic, you use a cb
14:11:44 <TrueBrain> or like: for climate A, use 90, for climate B, use 80?
14:12:58 <frosch123> the production rate was just an example :) common cases when you have to inject variables into actions is grf-parameters (obvious) and usage of 2CC recolorings (less obvious)
14:13:21 <TrueBrain> ah, yes, grf parameters ..
14:13:25 <TrueBrain> I wonder if I will ever care :P
14:13:38 <frosch123> nml also does it for optimisation, to compute certain things once, which are known to be constant later
14:14:12 <TrueBrain> but it sounds that is only a thing for a very short list of properties?
14:15:28 <TrueBrain> guess for things like "weight of cargo" I can imagine a grf parameter influences it? But not for name, or sprite number?
14:15:46 <frosch123> i guess it depends how you want to do the climate-specific things: you can use "if (climate) action_with_properties else same_action_with_different_value" or "if (climate) set_variables; action_with_variables"
14:16:03 <TrueBrain> I was thinking the first, honestly
14:16:24 <glx> magic of NFO, many ways to do the same thing
14:18:37 <frosch123> hmm, i guess you can get away with never needing action6, and doing everything in callbacks then
14:19:38 <frosch123> there was the idea to have grf parameters to control vehicle introduction
14:19:53 <frosch123> like steam age ends in year X, diesel age ends in year Y
14:20:02 <frosch123> and then the engine introduction scales along
14:20:10 <frosch123> kind of to avoid daylength stuff
14:20:23 <frosch123> but then V got busy with other stuff
14:20:27 <TrueBrain> so either way, I can postpone that problem to some time in the future :P
14:25:40 <michi_cc> So, how does one rename a struct member that is used in saveload?
14:27:15 *** roadt__ has quit IRC (Ping timeout: 480 seconds)
14:27:23 <TrueBrain> rename? As in, the new name needs to get the old value?
14:28:09 <michi_cc> Yes, with some potential after laod stuff to modify it. Mostly because the old name just does not match with the new function anymore.
14:28:36 <michi_cc> When it used to be positional, this was a total non-issue.
14:28:57 *** andythenorth has quit IRC (Quit: andythenorth)
14:29:09 <frosch123> isn't there a macro where you can pass both variable and name?
14:29:56 <TrueBrain> I can't remember if I had to remove it in the end as "it wasn't used yet" or not :P
14:30:15 <TrueBrain> it is amazing how difficult a context-switch from Rust to OpenTTD is :P Lol
14:31:51 *** roadt__ has joined #openttd
14:31:57 <michi_cc> Seems name macros only exists for SLEG_ variants.
14:32:46 <michi_cc> SLE_CONDVARNAME for a new macro?
14:32:51 <TrueBrain> if I remember correctly, but I would have to read up to it again, there are three ways to approach this:
14:33:01 <TrueBrain> 1) create a new macro where you can rename a field
14:33:07 <TrueBrain> 2) create some glue in the saveload code to alias fields
14:33:25 <TrueBrain> 3) add the afterload code in the chunk handler (instead of the big blob we have now) and use a temporary global to fix up renames
14:33:55 <glx> but savegame itself doesn't care about the name
14:36:39 <TrueBrain> SLE_CONDALIAS(OrderBackup, name, "old_name", SLV_MIN_VERSION, SLV_180)
14:36:49 <TrueBrain> could work too, but I think that would be far less used
14:38:02 <TrueBrain> hihi, we could also add something like SLE_CONDVARNAME(...., AfterLoadMe) :D
14:38:02 <frosch123> what is the intention of that? load with both names, save with new one? or keep both load/save with old name?
14:38:14 <TrueBrain> frosch123: the former
14:38:35 <frosch123> also, yes, we had some PRs now, which need a good way to provide a default, when something is not present in the save
14:38:57 <glx> if it's just a rename (with possible value conversion), I'd bump savegame version and use new name directly in the code
14:39:13 <TrueBrain> glx: headers will prevent you from doing that :)
14:39:46 <TrueBrain> there currently is no glue yet to make the old name end up in the new variable in that case ;)
14:39:59 <michi_cc> #define SLE_CONDVARNAME(base, variable, name, type, from, to) /* stuff */
14:39:59 <glx> but SLE_CONDVAR should be enough then
14:40:05 <michi_cc> Might not become a PR anyway :)
14:40:17 <TrueBrain> michi_cc: sounds reasonable to me!
14:40:41 <TrueBrain> it would be really nice if a lot of the conversion-afterload can be brought more locally .. meh .. so many things we could do to clean up the saveload mess
14:41:07 <TrueBrain> glx: remember savegames now have headers, which are used to figure out what goes where
14:41:11 <TrueBrain> the order is no longer relevant
14:41:21 <glx> and I need to think about a way to delay start GS and AIs
14:41:46 <TrueBrain> you could do a SLEG_CONDVAR ofc, and abuse a global for conversion, but yeah ... not pretty :)
14:42:55 *** roadt__ has quit IRC (Ping timeout: 480 seconds)
14:45:12 <frosch123> i am not sure whether it is a good idea to write the new name to the save
14:45:22 <frosch123> if you rename the variable again, you would need a macro with 3 names :p
14:46:16 <TrueBrain> not following, sorry :P
14:46:16 <glx> no, if you rename again you just have another from/to couple
14:47:59 <michi_cc> Yeah, at least my case needs data conversion anyway, so savegame version bump.
14:48:12 <glx> the issue would be to apply all the relevant renames
14:49:21 <TrueBrain> frosch123: what I was thinking about, is to have an alias, where when reading the header it would map the old names on the new name. That way you only need 1 alias for every old entry, even without savegame bump
14:50:13 <TrueBrain> you could even move that alias-table outside of the saveload struct
14:50:23 <TrueBrain> (and move it into the chunk loader, for example)
14:51:06 <frosch123> that sounds like "SLE_ALIAS(new_name, old_name), SLE_XXX(new_name ...)", i.e. you rename the variable in the regular SLE_xxx and add and SLE_ALIAS
14:52:19 *** roadt__ has joined #openttd
14:55:39 <TrueBrain> codespaces sometimes is weird .. it just randomly shuts down without warning .. still no clue why it does that
14:55:47 <TrueBrain> not a big issue, as you can just restart it
14:57:00 *** andythenorth has joined #openttd
14:57:21 <andythenorth> can I compile grf via log4j?
14:57:36 <TrueBrain> you can do anything you set your mind to!
15:00:34 <andythenorth> daylength in grf eh?
15:00:38 <andythenorth> that's been on my list for ages
15:00:52 <andythenorth> last time it got shot down as an idea
15:01:03 <andythenorth> maybe a 2022 feature :P
15:05:20 *** SpComb has quit IRC (Read error: No route to host)
15:05:55 *** roadt__ has quit IRC (Ping timeout: 480 seconds)
15:11:42 *** roadt__ has joined #openttd
15:16:47 <TrueBrain> action0::Cargo::UnitName { id: cargo.id, name: &cargo.unit }.write(output);
15:16:52 <TrueBrain> writes the string correctly too \o/
15:19:26 <DorpsGek> [OpenTTD/OpenTTD] Azophyte commented on issue #9742: [Bug]: "Your PC is too slow to keep up with this server" https://git.io/JDOMg
15:22:07 <nielsm> you know what the console log is missing? timestamps
15:23:13 <glx> there may be an option for that
15:23:38 <TrueBrain> fucking hate that most of the logs we get don't have them
15:23:57 <TrueBrain> so the client and server are connected via a STUN connection, but by the looks they can't really exchange data .. that is very odd
15:24:03 <glx> anyway "dbg: [net] Client 2 made an error and has been disconnected: general timeout" is the important info I think
15:24:07 <TrueBrain> also, the crashes with console open is odd
15:25:53 <nielsm> I think the "crashes" may be how win32 tends to suspend an application when you make a selection in the console
15:26:00 <nielsm> so it looks like it's hanging
15:26:12 <nielsm> but if you removed the console selection it would resume
15:26:52 <glx> seems the useful info is not printed in the console
15:28:12 <glx> all "IConsolePrint(CC_WARNING, "Client #{} (IP: {}) is dropped because" lines don't apply here
15:30:45 <nielsm> the in-game console and the debug logging really could use an integration...
15:31:32 <LordAro> there's no reason for the former to not be in the latter, i think?
15:31:43 <glx> I think dedicated server includes them
15:41:47 <andythenorth> I heard there's a good java logging tool
15:41:54 <andythenorth> especially on servers for logging user input
15:42:55 <glx> I think the application hanging they noticed is grf scan
15:45:53 <DorpsGek> [OpenTTD/OpenTTD] Azophyte commented on issue #9742: [Bug]: "Your PC is too slow to keep up with this server" https://git.io/JDOMg
15:56:39 <TrueBrain> I rather have timestamps but this is better than nothing :p
15:57:11 <LordAro> timestamps with a reasonable degree of precision are very long
15:57:23 <TrueBrain> Why are the values prefixed with + and -?
15:57:51 <LordAro> '+' because i wanted to make it relative to the previous debug message, but messed up
15:57:58 <LordAro> - because i got my before and after the wrong way round
15:58:01 <TrueBrain> Timestamps are nice as it is easier to process for humans .. these large numbers are tricky to visual diff
15:58:16 <LordAro> let me fix both of those problems and see what you think :)
15:59:09 <TrueBrain> 3h2m12s400ms format would also work I guess
16:02:47 <TrueBrain> BTW, doesn't dedicated server already has timestamps?
16:07:12 <TrueBrain> What if we enable that by default?
16:07:31 <TrueBrain> And not make it optional?
16:09:23 <LordAro> you know, i didn't even see that
16:10:24 <TrueBrain> You just wanted to code, I fully understand :D
16:11:16 <glx> doesn't seem to apply to dedicated console
16:12:50 <LordAro> of course, that LocalTime object doesn't support sub-seconds, afaict
16:14:29 <glx> oh of course it's only for _iconsole_output_file and _debug_socket
16:14:52 <LordAro> i'm not sure i was aware that remote debugging was an option
16:15:41 <glx> ha IConsolePrint() uses them too for dedicated server
16:17:01 *** SpComb has quit IRC (Read error: No route to host)
16:17:41 <glx> ok seems I have an openttd.cfg somewhere in higher priority than the expected one
16:18:11 <LordAro> glx: if only there was a debug message that told you which config file was being loaded
16:26:40 <glx> hmm no config dir is the correct one, but changing "show_date_in_logs" in cfg has no effect
16:32:33 <glx> ok _settings_client is full of 0
16:36:03 *** ChanServ sets mode: +v tokai
16:39:51 <glx> yup settings are loaded later
16:40:38 *** Wormnest has joined #openttd
16:42:57 *** tokai|noir has quit IRC (Ping timeout: 480 seconds)
16:54:59 <glx> though the untimed lime are not really important
17:03:57 <LordAro> just remove the setting, imo
17:40:14 <TrueBrain> right, time to finish my Rust work I guess .. pam pam pammmmmm
17:47:47 *** glx has quit IRC (Ping timeout: 480 seconds)
17:55:05 *** Kitrana1 has quit IRC (Quit: Leaving.)
17:58:05 *** Kitrana has joined #openttd
18:03:29 *** Kitrana1 has joined #openttd
18:05:34 *** Kitrana2 has joined #openttd
18:05:37 *** Kitrana has quit IRC (Read error: Connection reset by peer)
18:05:48 *** andythenorth has quit IRC (Quit: andythenorth)
18:10:15 <TrueBrain> GitHub Copilot is rubbish when you are refactoring
18:10:22 <TrueBrain> it gets really confused between old and new code
18:11:30 *** Kitrana1 has quit IRC (Ping timeout: 480 seconds)
18:20:40 <TrueBrain> its funny to see some flags being u32, others 2x u8 :) (Industry prop 1a vs 21+22)
18:22:53 <frosch123> some properties were originally u8 and then people wanted bigger values. in some cases another u8 was added for the high bits, in some cases a new u16 property was added which overrides the first u8, and in one case another u8 was added which was just shifted by 2 bits
18:26:25 <TrueBrain> industry prop 0f is not documented; lol
18:27:15 <frosch123> you mean there is no extra section with lots of bla?
18:27:29 <TrueBrain> in other words, no clue what it actually does :D
18:27:38 <frosch123> weird that you did not encounter that earlier
18:27:47 <frosch123> it's for most things which are obvious if you know it :)
18:27:55 <TrueBrain> "if you know it" :D
18:28:04 <frosch123> it says "fund cost multiplier"
18:28:23 <TrueBrain> most have some bla about the scale the value is in
18:28:35 <frosch123> all cost in ottd are defined by "base_cost * inflation * cost_multiplier"
18:28:40 <TrueBrain> guess this is just a flat multiplier or something :P
18:29:00 <TrueBrain> "Cargo multipliers in 1/256 units" <- most have details like that
18:30:43 <TrueBrain> had to check the code, but it really is a flat multiplier without scaling :P
18:30:53 <TrueBrain> sounds a bit useless prop to me :P
18:31:22 <frosch123> it's the cost for funding the industry, what else did you expect but a single number?
18:32:09 <TrueBrain> as I quoted earlier, some finer-grained selection I expected
18:32:17 <TrueBrain> now it is like: it is either twice as expensive, or the normal rate
18:32:23 <TrueBrain> want something in between: NOPE
18:32:46 <frosch123> i think you misread something :)
18:34:02 <frosch123> original industries cost between 115 and 244
18:34:36 <TrueBrain> well, that is not misreading .. that is just not being given the full amount of information :P
18:34:37 <frosch123> oil refinery is pretty much the maximum for costs
18:35:19 <TrueBrain> still a bit unexpected, but that is nothing new. At least that makes it a bit more sensible :D
18:38:33 <frosch123> oh, also note that construction cost for primary industry depends strongly on ottd settings
18:39:44 <frosch123> construction at player-selected place is 8x more expensive than prospecting at random place
18:40:33 <frosch123> money is always difficulty in ottd
18:40:49 <frosch123> people keep on changing the economy, thinking they can fix exponential growth :p
18:44:46 <frosch123> maybe use "steel mills" as price unit
18:45:07 <frosch123> if an industry cost 0.9 or 1.1 steel mills, that makes the price independent of inflation :p
18:45:45 <TrueBrain> action0::Industry::Layout { id: industry.id, layouts: &layouts }.write(output);
18:47:53 <TrueBrain> Cargo prop 15 ... one of those other "if you know you know" :D
18:48:17 <frosch123> there is a game setting to make freight heavier than pax
18:48:34 <frosch123> "freight status" is a bool, whether the cargo qualifies as freight or not
18:49:15 <frosch123> it's because people thought freight trains are too fast, and 7-tile freight trains should accelerate like 49-tile trains
18:49:33 <TrueBrain> should I implement that? :D
18:50:47 <frosch123> just derive it from the cargo classes. freight = !PAX && !MAIL
18:50:57 <TrueBrain> right, now for cargo prop 0b, 0c, and 1c .. what would be a sane value .. hmmm
18:51:01 <TrueBrain> owh, that is smart, tnx!
18:51:51 <frosch123> i would check what strings firs sets
18:51:59 <frosch123> i don't think there are that many
18:53:13 <frosch123> STR_CARGO_NAME_xxx is just a single noun
18:53:38 <TrueBrain> yeah .. I currently have that I set all those 3 props to the same string
18:53:41 <TrueBrain> so that seems to align
18:53:42 <frosch123> STR_CARGO_UNIT is mostly {VOLUME} or {WEIGHT} or {SIGNED_WORD} + "of noun"
18:54:07 <TrueBrain> "{SIGNED_WORD} sack{P 0 "" s} of coffee"
18:54:12 <TrueBrain> no clue what happens if I set that to 0b or 0c
18:54:16 <TrueBrain> but 1c should win, I guess
18:54:27 <TrueBrain> just specs are a bit weirdly written .. I have to set 0c first, and 1c after, it suggests?
18:54:31 <frosch123> 1c deprecates some of the other, no idea which
18:54:47 <TrueBrain> I will get bug reports if I did it wrong, I guess :D
18:55:32 <TrueBrain> okay .. now to Action0 IndustryTiles .. should be easy
18:55:32 <michi_cc> The nice thing with some of the deprecated/replaced prop is of course that if two are present, order still wins.
18:55:48 <frosch123> hmm, that suggests that both are used? and old grfs only set 0c, so 0c is used as fallback for 1c.
18:56:11 <TrueBrain> "This textID must be set after property 0c."
18:56:20 <TrueBrain> you can read that in two ways: it overwrites 0c if you set that
18:56:25 <TrueBrain> or: you need to set 0c first, before you can use this
18:56:38 <TrueBrain> no clue if 0c is optional or not :P But what-ever, I can just set both
18:56:41 <TrueBrain> not like I really care :D
18:56:44 <frosch123> both is wrong :) it means "0c overwrites 1c"
18:56:46 <michi_cc> And also: 0c will still overwrite it if it comes later.
18:57:10 <TrueBrain> so 1c only is enough? I guess 0b is also optional in that case? (again, ambiguous :D)
18:57:22 <frosch123> you have to check ottd source for that :)
18:57:38 <TrueBrain> owh, 1b overwrites 0b .. that I did not expect
18:57:45 <frosch123> i recall about a months ago lordaro wanted or did remove the last usage of some cargo string
18:57:56 <frosch123> only used in some weird subsidy news message
18:58:25 <TrueBrain> did not expect 0b to be what it is ..
18:58:39 <TrueBrain> specs give a completely different suggestion :D
18:59:15 <frosch123> rule of thumb: if ottd is a mess, the specs do not make it better :)
18:59:37 <frosch123> if you looked at the strings in ottd, you would not know their purpose either :)
19:00:12 <TrueBrain> comment is pretty clear in this case :P
19:00:32 <TrueBrain> so I will ignore 0b and 0c
19:01:16 <frosch123> oh, 0b/1b and 0c/1c are processed identically?
19:01:30 <frosch123> that must be from a time when grfs targeted both ottd and ttdp
19:01:30 <TrueBrain> turns out 0b / 0c are TTDp specific
19:01:58 <frosch123> TTD strings do not know about plurals and stuff, that is a ludde thing or so
19:02:17 <frosch123> (you may know better)
19:08:00 <TrueBrain> string stuff has always been magic to me :D
19:12:55 <TrueBrain> funny, reloading the GRF with another acceptance for an industry, doesn't update the industry anymore :P
19:13:36 <frosch123> yes, industry cargos can be set via cb on construction, so they are copied into the instance
19:13:53 <frosch123> you have to fund a new one
19:14:26 <TrueBrain> hmm ... the cargo gives me 0 currency
19:14:30 <TrueBrain> guess there is a bug :D
19:15:44 <TrueBrain> especially as I wasn't aware I did anything with prices :D
19:16:59 <TrueBrain> ah .. that is exactly the issue .. I do not set it :D
19:17:04 <TrueBrain> default is 0, it seems :P
19:27:37 <TrueBrain> okay, name, unit-name, cargo-name .. yeah, those names need to be better :P
19:27:43 <TrueBrain> guess short-name and long-name make a lot more sense
19:33:46 <TrueBrain> right .. action0 done ... time for action2 :D
19:35:13 <frosch123> i think you swapped the comments on disable/substitute :)
19:38:19 <frosch123> i wonder how often devs will now blame copilot, if there is somethign wrong :p
19:38:35 <TrueBrain> nah, that was all me
19:40:44 <frosch123> the disable thing is funny. normally industry ids are grf-specific, but when using the disable thingie the id suddenly is used to address an original industry
19:47:17 <TrueBrain> funny as in "specs are funny" or my implementation is? :)
19:48:26 <frosch123> it's hard to put that into an implementation
19:48:34 <frosch123> it looks like a property of the industry, but it really isn't :p
19:48:51 <frosch123> nml uses separate build-ins for that
19:49:10 <frosch123> global functions disable_xyz(id-range)
19:49:21 <TrueBrain> yeah .. what I just do is disable all built-in industries, and always clone the coal-mine to base the rest off
19:49:44 <TrueBrain> and called the first Disable, and the second Substitute .. although I think I will rename the latter into Enable, and force using coal-mine
19:49:51 <TrueBrain> just removes this whole "you need to know"
19:56:44 <TrueBrain> action 1/2/3 are a bit harder to abstract .. hmm .. lets see ..
20:30:58 <frosch123> oi, it's over 10 years now that we migrated the specs from tikiwiki to mediawiki
20:31:14 <frosch123> what a drama that was... and how shitty tikiwiki was
20:31:19 <TrueBrain> migration to TrueWiki when?
20:31:46 <frosch123> we discussed that, mostly because some weird polish guy translated the specs
20:32:30 <frosch123> the original idea behind the specs-wiki was to have a separate wiki that would never be translated, while ottd-wiki and forum-wiki were candidates for translation :p
20:32:41 <glx> so this guy may have a better understanding of the specs than any of us
20:33:16 <TrueBrain> or is just doing a translation, going: wtf wtf wtf wtf wtf
20:33:23 <frosch123> no idea, sometimes i think certain translators are in jail, and have to kill time somehow
20:34:28 <frosch123> but it looks like the translation thingie comes and goes in circles :)
20:34:55 <frosch123> docs used to be in the wiki, they were moved to github md because translations were shit, people keep asking about how to translate them then :)
20:35:39 <frosch123> maybe the solution is to have dorpsgek silently delete translations after 5 years, when noone looks
20:35:58 <TrueBrain> having the specs in a GitHub repo would make much more sense
20:36:03 <TrueBrain> as changes would require reviews
20:36:09 <TrueBrain> so you can make proper RFCs
20:38:14 <TrueBrain> the "flexible" part is the issue :P
20:38:16 <frosch123> maybe we need a new feature for truewiki
20:38:25 <frosch123> get pages from different repos
20:38:45 <frosch123> render english pages from ottd repo, and translations from wiki repo
20:39:02 <frosch123> that would also solve the readme translations
20:39:11 <TrueBrain> it is not a bad idea :)
20:39:19 <frosch123> docs can be in gh docs folder, and translators can still translate them
20:39:27 <TrueBrain> would also require a markdown renderer for TrueWiki :P
20:40:16 <frosch123> gh can also render wikitext, so we could convert the docs again :)
20:40:43 <frosch123> but i guess using wiki templates in the src repo makes little sense
20:40:54 <glx> MD is at least human readable in source form
20:40:59 <frosch123> so maybe it makes more sense to have some iframe feature in truewiki
20:41:11 <TrueBrain> Action8::General { grfid: &"TRU1".to_string(), name: &options.generic.name, description: &options.generic.description }.write(output);
20:41:33 <frosch123> so wiki readme would be: wiki-specific templates like translation links, followed by include-reference of whitelisted gh url
20:42:30 <TrueBrain> a much simpler solution might be to have a small script that syncs some docs from different sources into a new wiki, for the english language, and do a markdown -> wikitext
20:42:36 <TrueBrain> that way TrueWiki doesn't need any modifications ;)
20:42:37 <frosch123> oh right, what do you say instead of "whitelisted" nowadays?
20:42:41 <TrueBrain> put English on read-only
20:42:56 <TrueBrain> run the sync every night or so
20:44:10 <michi_cc> frosch123: inferiorly-pigmented-listed :D
20:44:19 <TrueBrain> and Codespaces decided to shut down again, grrrrr .. no clue why! :P
20:44:37 <glx> they added a max time IIRC
20:45:43 <TrueBrain> yeah, of inactivity
20:45:47 <TrueBrain> I was in the middle of a git commit :P
20:46:15 <michi_cc> Copilot decided you don't count for activity :P
20:46:17 <TrueBrain> right, lets see if I can do action14 proper .. it was a weird one
20:46:55 <glx> and it must be before action8
20:47:02 <nielsm> frosch123: my own preference is allow-list and block-list
20:49:09 <frosch123> action 14 is just a key-value thing with hierarchical structured keys, and values being either translateable strings or binary blocks
20:49:44 *** glx is now known as Guest8253
20:50:46 <TrueBrain> write_pseudo_sprite(&mut output.buffer, &[b"\x14CINFOBPALS\x01\x00D\x00\x00"]);
20:50:46 <TrueBrain> Action14::Palette { palette: 'D' }.write(output);
20:50:51 <TrueBrain> guess doing this does make the code more readable :P
20:51:49 <frosch123> that is a weird level of abstraction
20:51:57 <frosch123> you will never set a different palette
20:52:42 <frosch123> doing Action14(["INFO", "PALS"], b"D") would be useful, since it works for everything
20:53:04 <frosch123> but exposing the "palette" as special thing is useless, isn't it?
20:53:21 <TrueBrain> is it really? Those info things are so special cased ..
20:53:27 <TrueBrain> PALS is different from URL_, for example
20:53:30 <TrueBrain> one is a T, other is a B
20:53:37 <TrueBrain> so you need to do some magic on that anyway
20:53:48 <frosch123> you can dectect the B from the b"" (in python speech)
20:53:55 <TrueBrain> from a user perspective, I want to set the palette .. I don't care where in the Action14 chain that is done
20:54:04 <frosch123> T is translateable string, B is binary blob
20:54:46 <frosch123> TrueBrain: maybe palette is a bad example, but from a user perspective i do not want to set the palette at all :) it is always "D"
20:55:36 <frosch123> sure :) translations are for later
20:55:44 <TrueBrain> translating an URL ... lol
20:56:07 *** Guest8253 has quit IRC (Ping timeout: 480 seconds)
20:56:07 <frosch123> it's an intended feature, in case your docs are translated as well
20:56:08 <nielsm> why not? could be a url pointing to translated documentation
20:56:17 <TrueBrain> frosch123: yeah, I read
20:56:34 <TrueBrain> but that would be so far down my list of things I would implement .....
20:57:23 <frosch123> btw. is there a "publish to bananas"-button on the list?
21:02:55 <TrueBrain> hmm, action14 is not working .... what is the reason ...
21:03:20 <frosch123> you have to rescan the grfs
21:04:19 <TrueBrain> it does that for me :D
21:04:24 <TrueBrain> I love my big green button :)
21:06:37 <frosch123> where on your list is the "dump nfo" button? :)
21:07:16 <glx> nfo output is the most important part of nml :)
21:08:34 <TrueBrain> how hard would it be to port grfcodec to Rust? :P
21:09:15 <frosch123> i really hate grfcodec.... :)
21:09:51 <glx> making it work with cmake (and VS compatible) was enough for me too
21:10:59 <glx> at least 2 different coding styles, and both are "wrong"
21:12:32 <TrueBrain> okay, I assumed 0xff was "dont care about language" too for action14
21:12:54 <frosch123> wherever you used 0xff, it was 0x80+0x7f
21:13:39 <TrueBrain> yeah ... but the action14 points to action4, which says: 0xff works if your stringid is 16bit
21:13:44 <TrueBrain> and I don't care what my stringid is for action14 :P
21:14:04 <TrueBrain> one of those: if you know, you know!
21:14:07 <TrueBrain> right, now it works :)
21:15:12 <TrueBrain> the game is a bit weird if you change a GRF .. it shows the GRF both in "active" (with the old md5) and in "inactive" (with the new md5)
21:15:21 <TrueBrain> ofc the inactive is actually the one that is active, as .. well .. ofc it is :P
21:20:42 <TrueBrain> it still makes me giggle that the first (pseudo) sprite in a GRF is just completely ignored by OpenTTD :P
21:21:39 <TrueBrain> the only condition is that it has a length of 4 .. hmm .. what action to abuse for that ..
21:21:53 <frosch123> ttdp stuff :) read size, allocate memory, keep writing to memory until end of file, not checking the count
21:22:38 <frosch123> pretty sure ttdp just crashes if the num-sprites is too small
21:23:09 <TrueBrain> I love the error: "Custom .grf has invalid format"
21:23:59 <frosch123> that sounds old :p probably written by darkvater or truelight
21:24:19 <TrueBrain> but no other truelight would have written that :P
21:24:28 <TrueBrain> as NewGRFs ... iiiieeeeuuuuwwwwwwwww :D
21:25:32 <TrueBrain> right .. action2 ... guess I really should try to understand what I wrote a long time ago :)
21:25:42 <TrueBrain> write_pseudo_sprite(&mut output.buffer, &[b"\x02\x09", &[failed_set as u8], b"\x89\x0c\x00\x00\x00\xff\xff\x01\x00\x80\x00\x00\x00\x00\x00\x00\x00\x00", &failed_set.to_le_bytes()]);
21:25:46 <TrueBrain> I am sure it made sense at the time
21:26:09 <TrueBrain> or here a better one:
21:26:10 <TrueBrain> write_pseudo_sprite(&mut output.buffer, &[b"\x02\x0a\xfd\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00"]);
21:26:29 <TrueBrain> (both return invalid stuff for the end-of-chain)
21:30:13 <frosch123> also, what is that commit message style?
21:30:43 <frosch123> error("Too many sprites (%x). Recompile with higher NUM_SPRITES value or remove some custom GRF files.", <- lol
21:30:59 <frosch123> there is your num_sprites usage :)
21:37:38 <TrueBrain> okay ... so an action2 chain .. if it expect a sprite, terminating in a 0x8000 causes an error. When it expect a number, terminating in a sprite causes an error.
21:37:52 <TrueBrain> is there a common way to know what the end of the chain will be, I now wonder ..
21:38:33 <TrueBrain> guess not. Some callbacks want sprites, other numbers
21:38:51 <TrueBrain> but at the start of the chain I do already know, I guess
21:39:18 <TrueBrain> an easy way out would be to add both cases as like 0xfe and 0xfd for every feature
21:39:29 <TrueBrain> so I can just point there, or something
21:39:55 <frosch123> the case "expect a sprite, terminate with error" only exists in theory
21:40:01 <frosch123> but you never use that
21:40:21 <TrueBrain> so I can just make a single set which returns a sprite, and that will do for all, you say?
21:40:53 <TrueBrain> why you say it only exists in theory btw? For example, for industry layout, I can imagine I make a mistake and there is no sprite for a given tile?
21:42:36 <frosch123> for callbacks it is normal behavior to return "error" for unknown callbacks, esp. for callback invented after grf release
21:42:50 <frosch123> not retunring sprites is always a bug in the grf
21:44:44 <TrueBrain> okay, so if I generate a set-id with the code of the link you just send, I can safely use that "error" for everything. For sprites, it is a bug. For callbacks, it means "error".
21:46:53 <frosch123> hmm, no :) that site applies to features with spriteset-action2, industries have production-action2, industry tiles have spritelayout-action2
21:47:04 <frosch123> 3 different basicaction2 :)
21:47:41 <frosch123> action2 are: 02 <feature> <type>
21:47:59 <frosch123> types >= 0x80 behave the same for all features
21:48:05 <TrueBrain> bah; I was hoping it was equal for all .. that is just too bad :P
21:48:18 <frosch123> types <= 0x7F have feature-specific format, one of spriteset, production or spritelayout
21:48:44 <TrueBrain> yeah, I know; I was just hoping that 01 00 00 00 was magic enough that it mapped to the same on all :P
21:49:53 <TrueBrain> right, guess the right way would be to pick a sprite that makes it obvious there was an error, and use that for IndustryTiles as fallback
21:50:23 <TrueBrain> or .. hmm .. I can make the cases "clever" enough that the last value is always the default
21:50:33 <TrueBrain> but that might make bugs in TrueGRF less obvious
21:51:17 <frosch123> for spritesets and spritelayouts you can draw the questionmark sprite
21:51:47 <frosch123> for production you could set the "recurse infinite" flag, which ottd will display as "newgrf is broken" popup :p
21:52:45 <TrueBrain> k, questionmark sprite it is .. I did have the id for that, but .. hmm .. lost it
21:52:57 <TrueBrain> well, I know if I screw up I get to see it again, so that won't be difficult to find back :D
21:54:35 <TrueBrain> Action2::IndustryTiles { set: id, ground_sprite: 0x07e6, building_sprite: 0x800000 + id, size_x: 16, size_y: 16, size_z: 32 }
21:55:34 <TrueBrain> that is the easy part of the Action2 :P Now for the variant stuff :D
22:07:28 <TrueBrain> Action2::IndustryTiles::Chain { id: 0xf0, variable: Action2::IndustryTiles::Variables::Position, shift: 0, mask: 0xffff, add: 0, divide: 0, modulo: 0, switch: [ (0x0, 0x0000, 0x0000), (0x1, 0x0100, 0x0100), (0x2, 0x0001, 0x0001), (0x3, 0x0101, 0x0101) ], default: failed_set }.write(output);
22:07:31 <TrueBrain> Action2::IndustryTiles::Chain { id: 0xfe, variable: Action2::Industry::Variables::Layout, shift: 0, mask: 0xffff, add: 0, divide: 0, modulo: 0, switch: [ (0xf0, 1, 1) ], default: failed_set }.write(output);
22:07:35 <TrueBrain> that is not more readable :P
22:07:41 <TrueBrain> but tons of things I can optimize from there ..
22:08:08 <frosch123> just ignore the xistence of add/divide/modulo :)
22:08:42 <frosch123> use advaction2 instead
22:08:50 <frosch123> no need to implement the old special magic
22:08:58 <TrueBrain> owh, yeah, ofc, makes sense
22:09:44 <frosch123> are you defaulting to 32bit va2 like nml?
22:09:59 <TrueBrain> currently I am creating the leafs .. but after that I can make some easy constructs to create the graph, and let it everything for me automated :D
22:10:00 <frosch123> otherwise you would need some "size" thingie
22:10:06 <TrueBrain> yeah, 32bit everything
22:10:10 <TrueBrain> at least, that is what you advised me to do :)
22:11:43 <frosch123> are you aware of the premium bear trap of len(switch) == 0 ?
22:11:58 <TrueBrain> doesn't ring a bell
22:12:24 <frosch123> specifying no ranges is special for "do not switch, return the switch value"
22:13:07 <frosch123> so if you want to chain unconditionally (many valid usecases), you have to duplicate the "default" case into some dummy case
22:13:57 <TrueBrain> what is such a usecase? What does it do if you just jump to the next?
22:14:23 <TrueBrain> guess with the advanced?
22:14:25 <frosch123> it's used if you just want to store some value in some registers, which are used in the spritelayout
22:14:28 <TrueBrain> when setting registers etc?
22:14:32 <frosch123> or if you have to combine values from SELF and PARENT
22:15:17 <frosch123> oh, also, the ranges are unsigned
22:15:39 <TrueBrain> and signed values are 15bit, right? :)
22:15:40 <frosch123> so if you want to set -5..5 you have to split into two ranges -5..-1, 0..5
22:16:00 <TrueBrain> ha, good that you mention; makes sense :)
22:16:21 <frosch123> 15bit is the return value, the switch value is 32bit with unspecified sign
22:17:02 <frosch123> advaction2 has separate operators of signed/unsigned division, etc...
22:17:20 <TrueBrain> ever considered making action15 that doesn't have all this stuff? :P
22:18:01 <frosch123> the plan was: make all grfs author use nml, then make nml compile to some new format, or directly read nml
22:18:17 <TrueBrain> okay, I can understand that path :)
22:19:38 <TrueBrain> just a lot of work for relative little gain, I guess?
22:20:02 <frosch123> it will be like python2->3 :)
22:20:14 <TrueBrain> will take years, basically :P
22:22:04 <frosch123> though the first thing was actually done :p
22:23:32 <frosch123> i guess the "action2 summary" is your action15 :)
22:30:37 <TrueBrain> told you I would render questionmarks :P
22:31:46 <TrueBrain> awh, can't get the ID from it
22:31:48 <frosch123> the ground sprite work, so just enable transparency
22:32:23 <TrueBrain> I was using the sprite aligner to get the sprite-id of the questionmark
22:32:29 <TrueBrain> but it is an invalid sprite-id
22:32:29 <frosch123> there should be a DEBUG print about using an invalid spriteid
22:32:34 <dP> btw, I'm reading some nml output, isn't there a better way to calculate slope_to_sprite_offset of a tile than doing shitton of calculations with var41?
22:32:59 <TrueBrain> but I forgot some zeros at 0x800000 to make it a custom tile id :P
22:33:36 <frosch123> dP: i guess that was before functions were added
22:34:15 <frosch123> using a function would be a single switch: slope_values -> return spriteoffset
22:34:43 <frosch123> dP: i mean, pretty sure it can be done better, just needs a PR
22:35:24 <frosch123> but it was probably not possible to do it better, when that thing was added to nml initially, in nml 0.1 or something :p
22:37:05 <dP> so if I'm doing that without nml I should just make a single switch or is there even better way?
22:37:42 <frosch123> make a single switch and call it as a function
22:37:54 <frosch123> so you can use the result in whatever place you want
22:37:59 <frosch123> like, store in a register
22:39:56 <glx> TrueBrain: just use advanced sprite layout in all cases, it's more logical about sprite from grf and sprite from openttd
22:40:37 <TrueBrain> glx: it just contains so much extra bla that is not useful?
22:41:34 <dP> frosch123, hm, sounds logical, though what if I just repeat the switch for each object? it's not like it need it to be readable xD
22:41:35 <frosch123> only if you use it. otherwise it prboably only differs in 2 bits from your current code
22:41:54 <TrueBrain> owh, with flags I can skip the crap I don't need
22:42:26 <frosch123> dP: the "function" thing is not about being reusable, but about storing a switch result in a variable
22:42:43 <glx> and it now supports (in the spec) no buildings without needing a different format
22:42:46 <frosch123> otherwise you have to chain from each switch-case to a spearate action2 to store the offset in some variable
22:43:07 <TrueBrain> glx: I don't see how I can avoid the 0x8000000 thing to tell if it is a GRF sprite or OpenTTD sprite?
22:44:20 <glx> there's no way, bit31 needs to be set to say GRF sprite
22:44:31 <TrueBrain> okay; so how does advanced help me?
22:44:52 <TrueBrain> (I am confused :P You started that it would be more logical, but I don't understand why :D)
22:44:52 <glx> but my mind mixed up with station sprite layout
22:45:15 <frosch123> TrueBrain: it has less special cases, like for zero building sprites
22:45:18 <glx> where old format is the opposite of advanced format
22:45:37 <frosch123> and you can disable stuff like construction stage and other magic
22:45:53 <frosch123> or use recolor-sprites from action1, but i guess you don't need that
22:46:00 <dP> guess I'll have to figure out how that works first
22:46:22 <TrueBrain> once again GitHub CoPilot wrote a whole blob of code I didn't know how to write, and it is spot-on .. still scary shit
22:46:40 <dP> are there any examples or tutorials for doing va2 stuff in nfo?
22:47:05 <frosch123> TrueBrain: maybe you wrote that code, and copilot can erase your memory of that?
22:47:16 <glx> "With bit 31 set, this sprite will refer to a TTD sprite, not the action 1 sprite. For the first ground sprite the reverse meaning applies. " <-- that's the non advanced station sprite layout (and I discarded it totally in nml)
22:47:30 <TrueBrain> still a bit annoying that set_ids are mostly u16, but not in their definition .. makes for difficult code :P
22:48:16 <TrueBrain> &(s.set_id as u16).to_le_bytes(),
22:48:19 <TrueBrain> you get all that kind of stuff
22:53:21 <frosch123> it's always weird when mainstream media writes about IT details... there is a major incident, it's about something log4j, we do not now either what it means
22:54:22 <glx> "major incident" <-- that looks scary
22:55:52 <frosch123> i guess my main issue with it is: they write BS about stuff i know about, do i have to extrapolate from that onto other things they write, but where i may not detect BS :)
22:55:52 <glx> it's just a case of someone forgetting the "do not trust external data"
22:56:37 <glx> applied to a widely used lib
22:57:00 *** Wolf01 has quit IRC (Quit: Once again the world is quick to bury me.)
22:57:19 <TrueBrain> the more surprising thing .. why did it take so long to discover? :P
22:57:21 <frosch123> at my old job, there was a division using java and log4j, and a division using c++
22:58:07 <frosch123> at some point the c++ people wanted to pick a new logging framework, and it was considered a good idea to have the same logging output format as the java people
22:58:28 <frosch123> there were 3 ports of log4j to c or c++, they all evulated to completely-broken and leaking-like-hell
23:02:31 <TrueBrain> VarAction2::IndustryTiles { set_id: layouts + 0xf0, variable: 0x43, shift: 0, mask: 0xffff, switch: &switch, default: failed_set }.write(output);
23:02:32 <TrueBrain> okay, that is not too bad
23:02:40 <TrueBrain> now I just need to make the 0x43 better :)
23:03:08 <TrueBrain> are variables only used by action2? Or also by other actions?
23:03:43 <TrueBrain> no clue what they do, but sure!
23:03:47 <frosch123> also inside action2 itself
23:04:00 <glx> 6 rewrites following action
23:04:14 <glx> you don't want to use it unless forced :)
23:04:19 <TrueBrain> mostly wanted to know if I could put it in varaction2.rs or not :D
23:04:37 <frosch123> in general, variables 00-3F are global variables unrelated to your industry instance, and also available for 679D
23:04:58 <frosch123> 40+ is instance specific, so not available for 679D
23:05:03 <TrueBrain> but they have other numbers in those ?
23:05:10 <frosch123> 7x is a lot of magic
23:05:27 <frosch123> TrueBrain: bit 7 is swapped :)
23:05:44 <TrueBrain> okay, that is not a problem
23:06:17 <TrueBrain> Iron_Oil_Coal_Steel_Iron_Oil_Coal_Steel_Iron_Oil = 33
23:06:21 <TrueBrain> CoPilot sometimes is funny
23:06:29 <glx> var1A is a very useful one
23:07:50 <frosch123> TrueBrain: do it like nml :) separate the feature/instance-independent variables 00-3F from the others
23:08:18 <frosch123> VarAction2::IndustryTiles::tile_offset makes sense, VarAction2::IndustryTiles::current_date does not
23:11:28 <frosch123> anyhow, i meant to say: the variable ids can also appear in other places, specificall vehicle variable 61 and variable 7B
23:12:00 <frosch123> so, when you add support for 60+x variables, the 60+x parameter also has to accept variable ids :)
23:13:14 <frosch123> otoh, maybe both 61 and 7B are too advanced for the truegrf purpose
23:15:38 <TrueBrain> one thing at the time :P
23:15:44 <TrueBrain> I now want to auto-detect "related" or "self"
23:16:01 <frosch123> sounds impossible for vehicles
23:16:36 <TrueBrain> Variable::FirstVehicle vs Variable::Vehicle
23:16:41 <TrueBrain> and FirstVehicle is Vehicle
23:16:47 <TrueBrain> but the name allows me to match it :)
23:17:26 <frosch123> oh, another nml thing. you may want to wrap (variable-id, shift, mask) into a tuple
23:17:46 <frosch123> many variables contain multiple things, which are better addresses as separate variables
23:20:11 <TrueBrain> "same" won't work, due to conventions ... LAYOUT_NUM vs layout_num :P
23:20:42 <frosch123> we will survive differences in casing :)
23:23:55 <TrueBrain> sometimes I do not really understand Rust yet ... not even a bit :P
23:27:48 <TrueBrain> layout_switch.push(VarAction2Switch { result: layout_id as u16 + 0xf0, left: layout_id as u32 + 1, right: layout_id as u32 + 1 });
23:28:03 <TrueBrain> mixing u8/u16/u32 in 2 lines (you don't see the second line :P)
23:28:31 <TrueBrain> okay ... code works :D I am a bit surprised :P
23:28:36 <TrueBrain> not as ugly as I expected
23:37:28 *** sla_ro|master has quit IRC ()
23:39:57 *** nielsm has quit IRC (Ping timeout: 480 seconds)
23:42:12 <TrueBrain> VarAction2::IndustryTiles { set_id: 0xfe, variable: Variables::Industry::LayoutNum.into(), switch: &layout_switch, default: failed_set }.write(output);
23:42:15 <TrueBrain> should make frosch123 happy :P
23:42:26 <TrueBrain> (removed shift and mask, now part of variable)
23:43:05 <frosch123> good that you mention that, i would not have deduced that myself :)
23:44:49 <TrueBrain> Industry::LayoutNum => Self { variable: 0x44, shift: 0, mask: 0xff },
23:45:22 <TrueBrain> I really need to learn how Rust macros work .. need to copy/paste too much :D
23:47:38 *** frosch123 has quit IRC (Quit: be yourself, except: if you have the opportunity to be a unicorn, then be a unicorn)
23:48:36 <TrueBrain> yeah, codespace also shut down .. guess I should find my bed too :P
continue to next day ⏵
