IRC logs for #openttd on OFTC at 2020-06-04
⏴ go to previous day
00:48:36 *** WormnestAndroid has quit IRC
00:48:53 *** WormnestAndroid has joined #openttd
01:29:38 *** WormnestAndroid has quit IRC
01:30:25 *** WormnestAndroid has joined #openttd
02:22:21 *** Lejving has joined #openttd
08:13:41 *** sla_ro|master has joined #openttd
08:28:31 <DorpsGek_III> [OpenTTD/OpenTTD] techgeeknz opened pull request #8183: Codechange: Realign SDL driver with SDL2 driver to ease maintenance. https://git.io/JfX3D
08:30:54 <DorpsGek_III> [OpenTTD/OpenTTD] LordAro commented on pull request #8183: Codechange: Realign SDL driver with SDL2 driver to ease maintenance. https://git.io/JfX39
08:39:44 <DorpsGek_III> [OpenTTD/OpenTTD] techgeeknz opened pull request #8184: Cleanup: More code comment and doxygen fixes. https://git.io/JfXst
08:41:50 <DorpsGek_III> [OpenTTD/OpenTTD] techgeeknz commented on pull request #8183: Codechange: Realign SDL driver with SDL2 driver to ease maintenance. https://git.io/JfXsY
08:42:17 <DorpsGek_III> [OpenTTD/OpenTTD] LordAro commented on pull request #8184: Cleanup: More code comment and doxygen fixes. https://git.io/JfXsO
08:53:37 <DorpsGek_III> [OpenTTD/OpenTTD] techgeeknz updated pull request #8183: Codechange: Realign SDL driver with SDL2 driver to ease maintenance. https://git.io/JfX3D
08:55:44 <DorpsGek_III> [OpenTTD/OpenTTD] techgeeknz commented on pull request #8183: Codechange: Realign SDL driver with SDL2 driver to ease maintenance. https://git.io/JfXsP
09:00:30 <DorpsGek_III> [OpenTTD/OpenTTD] techgeeknz commented on pull request #8184: Cleanup: More code comment and doxygen fixes. https://git.io/JfXsN
09:04:25 <DorpsGek_III> [OpenTTD/OpenTTD] techgeeknz commented on pull request #8184: Cleanup: More code comment and doxygen fixes. https://git.io/JfXGq
09:13:55 <DorpsGek_III> [OpenTTD/OpenTTD] techgeeknz updated pull request #8183: Codechange: Realign SDL driver with SDL2 driver to ease maintenance. https://git.io/JfX3D
09:42:45 *** andythenorth has joined #openttd
09:48:34 <DorpsGek_III> [OpenTTD/OpenTTD] LordAro approved pull request #8183: Codechange: Realign SDL driver with SDL2 driver to ease maintenance. https://git.io/JfXZV
09:57:21 <DorpsGek_III> [OpenTTD/OpenTTD] techgeeknz commented on issue #8095: Feature suggestion: option to automatically space out vehicles in a shared order https://git.io/JfIUi
10:04:32 <DorpsGek_III> [OpenTTD/OpenTTD] andythenorth commented on pull request #8183: Codechange: Realign SDL driver with SDL2 driver to ease maintenance. https://git.io/JfXnq
10:05:24 <DorpsGek_III> [OpenTTD/OpenTTD] LordAro merged pull request #8183: Codechange: Realign SDL driver with SDL2 driver to ease maintenance. https://git.io/JfX3D
10:06:38 <DorpsGek_III> [OpenTTD/OpenTTD] LordAro approved pull request #8184: Cleanup: More code comment and doxygen fixes. https://git.io/JfXn3
10:16:53 *** gelignite has joined #openttd
10:59:44 <DorpsGek_III> [OpenTTD/OpenTTD] nielsmh commented on pull request #8184: Cleanup: More code comment and doxygen fixes. https://git.io/JfXcA
11:02:16 <DorpsGek_III> [OpenTTD/OpenTTD] techgeeknz commented on pull request #8183: Codechange: Realign SDL driver with SDL2 driver to ease maintenance. https://git.io/JfXCe
11:11:59 <DorpsGek_III> [OpenTTD/OpenTTD] techgeeknz commented on pull request #8184: Cleanup: More code comment and doxygen fixes. https://git.io/JfXC4
11:22:06 <DorpsGek_III> [OpenTTD/OpenTTD] techgeeknz dismissed a review for pull request #8184: Cleanup: More code comment and doxygen fixes. https://git.io/JfXn3
11:22:06 <DorpsGek_III> [OpenTTD/OpenTTD] techgeeknz updated pull request #8184: Cleanup: More code comment and doxygen fixes. https://git.io/JfXst
11:32:55 <DorpsGek_III> [OpenTTD/OpenTTD] techgeeknz updated pull request #8184: Cleanup: More code comment and doxygen fixes. https://git.io/JfXst
11:37:44 <DorpsGek_III> [OpenTTD/OpenTTD] techgeeknz updated pull request #8184: Cleanup: More code comment and doxygen fixes. https://git.io/JfXst
11:40:34 <DorpsGek_III> [OpenTTD/OpenTTD] techgeeknz updated pull request #8184: Cleanup: More code comment and doxygen fixes. https://git.io/JfXst
11:43:10 <DorpsGek_III> [OpenTTD/OpenTTD] techgeeknz commented on pull request #8184: Cleanup: More code comment and doxygen fixes. https://git.io/JfXWQ
11:47:41 *** WormnestAndroid has quit IRC
11:48:03 *** WormnestAndroid has joined #openttd
11:51:03 <DorpsGek_III> [OpenTTD/OpenTTD] techgeeknz updated pull request #8184: Cleanup: More code comment and doxygen fixes. https://git.io/JfXst
11:53:51 <DorpsGek_III> [OpenTTD/OpenTTD] techgeeknz opened pull request #8185: Cleanup: StationCargoList::AreMergable doxygen comment references Veh… https://git.io/JfXlC
12:23:21 *** johanna[m] has joined #openttd
12:55:05 <DorpsGek_III> [OpenTTD/OpenTTD] techgeeknz updated pull request #8185: Cleanup: StationCargoList::AreMergable doxygen comment references Veh… https://git.io/JfXlC
12:57:16 <DorpsGek_III> [OpenTTD/OpenTTD] techgeeknz updated pull request #8185: Cleanup: StationCargoList::AreMergable doxygen comment references Veh… https://git.io/JfXlC
13:02:05 <DorpsGek_III> [OpenTTD/OpenTTD] techgeeknz updated pull request #8185: Cleanup: StationCargoList::AreMergable doxygen comment references Veh… https://git.io/JfXlC
13:02:23 <DorpsGek_III> [OpenTTD/OpenTTD] techgeeknz updated pull request #8185: Cleanup: StationCargoList::AreMergable doxygen comment references Veh… https://git.io/JfXlC
13:07:55 <DorpsGek_III> [OpenTTD/OpenTTD] techgeeknz updated pull request #8185: Cleanup: StationCargoList::AreMergable doxygen comment references Veh… https://git.io/JfXlC
13:25:58 <FLHerne> LordAro: Pity about the spam though :p
14:06:58 *** gelignite has joined #openttd
14:20:29 <Borg> why in YAPF there is waiting for cheaper path... when more expensive one is clear to go? what is rationale for this?
14:30:24 <Guest26686> occopied track does not make the path unavailable, just slightly more expensive. Thus occupied vs detour is a trade-off which flips for a length of detour in favour of one or the other
14:31:05 <andythenorth> can't change the GS on a running game
14:32:50 <Guest26686> because reasoning similar to NewGRF iirc?
14:33:39 <andythenorth> GS can't store anything in the map afaik
14:34:09 <andythenorth> all GS data has to be serialised / deserialised on saveload
14:34:18 <andythenorth> (is why I assume that)
14:34:37 <andythenorth> seems to me that swapping the GS out should be trivial
14:34:52 <andythenorth> 'seems to me' are the dangerous words of the ill-informed :P
14:37:54 <FLHerne> Borg: A path being occupied is just a cost like the others
14:37:57 *** Guest26686 is now known as planetmaker
14:38:24 <FLHerne> It'll take a longer path if the shortest one is occupied, up to a point
14:39:01 <FLHerne> If that cost was too high, you'd have trains veering off on enormous detours instead of waiting a couple of seconds
14:40:36 <planetmaker> and the point to see there is: the path finder does not know anything about how permanent or temporary an obstacle is
14:57:01 <cawfee> can someone explain me, why i cant buy any train? new train, i see only trailer
14:58:17 <Borg> FLHerne: can I unflence that cost somehow? is there a setting?
14:59:07 <Borg> FLHerne: thats is preffered... go make detour.. instead block a whole queue..
15:01:45 <LordAro> cawfee: what date is it in game? trains expire in later game (wagons don't because of historical reasons)
15:02:07 <LordAro> Borg: there are lots of hidden pathfinder settings in the config file
15:05:37 <LordAro> cawfee: yeah, that's a bit late for standard trains :)
15:05:49 <LordAro> monorail & maglev might still be available, i can't recall
15:06:44 <cawfee> Argh! yes i see now ive found the electric rails
15:07:41 <Borg> okey, lets do RTFS then again..
15:12:45 <Borg> okey.. for stations.. it might be rail_lastred_penalty
15:15:06 <Borg> for normal tracks.. it might be rail_pbs_cross_penalty
15:28:25 <Borg> still doing stupid thing ;)
15:29:39 <Borg> okey.. rail_pbs_cross_penlaty 1000
15:29:47 <Borg> does it job... I wonder if there will be some side effects
15:35:26 <Borg> so far. seems to works..
15:39:05 <Borg> okey.. this is nice.. thet stopped doing stupid things.. like waiting for path to clear to empty platform.. where they have other platform empty (higher cost).. but path is clear..
15:39:13 <Borg> now they just happily go there..
15:45:41 <LordAro> Borg: that sounds suspiciously like you'd fiddled with your settings previously
15:45:49 <LordAro> trains definitely go to free platforms normally
15:46:16 <planetmaker> or... incompatible track types somewhere like a missing wire
15:46:42 <LordAro> planetmaker: presumably not if changing pathfinder settings changes behaviour
15:47:02 <planetmaker> you're right there :) I only read-back 2 lines :P
15:49:17 <Borg> LordAro: of course I fiddled w/ settings previously.. and im optimizing stuff even futher...
15:49:33 <Borg> I use PBS back singal as priority.. to have primary and auxialiary paths
15:49:57 <Borg> and stuff works very good... I just noticed.. that near stations trains sometimes were doing kinda stupid thing.. like waiting.
15:50:14 <LordAro> i'd highly recommend resetting your pathfinder settings to defaults then
15:50:51 <FLHerne> Borg: "waiting for path to clear to empty platform.. where they have other platform empty" sounds like it might be a different problem
15:50:55 <Borg> I will play w/ new settings now.. few days. to see if I will spot some oddities.. for now.. none spotted
15:51:13 <Borg> FLHerne: maybe I will do a screen shot.. to show setup ok? hold on a few secs
15:52:28 <FLHerne> Borg: Basically, if a train has cleared the end of a platform, but is still in the block, the pathfinder sees that platform as "clear" even if it can't be signalled into it
15:52:42 <Borg> as you can see... 4th platform is shared one.. w/ PBS back signals
15:52:43 <FLHerne> s/a train/a train in front/
15:53:55 <FLHerne> IME, that setup should work with the default pf settings
15:53:57 <Borg> now.. when first platform was clear.. and there was train on intersection moving into 2nd platform.. and I had train as well coming from 2nd track to 4th platform.. it just stopped there.. waiting for first train to clear path to 1st station.. instead moving to 4th platform.. with have cost +1500 compared to first
15:54:52 <Borg> FLHerne: it didnt.. because AFAIR.. with default settings.. PBS back signal penalty was too high.. and alt paths were basicaly never selected.. or very rary..
15:55:03 <Borg> I use PBS back signals on tracks as well
15:56:19 <Borg> I want smooth balancing.. but if both tracks are empty.. primary needs to be always choosed... not aux..
15:56:34 <FLHerne> That's odd, I use bidi PBS signals in similar situations all the time, and I very rarely see issues like that
15:57:07 <Borg> FLHerne: on stations? or on regular paths as well?
15:58:18 <planetmaker> FLHerne, he changed the non-UI pathfinder settings... so normal experience logic might not apply at all
15:58:27 <Borg> 2 long bridges ... a bit up. there is back pbs signal
16:00:16 <Borg> how I can reset stuff? manualy? adjust all penalities to default?
16:01:20 *** Speeder_ has joined #openttd
16:01:37 <Borg> can anyone give me... p0,p1,p2, pbs_signal_back defaults?
16:01:47 <FLHerne> Or openttd -c test.cfg
16:01:52 <LordAro> just delete them from your config
16:02:02 <planetmaker> quit openttd. move openttd.cfg to a different name. start openttd and quit again
16:02:04 <Borg> arent that settings stored in save?
16:02:08 <planetmaker> now oyu have your old and a default
16:02:28 <LordAro> there you go, 3 separate solutions :)
16:02:31 <planetmaker> they are. But the log only has the changes wrt when it was created. Which is a list of length 0
16:02:45 <Borg> lets see if I have backups .ini..
16:09:10 <Borg> yep... they do stupid things at station again
16:09:47 <Borg> but its ok? whats the problem? the settings there are here to tweak.. right?
16:09:57 <Borg> maybe 95% of players are happy w/ them..
16:10:44 <Borg> im supprised tho.. that the track w/ PBS back signal is selected tho.. but maybe because I already had tweaked settings months ago. when I was starting experimenting w/ PBS back signal
16:11:40 <LordAro> i'd say 99.9% of players are happy with them
16:13:28 <Borg> okey.. back to my settings then..
16:21:04 <happpy> hi i got a question about the new openttd is this the writing irc channel?
16:21:30 <planetmaker> openttd does not support natively to write anywhere else than ingame chat
16:22:02 <LordAro> planetmaker: i think that was supposed to be 'right'
16:22:18 <LordAro> happpy: this is the channel for talking about OpenTTD things, yes
16:22:36 <happpy> y has the new openttd not fixs the problem on mac
16:23:16 <LordAro> is this the problem on 10.12 ?
16:23:58 <LordAro> basically, because no one here has a machine old enough to reproduce the issue
16:24:16 <LordAro> and as yet we've not had any offers of help from people who know how to debug such a weird issue
16:24:20 <planetmaker> he, ok. I totally mis-understood the question. Sorry. Yes, this is the channel to talk about OpenTTD. Of course
16:24:44 <LordAro> happpy: as far as i know, you should be able to to upgrade to 10.13 (or newer) with relative ease
16:24:51 <Borg> happpy: is openttd 1.8.0 works better? compared to newer versions?
16:25:20 <FLHerne> Borg: Everything up to 1.10.0-RC1 should be fine
16:25:39 <LordAro> Borg: this is not the speed issue
16:25:42 <happpy> its not for me a player on openttdcoop discord got mac problem
16:26:55 <Borg> LordAro: I dunno what the issue is at all :) just curious.... because I saw forums posts about it..
16:27:15 <Borg> I for example.. still on 1.8.0 and im happy with it... my choice..
16:28:22 <LordAro> see previous as to why it's not been fixed
16:28:53 <LordAro> wait, that's where you got the screenshot
16:29:44 <happpy> IvanLeshev used a mac to play openttd but he can not
16:30:32 <LordAro> happpy: options 1) learn deep knowledge of MacOS' internals, and fix the issue for us (we can't, and have little desire to support an out of support OS) 2) tell the user to upgrade to 10.13+ 3) Play on 1.10.0-RC1 or below
16:30:54 <LordAro> i'm not sure there's any more to discuss here
16:30:56 <andythenorth> mac support is current -2 yes/no?
16:31:13 <LordAro> Borg: the speed issue was fixed, and as long as you're not on 10.12, it should run as expected
16:31:23 <LordAro> andythenorth: in theory we still support 10.9 in the code
16:31:51 <LordAro> nielsm's laptop is "only" 10.13
16:32:05 <Borg> LordAro: Im on Windows :) so.... its not my stuff.. I just dont get why people always want to newest... bestest... etc.. especially.. when they use outdated SW/HW..
16:32:26 <Borg> just use whatever works.. or as you said.. learn stuff. and send patches..
16:32:42 <LordAro> Borg: well you're just being stubborn for no reason then
16:32:53 <Borg> I know I know.. its just me..
16:33:12 *** arikover has joined #openttd
16:33:38 <happpy> but if you had the bug log about the mac problem
16:35:58 <LordAro> happpy: probably not, the crash log hasn't been helpful in this case
16:38:04 <happpy> ok will i hop its get fixs soon
17:11:41 *** Wormnest has joined #openttd
18:09:53 *** virtualrandomnumber has joined #openttd
18:56:16 <_dp_> happpy, it's not a bug, it's a debug feature
18:57:02 <_dp_> can be disabled somewhere in help menu iirc
18:57:24 <DorpsGek_III> [OpenTTD/OpenTTD] glx22 dismissed a review for pull request #7270: Introduce CMake (and removing all other project-related code) https://git.io/JfPbN
18:57:24 <DorpsGek_III> [OpenTTD/OpenTTD] glx22 updated pull request #7270: Introduce CMake (and removing all other project-related code) https://git.io/fhbqc
18:59:18 <happpy> will thinks of the info
18:59:49 <DorpsGek_III> [OpenTTD/OpenTTD] glx22 commented on pull request #7270: Introduce CMake (and removing all other project-related code) https://git.io/JfXi4
19:04:18 *** mindlesstux6662 has quit IRC
19:04:42 *** mindlesstux6662 has joined #openttd
19:23:51 <andythenorth> supermop_Home_ did you have time to break Horse yet?
19:24:17 <glx> andythenorth: #156 should fix your issue
19:29:36 *** frosch123 has joined #openttd
19:32:14 <andythenorth> glx thanks, seems to work :)
19:32:56 <Afdal> Hey guise, a thought occurs to me: has anyone ever considered making some tweaks to the company rating system to making it more interesting and competitive?
19:33:12 <Afdal> I'm a little surprised that someone hasn't made a patch
19:33:50 <DorpsGek_III> [OpenTTD/nml] andythenorth commented on pull request #156: Fix: Procedure calls reference counting https://git.io/JfXPD
19:34:24 <Afdal> would a game script mean you could simply make it as a newgrf
19:34:27 <andythenorth> glx probably needs a review from someone smarter than me?
19:35:24 <FLHerne> Afdal: Gamescripts and NewGRFs are different things
19:35:37 <FLHerne> You can rate companies with a GS, but not a grf
19:36:00 <Afdal> Why do I feel so unfamiliar with game scripts
19:36:04 <Afdal> is this a relatively new feature?
19:36:24 <FLHerne> So, relative to grfs, but not particularly
19:36:49 <andythenorth> so should I release new Iron Horse?
19:37:07 <FLHerne> It's basically the same Squirrel interface as AIs, but not attached to a company
19:37:25 <andythenorth> it has this mimick of var 41 with 24448 checks of var 61 per vehicle
19:37:39 <FLHerne> And it can create goals, pay companies for achieving targets, etc.
19:37:43 <andythenorth> frosch123 ^ is 25k checks of var 61 per vehicle unwise in graphics chain?
19:38:07 <supermop_Home_> andy i got distracted building a steel chain to fund my emus
19:38:08 <andythenorth> doesn't seem to have any noticeable performance impact in the mac client
19:39:35 <FLHerne> (with links to forum threads)
19:39:36 <Afdal> Yeah I'm lookin at them now
19:39:40 <Afdal> I should use game scripts more often
19:40:10 <supermop_Home_> then i started making a screen for t shirts
19:40:15 <frosch123> andythenorth: ofc it is unwise. how many variables does a normal vehicle use? newgrf have a significant impact on performance. by making the switch more complex, you lower the total amount of usable vehicles in game
19:41:18 <andythenorth> I can reduce it by a factor of 16, if I can figure out the syntax for STORE_TEMP with var 61 result
19:41:25 <andythenorth> currently I have failed to make that work
19:42:01 <andythenorth> I can reduce it by factor 7 by rewriting my code to cache some results earlier in the chain
19:42:04 <glx> STORE_TEMP(expression, reg) should work
19:48:17 <andythenorth> I was wearing clown shoes
19:48:30 <andythenorth> I was attempting to use STORE_TEMP([STORE_TEMP(-1, 0x10F), var[0x61, 0, 0x0000FFFF, 0xC6]], 0)
19:48:57 <andythenorth> [STORE_TEMP(-1, 0x10F), STORE_TEMP(var[0x61, 0, 0x0000FFFF, 0xC6], 0)] should be fine
19:49:16 <glx> I think both work in theory
19:49:41 <andythenorth> hmm, compiles, but wrong results
19:49:44 <andythenorth> probably my mistake
19:50:32 *** virtualrandomnumber has quit IRC
19:51:26 <glx> anyway you can always check the nfo to ensure it's correct
19:52:18 <andythenorth> that's nice trolling :)
19:52:25 <andythenorth> I haven't read that much raw nfo for some years :)
19:53:26 <glx> but nml usually doesn't put enough comments so it's not easy to check the output
19:55:37 <glx> anyway reading an action 2 is not that hard
19:56:03 <andythenorth> does STORE_TEMP() return any value in any circumstance to an expression? (I'm not expecting it to)
19:56:56 <glx> it's a /2s so 0E \2s or \2sto [1] var7D[val2] = val1, result = val1
19:57:55 <glx> so STORE_TEMP(1,x)+1 stores 1 and return 2
19:58:56 <glx> but I think [] syntax uses \2r for each element
19:59:11 <glx> discarding the previous result
20:03:50 <andythenorth> and I expect register 0 to contain the value of var 61 for a specific vehicle offset (last switch)
20:04:43 * andythenorth wonders how to debug temp registers :P
20:04:50 <andythenorth> perm storage in industries is readable
20:17:34 <supermop_Home_> andythenorth curfew isn't til 20:00
20:28:50 *** ChanServ sets mode: +o planetmaker
20:28:50 *** ChanServ sets mode: +v orudge
21:10:22 <glx> andythenorth: what doesn't work ?
21:11:11 <glx> because it looks like they should do the same
21:13:04 *** Progman has joined #openttd
21:15:21 <andythenorth> they're returning different results
21:15:34 <andythenorth> there's no trivial way to inspect the registers as far as I know?
21:15:53 <andythenorth> is there some stupid oversight in my nml?
21:16:23 <glx> well switch_alt_var_41_position_in_vehid_chain_multiple_ids_127 always return 126 in both case I think
21:17:05 <andythenorth> there's a 126 other similar switches before that :P
21:17:15 <andythenorth> all the same in both versions
21:17:50 <glx> and all the == are useless to me
21:19:12 <andythenorth> maybe register 0 is over-written by something else
21:20:22 <andythenorth> reading a register doesn't clear it afaik
21:20:31 *** arikover` has joined #openttd
21:22:29 <andythenorth> quite puzzling :)
21:22:36 <glx> switch_alt_var_41_match_ids_15 overwrites register 0
21:23:54 <glx> ah no I clearly don't follow your code
21:24:25 <frosch123> is there a paste with the nfo?
21:25:05 <glx> yeah the nfo would help a lot
21:25:39 <glx> because nml wise they do the same
21:26:36 <glx> anyway to me switch_alt_var_41_match_ids() returns 0 or 1, but the result is not used
21:29:33 <glx> so basically a waste of cpu just to return 126 anyway ;)
21:36:41 <andythenorth> I considered optimising away the last switch in the chain
21:37:23 <glx> last switch could have a single "return;"
21:37:49 <glx> but I don't see what all the checks are for
21:38:02 <andythenorth> hang on I'll paste more
21:38:05 <glx> if you just ignore the result
21:40:12 <glx> ha yes it makes more sense :)
21:40:36 <andythenorth> to be clear also, this code works if I read var 61 16 times
21:40:47 <andythenorth> just not when I try to make it more efficient at run time :)
21:42:07 <glx> so yes nfo for switch_alt_var_41_match_ids may help
21:42:43 <glx> because that's the probable failing point if you get a different result
21:42:51 <andythenorth> oh the nfo is commented :D
21:43:27 <glx> it's not fully commented but at least you can find the switches easily :)
21:43:35 <andythenorth> switch_alt_var_41_match_ids_15
21:44:36 <andythenorth> wow I can almost read this nfo
21:44:50 <andythenorth> in some ways nfo is much easier than nml
21:47:19 <andythenorth> why is switch_alt_var_41_match_ids_0 doing \2sto
21:50:18 <glx> it's load(1), store in 82, load(0), compare with 82
21:57:08 <andythenorth> I've tried it with different register numbers that are definitely unused elsewhere
21:57:34 <andythenorth> in case this code works, but trashes a register needed by some other switch
21:58:11 <frosch123> 1 + switch_alt_var_41_position_in_vehid_chain_multiple_ids() + switch_alt_var_41_position_in_vehid_chain_from_end_multiple_ids(); <- does the evaluation order matter there?
21:58:29 <frosch123> nml reverses them so, if the second procedure relies on registers from the first, it fails
21:59:19 <andythenorth> they _shouldn't_ rely on each other, although that fact is also worth knowing
22:00:40 <andythenorth> does LOAD_TEMP ever need a mask or shift?
22:01:00 <frosch123> i think register 82 is destroyed
22:01:03 <glx> no it just reads the value as it's stored
22:01:28 <frosch123> the 1 + proc + proc uses it
22:01:33 <glx> reg 82 is temporary to each switch_alt_var_41_match_ids_XX
22:01:34 <frosch123> but at least one of the procs also uses it
22:02:29 <frosch123> so the result of ..._from_end... is lost?
22:02:29 <glx> and I think #156 properly notice it
22:03:05 <andythenorth> hmm I have a new interesting result
22:03:30 <andythenorth> this might be compound issues
22:03:36 <glx> are you using #156 andythenorth ?
22:03:58 <andythenorth> ha ha ok I've got a _partial_ repro
22:04:09 <andythenorth> there are 16 registers, to hold up to 16 vehicle IDs
22:04:47 <andythenorth> to prevent unwanted ID collisions I set -1 to any spare registers that aren't actually required to hold a vehicle ID
22:05:10 <glx> I think at some point a reference is not marked as proc
22:06:07 <andythenorth> changing the -1 to a positive value gets a less broken result
22:06:11 <andythenorth> still broken, but less broken
22:06:30 <glx> the issue is reg 82 overwrite
22:06:30 <andythenorth> so comparing var 61 to -1 works
22:06:55 <andythenorth> ok so the -1 thing is just some side effect?
22:08:57 <glx> (switch_alt_var_41_position_in_vehid_chain_multiple_ids + 1) + switch_alt_var_41_position_in_vehid_chain_from_end_multiple_ids is basically (switch_alt_var_41_position_in_vehid_chain_multiple_ids + 1) + last_checked_id
22:09:10 <andythenorth> is this something that _should_ work, or am I just pushing nml too far? :)
22:09:16 <glx> because 82 is overwritten
22:09:30 <glx> it should work, but there's a bug in nml
22:09:43 <andythenorth> well this is fun
22:09:46 <glx> switch_alt_var_41_match_ids_XX should not reuse 82
22:10:03 <glx> some references are just improperly marked
22:10:45 <andythenorth> this silly feature has been quite useful for finding bugs :)
22:10:55 <andythenorth> also I can test procedure params with it
22:11:30 <glx> params are broken for now because #156 is not included yet :)
22:12:06 <andythenorth> procedures are proving so useful
22:12:22 <andythenorth> takes a bit of thinking about what needs putting in registers
22:12:25 <glx> but I'll try your reduced test case gist, it should show the bug
22:12:35 <DorpsGek_III> [OpenTTD/OpenTTD] nielsmh approved pull request #7270: Introduce CMake (and removing all other project-related code) https://git.io/JfX9v
22:12:54 <andythenorth> store_temp_var_61_result branch in Iron Horse also
22:13:40 <andythenorth> once params are in, I can use a stored procedure to set all the registers for a chain in one go, without repeating code per vehicle. So helpful
22:15:11 <glx> oh of course trying to plug the test case in FEAT_INDUSTRY won't work
22:15:26 <andythenorth> hmm if we had vehicle perm storage, I could run this switch chain once in depot and store the result
22:15:54 <andythenorth> if we had vehicle perm storage, and I could read it with var 61, the switch chain might be even simpler :P
22:18:07 <andythenorth> or I could just use bitmask_vehicle_info, how big is it? 256 unique values?
22:19:20 <glx> ok confirmed the issue, the register is reused while it should not
23:25:59 *** gelignite has joined #openttd
continue to next day ⏵
