IRC logs for #openttd on OFTC at 2023-04-17
⏴ go to previous day
00:15:54 <petern> `buff += seprintf(buff, last, "%s", decimal_separator);` that... was special 🙂
00:34:46 *** Soni has quit IRC (Ping timeout: 480 seconds)
01:28:39 *** argoneus has quit IRC (Quit: Ping timeout (120 seconds))
01:28:46 *** argoneus has joined #openttd
02:13:17 *** Wormnest has quit IRC (Quit: Leaving)
02:48:51 *** debdog has quit IRC (Ping timeout: 480 seconds)
04:30:04 *** Flygon has quit IRC (Quit: A toaster's basically a soldering iron designed to toast bread)
06:32:27 <petern> Just Eat emailing me to tell me to order breakfast. They don't know me.
06:44:59 <andythenorth> hmm breakfast though
06:45:13 <andythenorth> the idea of ordering breakfast is deeply unappealing
06:45:37 <andythenorth> there is a orange in my fridge, which is more convenient
06:46:57 *** JustANortherner has joined #openttd
06:46:57 <JustANortherner> Only time to order breakfast is when you're hungover and have a craving for Maccies
06:46:59 <pickpacket> I had nutella sandwiches and a pot of tea for breakfast
06:47:37 <JustANortherner> My breakfast was a lovely Vanilla Crown with a pot of Tea, and a Glass of OJ. Got some ginger biscuits for the rest of the day tol
06:48:03 <andythenorth> ginger is good for you
06:49:26 <JustANortherner> I do like a good Ginger
06:51:08 <andythenorth> petern: it's not just you 😛
06:56:40 <petern> Will they let me order salad... for midday?
06:56:55 <petern> Actually of course they will. I'm not going to.
07:07:34 <petern> Hmm, PSAs for vehicles.
07:08:09 <petern> They're only allocated if used, so it adds a pointer, but not 1024 bytes.
07:08:13 *** WormnestAndroid has quit IRC (Ping timeout: 480 seconds)
07:09:47 *** WormnestAndroid has joined #openttd
07:13:07 <petern> Is there a system to say when persistent storage can be written?
07:16:00 <andythenorth> not aware of one for industries / towns
07:16:16 <andythenorth> store is available in most callbacks afaik
07:16:46 <petern> Hmm, okay, what stops everyone desyncing, just NewGRF authors?
07:17:33 <andythenorth> worrying thought 😛
07:18:00 <petern> Maybe for the existing features there are no graphical resolves.
07:18:05 <andythenorth> store is operator 0x0E, wonder if I can find that
07:18:56 <andythenorth> what's `GRFInhibit`?
07:19:33 <petern> Disabling another NewGRF, like a good citizen...
07:19:38 <JGR> See PersistentStorageMode
07:19:55 <JGR> Stores are only enabled in some contexts
07:21:13 <petern> Ah that's interesting.
07:22:07 <andythenorth> I wonder which is nicer: allowing grf authors to have arbitrary vehicle storage, or having a 'freeze graphics' callback 😛
07:22:52 <andythenorth> I am already planning how I can read/write adjacent vehicle storage using cb 36 and var 0x61
07:23:04 <andythenorth> "what could go wrong?"
07:24:08 <petern> So it seems to actually write to storage, and then it gets automatically undoes them.
07:24:34 <petern> So you could accidentally do it but it's pretty inefficient.
07:28:15 <andythenorth> we can't just run the vehicle graphics chain infrequently?
07:28:24 <andythenorth> I guess animated steam engine wheels says 'no'
07:28:51 <petern> I think something was changed so that is the case.
07:35:15 <petern> Well, I have a (pushed) branch that maybe implements persistent storage for vehicles. But I can't test it, and I'm not going to PR/Draft it at this stage.
07:36:11 <LordAro> oh yeah, i booked my bike in for a service today
07:37:27 <petern> Hmm, looks like storage was originally 16 entries, then extended to 256 entires.
07:37:46 <petern> "16 isn't enough, let's bloat it massively..."
07:38:03 <andythenorth> FIRS uses lots 😄
07:43:26 <JGR> 16 ought to be enough for vehicles
07:43:55 <LordAro> Bill "JGR" Gates right here
07:44:31 <Brickblock1> what if I want on per vehicle? or is that 16 per vehicle?
07:47:17 <petern> Yes, but it's not variable, it's the same for all features.
07:49:35 <LordAro> glx[d]: can you do your usual dmp decoding magic with #10564 ?
07:53:12 <Eddi|zuHause> goes it throw out limitation?
07:55:08 <petern> I have 64GB RAM so why would I care...
07:55:21 <petern> I think it's work o'clock 😦
07:57:23 <Eddi|zuHause> wasn't there like a madonna song about 4 minutes? :p
08:19:00 *** D-HUND is now known as debdog
08:21:50 <JustANortherner> petern: Annual Leave this week.... just to make you jealous 😉
08:29:43 <petern> Good job I can't ban people here 🙂
08:32:42 <TrueBrain> Those permissions can be arranged petern 😛
08:33:17 <TrueBrain> right, what was I doing .... did the timer thingy ... changed those pesky ai-start-date and autosave timers ..
08:33:28 <TrueBrain> guess that was all Tyler asked
08:33:29 <andythenorth> management actions?
08:34:30 <petern> Damn, I had 4 PRs merged yesterday, so much for pull requests being a bad concept...
08:34:49 <andythenorth> I can't keep up 🙂
08:34:52 <andythenorth> with all the shipping
08:34:58 <andythenorth> do we need to release again soon? 😛
08:35:30 <petern> Only one of those was a visible change, so...
08:40:38 <petern> InitializeWindowsAndCaches() is a mess of a function... maybe it should be an event 😉
08:41:06 <TrueBrain> it really is a messy function, yes; especially how often/when it is being called
08:41:09 <TrueBrain> sometimes feels random
08:41:39 <petern> But it updates game state, not just windows...
08:41:48 <TrueBrain> wauw, can't read .. was reading InvalidateWindow
08:42:10 <TrueBrain> I also have the suspicion people sometimes do Invalidate where they mean SetDirty and the other way around 😛
08:42:18 <petern> Your focus on window events is probably a better place to start 🙂
08:43:05 <petern> andythenorth: fancy testing 10670 to see if it can improve performance by avoiding long chains for sprite resolution...?
08:43:30 <petern> I suspect it's not exactly simple to restructure chains.
08:44:21 <petern> Okay, my database-level resource/authorization filter is going to need some work 😦
08:46:27 <andythenorth> petern: yes, but it's not a quick job 😛
08:46:48 <andythenorth> perhapas we need Wentbourne Horse 😛
08:48:00 <petern> Yeah, I also don't know if it's feasible, the memory usage is quite high.
08:48:22 <petern> Well, one pointer added on regardless of whether persistent storage is used.
08:48:39 <JGR> Might be worth changing the persistent storage structure to be dynamically sized, perhaps?
08:50:17 <andythenorth> 256 storages, but only in the consist (lead engine)
08:50:27 <andythenorth> max train length is 255?
09:01:47 <Eddi|zuHause> why do we have a max train length? :p
09:03:00 <petern> Why only in the lead engine?
09:03:11 <petern> Don't wagons have graphical choices to make?
09:03:45 <petern> Bah, just use variants for everything no need for complex chains anyway.
09:04:10 <Eddi|zuHause> putting everything in the front engine kills every remnant of mixing vehicle grfs
09:04:47 <petern> Some would say that's a good thing.
09:05:01 <Eddi|zuHause> i probably had a use case for vehicle storage
09:05:07 <Eddi|zuHause> but i forgot everything
09:08:21 <Eddi|zuHause> "just put it in the front engine" puts you back into the days of "vehicle override", which is a very flawed concept
09:14:19 <andythenorth> think of the RAM saving 😛
09:15:39 <Eddi|zuHause> try saying that when games like Cities:Skylines need like 32GB :p
09:17:19 <petern> Making PersistentStorage could help, but then you end up with more separate memory allocations.
09:17:26 <andythenorth> petern: my idea was we could var 0x61 into the lead engine 😛
09:17:35 <andythenorth> "not a complex chain"
09:18:01 <petern> I don't know what that even means
09:18:02 <andythenorth> or the lead engine could have a callback, taking the calling vehicle as extra callback infor 😛
09:18:14 <andythenorth> I think I should go and do my grownup meeting
09:18:26 <Eddi|zuHause> you don't need var 0x61 for accessing the lead engine. you need that for anything OTHER than the lead or current vehicle
09:19:00 <Eddi|zuHause> for accessing the lead engine you have PARENT
09:19:42 <dP> wonder how feasible would it be to add something like consist feature (possibly fake)
09:19:46 <petern> Hmm, towns can have multiple persistent storage too. Nice.
09:19:55 <petern> (Different for each NewGRF that accesses it)
09:19:58 <andythenorth> towns have so much potential
09:20:08 <andythenorth> but there are minimal useful callbacks that can use it 🙂
09:20:18 <andythenorth> can do electricity though
09:21:05 <dP> dP: to avoid dumping all consist-related stuff on the lead engine
09:22:14 *** MarkoMarko has quit IRC (Quit: User went offline on Discord a while ago)
09:28:04 <petern> Nobody except andy was going to do that.
09:31:01 <dP> I don't know any use case for storage on individual vehicles
09:31:21 <petern> JGR, Hmm, because PersistentStorage is stored in a pool, each pool entry is 256 * uint32 + a bit of extra metadata. That's fine, but if it was dynamic the big chunk of data would then be moved out of the pool, spread whereever.
09:32:09 <dP> complex calculations that need to be cached only appear when iterating consists are involved
09:33:04 <dP> for PersistentStorage size maybe add a callback for newgrf to allocate it? if it's not defined allocate 256
09:33:40 <JGR> The pool items are already spread wherever
09:34:31 <JGR> You could make the pool items themselves variable size by making the data the last struct item if you really wanted, possibly not worth the bother though
09:35:57 <petern> dP: That isn't necessary and overcomplicates it, we can automatically determine how big it needs to be based on usage.
09:36:35 <dP> dynamic allocation is a bit wasteful on cpu and memory
09:36:56 <petern> Hmm, so pools are just arrays of arrays of pointers, not arrays of arrays. My memory is deceiving me, but that would explain why vehicles work :p
09:36:58 <dP> if newgrf defines it right there won't be any reallocation
09:37:24 <petern> You only need to dynamically allocate on first write, after that it will most likely already be allocated.
09:38:01 <petern> And we already do allocate on first write, just it allocated the fixed size.
09:38:10 <dP> on first write you don't know how many items you need
09:38:18 <dP> it can write to 1 then to 2, ... 256
09:38:28 <petern> Then it will reallocate 3 times.
09:38:39 <petern> After that, it's already allocated and won't need to be reallocated.
09:38:46 <dP> I mean write to every register from 1 to 256 in order
09:38:58 <dP> that's 256 allocations if you allocate to the exact size
09:39:08 <dP> and if you don't that's some memory wasted
09:39:30 <JGR> NewGRFs almost never use dynamic addressing for persistent storage, so you could work it out by ahead of time without adding the GRF
09:39:51 <petern> "I can't think of a use case" vs "let's make up a use case that uses every possible slot"
09:40:46 <dP> if we're talking about persistent storage in general there are some usecases in industries
09:41:09 <dP> idk in what order firs writes them but it's not unrealistic to assume 1->n
09:41:26 <dP> for vehicles, yes, I don't know usecases for more than a few bytes of storage
09:41:50 <Eddi|zuHause> we're still talking about 255 reallocations over an entire game session, right?
09:42:16 <Eddi|zuHause> (probably during loading)
09:42:56 <petern> Loading would have to change to store the number of entries, so would not involve reallocations.
09:43:03 <dP> somewhere in the initial phase of the game I'd guess, at least for industries
09:43:40 <petern> Well, how much space does a std::vector reserve behind the scenes if you don't tell it to.
09:43:59 <dP> it's smth-smth golden ratio iirc
09:44:00 <petern> (Implementation specific, of course)
09:44:47 <Eddi|zuHause> dunno, my intuition is that slowdowns during loading isn't particularly noticeable by the average user
09:46:37 <petern> Yeah, save/loading would be changed by necessary of making it dynamic, so any problem there is fixed due to that change, not fixed because it's slow otherwise.
09:46:44 <dP> though in std::vector case golden ratio seems to be 1.5 xD
09:48:04 <petern> Mind you you can't use push_back/emplace_back in this case, an explicit resize() is likely to allocate only what you tell it.
09:49:00 <petern> Or make it not dynamic, just limit vehicles to only 16 slots instead of 256 slots 😄
09:49:23 <andythenorth> think of the poor grf authors
09:49:24 <petern> "Oh but I need more than 16"
09:49:28 <andythenorth> are the storages dwords?
09:50:00 <andythenorth> yeah, so we can just use masks for bytes and nibbles
09:50:07 <andythenorth> "loads of storage"
09:50:39 <JGR> Actually doing this in NML is mega tedious though, so probably most won't do that
09:50:59 <andythenorth> having made one of the bigger more complicated train sets
09:51:10 <andythenorth> not the biggest, or most complicated, but in the upper end
09:51:31 <andythenorth> I only found a few use cases for storage
09:52:19 <andythenorth> 1. "game is slow", running a lot of varact2 to calculate graphics. this is conjecture, though, don't have any performance charts
09:52:54 <andythenorth> 2. stuff that walks the consist looking for other vehicles with BAD FEATURES. Which could possibly be done with prop 25, but prop 25 is just weird
09:53:26 <andythenorth> I mean....I'm sure we'll find ways to abuse it 😛
09:53:47 <andythenorth> "this engine was built in 1965 in the depot at grid co-ordinate (99, 465)"
09:53:55 <JGR> On 1, vehicles which are off screen don't need to be drawn, so it's not such a critical problem
09:53:58 <andythenorth> "this engine has had 14 different consist changes"
09:54:10 <andythenorth> "you tried to attach disallowed wagons 7 times"
09:54:23 <dP> andythenorth: hmm... prevent selling it on the other end of the map? xD
09:54:24 <andythenorth> all of which can now be shown via the name callback in vehicle details window 😛
09:55:04 <andythenorth> I think George had some cases for it though
09:56:47 <petern> I guess if you have complex chains for things that could change on a new tile...
09:56:59 <andythenorth> oh we could do fuel?
09:57:05 <andythenorth> "this engine ran out of diesel"?
09:57:15 <JGR> This must be done carefully to avoid desync issues
09:57:18 <andythenorth> arbitrary "breakdowns" by nerfing speed
09:57:50 * andythenorth trying to think if a train robbery can be simulated
10:00:30 <petern> Yeah, that's why I asked about desyncing earlier.
10:01:25 <petern> As long as all those callbacks are in the same order on each client then it should be fine.
10:02:03 <dP> desyncing is kinda simple, just don't let gui callbacks write storage
10:02:12 <JGR> The issue is that the the callbacks are run at load, I.e. when joining the server
10:02:13 <dP> not sure that's feasible with current callbacks though xD
10:02:21 <andythenorth> hmm could store how many load / unload, and weather the vehicle
10:02:47 <andythenorth> could store the last transported cargo type, and show appropriate sprites for '99% empty'
10:03:29 <andythenorth> could store the names of the driver and fireman
10:03:36 <andythenorth> and pass them to the 'have died' news message
10:03:43 <JGR> If the GRF is careless, the vehicle will end up with different cached values on a new client as it has on the server and other clients
10:03:45 <andythenorth> 'George and Sam were sadly lost'
10:04:04 <andythenorth> 'Bob and Pedro perished in the line of duty'
10:04:23 <petern> If you limited it to the wagon attach callback, that is only called in the depot and not on load. Right?
10:04:27 <dP> JGR: can't stuff like this just be cached in the save?
10:04:48 <JGR> dP: Yes, that is what I am doing, but this does not exist in vanilla
10:05:24 <dP> sounds worth upstreaming ;)
10:06:45 <dP> does that include basecosts btw?
10:07:25 <JGR> petern: The wagon attach callback is a one-off decision
10:07:37 <Eddi|zuHause> petern: there's also a 32 tick callback that might be worth using storage with
10:07:46 <JGR> Either the wagon gets attached or it doesn't, there isn't any extra cache
10:08:11 <petern> JGR yea, perhaps not that specific callback, but something that does an update for the whole consist at that time.
10:08:30 <petern> I mention that because that was the use-case that George mentioned.
10:09:20 <Eddi|zuHause> there was a problem with the attach-callback in that it's only called for the front engine, not for the attached wagon
10:09:46 <JGR> dP: I've yet to find a NewGRF which somehow breaks basecosts in multiplayer
10:10:23 <Eddi|zuHause> (which is how invisible engine can circumvent the restrictions from the attach callback)
10:10:26 <JGR> Yes, but in not going to try to prevent every possible deliberate sabotage
10:11:30 <petern> I'm not sure what the deal is with basecost desync... is it something like setting different bases on load based on e.g. date?
10:12:13 <dP> I mostly just want to change them without newgrf 😆
10:12:24 <JGR> Date is deliberately set to 0 during GRF load to prevent that type of nonsense
10:12:26 <dP> but yeah, I think it's possible to desync them with action6 or smth
10:13:01 <petern> Set to 0 in MP-only or always?
10:13:25 <petern> I guess there's a load of other variables that could differ 😄
10:14:01 <JGR> Seems that it's only in multiplayer
10:14:32 <petern> Imagine breaking the roads in TTRS3 (iirc that was the one)
11:12:18 *** WormnestAndroid has quit IRC (Remote host closed the connection)
11:12:24 *** WormnestAndroid has joined #openttd
11:22:06 <andythenorth> I think that it might be lunch
11:22:19 <GeorgeVB> Looks like I've found some sort of a bug in handling bitmask_vehicle_info
11:22:19 <GeorgeVB> switch (FEAT_TRAINS, SELF, namefull,
11:22:19 <GeorgeVB> prev_vehicle_type_id() != vehid])
11:22:21 <GeorgeVB> { 1: return bitmask(FLAG_WRONG_CONSIST);
11:22:23 <GeorgeVB> The similar code for graphics
11:22:25 <GeorgeVB> switch (FEAT_TRAINS, SELF, name_sprites_start_after,
11:22:27 <GeorgeVB> prev_vehicle_type_id() != vehid])
11:22:27 <GeorgeVB> { 1: name_sprites_start_mark;
11:22:29 <GeorgeVB> name_sprites_start; }
11:22:31 <GeorgeVB> Is this information is enough or some more information is required?
11:27:28 <petern> Where does bitmask_vehicle_info fit in that?
11:29:30 <GeorgeVB> bitmask_vehicle_info callback
11:30:35 <Brickblock1> You can't use var 61 with property based callbacks
11:32:03 <GeorgeVB> I have to build a workaround with count_veh_id var 😦
11:36:05 <petern> Oh the get property callback.
11:38:02 <petern> Yes, it's disallowed to prevent circular dependencies, where the order of callback execution changes things.
11:38:29 <andythenorth> oh context is cb36?
11:38:29 <petern> (Or just re-running it gives different results)
11:38:46 <petern> Yeah, it's callback 36, the "bitmask_vehicle_info CB" threw me.
11:44:09 <petern> Hmm, how many different result values are required for precomputing complex chains?
11:44:29 <petern> Would a single non-PersistentStorage int32 be enough?
11:46:03 <dP> we did discuss adding one or two ints at some point
11:46:11 <dP> but dynamic storage would be better imo
11:47:09 <dP> it's more flexible and benefits all objects that uses storage not just vehicles
11:51:21 <andythenorth> we discussed making prop 25 readable also 😛
11:51:32 <andythenorth> afaict, it's settable, but not readable
11:51:49 <andythenorth> unless there's some var access to it I forgot
11:52:17 <petern> It's not persistently settable.
11:52:59 <petern> And it's also only a byte, which may be enough but that's less than 1KB.
11:53:58 <andythenorth> petern: using action1 realsprites as a proxy for return values, Horse uses 91 for an open wagon
11:54:11 <petern> With an int32, you could simulate the normal persistentstorage, except avoid the allocation overheads
11:54:12 <andythenorth> load states, cargos etc
11:54:51 <petern> But load state isn't something you need to precalculate.
11:55:25 <petern> Nor is cargo, that's determined by the chain you're in. (though probably you don't use that original feature...)
11:56:25 <petern> The complex stuff is "what are these other vehicles in the chain"
11:57:40 <andythenorth> that's the mad recursive stuff yes
12:00:33 <GeorgeVB> And it would be so cool to calculate it in some cheap CB like can_attach_wagon and reuse later
12:02:15 <GeorgeVB> xUSSR set uses "what are these other vehicles in the chain" a lot, making fast-forward button unusable in 500+ trains 😦
12:04:50 <petern> it would need to run for each vehicle in the chain, otherwise you could only the storage for the wagon that's being attached (or possibly the head as parent scope)
12:05:14 <petern> So would need to be in addition to the can_attach_wagon callback
12:05:40 <petern> It's a callback that doesn't need to return anything which is odd? 😄
12:06:29 <GeorgeVB> GeorgeVB: I mean it is required to calculated it once then it is in depot and there is no need to recalculated it on map in xUSSR set case
12:07:05 <petern> Well also, maybe someone else has some use-case where updating it on map would be needed?
12:07:41 <petern> Hmm, that can maybe almost be narrowed down to during triggers.
12:08:49 <petern> Do vehicles even have triggers? I'm going made.
12:08:53 <petern> They trigger other things.
12:09:58 *** JohnFranklin has joined #openttd
12:09:58 <JohnFranklin> Hi George, are you planning to put xUSSR Buses on BaNaNaS? I just found your fantastic website
12:12:22 <GeorgeVB> As far As I remember, LV4 was on bananas.
12:13:19 <GeorgeVB> And v5 was never done, because I couldn't find a way to code them in appropriate way
12:13:36 <petern> It's still mind boggling that people have been going this long
12:14:18 <petern> I guess that predates all the extended engine IDs and things? Can't remember when that was done.
12:15:57 <GeorgeVB> petern: But you are not a newcomer too 🙄
12:16:42 <petern> No but I think you were making graphics for TTDPatch before I'd even heard of that and OpenTTD.
12:19:28 <GeorgeVB> Well, according to the site, first graphics uploading was on 13 April 2003
12:19:57 <GeorgeVB> 20 years and 4 days ago
12:27:29 <GeorgeVB> GeorgeVB: switch (FEAT_TRAINS, SELF, namefull,
12:27:29 <GeorgeVB> [ STORE_TEMP(count_veh_id(vehid), 3),
12:27:29 <GeorgeVB> STORE_TEMP(3, 0x10F),
12:27:29 <GeorgeVB> count_veh_id(vehid) - LOAD_TEMP(3) > 0])
12:27:29 <GeorgeVB> { 0: return bitmask(FLAG_WRONG_CONSIST);
12:27:31 <GeorgeVB> Does not work either.
12:28:03 <GeorgeVB> Any idea how to solve the problem?
12:29:09 <GeorgeVB> I want a vehicle to specify a FLAG in case it is sorrownded with wrong vehicles.
12:29:10 <Eddi|zuHause> i think LV4 was one of the reasons i started coding long wagons, which lead to CETS
12:35:49 <GeorgeVB> GeorgeVB: petern could you help me with this?
12:42:23 <GeorgeVB> When xUSSR set was a single set, I coded attaching limits with can_attach_wagon CB, but now, when the set is being split, I can't apply rules for diesels if the leading engine is a steamer. So I wanted to use bitmask_vehicle_info CB, by making a vehicle checking vehicles nearby and throwing a FLAG if it is wrong. Than the first vehicle in consist would check for the flag and disallow starting consist in case it presents.
12:44:05 <GeorgeVB> but I can't make it throwing a flag 😦
12:46:23 <Eddi|zuHause> FLAG as in prop25?
12:50:45 <GeorgeVB> FLAG is a bit in bitmask_consist_info
12:51:06 <Eddi|zuHause> i take that as a "yes", then
12:52:38 <Eddi|zuHause> [ STORE_TEMP(count_veh_id(vehid), 3), STORE_TEMP(3, 0x10F), count_veh_id(vehid) - LOAD_TEMP(3) > 0]) <-- that logic loks weird, your store count, then do something completely unrelated, count again, and think the count changed?
12:52:38 <GeorgeVB> My question is "How to get around this limitation" 😉
12:53:37 <GeorgeVB> I want to count for Current one and a one that is after
12:53:40 <petern> Not exactly, bitmask_consist_info is prop 25 of all vehicles in the chain ORed together. Hmm.
12:54:26 <petern> That is only available from var 42, which I don't see you referencing there.
12:55:04 <Eddi|zuHause> petern: i was assuming this is a callback to set prop25
12:56:34 <petern> Okay to the test for var 42 must be elsewhere?
12:56:53 <petern> Hmm, is "prop25" visible in the debug window? Not sure 😄
12:59:55 <petern> Back in the early days for varaction implementation I used to add debug output for every little step. But that's costly.
13:02:00 <petern> Var 42... so you've got "09" there.
13:02:36 <GeorgeVB> Yes, while I expect 1
13:02:57 <GeorgeVB> 8 is added, but not expected
13:03:16 <petern> Is "8" the in any of the default prop 25s?
13:04:02 <Eddi|zuHause> the 8 would be from another flag somewhere
13:04:09 <GeorgeVB> GeorgeVB: 8 is bit 3 (FLAG_WRONG_CONSIST)
13:05:20 <Eddi|zuHause> i'm still confused about what you're asking
13:07:02 <GeorgeVB> there are vehicles from 3 sets on the screen (steamers, diesels and wagons)
13:07:37 <GeorgeVB> When it was a single set, you were not allowed to put a steamer after a mid section
13:08:18 <GeorgeVB> But now it works only the first engine in consist is dieasel
13:09:09 <GeorgeVB> if the first one is a steamer, rules for can attach wagon CB from diesels set are not applied
13:09:19 <GeorgeVB> So I need a workaround.
13:10:13 <GeorgeVB> Diesel engine needs to tell a steamer in the head "I'm in illegal position, do not start"
13:10:44 <GeorgeVB> I expected to use bitmask_vehicle_info CB
13:10:48 <petern> Is it ever allowed to place a diesel engine after a steamer?
13:11:39 <petern> I'm not really sure why you'd want to stop it, other than "they never did this in real life" which is kinda silly.
13:11:43 <EmperorJake> AFAIK it's not possible because only the lead vehicle can determine what may be coupled after it. This exploit is how the invisible leading engine works.
13:11:47 <petern> But maybe there's some specific combos.
13:12:08 <GeorgeVB> It is definitely legal to place diesel with eclectic, and from OTTD POV it causes the same problem
13:12:19 <petern> What is the problem caused?
13:12:44 <petern> Step back a bit here 😄
13:13:46 <GeorgeVB> The problem: A wrong order of vehicles can leave the depot
13:15:18 <GeorgeVB> In the picture the A steamer can't be located between 3TE25K2M and 3TE25K2M_M (Middle section)
13:15:25 <JohnFranklin> GeorgeVB: LV4 includes xUSSR Buses?
13:16:01 <EmperorJake> Why not code it as an articulated vehicle instead? It would make the set more user friendly than the overly complex coupling restrictions that xUSSR set has
13:16:22 <GeorgeVB> JohnFranklin: If you mean the normal scale or 32bit set, than no, they are different sets of different artists.
13:17:19 <GeorgeVB> EmperorJake: Because they can be used without middle sections. The locos, that can't be decoupled, are coded as ARV
13:17:57 <EmperorJake> Why not code them as variants? Have a 2 section and 3 section variant
13:18:11 <petern> code the diesel locos as multi-head, then they get some extra restrictions.
13:18:32 <petern> e,g, I believe you can't place another loco in between
13:18:51 <andythenorth> you'd get wagons between them though 🙂
13:19:15 <petern> What's wrong with wagons though? Just because it doesn't look pretty, or it wasn't done IRL?
13:20:27 <GeorgeVB> andythenorth: No, you can reassemble the one already build.
13:20:27 <GeorgeVB> Yes, I understand, that xUSSR set can be coded much less realistic, but I'd like to code it as realistic as possible.
13:21:26 <petern> Realism can be annoying. There's things done with IC125s that you can't do in OpenTTD because "realism"
13:21:52 <Eddi|zuHause> so, we have 3 options here: 1) don't care, 2) use a different method (like variant consists) to ensure the engines don't get disconnected, or 3) fix the prop25 logic
13:23:10 <petern> You can also use the start/stop callback to prevent it from moving, even if it is still attached.
13:23:14 <Eddi|zuHause> in case of 3) we need more code than the snippet you gave us, because that doesn't make any sense
13:23:52 <petern> Yes, the problem with context is they're usually massive sets and difficult for anyone else to understand 🙂
13:24:06 <andythenorth> for the start/stop case, just need to recurse the consist setting 2 flags?
13:24:18 <andythenorth> flag 1 is 'previous vehicle was type X'
13:24:25 <andythenorth> flag 2 is 'current vehicles is type Y'
13:24:57 <GeorgeVB> petern: Because in case of, e.g. TE10 series there are 8 models that can be combined in various combinations
13:31:13 <Brickblock1> GeorgeVB: what does ` STORE_TEMP(3, 0x10F),` do?
13:31:36 <Brickblock1> doesn't seam to be referenced
13:31:53 <GeorgeVB> petern: Ok, commited current code to github. Lets have a look:
13:31:53 <GeorgeVB> lines 16 - 19 are callback code
13:31:53 <GeorgeVB> engine_penalise_speed2(_3te25k2m_m, _3te25k2m, 4)
13:31:53 <GeorgeVB> engine_has_before(_3te25k2m_m_bitmask_vehicle_info_advanced3, _3te25k2m, _3te25k2m_m_bitmask_vehicle_info)
13:31:55 <GeorgeVB> engine_has_after(_3te25k2m_m_bitmask_vehicle_info_advanced2, _3te25k2m, _3te25k2m_m_bitmask_vehicle_info_advanced3)
13:31:55 <GeorgeVB> engine_notlast(_3te25k2m_m_bitmask_vehicle_info_advanced, _3te25k2m_m_bitmask_vehicle_info_advanced2)
13:31:57 <GeorgeVB> Detailed code for functions
13:31:59 <GeorgeVB> The code should throw a flag in case nearby vehicle is wrong (_3te25k2m_m should be surrounded by _3te25k2m)
13:32:01 <GeorgeVB> return bitmask(FLAG_WRONG_CONSIST)
13:32:52 <Eddi|zuHause> and where are you reading the flag?
13:33:11 <GeorgeVB> Brickblock1: I've tried to calculate amount of _3te25k2m for current vehicles and for the second part of the next one
13:33:24 *** sla_ro|master has joined #openttd
13:34:17 <GeorgeVB> No, I can't check all the ids available, on the contrary I check only allowed ones
13:35:29 <GeorgeVB> GeorgeVB: As you can see for graphics, it works fine
13:37:04 <GeorgeVB> is_wrong_consist() is defined in
13:39:36 <GeorgeVB> Current situations - the FLAG is always thrown, regardless the vehicles nearby
13:40:17 <Brickblock1> could you share the raw nml?
13:40:46 <Eddi|zuHause> "set_offset_to(3)," <-- is this the new syntax vor var61?
13:41:01 <petern> Can you delete all those embeds please?
13:41:42 <Brickblock1> Eddi|zuHause: no that is not regular nml
13:41:59 <petern> Slightly frustrating that the Discord client doesn't let me do it 😄
13:42:25 <andythenorth> that's just a procedure call
13:42:34 <Eddi|zuHause> i mean, you're setting param 0x10F, but i'm not seeing var61 being explicitly referenced
13:43:00 <Brickblock1> petern: I can but it would do it for everyone, which might not be wanted
13:43:09 <Eddi|zuHause> and i'm not familiar with how nml does that nowadays
13:43:22 <Brickblock1> nml doesn't to var 61
13:43:40 <Brickblock1> but it can be used thru nfo ish code
13:44:02 <Eddi|zuHause> yes, with var[0x61, blah blubb]
13:44:09 <andythenorth> var 61 stuff tends to look like
13:44:09 <andythenorth> `[STORE_TEMP(-1, 0x10F), getbits(var[0x61, 8, 0x00FFFFFF, 0x5F], 2, 1)]`
13:44:19 <Brickblock1> xussr likely hiddes that
13:44:31 <Eddi|zuHause> exactly, but that seems to be missing here
13:44:35 <GeorgeVB> Brickblock1: Copied to the same folder
13:45:32 <GeorgeVB> Eddi|zuHause: it is STORE_TEMP(offset, 0x10F)
13:45:43 <Eddi|zuHause> that's only half of it
13:48:27 <GeorgeVB> switch (FEAT_TRAINS, SELF, _3te25k2m_m_speed, (hasbit(bitmask_consist_info, 0)) ? (vehicle_is_not_powered && (position_in_consist == 0)) ? 10 : 120 * (100 - speed_penalty_percent) / 100 : 120)
13:48:27 <GeorgeVB> switch (FEAT_TRAINS, SELF, _3te25k2m_m_bitmask_vehicle_info3, [ STORE_TEMP(LOAD_TEMP(0) - count_veh_id(_3te25k2m_m) - count_veh_id(_3te25k2m), 0), (LOAD_TEMP(1) && (position_in_consist == 2 * LOAD_TEMP(0)) && LOAD_TEMP(0) < 4)])
13:48:31 <GeorgeVB> switch (FEAT_TRAINS, PARENT, _3te25k2m_m_bitmask_vehicle_info2, [ STORE_TEMP(count_veh_id(_3te25k2m_m) + count_veh_id(_3te25k2m), 0), STORE_TEMP((vehicle_type_id == _3te25k2m_m) || (vehicle_type_id == _3te25k2m), 1) ])
13:48:31 <GeorgeVB> { _3te25k2m_m_bitmask_vehicle_info3; }
13:48:33 <GeorgeVB> switch (FEAT_TRAINS, SELF, _3te25k2m_m_bitmask_vehicle_info, (position_in_consist == 0) || (vehicle_is_not_powered) || (position_in_articulated_veh > 0))
13:48:35 <GeorgeVB> _3te25k2m_m_bitmask_vehicle_info2;
13:48:37 <GeorgeVB> switch (FEAT_TRAINS, SELF, _3te25k2m_m_bitmask_vehicle_info_advanced3, [ STORE_TEMP(count_veh_id(_3te25k2m), 3), STORE_TEMP(-2, 0x10F), (LOAD_TEMP(3) - count_veh_id(_3te25k2m)) > 0])
13:48:39 <GeorgeVB> 0: return bitmask(3);
13:48:41 <GeorgeVB> _3te25k2m_m_bitmask_vehicle_info;
13:48:43 <GeorgeVB> switch (FEAT_TRAINS, SELF, _3te25k2m_m_bitmask_vehicle_info_advanced2, [ STORE_TEMP(count_veh_id(_3te25k2m), 3), STORE_TEMP(3, 0x10F), (count_veh_id(_3te25k2m) - LOAD_TEMP(3)) > 0])
13:48:45 <GeorgeVB> 0: return bitmask(3);
13:48:45 <GeorgeVB> _3te25k2m_m_bitmask_vehicle_info_advanced3;
13:48:47 <GeorgeVB> switch (FEAT_TRAINS, SELF, _3te25k2m_m_bitmask_vehicle_info_advanced, position_in_consist_from_end == 1)
13:48:49 <GeorgeVB> 1: return bitmask(3);
13:48:51 <GeorgeVB> _3te25k2m_m_bitmask_vehicle_info_advanced2;
13:49:29 <Eddi|zuHause> the correct syntax would be something like: STORE_TEMP(offset, 0x10F), var[0x61, whatever-the-hex-value-of-count_veh_id, 0, 0xFF, vehid]
13:51:13 <GeorgeVB> petern: As it was mentioned above, using var 61 is not allowed, so I'm looking for workaround
13:51:18 <Eddi|zuHause> the worst part of that is that you can't get the hex-value of the property by the property name
13:52:02 <Eddi|zuHause> but writing to 0x10F without var[0x61, ...] just does nothing
13:53:13 <petern> It's allowed during the allow_wagon_attach and start_top_check callbacks.
13:54:09 <petern> It's not allowed during the callback that sets vehicle properties
13:55:18 <GeorgeVB> So, count_veh_id() does not take 0x10F into account? Ok, that is pity 😦
13:56:39 <Brickblock1> would still lead to the same issues as before tho wouldn't it
13:58:27 <GeorgeVB> Well, what would be the easiest way to solve the problem?
13:58:27 <GeorgeVB> Is there some way for a switch to call the block form the other GRF?
13:59:07 <Eddi|zuHause> i don't think so
13:59:43 <Brickblock1> grfs generally can't communicate
13:59:59 <Brickblock1> why are you splitting it in the first place?
14:38:31 <GeorgeVB> Strings limit (1024 strings)
14:42:38 <andythenorth> that's quite an interesting reason 🙂
14:44:01 *** MarkoMarko has joined #openttd
14:44:01 <MarkoMarko> I'm sorry if I've selected the wrong channel.
14:44:01 <MarkoMarko> Is this a bug or a feature?
14:47:15 <GeorgeVB> andythenorth: Do you know a way to fix it? I would leave it unsplited then
14:47:15 <jfs-> MarkoMarko: Well, start by describing "this", what exactly you're paying attention to on your screenshot that seem wrong or unexpected
14:48:21 <jfs-> I would guess that you're talking about the accepts and supplies for the station not showing any cargo types, but it's best if you can be explicit about those details when you ask a question
14:48:23 <MarkoMarko> jfs-: I'm talking about the hitbox, which means that most of the sawmill is within the radius, but it doesn't accept wood.
14:48:37 <andythenorth> one day we will fix that
14:48:49 <andythenorth> and somebody somewhere will complain that we ruined their life
14:50:23 <MarkoMarko> Understood, thanks for the reply.
14:50:53 <jfs-> only that single tile actually Accepts Wood
14:51:45 <jfs-> it's a weird design but it's how Transport Tycoon Deluxe did it and it's basically one of the OpenTTD goals to keep those parts of the game data as close to original as possible
14:53:26 <andythenorth> it's a case where we could change it
14:53:50 <andythenorth> 'savegame compatibility' is a promise to load the savegame, not preserve all gameplay
14:54:06 <andythenorth> we're just not wanting to deal with the inevitable monstrous outpouring of hate
14:54:25 <andythenorth> because our community contains about 5 people whose behaviour might be labelled as 'dickhead'
14:54:38 <andythenorth> if one was making judgements
14:54:41 <andythenorth> I don't, of course
14:55:16 <MarkoMarko> It makes sense. I hadn't thought about it. On the one hand, it's a small thing, but on the other hand, it's a huge change.
14:57:17 <andythenorth> not sure how old, but old 🙂
15:06:16 <Rubidium_> yes, long tunnels are way too expensive! They used to give you money in TTD! So OpenTTD is broken ;)
15:06:49 <TallTyler> andythenorth: I tried, in #9832. Nobody seemed to have strong objections but it quickly turned into bikeshedding about how to prevent any possible objections, so I gave up. I’m not opposed to reopening it, as I still think should be changed.
15:07:16 <andythenorth> it should, but my inclination to deal with boring people has evaporated
15:07:21 <andythenorth> there's too much of it about
15:10:54 <GeorgeVB> andythenorth: If they start accepting cargo, some supply chains will break because the cargo will go to the wrong industry.
15:11:27 <andythenorth> this is a sad outcome, but the lack of 8/8 acceptance on tiles confuses new players
15:11:31 <TallTyler> People shouldn’t do that then
15:12:18 <Brickblock1> GeorgeVB: this is a imo silly reason to prevent change
15:12:32 <GeorgeVB> Would newgrf industries be forced to change the same way?
15:12:57 <GeorgeVB> ECS industries uses such feature a lot
15:13:09 <TallTyler> No, it does not affect NewGRF industry tiles, even if they inherit a base game industry tile
15:13:21 <TallTyler> It just changes vanilla industry tiles
15:13:40 <jfs-> I think it'd be possible to have newly build industries place subtly different tiles on the map, which would have full accepts, while industry tiles already on a map keep their existing accepts
15:14:04 <TallTyler> Perhaps, but I don’t know how to do that
15:15:18 <jfs-> I see I did already suggest that before
15:15:33 <TallTyler> Yes, that was the bikeshedding I mentioned 😉
15:15:41 <TallTyler> I honestly don’t know how I’d implement that
15:16:16 <TallTyler> Saveload versions for industry tiles, perhaps, but that seems both overkill and beyond my current understanding
15:18:45 <Eddi|zuHause> that would still apply the same way to base game industry tiles and newgrf industry tiles
15:22:30 <jfs-> eddi: unless NewGRF industries inherit original tile data instead of the modified
15:24:59 <andythenorth> grfs are editable
15:25:43 <andythenorth> the idea that modding/module/plugin support is 100% maintained is weird, and I haven't seen it any other successful project
15:33:32 *** HerzogDeXtEr has joined #openttd
15:52:27 *** tokai|noir has joined #openttd
15:52:27 *** ChanServ sets mode: +v tokai|noir
15:59:19 *** tokai has quit IRC (Ping timeout: 480 seconds)
16:01:59 *** WormnestAndroid has quit IRC (Remote host closed the connection)
16:02:01 *** WormnestAndroid has joined #openttd
16:04:16 *** tokai|noir has quit IRC (Quit: c('~' )o)
16:04:18 <Eddi|zuHause> jfs-: the problem is, during saveload you cannot necessarily decide whether the industry tile needs to be converted to the new tile or stay as the old tile
16:04:45 <Eddi|zuHause> (or maybe i misinterpret the suggestion)
16:06:39 <Eddi|zuHause> the second problem is that now you disconnected the NewGRF industry defaults from the actual default industrie, which will confuse everyone that starts a new industry set, expecting the new industry defaults
16:12:14 <jfs-> eddi: my idea would be that you do not convert tiles when loading old saves. industries built before the change would have the original tiles, industries built after would have the new tiles
16:12:14 <jfs-> it might also be possible to do something like set a flag on an industry in newgrf to indicate you want the new defaults for it instead of inheriting the ghosted old defaults
16:16:53 <jfs-> and the old and new tiles would have different ids
16:18:30 <andythenorth> I'd just break saves and move on 😛
16:18:43 <andythenorth> but as I do not have the competence to run a patchpack
16:19:25 <andythenorth> grf authors relying on those tile properties need to do better
16:19:32 <andythenorth> seriously, mod better
16:21:01 <Brickblock1> if you aren't changing them you probably wan't them t
16:21:27 <JGR> You're never going to want to have some industries with the old behaviour and some with the new in the same game
16:22:16 <JGR> So it could just be a non-writable setting or equivalent which is properly set on load if needed
16:23:17 <JGR> That said, it might be better to gently point players to an industry GRF
16:24:06 <andythenorth> once upon a time I wanted to convert all the content to grf by default
16:24:12 <andythenorth> vanilla industries, vanilla vehicles etc
16:24:16 <andythenorth> then I thought again 😛
16:24:42 <andythenorth> the upside of that is it fixes the problem
16:24:49 <andythenorth> without the outrage and drama
16:26:49 <jfs-> tbh yes, shipping some default NewGRFs with the game might be a better option, and have them default-enabled for new games
16:26:55 <andythenorth> in this project, we do seem to veer between
16:27:15 <andythenorth> "we must never ever upset the 3 squeaky wheels who might be badly behaved in some internet site"
16:27:31 <andythenorth> "yolo let's just break something with no consultation or comms"
16:27:44 <andythenorth> I'm as guilty as anyone, but eh
16:27:56 <jfs-> like, a NewGRF named "OpenTTD 14.0 standard rules" which changes some vehicle expiry dates and industry tile accepts around
16:28:20 <TallTyler> Helicopters never go obsolete? I’d support that
16:28:31 <jfs-> and then keep shipping that grf with new releases even if 15.0 includes another new updated ruleset
16:28:50 <TallTyler> andythenorth: This is the current state of the pendulum, so I thought I’d seize the moment 😛
16:29:51 <jfs-> and playing without any of those "standard rules" GRFs could be called "legacy mode", and adding other GRFs on either would be "modded"
16:30:27 <andythenorth> jfs-: and then maybe some online grf making tool? 😛
16:30:45 <andythenorth> which can change the 'standard rules' grf? 😛
16:33:03 <petern> I mean that's as good an excuse as any to "get new wheels" but sometimes you don't want to...
16:34:07 <jfs-> andythenorth: tbh, no. but maybe make a dropdown in the new game GUI to select "mode", either "current", "legacy", "modded", and selecting "modded" if no newgrfs are configured right now could bring up the config ui
16:36:52 <petern> MarkoMarko: Why does this sawmill look so odd anyway?
16:36:55 <LordAro> petern: less than two years old
16:37:19 <petern> "Too much power" innit
16:37:41 <LordAro> too many potholes, more likely
16:37:45 <LordAro> but yeah, giving warranty a go
16:37:56 <LordAro> hunt say 3 years, so in theory shouldn't be an issue
16:40:26 *** virtualrandomnumber has joined #openttd
16:43:19 <petern> Apparently after downloading zBase I need to restart the game to make it seen.
16:43:23 <petern> I would rather not see it.
16:43:29 <petern> The sawmills in zBase are... wtf?!
16:43:51 <andythenorth> it was a proof of concept 🙂
16:44:34 <petern> I have proof of contempt
16:46:03 <andythenorth> I have proof of pudding
16:46:14 <andythenorth> well I don't, but I wanted to write that
16:47:33 <jfs-> I would suggest against storing your proof in the pudding though, it tends to be difficult to clean and may not be accepted by the professor when you turn it in
16:52:49 <andythenorth> right what was I doing?
16:52:56 <andythenorth> besides breaking my build?
16:53:51 <jfs-> andythenorth: 🇧 🇷eaking 🇧🇺ild
16:59:29 *** virtualrandomnumber has quit IRC (Quit: virtualrandomnumber)
17:00:15 <andythenorth> don't I need to update grf spec?
17:27:03 <MarkoMarko> petern: To me, it looks like the usual 🤓 I use zBase.
17:31:17 <MarkoMarko> I'm used to it. I don't know, the pixels hurt my eyes too much. But probably most players play on standard graphics.
17:31:17 <MarkoMarko> I also play without trees. I must be a weirdo 🥸
17:34:14 <Brickblock1> If I was using zbase I would hide the trees
17:34:32 <Brickblock1> but generally I don't you just need good graphics
17:40:41 *** gelignite has joined #openttd
17:40:42 <petern> Oh I wonder if my chunky-line patch will work now 🙂
17:43:09 <petern> Normal computer monitors only show pixels, so that must be eyestraining.
17:43:18 <petern> A vector CRT is probably out of the question...
17:49:43 <MarkoMarko> I meant pixel graphics. I don't enjoy playing a game with pixelated graphics. Modern graphics have changed me.
17:53:43 <LordAro> MarkoMarko: most people here are baffled by such an opinion :p
17:54:40 <MarkoMarko> I may have offended someone, I'm sorry.
17:57:18 <michi_cc[d]> Hmm, lot's of talk to catch up to 🙂 No Andy, nothing to read, but we are back to our regular programming again ❤️
17:57:36 <LordAro> a fair amount of andy
17:58:04 <andythenorth> I tried just talking to GPT
17:58:06 <petern> zBase is still made of pixels... they're badly placed.
17:58:17 <andythenorth> Zeph is in the channel 🙂
17:58:24 <andythenorth> I am sure he welcomes your PR 🙂
17:58:50 <petern> There's lots of music I don't like, and I can't make good music myself either.
17:59:04 <andythenorth> "4x EZ: was it a mistake?"
17:59:27 <LordAro> definitely usual programming
18:00:09 <michi_cc[d]> GeorgeVB: Starting with OpenTTD 13.1, you get a lot more possible GRF strings (with some text stack trickery in some places). Only problem here is that nobody wrote the NML support for it so far. I did have a look, but there are some hardcoded rules in NML that I don't know to properly change.
18:01:25 <michi_cc[d]> andythenorth: Nope, name callback does not get the vars of a real vehicle (exactly to prevent desyncs on other shenanigans).
18:17:14 <michi_cc[d]> Not turning green for me either 😦
18:27:58 <andythenorth> nice and recursive?
18:28:17 <TallTyler> Or baby’s first NewGRF is terrible 😛
18:28:30 <TallTyler> I haven’t looked at my source code for that in a long time
18:29:04 <petern> I'm checking a few other house grfs, see if they do the same.
18:33:50 <petern> Yeah, yours is the only one that does this.
18:34:33 <petern> So I think the behaviour change is fine as it matches the spec. I'm not sure how it affects those buildings, it may just reset all properties and not cause any difference anyway.
18:38:26 <TallTyler> Hmm, did I reuse IDs between different climates?
18:38:36 <TallTyler> (Not at a computer to check)
18:38:47 <TallTyler> (Just wondering aloud 🙂 )
18:39:02 <petern> Yes you redefine them for different climates, but don't actually check the current climate before doing so.
18:39:24 <TallTyler> Oh I think I see what you mean
18:40:13 <petern> Well, #10627 stops OpenTTD crashing with it, and I guess the behaviour was "undefined" before, heh
18:40:27 <petern> Did not match the spec at least.
18:41:05 <DorpsGek> - Update: Translations from eints (by translators)
18:45:53 <Kuhnovic> For my pathfinder PR I had lots of debug drawing code to properly visualize what was going on. I was a little surprised that there was nothing sort-of-generic already made. I mean I'm not the first one that needs a bit of extra debug visualization I guess. Any thoughts on this? Is there something available that I'm not aware of maybe?
18:46:37 <petern> Problem is it tends to be very specific to what you are visualizing.
18:47:20 <Kuhnovic> True, but I think in general it doesn't hurt to have some basic stuff out there. Marking tiles, marking tracks, that sort of thing.
18:47:49 <jfs-> first that it tends to be quite specific to what you're doing, and second that it tends to get in the way when going through the code with other purposes
18:48:17 <jfs-> but well yes, some more mechanisms to insert some kind of overlay drawing on world viewports can be useful
18:48:55 <Kuhnovic> I definitely doing think that any of the debug drawing code should ever stay there, it should be only for development purposed and should only compile in debug mode IMO
18:49:47 <JGR> I think dP has more stuff in this area
18:50:06 <jfs-> we definitely need more ways to highlight tiles in main
18:50:30 <Kuhnovic> Yeah the stuff dP did for CityMania is quite impressive
18:51:14 <JGR> You can get a long way using the existing tile highlight sprites if you just want something for debug though
18:55:53 <Kuhnovic> JGR: That's exactly what I did. But maybe it's an idea to make that code a little bit more proper / permanent so dev can use it easily during development.
19:24:14 <andythenorth> "GS says hi and would like to optionally display tile highlights"
19:24:28 <andythenorth> marking out regions etc
19:25:55 <andythenorth> ok so nml, who can tag and release?
19:30:10 <petern> Hmm, where did the rest of this branch go...
19:31:25 <petern> There was a git command to grep inside commits... Hmm
19:39:51 <michi_cc[d]> petern: `git log -S` maybe?
19:40:22 <petern> Not quite, I need it to search stashes/branches.
19:41:30 <andythenorth> I've been searching refs directly recently 😛
19:41:35 <andythenorth> for some things I 'misplaced'
19:42:18 <petern> And in my bash history... "git reflog --grep-relog" hmm
19:42:42 <petern> But that doesn't find anything. Hmm.
19:44:38 <petern> Found a stash search, but not the missing change. Oh well. Must be properly missing.
19:45:30 <glx[d]> but the date in 0.7.2 changelog is incorrect
19:48:46 *** gelignite has quit IRC (Quit: Stay safe!)
19:51:36 <glx[d]> hmm would be nice to fix the "Git checkout found but cannot determine its version. Error: Command '['git', '-C', '/home/runner/work/nml/nml', 'describe', '--tags', '--long']' returned non-zero exit status 128." in actions at some points
19:52:45 <andythenorth> is that legacy coop version detection?
19:54:09 <LordAro> jfs-: well that's different
19:55:31 <glx[d]> should be flawless this time (was fine when I tested 10 days ago)
19:56:10 <jfs-> I've wanted to remake the title screen GUI for a long time, to allow the centre part of the intro game to be visible
19:57:07 <glx[d]> the window can be moved
19:57:19 <jfs-> how many actually move it?
19:57:41 <LordAro> if i click it by accident i usually put it back where i found it :D
19:59:05 <glx[d]> pff windows workflow failed
19:59:30 <JGR> I'm not sure that the title screen is that exciting to need to move the UI off of it
19:59:55 <GeorgeVB> michi_cc[d]: Holy shit, I need to roll everything back!
20:00:27 <jfs-> I need to fix the resizing logic tho
20:01:44 <glx[d]> seems only the standalone upload failed, pypi looks fine
20:07:10 <GeorgeVB> GeorgeVB: And when should we expect the nmlc update?
20:07:56 <dwfreed> why are you asking yourself that question? :D
20:11:55 <Gwyd> JGR: But also I agree with this, it's more of an ambient nicety than a center of attention
20:12:29 <Gwyd> The most important thing on that screen is the main menu, which this layout would take attention from I feel
20:13:25 <jfs-> on the contrary, what I try to do with this alternate layout is group the features more, and put the primary "start playing" buttons in the centre
20:13:53 <jfs-> centre: start playing! - left: configure content - right: game settings and info
20:14:28 *** WormnestAndroid has quit IRC (Ping timeout: 480 seconds)
20:14:45 <jfs-> if someone artistic could spice it up with some nice big button arts, I think this would be much more attractive
20:16:38 <glx[d]> manually uploaded the windows standalone version
20:18:05 <glx[d]> but I still need to fix the workflow (again)
20:24:44 <LordAro> glx[d]: also action updates & set-output and things
20:26:06 <glx[d]> updating the action will be hard, it's archived
20:26:13 <glx[d]> will need to replace it
20:37:33 <michi_cc[d]> GeorgeVB: Whenever someone turns up to write it. Unfortunate but truthful answer.
20:39:12 <michi_cc[d]> jfs-: I think the current trendy game thing would be a full height menu bar just on the left. I've seen that in a lot of recent games.
20:50:52 <andythenorth> quite conventional
20:53:12 <andythenorth> hmm could we unify stations and objects somehow?
20:53:28 <andythenorth> and then choose on construction whether an object is a station tile, or a neutral object?
20:53:47 <andythenorth> or....I could just generate both from the same compile 😛
21:04:23 <glx[d]> but stations and object don't use the exact same sprite layouts
21:04:39 <glx[d]> because stations need to use weird workarounds
21:06:49 *** keikoz has quit IRC (Ping timeout: 480 seconds)
21:09:42 <glx[d]> it's really weird, {{ steps.nml_archive.outputs.archive }} is empty but ${{ steps.nml_source_archive.outputs.archive }} is correct
21:18:29 <andythenorth> I could probably transform the spritelayouts 🙂
21:19:12 <andythenorth> wonder if we could make objects behave as decor (non-track) station tiles though 😛
21:19:40 <andythenorth> as a new implementation
21:20:40 <JGR> People have already started using road stops for that
21:23:41 <andythenorth> (assuming the object limit is lifted) I'm going to end up creating 600 industry decor objects 😛
21:23:50 <andythenorth> then re-implementing them as stations 😛
21:24:44 <andythenorth> generally the object is preferable as it can be built on corner slopes and doesn't connect to stations causing join issues
21:24:58 <andythenorth> but to show waiting cargo, or extend a catchment, a station tile is necessary
21:25:18 *** WormnestAndroid has joined #openttd
21:25:27 <andythenorth> for a non track station, what props does it have? 😛
21:25:33 * andythenorth looks in the bits
21:25:44 *** nielsm has quit IRC (Ping timeout: 480 seconds)
21:26:32 <andythenorth> hmm but we have no concept of 'station' so my question is meaingless
21:29:19 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
21:29:44 <petern> Hmm, where did I set the msbuild concurrency flag again...
21:29:58 *** WormnestAndroid has joined #openttd
21:30:32 <TallTyler> andythenorth: That’s hawt
21:30:41 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
21:30:47 *** WormnestAndroid has joined #openttd
21:31:22 <TallTyler> Waiting cargos at stations are still flawed since you shouldn’t see them with good service, I’d rather have cargos as object tiles that I could place as I choose
21:31:39 <TallTyler> I do agree that corner tiles make objects generally a better choice
21:33:58 <andythenorth> I am awaiting inspiration on how best to display cargo 😛
21:34:31 <andythenorth> I never figured out one good simple way
21:34:49 <andythenorth> the best way might be some horrific combination of 'amount industry is producing' and 'current station rating'
21:36:07 <andythenorth> recolour cargo sprites to red if too much is waiting? 😛
21:36:14 <andythenorth> or rating has dropped horribly?
21:36:20 <andythenorth> is it a game or a train sim?
21:36:27 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
21:36:44 <petern> It's "make loads of money out of 5 mph 200 tile journey" sim
21:37:01 *** WormnestAndroid has joined #openttd
21:37:44 <andythenorth> well....depends on how we patch the payments eh
21:38:24 <andythenorth> maybe we should make snail-mode even more profitable
21:38:31 <andythenorth> we could have a set of settings for it
21:44:22 *** Wolf01 has quit IRC (Quit: Once again the world is quick to bury me.)
21:51:21 <petern> Hmm, one of my LED lamps is dead. Oh well.
21:57:25 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
21:57:27 *** WormnestAndroid has joined #openttd
22:01:29 <petern> Looks like var60 is fine already.
22:02:42 <petern> #10627 (nice number swap) makes that pretty simple. Assuming it works.
22:04:56 <petern> andythenorth: get to it.
22:07:40 <andythenorth> ` nmlc info: Object items: 252/256` FIRS
22:08:26 <andythenorth> we can do it for 13.6?
22:08:38 <andythenorth> that's June or something?
22:18:12 <andythenorth> `return self.unit.consist.buyable_variant_group.parent_vehicle.base_numeric_id`
22:18:18 <andythenorth> just some python
22:18:52 <andythenorth> wonder if it pickles ok 😛
22:19:31 <andythenorth> oops I broke variants 😄
22:22:10 <andythenorth> I have unbroken it
22:22:41 <andythenorth> ach my morning alarm is unpleasantly soon
22:24:27 <petern> Turn your alarm off, then it's not a problem.
22:24:53 <petern> The only reason I have an alarm on is that it enables slow-charging mode on my phone.
22:25:25 <petern> That and I can't make 6.30 on a Saturday without assistance, and even then sometimes don't.
22:38:56 *** WormnestAndroid has quit IRC (Ping timeout: 480 seconds)
22:38:59 *** WormnestAndroid has joined #openttd
23:02:28 *** HerzogDeXtEr has quit IRC (Read error: Connection reset by peer)
23:20:23 *** gnu_jj_ has quit IRC (Read error: Connection reset by peer)
23:28:17 *** sla_ro|master has quit IRC ()
continue to next day ⏵
