IRC logs for #openttd on OFTC at 2024-10-04
β΄ go to previous day
00:06:34 <_glx_> aviationgamerx: looking at build logs, it seems to be regression test
00:07:32 <_glx_> so you should be able to test and fix locally
00:59:33 *** Wormnest has quit IRC (Quit: Leaving)
01:27:42 <aviationgamerx> _glx_: regression test?
01:30:20 <_glx_> it's done via ctest, under test menu in VS
01:42:51 <_glx_> when test fails you'll get regression_regression_output.txt in build dir, you can compare it to regression/regression/result.txt in source dir
01:43:47 <_glx_> if the changes are expected (and look correct) you then can overwrite result.txt with the new output
02:11:14 *** gnu_jj_ has quit IRC (Ping timeout: 480 seconds)
02:22:39 *** debdog has quit IRC (Ping timeout: 480 seconds)
02:31:56 <locosage> peter1138: hey, I've had a few prs :p
02:32:07 <locosage> sometimes it's a good place for things vanilla rejected/ignored
03:28:47 <locosage> ian01223: it's harder than it looks because hotkeys.cfg only handles key press events, for map movement you need key up/down
06:18:47 <andythenorth> think I'm going to delete all translations from grfs
06:21:53 <_pruple> I think I had some translations in older ones, but not recently
06:23:13 <andythenorth> they're pretty much a guilt hole, with bonus infosec risk
06:24:06 <_pruple> And you're GPL, so if people want to make translated versions, they can π
06:32:58 <wensimehrp> andythenorth: Won't you accept new ones? π¨
06:33:18 <andythenorth> I'm considering my options
06:33:32 <andythenorth> translations are a pain in the arse
06:33:46 <andythenorth> when we had web translator it was ok
06:34:46 <andythenorth> I'll list the problems
06:36:02 <andythenorth> 1. translations are a security risk, I have to read the diff every time, and I can't be sure if there's e.g. something that will cause an RCE due to overflow, and this is particularly tricky with non-roman glyphs
06:36:52 <andythenorth> 2. I have no idea if someone is just translating every string to 'cocks' in a language I can't read
06:37:12 <andythenorth> 3. many translators are incapable of learning how to github
06:37:22 <andythenorth> 4. many translators are incapable of learning TOML
06:37:38 <andythenorth> 5. many translators are hard to understand in communication
06:37:52 <andythenorth> 6. I have to be grateful to translators
06:38:17 <andythenorth> 7. changes in the grf mean I often have to delete existing translation strings
06:39:56 <wensimehrp> andythenorth: π€ͺ FIRS Simplified Chinese setting strings are already unreadable. Last translator just used machine translation service
06:41:28 <andythenorth> and then translators donate funds to get their language supported
06:41:43 <wensimehrp> andythenorth: Wtf no
06:44:55 <andythenorth> Bananas -> decompile grf -> insert translations -> recompile
06:45:03 <andythenorth> Do it all in a lambda
06:45:17 *** Flygon has quit IRC (Remote host closed the connection)
06:51:01 <wensimehrp> andythenorth: Sounds like you've already dealt with a thousand of them π
06:55:15 <ahyangyi> andythenorth: To be honest, it would be a feat to translate the many different things to "cocks" and be not obvious. I wonder how many different ways to say "cock" are needed to achieve that.
06:58:57 *** tabytac has joined #openttd
06:58:57 <tabytac> ian01223: btw if you still want to use WASD for camera movement. I have an AutoHotkey script ive been using for years now to toggle wasd with the capslock key. It needs autohotkey v2 to work but its great imo
07:50:39 <peter1138> Putting translations into the binary NewGRF format is not ideal.
07:55:37 <LordAro> when people decide they want to keep a feature in its broken state i'm tempted to just remove it entirely
07:59:45 <_pruple> lng files for newgrf then, let's go...
08:00:36 <truebrain> LordAro: lalalala, "shares", lalalala π (in other words: I agree with you π )
08:01:54 <truebrain> so "Remove: inflation" next? π
08:02:54 <_pruple> I thought we already did that? defaults to off, anyway. π
08:03:13 <LordAro> defaulting something to off is basically deprecation
08:05:25 <truebrain> the survey says .... 80.6%
08:05:39 <truebrain> ofc we didn't reset the setting, so 19.4% might well be "people who played before" π
08:06:21 <truebrain> funny, 51% of the people do not play OpenTTD via Steam
08:06:28 <truebrain> which means we have a much larger audiance than I expected
08:06:30 <truebrain> (according to survey)
08:06:32 <peter1138> Inflation isn't broken, just misunderstood.
08:07:51 <truebrain> and wow, 10% of the players are MacOS, last week
08:08:15 <truebrain> did not expect that, tbh
08:08:23 <truebrain> day full of unexpected things
08:09:34 <LordAro> does that account for playtime?
08:19:14 *** mindlesstux has joined #openttd
08:24:05 <LordAro> (the response is also perfectly justified)
08:28:24 <andythenorth> LordAro: "no comment"
08:28:56 <andythenorth> do we have a survey cross-tab? π
08:29:00 <andythenorth> Horse users vs. inflation users?
08:30:40 <truebrain> LordAro: The survey only takes into account playtime. Amount of seconds the game has been active since it was last transmitted. So it should correct for people creating a lot of small games, and/or a single user π
08:31:09 <LordAro> i knew it did that for the overall usage, didn't know whether it did it for all the others as well
08:31:32 <truebrain> all stats, except for savegame size, works like that π
08:32:12 <truebrain> I stil hope it makes for a fair estimation π But I am not a statisian
08:34:07 <ahyangyi> andythenorth: What makes Horse uninflatable?
08:37:25 <xarick> `std::abs` or `abs` - what is the consensus?
08:37:56 <reldred> ahyangyi: Horses base costs already simulate it.
08:38:23 <reldred> Plus inflation maths is based on 1950-2050, if you start earlier it gets ridiculous in later years
08:39:44 <reldred> I had a brief look at the inflation code when I was playing with economic event freq scaling and I just noped the hell away from it
08:43:14 <_pruple> reldred: this changed ~4 years ago? Inflation is now applied from 1920 to 2090, regardless of start date.
08:43:44 <_pruple> it's still broken and dumb, just less broken and dumb.
08:43:50 <reldred> _pruple: Shows how much attention Iβve been paying!
08:43:53 <andythenorth> ahyangyi: players
08:43:57 <truebrain> _pruple: "explainable" and dumb π
08:44:12 <andythenorth> I had enough of hearing that Horse had umanageable costs
08:44:31 <andythenorth> and schadenfreude as I once lodged the same report to OzTrans about CanSet
08:44:39 <andythenorth> due to inflation
08:45:09 <reldred> Horse running costs can be a little spicy but JGRPP has some tools to manage things at least in bigmap games.
08:46:19 <andythenorth> I suspect the problem is FIRS not Horse
08:46:54 <reldred> Possibly. I only play firs or axis
08:47:13 <reldred> And I play on bigger maps than you do.
08:48:27 <reldred> And I play with very very sparse towns and industries
08:58:26 <truebrain> that is something you don't see a lot
09:00:24 <peter1138> Tabs? In my code? How are you!
09:02:02 <johnfranklin> Is there is a typo missing d?
09:02:22 <LordAro> peter1138: i'm fine, how are you?
09:02:31 <xarick> when will `abs` to `std::abs` gonna be done?
09:02:51 <LordAro> xarick: it's the same function
09:02:56 <LordAro> but new stuff should use std::abs
09:03:10 <peter1138> It's a good job I can't easily post images to the forums.
09:07:31 *** Smedles_ has joined #openttd
09:10:35 *** Smedles has quit IRC (Ping timeout: 480 seconds)
09:10:39 *** Smedles_ has quit IRC (Read error: Connection reset by peer)
09:11:03 *** Smedles has joined #openttd
09:13:38 <_pruple> there's perhaps a case for not changing the default cargos or vehicles at all, and just defining the bits for newgrf use - in which case, there's no changes to the game required at all.
09:17:27 <peter1138> I can make a modification that tests if those the bits on load.
09:18:00 <peter1138> But loading all the NewGRFs manually takes some time π
09:56:49 *** D-HUND is now known as debdog
10:12:34 <xarick> i wish savegaming was multithreaded
10:12:46 <xarick> creating a 4k save in debug mode takes 5 minutes or so
10:13:08 <xarick> only using 12.5% of cpu
10:14:08 <LordAro> let me guess, you have 8 cores
10:14:12 <truebrain> _jgr_: I am working on quartily survey reports. For 14.X series I just say: it is very likely the whole of 14.X has the same settings, so I can just merge those results. So whether it is 14.1 or 14.2, they will become "14".
10:14:12 <truebrain> But for JGRPP, can I do something similar there? Collapse "0.58.0" to "0.58"?
10:14:28 <truebrain> or I guess I can just do "jgrpp", but that also feels a bit tricky
10:28:41 <_jgr_> truebrain: Yes that's no problem. Happy for you to aggregate it how you think it works best.
10:29:02 <truebrain> but I ran out of my own ideas on what works best! Looking for input π
10:30:03 <_jgr_> How a high level summary comparing with 14.x, aggregating all the jgrpp releases together ought to be fine.
10:30:29 <_jgr_> I doubt that there's that much difference in settings between 0.58 and 0.59 for example (except for new settings)
10:30:47 <LordAro> not like there's much difference between 13 & 14 either :p
10:31:12 <truebrain> both are fair arguments; okay, `jgrpp` it is
10:48:45 <_pruple> appears to affect other right to left languages too
10:52:40 <truebrain> Git blame ratting you out
11:08:38 <kuhnovic> Don't you love it when someone writes unit tests so f#$%^@& convoluted that you end up spending hours fixing the test setup instead of the actual functionality / tests
11:11:12 <truebrain> Haha, I know that pain
11:16:21 <andythenorth> kuhnovic: Industry fallacies #3893: the same developers who need to write unit tests to catch their imperfect codeβ¦can write perfect tests
11:17:41 <kuhnovic> No offense Xarick, your tests are not that good π
11:18:12 <kuhnovic> But to your credit, you have found lots of issues with them, so I am glad you do them
11:18:24 <kuhnovic> Keeps me off the street
11:21:29 <xarick> speaking of bad tests, i just detected an issue with my track3 test
11:22:06 <xarick> it's again the binaryheap tie breaking stuff... it's hard to get around these
11:22:33 <xarick> I want to ignore them, but I also want not to
11:28:26 <xarick> without tie-breaker on the left, with tie-breaker on the right
11:31:04 <xarick> the depot is 6 regions away, sometimes the intermediate region is a straight "I", sometimes it's a "L", that influences where to llpf
11:31:44 <xarick> llpf returns different costs, different tracks
11:31:55 <xarick> but it's a false positive
11:33:46 <xarick> from a hlpf perspective, the cost is the same though
11:39:26 <kuhnovic> Still focusing on the wrong things I see
12:03:01 <_glx_> Only reason I could find looking at the lexer
12:18:14 <xarick> who's the frame rate expert here?
12:18:52 <xarick> CheckIf"insertvehicletype"NeedsServicing is not being accounted for "vehicletype" metric
12:23:05 <ian01223> tabytac: ooh I saw version one of this on that forum thread but didn't have toggling
12:23:16 <ian01223> the only problem is that my caps lock key doesn't work
12:23:17 <kuhnovic> I'd first worry about fixing your issue, and only about performance issues if you see them
12:23:25 <ian01223> so I'll have to change it, but I can do that
12:25:59 <ian01223> i'll probably bind it to one of the function keys
12:29:10 <ian01223> locosage: I'm so used to modern game engines where this is like 3 clicks of adding a key up and key down function...
12:30:15 <ian01223> from the GUI it of course has
12:32:34 <xarick> should I move performance accumulator to before RunEconomyVehicleDayProc()? This is the function that runs CheckIf"Vehicle"NeedsServicing
12:33:59 <xarick> but then it's gonna include stations into vehicle...
12:38:45 <ian01223> still though, that doesn't seem that compl- oh no I'm not falling into this trap again
12:40:56 <ian01223> isn't that the same as just checking if a key is pressed down right now, though?
12:42:02 <ian01223> and in any case, that logic is already implemented, it's just what key that's being used that's being changed
12:43:40 <ian01223> I mean, I don't actually know what said logic even looks like, and I've taken a cursory look at the viewport logic
12:45:38 <Borg> anyone can point me to a file where this stuff is processed?
12:46:42 <Borg> okey thanks.. found sth...
12:49:08 <truebrain> `We received surveys for a total of 511925 hours of games played, over a total of 185496 games. This is an average of 2.76 hours per game. `
12:50:26 <peter1138> ian01223: The hitjey system only deals with "Key pressed", viewport scrolling is handled completely differently and has no knowledge of configurable keys
12:51:58 <peter1138> So imho step 1 would be "implement keydown/keyup-based hotkey events"
12:52:08 <kuhnovic> That's 58,44 years worth of gameplay in Q3 alone. Damn.
12:52:19 <truebrain> and they say OpenTTD is dead π
12:52:38 <peter1138> Step 2 would be "migrating directional key handling to keydown/up hotkey events"
12:53:16 <locosage> I even looked at extending hotkey system in cmclient at some point but decided it needs more time than I was willing to spend.
12:53:37 <locosage> peter1138: and modifier-only "hotkeys" while at it
12:54:10 <locosage> or, in other words, configurable modifier keys
12:55:18 <peter1138> Or, if you like, "migrate OpenTTD to a modern game engine"
12:55:50 <ian01223> now you see this is where you'll lose me because my idea of a solution/bodge to this is to just find wherever this logic is, add a variable where the hardcoded key is now, add a function somewhere to read the config at startup and then just set variable to that
12:56:30 <ian01223> doesn't actually fix the technical debt at all but it does satisfy me
12:56:57 <ian01223> peter1138: lets not get too ahead of ourselves now
12:57:38 <locosage> ian01223: well, bodge isn't exactly a good thing to have in a codebase
12:58:05 <locosage> there's been plenty of bodging hotkeys but no one did a proper solution for vanilla yet
13:00:14 <ian01223> I feel like that's the wrong way around
13:00:25 <Borg> guys/ I think that Action0 wiki page needs to be updated.. is very misleading
13:00:48 <peter1138> 20 years of it being the same and NOW it's wrong?
13:01:03 <Borg> peter1138: okey.. so lets try to clarify it
13:01:10 <locosage> ian01223: it's all kinds of wrong but someone actually did it and it works
13:01:10 <Borg> im trying to change some properties
13:01:43 <Borg> peter1138: so ID of vehicles needs to be sequental right?
13:02:06 <locosage> well, by now I probably rewrote the original patch completely so in cmclient case that "someone" would be me xDD
13:02:08 <peter1138> Yes. It only asks for the ID of the first vehicle.
13:02:18 <_glx_> if they're not you need more action 0
13:02:23 <Borg> peter1138: yes! now I get it.. this need to be stated imo in Action0 wiki
13:02:29 <Borg> only first id.. and sequental..
13:02:35 <peter1138> > The ID of the first vehicle/station to change
13:02:54 <Borg> its not clear to me.. I was feding <id> <prop> <value>
13:03:04 <_glx_> "The Vehicle ID of the first vehicle or station to change. If num-info is greater than one, this vehicle/station and the following vehicles/stations will be changed. "
13:03:05 <Borg> and wondered why I got garbage
13:03:45 <Borg> still its not clear that you need to just then use <prop> <value> list
13:03:49 <Borg> not.. <id> <prop> <value>
13:03:57 <Borg> anyway.. thanks for help..
13:04:01 <locosage> @Borg, what are you even trying to do that you need to dig into grf spec?
13:04:29 <_glx_> the syntax is clear for me `<Sprite-number> * <Length> 00 <Feature> <Num-props> <Num-info> <Id> (<Property <New-info>)...`
13:04:56 <Borg> _glx_: okey.. that (...) thingie I should pay more antention to indeed...
13:05:07 <Borg> locosage: improving my GRF mod :)
13:05:19 <locosage> I think with grf-py at some point I gave up on trying to understand action0 spec and just read the openttd source
13:05:31 <Borg> locosage: I use newgrf nearly directly
13:06:20 <Borg> okey, thanks a lot for help.. things are clear now..
13:07:12 <_glx_> but I agree, it's sometimes hard to find the wanted info in grf wiki
13:08:14 <peter1138> If you do have sequential IDs, this 'batching' ability is quite nice.
13:08:31 <peter1138> Something like NML is pretty dumb and basically ignores it.
13:08:58 <peter1138> (It would add a lot of complexity to support it)
13:09:05 <_glx_> nml uses it only for multitile houses I think
13:09:15 <locosage> at the end of the day batching basically just saves a few bytes
13:09:19 <_glx_> but the support is present
13:20:44 <truebrain> JGRPP in 2024Q3 is: `We received surveys for a total of 95752 hours of games played, over a total of 11519 games. This is an average of 8.31 hours per game. `
13:21:13 <truebrain> the average game session is four times longer π
13:21:37 <LordAro> now that's definitely because of Andy :p
13:21:44 <_glx_> daylength is longer π
13:24:06 <peter1138> 95752 out of 511925 is a good proportion. Not quite "everyone plays JGRPP" though.
13:24:30 <LordAro> 20% is higher than i might have expected
13:24:47 <truebrain> it is, what, 5% of the games, 20% of the playtime
13:25:09 <truebrain> I should do proper math, not guestimate it π
13:25:59 <truebrain> well, I should add it up first
13:26:03 <truebrain> ugh, nevermind, you get my point! π
13:27:24 *** nielsm has quit IRC (Ping timeout: 480 seconds)
13:27:49 <kuhnovic> And then there's all the people that turn the survey off. The ones we'll never know about π
13:28:05 <kuhnovic> "Outside the observable universe"
13:28:18 <locosage> or use other patchpacks π
13:35:12 <truebrain> a JGRPP game is ~10MB and a vanilla is ~3MB. So if we would store every game people exit, it would be 100GB of JGRPP and 600GB for vanilla
13:35:19 <truebrain> making a rough estimation what cloud saves would cost π
13:35:44 <truebrain> so ~1TB when all those games would not overwrite per quarter
13:35:52 <truebrain> that is not too bad
13:36:20 <LordAro> truebrain: a single 1TB HDD attached to Andy's MBP?
13:36:45 <andythenorth> I have a 1TB backup drive, can we use that?
13:37:06 <peter1138> truebrain: Yeah but if you have to cloud-save Xarick's 70,000 ships...
13:37:49 <xarick> I solved the problem about PerformanceAccumulator
13:38:16 <LordAro> tbf, RPi5 w/ 1TB NVMe might actually suffice
13:38:24 <LordAro> except for the lack of redundancy
13:38:34 <truebrain> I asked Cloudflare if they are willing to sponsor it
13:40:14 <xarick> I noticed PerformanceAccumulator on RoadVehicle::Tick() is accounting for each v of the consist, but on Train::Tick() it's only accounting for front engine
13:47:39 <xarick> not sure if I go with Change or Fix
13:53:20 <xarick> the frame rate window however has... "vehicle type 'ticks'" in the name though
13:54:04 <xarick> I'm adding now OnNewEconomyDay + Ticks
13:54:22 <xarick> do I need to change the 'ticks' wording?
14:12:53 <xarick> I lose 1 hour to write a commit message
14:13:01 <kuhnovic> Try not to combine different fixes. Small changes are easier to review, test and comment on.
14:14:08 <kuhnovic> I mean more like: you've fixed the performance accumulator for ships, put that in a PR. You can then fix the one trains later, when you feel like it.
14:15:38 <truebrain> calculating Quarterly reports takes a good amount of time π
14:15:58 <truebrain> aggregating that many reports ... really, we receive so many more survey results than I anticipated π
14:16:15 <talltyler> What a good problem to have! π
14:16:32 <truebrain> and I am happy the infra has worked without issues for it π
14:36:40 <truebrain> I hope I did my workflow correctly ... can only test when actually running it π
14:39:47 <johnfranklin> Yes, I can lick shift and ctrl at the same time
14:40:32 <truebrain> nothing to see, lalalala
14:41:48 <truebrain> `Downloading packs for quarter 1 in 2024: [2024-01-01 .. 2024-03-31]`
14:44:18 <DorpsGek> - Add: summary for Q1 of 2024 (by OpenTTD Survey)
14:44:34 <truebrain> Every 20XX-01-01, 20XX-04-01, 20XX-07-01, 20XX-10-01 it should now generate a quarterly report of the quarter of the day before. In theory.
14:45:27 <truebrain> but we will only find out next year π
14:51:25 <truebrain> okay, Q2 and Q3 reports are being created; will take a few before they arrive π
14:51:39 <truebrain> finally got that done too! Now someone can remove unused settings based on those results (once they are in π )
14:51:48 <DorpsGek> - Add: summary for Q2 of 2024 (by OpenTTD Survey)
15:01:53 *** Borg has quit IRC (Quit: leaving)
15:11:38 <DorpsGek> - Add: summary for Q3 of 2024 (by OpenTTD Survey)
15:13:44 <kuhnovic> Looks like we can remove a lot of YAPF settings and make them constants
15:14:14 <kuhnovic> We kinda knew that already, but these results are pretty convincing
15:15:30 <kuhnovic> But who in their right mind.... π
15:34:28 <xarick> nice! i made the CheckIfShipNeedsService actually... comparable with current master
15:36:04 <aviationgamerx> I think my pull request started a long debate now
15:36:29 <aviationgamerx> I don't think I am gonna keep it going
15:37:36 <aviationgamerx> I will try to fix the problems anyway, I don't know why the comments turned into a debate so fast
15:47:25 *** gelignite has joined #openttd
15:59:45 <xarick> Should I ask CoPilot to document my code
16:01:05 <truebrain> aviationgamerx: Sadly, that happens more often, and mostly out of our control. Always good to remember that those debates are rarely with developers, but with passionate players. They don't always see all sides of the coin.
16:02:20 <truebrain> But yeah, fixing the issues is always good π don't let one debate keep you from learning and having fun π
16:05:21 <xarick> How do I convince you that #12206 is the way to go π
16:06:26 <xarick> first, it fixes a problem, then it leads the way as basis to my FindNearestDepot
16:06:36 <xarick> which I also intend to PR
16:09:07 *** Wormnest has joined #openttd
16:22:18 <kuhnovic> Start by explaining, using logical reasoning, how you have solved the problem. "My 70K ship save works" doesn't count as logical reasoning.
17:04:40 <_glx_> and I think many already said it would be better to reverse the search
17:06:34 <_glx_> as pf already supports multiple origin for 1 destination, there's no need to add support for multiple destination if you use the existing stuff, but that implies reversing logic in some places
17:09:42 <xarick> gonna try doing it that way
17:23:10 <bigyihsuan> do we have a reason why it uses very low industry density specifically in the scenario editor?
17:47:33 <xarick> _glx_: oh, I need to edit yapf_common.hpp create a new SetOrigin type which accepts multiple origins?
17:48:13 <xarick> and the destination is the ship in a reversed trackdir
17:48:21 <johnfranklin> Todayβs dinner is fish and chips
17:50:34 <xarick> gonna try something there after dinner
17:56:10 <_glx_> xarick: not really, you just need another CYapfOriginXXX class
17:56:19 <peter1138> Hmm, I noticed that some of JGRPP UI still does the 1-pixel-shift-if-lowered stuff.
17:57:29 <_jgr_> truebrain: Looks good π
17:58:24 <_jgr_> peter1138: In general 1 pixel offsets like that is not something that is on my radar at all
17:58:38 <johnfranklin> Can 2GB machine run JGRPP?
17:59:19 <_jgr_> peter1138: If I notice something wrong I'll (eventually) fix it though
17:59:34 <truebrain> _jgr_: main observations is that JGRPP savegames are, on average, three times as big. But also, the retention (length of a game-session) is with JGRPP a lot higher. So you are doing something right there π
17:59:55 <_jgr_> johnfranklin: It should be fine, if it's slow, just use a smaller/less busy map
18:00:48 <peter1138> _jgr_: rail_gui.cpp:674 in this case.
18:01:08 <peter1138> I assume it's custom drawing purely for PALETTE_TO_GREY.
18:01:54 <_jgr_> I never actually use that button, but yes, that looks wrong, I'll fix that
18:18:43 <bigyihsuan> i wish visual studio had this sort of identifier highlighting
18:57:09 <xarick> working on setting multiple origins... if the tile is currently not water, what do I do?
18:57:42 <xarick> imagine it is a dock, temporarily removed
18:57:59 <xarick> the station sign is on land
18:58:48 <_glx_> How destination handled it ?
18:59:44 <xarick> path not found I think
19:07:26 <peter1138> If it's not a water tile, it's not going to be an origin, right?
19:10:17 <_glx_> anyway first step before really handling multiple origins would be to actually invert the pf run
19:11:04 <xarick> this already looks massive
19:12:34 <xarick> well for depots it's only 2 origins per tile
19:13:11 <_glx_> don't modify CYapfOriginTileT, but implement another class
19:13:30 <xarick> I copy pasted it into yapf_ship.cpp
19:13:44 <xarick> renamed to CYapfOriginTileWaterT, and now I'm working from there
19:17:43 <_pruple> how do the default vehicles refit, if not through cargo classes?
19:19:22 <_glx_> only way to make vanilla compatible with newgrf π
19:34:33 <peter1138> It's by class but it depends on the cargo type, it's not directly set on the vehicle.
19:36:04 <_pruple> makes sense, I guess that simplifies that question then π
19:36:22 <_pruple> I doubt many people are running newgrf industries and default vehicles, in any case...
19:36:35 <_glx_> but it should work fine π
19:36:52 <_pruple> works fine, doesn't have to work *pretty* π
19:43:01 *** ChanServ sets mode: +v tokai
19:46:06 <xarick> wow, it build, this must be cursed
19:47:06 *** tokai|noir has quit IRC (Read error: Connection reset by peer)
19:47:19 <xarick> assert(node->GetTile() == v->tile);
19:47:49 <xarick> the last tile is now one of the origins
19:51:25 <xarick> assert(std::find(dest_tiles.begin(), dest_tiles.end(), node->GetTile()) != dest_tiles.end());
19:53:35 <xarick> the ships from the main menu are confused
20:02:32 <xarick> oh boy... it's not as simple as I thought
20:17:26 <johnfranklin> Peter is much likely living in Milton Keynes, hmmβ¦
20:21:38 <peter1138> No but I was just watching a video about the A421 flooding between Bedford and MK.
20:40:08 <LordAro> peter1138: surprised that's only needed in 2 places
20:40:14 <LordAro> not textfile windows?
20:41:12 <peter1138> Hmm, didn't check textfile actually.
20:42:23 <peter1138> Good shout. That's broken too./
20:51:30 <peter1138> Why do I have 996 NewGRFs...
21:00:40 <andythenorth> because you've lost 3
21:00:46 <andythenorth> hmm also, is it naptime?
21:26:28 *** keikoz has quit IRC (Ping timeout: 480 seconds)
21:38:35 <xarick> `if ((TrackdirToTrackdirBits(best_origin_dir) & TrackdirToTrackdirBits(ReverseTrackdir(FindFirstTrackdir(forward_dirs)))) == TRACKDIR_BIT_NONE) {`
21:39:11 <xarick> if forward_dirs happens to have more than 1 track, i'm screwed
21:58:20 <xarick> I'm lost with all these reversings
22:00:24 <xarick> standard method: path is found 1-2-3-4, navigating the path parents means 4-3-2-1
22:01:15 <xarick> origin as dest method: path is found 4-3-2-1, navigating the path parents 1-2-3-4, but I need it in 4-3-2-1 form
22:01:42 <xarick> pen drawing isn't helping
22:17:43 *** nielsm has quit IRC (Ping timeout: 480 seconds)
22:17:54 *** Wolf01 has quit IRC (Quit: Once again the world is quick to bury me.)
22:51:25 <peter1138> In the absense of translatable text files... Hmm.
22:52:20 <peter1138> But it's better than current.
23:03:46 *** gelignite has quit IRC (Quit: Stay safe!)
23:31:32 *** HerzogDeXtEr has quit IRC (Read error: Connection reset by peer)
23:32:09 *** debdog has quit IRC (Ping timeout: 480 seconds)
continue to next day β΅