IRC logs for #openttd on OFTC at 2023-04-23
⏴ go to previous day
00:32:28 *** Wormnest has quit IRC (Ping timeout: 480 seconds)
00:36:10 *** WormnestAndroid has quit IRC (Remote host closed the connection)
00:36:20 *** WormnestAndroid has joined #openttd
00:45:42 *** greeter has quit IRC (Remote host closed the connection)
00:51:01 *** greeter has joined #openttd
01:02:31 *** Wormnest has joined #openttd
01:45:16 *** HerzogDeXtEr has joined #openttd
01:49:40 *** WormnestAndroid has quit IRC (Ping timeout: 480 seconds)
01:50:14 *** WormnestAndroid has joined #openttd
01:51:28 *** HerzogDeXtEr2 has quit IRC (Ping timeout: 480 seconds)
01:51:29 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
01:51:36 *** WormnestAndroid has joined #openttd
01:55:10 *** Wormnest has quit IRC (Ping timeout: 480 seconds)
02:04:47 *** Wormnest has joined #openttd
02:42:44 *** debdog has quit IRC (Ping timeout: 480 seconds)
02:53:08 *** D-HUND is now known as debdog
03:25:43 *** Flygon has quit IRC (Read error: Connection reset by peer)
03:33:41 <pickpacket> I compiled 13.1 yesterday. The exact same settings as when I compiled 13.0. Did something happen in the code that made the game significantly slower? It lags *a lot*
03:37:55 <pickpacket> even just in the main menu
03:50:01 <pickpacket> I had a similar experience after compiling 13.0 with asserts enabled, but this time they're disabled already
06:49:51 <petern> Did you make a debug build?
07:08:57 <Eddi|zuHause> do we still swap tab with shift on debug builds? would be an easy way to identify them
07:21:06 <andythenorth> oops have to restart OpenTTD for grf action 14 changes
07:57:25 <pickpacket> petern: ... maybe... crap
08:00:34 <pickpacket> ever. single. time.
08:06:31 <Eddi|zuHause> andythenorth: wasn't there a command for rescanning grfs?
08:07:02 <andythenorth> doesn't work for action 14 afaik
08:07:15 <Eddi|zuHause> not reload. rescan
08:07:45 <andythenorth> yes, there's a button for it as well
08:21:08 <andythenorth> the static grf stuff, params, version etc
08:21:24 <andythenorth> might work on rescan, might be user error
08:26:13 <petern> Waiting for coffee, I think they're cooking up a large batch of bacon breakfasts.
08:35:33 <EmperorJake> I know that changes to stuff like GRF title and description don't show up until a game restart
09:13:15 <Eddi|zuHause> sounds like a bug to me
09:41:39 <EmperorJake> I assumed it was a necessary limitation
10:00:49 <Eddi|zuHause> dunno why it would be
10:55:42 *** lobstarooo has joined #openttd
11:10:23 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
11:11:05 *** WormnestAndroid has joined #openttd
11:14:55 <TrueBrain> I am very sure we fixed more of these before ... they keep popping up 😄
11:49:53 *** WormnestAndroid has quit IRC (Remote host closed the connection)
11:49:59 *** WormnestAndroid has joined #openttd
12:47:22 <andythenorth> so are newgrf trains now complete?
12:48:47 <andythenorth> maybe this is the last refactor of Horse 😄
12:54:17 <Eddi|zuHause> it's over now. you can go to sleep
12:58:40 <andythenorth> is it a quote? 😛
13:01:56 *** HerzogDeXtEr1 has joined #openttd
13:06:49 *** HerzogDeXtEr has quit IRC (Ping timeout: 480 seconds)
13:36:59 *** gelignite has joined #openttd
13:52:08 <TallTyler> Okay bike people, what’s your favorite (ideally free) bike ride analytics app? My rides are pretty short (5-10 miles) and quite flat along rivers, but it would be nice to track them somehow 🙂
13:52:42 <TallTyler> Apple Fitness only understands walking, it seems
13:53:17 <andythenorth> I knew already that `vehicle_is_flipped` can't be used in purchase list varact2 chains
13:53:24 <andythenorth> as it returns 1 always, which is unhelpful
13:53:43 <andythenorth> but it seem even calling the var causes the chain to fail
13:54:14 <petern> It's invalid to read it.
13:54:46 <andythenorth> I am checking it's not me, but I was trying to use a ternary which checked if we're in purchase list
13:55:12 <andythenorth> nah it must be my code
13:55:14 <petern> Reading an invalid variable always returns UINT_MAX.
13:55:43 <andythenorth> `0 == 1 ? vehicle_is_flipped : 0` works in purchase list (obviously it's stupid, but trying to isolate the failure)
13:55:49 <Eddi|zuHause> there aren't many valid variables in purchase list
13:56:01 <andythenorth> nope, actually that ternary fails
13:56:08 <andythenorth> sometimes purchase list CC is cached
13:56:16 <andythenorth> which makes this prone to human error 🙂
13:57:17 <petern> Basically, don't use vehicle_is_flipped at all in your purchase list chains.
13:57:51 <andythenorth> I'm trying to do that 😛
13:58:02 <Eddi|zuHause> basically, if you use any variable at all other than globals, you need a separate purchase callback
13:58:07 <andythenorth> it's lol, I have to clone the entry point switch, just to handle this
13:58:30 <petern> Welcome to TTDPatch design decisions 😄
13:59:33 <petern> Instead of "vehicle doesn't exist, return a sensible default" it's "vehicle doesn't exist, fail it and the rest of the chain"
14:01:12 <Eddi|zuHause> we should do a grfv9? 10?
14:01:25 <JGR> andythenorth: You can probably get around it by putting the variable read in a procedure
14:02:19 <andythenorth> it's in a procedure currently
14:02:29 <andythenorth> I pass a flag to the procedure for the context
14:02:47 <andythenorth> but it seems to cause the colour callback to fail entirely
14:03:50 <Eddi|zuHause> petern: i'm assuming in TTDPatch this would have caused invalid memory accesses and stuff
14:03:57 <JGR> I mean put the variable read in a procedure of its own
14:04:23 <JGR> So you'd get a result of either 0, 1, or failed
14:04:53 <JGR> And can then do something useful with that at the call site
14:05:24 <Eddi|zuHause> how do you even handle "failed" in a switch?
14:05:35 <petern> I wonder if "much" would break if we stopped failing these things.
14:06:22 <JGR> You just use `== 1`, and treat failed and 0 as the same in this case
14:06:59 <Eddi|zuHause> petern: you mean if we could get away without bumping grf version?
14:07:27 <Eddi|zuHause> i'm sure SOMEONE abused that and complains his grf stopped working
14:08:03 <petern> I'm not sure you could usefully do that.
14:08:43 <Eddi|zuHause> it's the first rule of compiler construction: even if you don't see a use in a specs quirk, someone will.
14:09:11 <JGR> There are GRFs which use it
14:21:03 <andythenorth> seems even reading the var in purchase just causes the cb to fail
14:21:13 <andythenorth> not sure nesting it in more procedures helps
14:21:29 <andythenorth> it seems to return
14:26:31 <andythenorth> seems accessing random bits also causes purchase colour mapping cb to fail
14:28:01 <andythenorth> nah, THAT one must be user error
14:43:46 <andythenorth> oops ran out of random bits for wagons 😛
14:44:36 <petern> Clearly you need 8192 bits of persistent storage...
14:47:43 <Eddi|zuHause> does the persistent storage have the same limitations as var61?
14:48:39 <Eddi|zuHause> or rather, can it be used to get around that limitation?
14:50:00 <Happpy> Hi I like to report a bug in the game will 2 bugs is this the right channel for it
14:50:22 <Eddi|zuHause> bug reports best go on github
14:50:35 <Happpy> I don't have a account
14:51:05 <Eddi|zuHause> well, make one, then. bug reports often need some way to contact the author.
14:52:09 <glx[d]> it's owned by microsoft
14:53:08 <Eddi|zuHause> not sure if that answers the question in a satisfying way :p
14:54:37 <glx[d]> MS seems safer than google (based on current trend of youtube accounts hacked by session cookies stealing)
15:02:46 <TrueBrain> having a talk whether GitHub (and in extension, Microsoft) is safe on a platform like Discord is another type of irony 😄
15:05:21 <Happpy> OK where in that website do post a bug report
15:05:38 <TrueBrain> petern: As mentioned, there 🙂
15:08:45 <petern> Hmm, what does MakeEnumPropsT actually do...
15:11:54 *** WormnestAndroid has quit IRC (Remote host closed the connection)
15:11:55 *** WormnestAndroid has joined #openttd
15:11:56 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
15:11:58 *** WormnestAndroid has joined #openttd
15:12:00 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
15:12:07 *** WormnestAndroid has joined #openttd
15:14:44 <petern> I can comment out everything inside it and everything still seems to work.
15:17:06 <JGR> It was used by the Extract command helper
15:17:15 <JGR> For p1/p2 bit unpacking and the like
15:17:49 <Happpy> Hmm I do a report on the bug I got
15:20:03 <petern> You didn't fill the title 🙂
15:20:12 <petern> "expected result" > trains bug
15:21:05 <Happpy> Train going to the deport to severice I got the train breakdown of
15:21:11 <dP> breakdowns and servicing are separate settings iirc
15:21:48 <Happpy> What's the setting for the severice
15:25:28 <Happpy> So is got to green or red
15:25:42 <dP> green if you don't want them to service
15:26:33 <Happpy> And stil the trains going to the deport
15:27:25 <dP> do you have auto-replace set up?
15:28:55 <dP> upload your save to the ticket
15:29:10 <LordAro> as a rule of thumb, bug reports should contain enough information for someone who otherwise knows nothing about your system/config/save to reproduce the issue
15:29:32 <Happpy> I try but but did not accept the file tyip
15:32:38 <LordAro> all parts of the bug can be edited
15:36:23 <Happpy> OK I can not up load the save and I dm you and give you the game save map
15:36:44 <petern> it doesn't seem important, it's more the description of the problem is... lacking.
15:37:05 <petern> Well, I suppose the settings in use would be in the savegame.
15:37:34 <petern> Oh I see you think it isn't autorenew/replace either.
15:38:08 <glx[d]> how old is the train ?
15:38:09 <petern> Have you zipped the savegame or did that not help?
15:38:29 <Happpy> petern: I nedd help on that bit
15:38:49 <glx[d]> right click, send to, compressed folder
15:40:56 <glx[d]> I don't have that in win10 🙂
15:42:07 <Happpy> OK hop this beter soory if its still not
15:42:26 <glx[d]> you could reopen the other one
15:43:14 <Happpy> Dus the zip flile shor up
15:44:50 <Happpy> Mite be a bug because I use purr whive the normal trains set
15:46:56 <Happpy> All the settings is fine
15:47:04 <Happpy> So I don't understand it
15:48:40 <glx[d]> maybe it's because the signal after depot is red
15:49:19 <Happpy> The reliability is 94 %
15:52:38 <Happpy> I just ade a oder severice to the deport if nedd it and it fix it
15:54:15 <petern> You have autoreplace set up on wagons.
15:55:20 <Happpy> No I just ade severice at the nesrs deport and it's fix it
15:57:41 <petern> What do you mean "No"? This is from your savegame.
15:58:10 <petern> Anyway, breaking protocol
15:58:14 <Happpy> OK some trains stil dus it but not all ove them
15:59:34 <Happpy> Yes I did had some wagons auto on but I stop them
16:03:03 <Happpy> petern: (via GitHub) year I fix it by stop them
16:07:00 <Happpy> Only problem is I fort to ade a game scrip so tress port down automatically
17:02:00 <TallTyler> Nope, no permissions
17:07:28 <petern> Hmm, confused by CfgApply. It runs in 3 stages and can modify data by adding to an existing value.
17:07:47 <petern> Which in my mind means it'll end up with wrong value.
17:09:36 <petern> (Other than the more optimal iterator dereference)
17:19:21 <petern> Ah it relies on the NewGRF using Action D to skip as appropriate. How hairy!
17:19:44 <petern> Hmm, no I misread that I think.
17:20:13 <petern> Yeah, the line before that is relevant though 😄
17:20:20 <petern> > Skip the action D's as well as both action 6 and the action it modifies during the "test" stage by skipping these actions if action 7 var 84 has bit 10 set.
17:22:44 <Eddi|zuHause> that sounds like gibberish
17:35:05 <petern> Hmm, do we have something like Backup that will execute a lambda?
17:40:54 <jfs-> I think I saw something like that recently
17:42:25 <jfs-> mostly it might be more appropriate to just write the small class/struct that has an appropriate destructor... I think std::unique_ptr can do something like it too
17:43:26 <petern> Then you have a specialized class that is only used in one place.
17:44:03 <Eddi|zuHause> a lambda-class? :p
17:51:38 *** WormnestAndroid has quit IRC (Ping timeout: 480 seconds)
17:53:04 *** WormnestAndroid has joined #openttd
18:07:19 <petern> Especially the (void*)1
18:28:39 <petern> Yes I saw that too, but it's more than 3 lines 😉
18:29:07 <TrueBrain> it is even pretty recent .. lol
18:29:44 <TrueBrain> petern: true, but at least you wouldn't need to maintain it 😄
18:31:39 <petern> Urgh, Doom secrets that are triggered by one-off events -- miss it and you can never get 100% 😦
18:41:19 <DorpsGek> - Update: Translations from eints (by translators)
19:03:43 <andythenorth> oof wonder if I can make Horse compile faster
19:04:08 <andythenorth> probably by having less graphics processing 😛
19:04:14 <andythenorth> it's 6 seconds to generate all the sprites now
19:05:59 <petern> Is 6 seconds causing you issues...
19:06:45 <andythenorth> the entire compile is 16s
19:08:48 <andythenorth> random enough? 😛
19:08:55 <Brickblock1> write it in assembly
19:09:23 <andythenorth> hmm that category should probably just be 'Mineral Wagons' eh
19:09:38 <andythenorth> wonder if I can do a black one
19:10:02 <andythenorth> the brown colour is quite hard to do, it's not really dark enough
19:10:32 <andythenorth> but all the brown shades tend towards 'poo'
19:17:10 <andythenorth> meh, this has issues 😄
19:25:10 <petern> Hmm, I wonder where else I could use scope_guard to justify including it...
19:26:20 <TrueBrain> petern: Replace Backup with it? :p
19:27:00 <Rubidium_> petern: I'd say, look for destructors
19:31:17 *** nielsm has quit IRC (Ping timeout: 480 seconds)
19:34:20 <petern> Heh, goal_base.h says "Empty destructor has to be defined" and then proceeds to have a non-empty destructor...
19:34:43 <petern> (But that is char * to std::string stuff)
19:36:03 <andythenorth> maybe that brown can be improved
19:40:14 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
19:41:24 *** WormnestAndroid has joined #openttd
19:45:43 *** Wormnest has joined #openttd
19:49:09 <Rubidium_> petern: would it make sense to replace the FileDeleter with scope_guard? Just asking because it's called the deleter, because it's the delete in context of unique_ptr but it's not actually deleting the file
19:55:20 <TallTyler> Build before PR with +376 -95 in 17 commits? Yeah, guess I should… 😛
20:07:23 *** gelignite has quit IRC (Quit: Stay safe!)
20:08:27 <andythenorth> uuf can we have more vehicle random bits pls?
20:08:39 <andythenorth> I could do everything as articulated, then use 1/8 vehicles
20:10:01 <andythenorth> 16 random bits maybe? :
20:11:31 <petern> Hmm, what could it break...
20:12:07 <andythenorth> silly random switch?
20:12:17 <andythenorth> switch / random varact2
20:12:32 <petern> There's some parameter reading var 0x5F that shifts random_bits << 8.
20:13:38 <andythenorth> this random stuff makes the game more alive
20:15:43 <petern> Hmm, reseed already copes with 32 bits, I think.
20:17:45 <TallTyler> Thanks TrueBrain for the new timers. They’re glorious and so much nicer than the old cascade of OnNewMonth(), etc, functions
20:25:51 <petern> > if (parameter == 0x5F) {
20:25:51 <petern> > /* This seems to be the only variable that makes sense to access via var 61, but is not handled by VehicleGetVariable */
20:25:51 <petern> > return (u->random_bits << 8) | u->waiting_triggers;
20:25:57 <petern> Hmm, wonder where that is in the specs.
20:26:43 <petern> > case 0x5F: return (scope->GetRandomBits() << 8) | scope->GetTriggers();
20:26:50 <petern> Ah, standard non-specific stuff.
20:27:24 <petern> Okay, so industries have 32 random bits...
20:27:32 <andythenorth> non standard standards
20:27:48 <petern> If you use the randomized action 2 then it doesn't matter, the full 32 bits will be used.
20:27:59 <petern> If you test against var 5F then you only get the lower 24 bits.
20:28:16 <petern> I'm not sure what NMLC does.
20:30:51 <petern> Maybe we need a uint24 😄
20:45:34 <dP> more random stuff in the savegame :/
20:46:02 <dP> thankfully there aren't many vehicles
20:46:12 <dP> but probably it all can be just replaced with some hash
20:46:36 <petern> If you want to break random triggers, sure.
20:47:01 <andythenorth> special compression mode for people who worry about savegame size
20:47:15 <andythenorth> 32 bits, but it's 8 bits repeated 4 times
20:47:29 <dP> I guess it can be hash first, saved later
20:47:42 <dP> just so it's not wasted on something that's not using random at all
20:47:52 <Rubidium_> can't you have a counter with number of randomize calls?
20:47:57 <petern> Just set them all to 4. Guaranteed by dice-roll.
20:48:01 <dP> probably most useful for something like objects
20:48:25 <petern> I guess you could potentially test if random is used.
20:48:39 <dP> likely less random than just random
20:48:40 <andythenorth> if we had 256 storages....
20:48:46 <andythenorth> I could store the bits and re-roll 😛
20:49:00 <petern> Rerandomization doesn't have to change all bits.
20:49:16 <petern> So you'd need to store the counter for each bit.
20:49:33 <Rubidium_> sounds like a plan to not have random in the savegame
20:50:00 <dP> dammit, why everything newgrf has to be that anoying :p
20:50:04 <petern> dP doesn't like variety. dP likes smallest savegames.
20:50:13 <petern> Because that's truely the metric that matters.
20:50:27 <Rubidium_> if only computers were faster, then we could just only save the completely non-random human actions and the initial random seed with settings
20:50:43 <dP> also matters for server connection speed
20:50:54 <andythenorth> how about we just lambda on AWS every time we want random bits?
20:55:05 <FLHerne> petern: I do sympathise when it's trees
20:55:19 <andythenorth> trees are needlessly random
20:55:41 <dP> btw, in my case command log usually takes more than a save game xd
20:55:42 <FLHerne> no-one has ever cared about more than maybe 0.1% of trees
20:55:47 <dP> most of it is just goal stuff spam though
20:55:48 <andythenorth> ^^^ that could be done differently, if the game did the randomising
20:55:58 <andythenorth> but that's one vehicle, chaining to many other vehicles 😛
20:56:04 <andythenorth> random bits run out fast
20:56:16 <FLHerne> oh, did rb or someone implement that idea to make them less random?
20:56:36 <dP> trees are still plenty random
20:56:48 <dP> it's just harder to get rid of than the counter
20:57:12 <petern> "I want to play huge games but save on disk space" is stupid.
21:02:39 <dP> petern: it's one thing to save useful data but another to save random noise :p
21:03:47 *** keikoz has quit IRC (Ping timeout: 480 seconds)
21:04:46 <andythenorth> write a setting that turns all the grf random bits off
21:04:57 <andythenorth> or unifies them to a single random per feature type
21:05:02 <andythenorth> think of the savings
21:05:17 <dP> I was thinking about adding feature property
21:05:31 <dP> if object doesn't want random bits it can just opt-out
21:06:52 <dP> btw, iirc jgr did hash some random bits somewhere
21:09:47 <dP> oh, it's in newgrf landscape
21:34:44 <TrueBrain> So this variant stuff ... does that basically means NewGRFs will be even bigger now? :p
21:34:58 <TrueBrain> Looking at the endless images from Andy and co
21:35:46 <dP> at least Andy doesn't do ez xD
21:35:55 <andythenorth> Horse is now 20.5 MB
21:36:24 <dP> how many of that is switches? xD
21:37:18 <andythenorth> piss, if I recolour to DARK_BLUE in a recolour sprite, that is then recoloured to CC1 by the game
21:37:32 <petern> TrueBrain: Nah, just all the liveries that were hidden away behind cargo refits are now more easily visible.
21:37:37 <andythenorth> that's not normally what happens, maybe I can do it differently
21:38:09 <TrueBrain> I really should look into better compression backend side :p
21:38:10 <andythenorth> 50% of Horse ones are just recolour sprites
21:38:17 <andythenorth> so the game probably gets slower, but eh
21:40:19 <dP> Found 128945(66%) duplicate sprites, 21399823(65%) bytes total
21:40:19 <dP> Finished decompiling `Iron_Horse_2_Trains-2.64.0/iron-horse.grf` into directory `iron-horse`.
21:40:19 <dP> Action 0x00: 4116 times, 302022 bytes total
21:40:19 <dP> Action 0x01: 336 times, 5040 bytes total
21:40:19 <dP> Action 0x02: 42265 times, 1549141 bytes total
21:40:20 <dP> Action 0x03: 899 times, 18930 bytes total
21:40:20 <dP> Action 0x04: 10766 times, 474160 bytes total
21:40:22 <dP> Action 0x06: 1304 times, 21119 bytes total
21:40:22 <dP> Action 0x07: 577 times, 10386 bytes total
21:40:24 <dP> Action 0x08: 1 times, 52 bytes total
21:40:24 <dP> Action 0x09: 4640 times, 81615 bytes total
21:40:26 <dP> Action 0x0A: 1 times, 20 bytes total
21:40:26 <dP> Action 0x0B: 2 times, 249 bytes total
21:40:28 <dP> Action 0x0D: 10970 times, 194504 bytes total
21:40:28 <dP> Action 0x14: 1 times, 16603 bytes total
21:40:29 <petern> Just remove all random pixels, store the seed andy used to draw them.
21:40:30 <dP> Action 0xFD: 194522 times, 2528786 bytes total
21:40:30 <dP> Graphics action 0xFF: 194522 times, 33041027 bytes total
21:40:53 <TrueBrain> He is an AI after all, so we just need to add the algorithm
21:41:34 <glx[d]> dP: and it's using procedure, imagine the action 02 count before
21:42:01 <andythenorth> if only somebody would patch the game so duplicate sprites were removed
21:42:46 <TrueBrain> Why are there duplicated sprites? Explain to me like I am 5 Andy 🙂
21:42:47 <petern> At least you don't need all those reversed images for flipping.
21:42:51 <glx[d]> grf format supports duplicate reduction IIRC
21:42:57 <dP> not only nmlc, some of them have different offsets
21:43:10 <andythenorth> TrueBrain: pff, no idea
21:43:24 <andythenorth> it's generated code going to a compiler which generates more code
21:43:36 <glx[d]> most of duplicates is caused by nml syntax
21:44:08 <andythenorth> nml has substantial magic inside it
21:45:00 <dP> red frame - full duplicate, yellow - different offset
21:46:26 <petern> That smells of shorter-vehicle-flipping offset differences which are not needed any more.
21:46:48 <andythenorth> or a vertical shift by 1px
21:46:51 <andythenorth> which the containers do
21:46:56 <petern> Or all 8 directions when you only need 4.
21:47:01 <andythenorth> any of the above
21:47:11 <andythenorth> ok so this is lolz
21:47:25 <andythenorth> the dark blue wagons are dark blue because I set a parameter for it
21:47:36 <andythenorth> the pink wagons should be dark blue, but they are getting recoloured to CC 1
21:47:42 <andythenorth> this is genuinely funny
21:48:16 <andythenorth> probably I have something in sprite stack, there's a palette setting there
21:49:26 <andythenorth> they take the colour from the parameter if I change their config
21:49:35 <dP> Found 40299(40%) duplicate sprites, 6219407(37%) bytes total
21:49:35 <dP> Finished decompiling `iron-horse.grf` into directory `iron-horse`.
21:49:35 <dP> Action 0x00: 5230 times, 352070 bytes total
21:49:35 <dP> Action 0x01: 229 times, 3435 bytes total
21:49:36 <dP> Action 0x02: 29810 times, 1219393 bytes total
21:49:36 <dP> Action 0x03: 1189 times, 25020 bytes total
21:49:38 <dP> Action 0x04: 13629 times, 578810 bytes total
21:49:38 <dP> Action 0x06: 1534 times, 24769 bytes total
21:49:40 <dP> Action 0x07: 810 times, 14580 bytes total
21:49:40 <dP> Action 0x08: 1 times, 51 bytes total
21:49:42 <dP> Action 0x09: 4335 times, 75048 bytes total
21:49:42 <dP> Action 0x0A: 1 times, 20 bytes total
21:49:44 <dP> Action 0x0B: 2 times, 249 bytes total
21:49:44 <dP> Action 0x0D: 12412 times, 218520 bytes total
21:49:46 <dP> Action 0x14: 1 times, 16086 bytes total
21:49:46 <dP> Action 0xFD: 100175 times, 1302275 bytes total
21:49:48 <dP> Graphics action 0xFF: 100175 times, 16737920 bytes total
21:50:02 <dP> horse-to-switch ratio seems about the same xD
21:50:42 <petern> Oh, that was Horse 2!? Yeah, that would be flipping.
21:51:02 <andythenorth> it's shocking that we implemented a fix to cut duplicates, and duplicates were cut
21:51:19 <andythenorth> Colour me amazed
21:51:56 <andythenorth> depends on CC setting
21:52:06 <andythenorth> wonder why so many duplicated action 2
21:52:16 <andythenorth> well I kind of know why so many duplicated action 2
21:52:27 <glx[d]> generated code tends to do that
21:52:46 <andythenorth> I confess I didn't test 10701 yet 😛
21:52:54 <andythenorth> got excited making liveries
21:53:10 <andythenorth> wonder if nml will need patched
21:53:49 <petern> If it limits vehicle random bit usage to 8, yes.
21:56:26 <glx[d]> so yes limited to 8 I think
21:57:21 <glx[d]> ``` 'waiting_triggers' : {'var': 0x5F, 'start': 0, 'size': 8},
21:57:21 <glx[d]> 'random_bits' : {'var': 0x5F, 'start': 8, 'size': 8},```
21:57:55 <andythenorth> how will we patch it? 😛
21:58:26 <andythenorth> hmm this company colour thing is completely baffling 🙂
21:58:40 <petern> That's if you test with DeterministicSpriteGroup instead of RandomizedSpriteGroup.
21:58:48 <andythenorth> the returned result is *identical* in both cases, but one is derived from a parameter, and one is a constant
21:58:54 * andythenorth rabbit hole sorry
21:59:06 <andythenorth> who knows what nml is doing here
21:59:40 <glx[d]> ```vehicle_random_types = {
21:59:40 <glx[d]> "SELF": {"type": 0x80, "param": 0, "first_bit": 0, "num_bits": 8, "triggers": True},
21:59:40 <glx[d]> "PARENT": {"type": 0x83, "param": 0, "first_bit": 0, "num_bits": 8, "triggers": False},
21:59:40 <glx[d]> "TILE": {"type": 0x80, "param": 0, "first_bit": 0, "num_bits": 8, "triggers": False},
21:59:40 <glx[d]> "BACKWARD_SELF": {"type": 0x84, "param": 1, "first_bit": 0, "num_bits": 8, "triggers": False, "value": 0x00},
21:59:42 <glx[d]> "FORWARD_SELF": {"type": 0x84, "param": 1, "first_bit": 0, "num_bits": 8, "triggers": False, "value": 0x40},
21:59:42 <glx[d]> "BACKWARD_ENGINE": {"type": 0x84, "param": 1, "first_bit": 0, "num_bits": 8, "triggers": False, "value": 0x80},
21:59:44 <glx[d]> "BACKWARD_SAMEID": {"type": 0x84, "param": 1, "first_bit": 0, "num_bits": 8, "triggers": False, "value": 0xC0},
22:00:01 <andythenorth> ha I found my error 😄
22:00:31 <petern> Be interesting to see the random_bits definition for 0x5F for industries...
22:01:21 <glx[d]> 'random_bits' : {'var': 0x5F, 'start': 8, 'size': 8},
22:02:33 <glx[d]> ah no that's industry_tile
22:02:50 <glx[d]> 'random_bits' : {'var': 0x5F, 'start': 8, 'size': 16},
22:03:02 <glx[d]> for industry it's 16 bits
22:03:10 <petern> Industries have 32 random bits.
22:03:50 <petern> Where was I seeing 32 bits then.
22:06:55 <petern> Guess I saw that, but that is something else...
22:08:00 <petern> And the random bits of the industry itself are just called "random"
22:08:18 <glx[d]> 8F is production_rate_2 in nml
22:08:21 <petern> Well, maybe I should change 10701 to be 16 bits 🙂
22:08:52 <petern> In CBID_INDUSTRY_LOCATION it is these 32 random bits.
22:09:14 <petern> That callback has a different set of variables I think.
22:09:58 <glx[d]> ah probably in var10 and var18
22:10:24 <glx[d]> ah no, the industry doesn't exist yet
22:10:36 <glx[d]> so it get some stuff for 5F
22:12:19 <petern> Well anyway, with 10701 you get 32 bits, but only 24 available in 5F.
22:12:44 <petern> Maybe 16 is enough, to avoid setting precedents 😄
22:12:51 <petern> And also that'll half the savegame size...
22:29:20 <petern> Maybe if 8 isn't enough you should be using more variants 😉
22:37:22 <andythenorth> got 5 bits in use currently 😛
22:38:41 <andythenorth> I forsee tomorrow arriving soon
23:28:45 <petern> Hmm, so is there any example of act2 chains being measurably slow...
23:36:04 <JGR> On the whole is is not straightforward to measure the cost of individual action 2 chains
23:37:54 <JGR> Just about any non-trivial GRF written in NML will have very inefficient action2 chains though
23:39:06 <JGR> Even then it probably won't be "slow" because they're need not be executed that frequently
23:40:20 *** Wolf01 has quit IRC (Quit: Once again the world is quick to bury me.)
23:50:15 <dP> hm, these warnings in 10702 don't seem to check for frozen economy and control flags
23:57:09 <petern> Hmm, rerandomization is quite rare.
continue to next day ⏵
