IRC logs for #openttd on OFTC at 2023-07-24
⏴ go to previous day
00:02:13 <pickpacket> anyways. Cargo loading speed for the default vehicles. Anyone knows where in the code I can find it?
00:03:08 <Eddi|zuHause> probably src/table/something, but i wouldn't mess with that, sounds like a newgrf thing
00:08:54 <pickpacket> I don't want to mess with it :D just use it for reference
00:11:36 <Eddi|zuHause> pickpacket: in the grf specs there's a table with all the default vehicle stats
00:12:01 <Eddi|zuHause> that's probably more reader friendly than the code
00:13:13 <FLHerne> it doesn't include loading speed
00:13:20 <FLHerne> but nor does src/table/engines.h
00:13:40 <FLHerne> so I assume all the default vehicles share one value hardcoded somewhere
00:18:01 <pickpacket> Eddi|zuHause: thanks! I don't know how I missed that
00:18:30 <pickpacket> also found the EngineInfo struct in src/table/engines.h
00:18:49 <pickpacket> Appears to have all the info for vehicles *except* loading speed 😂
00:21:23 <pickpacket> hmm. Have yet to find defaults for carriages in the NewGRF wiki...
00:24:04 *** esselfe has quit IRC (Ping timeout: 480 seconds)
00:25:38 *** bryjen has quit IRC (Quit: Leaving)
01:22:57 *** Wormnest has quit IRC (Quit: Leaving)
01:52:49 <Eddi|zuHause> and the NFO version?
02:21:55 *** debdog has quit IRC (Ping timeout: 480 seconds)
02:22:07 *** D-HUND is now known as debdog
05:59:14 <pickpacket> Eddi|zuHause: where do I find that?
06:00:55 <pickpacket> FLHerne: I don’t think they share one value. I think the maglev carriages load faster, for example. But either way the code needs to store loading speed info somewhere or NewGRF vehicles couldn’t have their own
06:46:38 <pickpacket> I think I might have found it
07:31:59 <pickpacket> I feel like I'm going in circles in the code right now, but engines have a load_amount which is how much they can load in a tick. It's a byte value
07:34:19 <andythenorth> pickpacket: everything is an engine
07:34:31 <andythenorth> wagons are just engines with power 0, in most circs
07:37:09 <pickpacket> I can't find where the load_amount is ever set, just that economy.cpp uses it
07:38:28 <peter1138> The default is set in tables/engines.h
07:39:11 <pickpacket> peter1138: really? Because load_amount isn't even mentioned there
07:40:03 <peter1138> ``` * @note the 5 between b and f is the load amount```
07:44:09 <pickpacket> peter1138: thanks! I'd even seen that but somehow still overlooked it XD
07:44:33 <pickpacket> I assumed that maglev carriages loaded faster than ordinary carriages. Apparently I was mistaken
07:48:28 *** keikoz has quit IRC (Ping timeout: 480 seconds)
07:50:27 <pickpacket> by request from players I'm going to increase the loading speed for my tea carriages and I wanted to find out what the maglev carriages value was for reference :)
07:53:05 <peter1138> Well, I was ravenous so had breakfast cereal already for a change... and I'm still hungry 😦
08:30:07 <pickpacket> yeah, it's not very filling
09:31:12 <pickpacket> hmm. I want to create two kinds of carriages in the same newgrf. One type runs on RAIL, ELRL, the other on MONO, MGLV. How do I do that? If I declare a railtypetable with all four then both kinds will run on all four
10:06:33 <FLHerne> pickpacket: that's not correct - the railtypetable just has to list all railtypes referenced by your grf; vehicles use track_type
10:06:53 <FLHerne> I'm not sure why nml can
10:07:23 <peter1138> Railtype compatibility is defined by the rail type.
10:07:49 <peter1138> Regular RAIL can run on ELRL by default, but MONO cannot run on MGLV.
10:08:04 <peter1138> So you'll need to define separate wagons for RAIL, MONO and MGLV .
10:08:18 <FLHerne> *why nml can't generate the contents of `railtypetable` automatically, at least in simple cases
10:08:56 <Eddi|zuHause> FLHerne: why would it want to? people rarely do simple cases
10:09:13 <FLHerne> or even more complex ones, the 'fallback' thing of railtypetable could be inlined into the track_type value
10:09:36 <FLHerne> Eddi|zuHause: to keep the simple case simple?
10:10:19 <Eddi|zuHause> FLHerne: but that would suggest the vehicle could define the fallback, instead of the railtype
10:12:20 <FLHerne> I see new users try to make a 'simple' grf, and see tons of "code" that's mostly boilerplate - there's no reason a grf that only uses existing railtypes should need a table that simply lists every railtype it references
10:12:30 <FLHerne> less sure about the fallback case
10:13:12 <pickpacket> ugh. I need two identical blocks for the MGLV and MONO versions then?
10:13:19 <FLHerne> it would implicitly create a railtype for each unique set of fallbacks
10:14:43 <FLHerne> which honestly is what people do anyway when they want vehicles with a given fallback behaviour?
10:15:00 <locosage> nml can generate pretty complex railtype tables with fallbacks and stuff
10:16:30 <Eddi|zuHause> FLHerne: i guess it could do that, but it would first have to run a semantic analysis over the whole file, and then fill out the table
10:16:54 <Eddi|zuHause> i don't think it needs to do that for any other feature so far
10:17:23 <Eddi|zuHause> and you need some trigger whether it needs to do that at all
10:17:42 <Eddi|zuHause> because you won't need to run that analysis on an industry set
10:17:46 <FLHerne> but it's not the only case where NML could be a much smarter compiler
10:18:31 <FLHerne> I don't think it would be hugely complex, there's a relatively limited set of places that can use railtypes
10:19:18 <Eddi|zuHause> but would it really be that much simpler to be worth the effort?
10:20:10 <Eddi|zuHause> i mean, you could put some example railtype tables in the wiki and say "hey, just copy-paste this into your 'simple' grf"
10:21:17 <Eddi|zuHause> once your grf gets larger and you have to copy-paste the same fallback rules over and over, you better had a real table anyway, in case you want to change the fallbacks
10:25:23 <Eddi|zuHause> so by making this seemingly "difficult" step optional, you've put a stepping stone in the development process that will reveal its ugly head much later, where it would be more difficult to fix
10:34:06 <FLHerne> I can see the argument
12:03:09 <andythenorth> it's extra confusing because nml (with good intentions) inserts the fallback labels
12:03:21 <andythenorth> which creates a misleading understanding about how railtypes work
12:04:38 <andythenorth> "RT_SHINY_RAIL: [SHNY, RAIL]"
12:04:47 <andythenorth> that's not a feature of the railtypes spec
12:06:33 <andythenorth> nml uses action 6 or 7 or 9 (don't know which, I didnt wade through the nfo) to conditionally support different railtypes being available in the game
12:06:55 <andythenorth> this is for the railtype table in a vehicle grf
12:07:02 <andythenorth> this is confused with railtype compatibility, which is defined by the railtype grf, not the vehicle grf
12:31:28 <Eddi|zuHause> i think railtype table is mostly action6
12:32:18 <Eddi|zuHause> so you start with an empty dummy table of the right size, and action6 all the values in
12:33:21 <Eddi|zuHause> "if railtype WXYZ exists, put value WXYZ at position A"
12:38:58 <_glx_> tables are only for translation
12:39:58 <_glx_> it's an action 0 feature 8, so yeah most likely it uses action 6 for "RT_SHINY_RAIL: [SHNY, RAIL]"
13:19:58 <andythenorth> it's very clever, and of use to vehicle grfs
13:20:14 <andythenorth> but it's also confusing for authors to understand proper domain for compatibility 🙂
14:51:41 <pickpacket> I did *not* understand that. Especially not how to use it to make a train carriage work on both mono and maglev
14:54:56 <pickpacket> Then I’ll just make two identical carriages with different railtypes
15:03:24 *** gelignite has joined #openttd
15:36:26 *** esselfe has joined #openttd
16:20:40 *** HerzogDeXtEr has joined #openttd
17:30:14 *** Wormnest has joined #openttd
17:49:41 <andythenorth> you can do it, but it may have edge cases
17:49:59 <andythenorth> you can create a hidden railtype that provides compatibility to both mono and maglev
17:54:20 <brickblock19280> you can but that has loads of issues
17:58:28 <andythenorth> probably ok for wagons
18:21:21 <peter1138> Loads of issues like conflicting with railtype grfs.
18:21:50 <peter1138> Seeing as engine IDs are near unlimited...
18:40:23 <DorpsGek> - Update: Translations from eints (by translators)
18:53:58 *** nnyby has quit IRC (Remote host closed the connection)
20:05:26 *** Born_Acorn has joined #openttd
20:10:32 *** Born_Acorn has quit IRC (Quit: Page closed)
20:10:53 *** Born_Acorn has joined #openttd
20:30:54 *** Soni has quit IRC (Ping timeout: 480 seconds)
21:11:48 *** HerzogDeXtEr has quit IRC (Read error: Connection reset by peer)
21:31:01 *** Born_Acorn has quit IRC (Remote host closed the connection)
22:14:10 *** Wolf01 has quit IRC (Quit: Once again the world is quick to bury me.)
22:21:06 *** nielsm has quit IRC (Ping timeout: 480 seconds)
22:30:46 *** Flygon has quit IRC (Read error: Connection reset by peer)
22:56:59 *** gelignite has quit IRC (Quit: Stay safe!)
23:43:15 *** Smedles has joined #openttd
continue to next day ⏵