IRC logs for #openttd on OFTC at 2023-09-08
⏴ go to previous day
01:18:20 *** _pruple has joined #openttd
01:19:59 <_pruple> why are vehicles suddenly -1 year to lifespan? eg this should be 30 years.
01:39:28 <_glx_> ah yes that should be it as the GUI draws it with `SetDParam(1, DateToYear(e->GetLifeLengthInDays()));`
01:41:09 *** talltyler has joined #openttd
01:41:09 <talltyler> What is the value defined by the GRF?
01:41:55 <talltyler> 11173 shouldn’t affect anything though
01:42:14 <_glx_> yeah 11173 just moves the division
01:42:39 <_glx_> but 11174 changes the multiplication before the division
01:59:34 *** Wormnest has quit IRC (Quit: Leaving)
02:10:05 <_pruple> the value defined by the grf is 30
02:10:27 <_pruple> every vehicle appears to be -1 to lifespan, 25 has become 24, 20 has become 19, etc...
02:58:11 *** debdog has quit IRC (Ping timeout: 480 seconds)
03:50:30 *** johnfranklin has joined #openttd
03:50:30 <johnfranklin> truebrain: A famous coffee chain shop in China is mixing coffee with spirit
03:52:59 *** D-HUND is now known as debdog
03:53:50 <johnfranklin> sauce-flavor latte
04:18:59 *** tokai|noir has joined #openttd
04:18:59 *** ChanServ sets mode: +v tokai|noir
04:26:03 *** tokai has quit IRC (Ping timeout: 480 seconds)
06:10:25 <peter1139> Oops. I didn't look at 11174 but changing the regression test should've been a warning.
06:59:21 *** gelignite has joined #openttd
07:06:45 *** esselfe has quit IRC (Ping timeout: 480 seconds)
07:25:47 *** truebrain has joined #openttd
07:25:48 <truebrain> The description explains the regression change well 😛 but I guess we still have a few leap vs no-leap 😄
07:37:11 <peter1139> Hmm, so maybe it's more like a rounding issue, where it used to be 25 years it is now 24.99 years (I don't know the exact difference), but we show it as 24.
07:40:24 <peter1139> Okay the problem with that change is it's applying leap-year logic (which applies to absolute dates) to what are actually intervals.
07:46:32 <truebrain> We make no difference between Date and DateDiff, which has come up a few times of being slightly problemetic 😄
07:46:54 <truebrain> so sometimes we divide by 365, sometimes by 366, and sometimes we calculate it all exact
07:47:35 <truebrain> in other words: it is messy! 😄
07:48:09 <pickpacket> Would it be possible to shift it over to using an existing date/time lib?
07:49:43 <truebrain> (similar with Year and TileIndex btw .. but I guess they don't have the issue of not always containing the same amount of units per unit 😛 )
07:51:46 *** locosage has joined #openttd
07:51:46 <locosage> hm, am I the only one getting assertion on master in release build?
07:52:00 <truebrain> euh, Year -> Date, whatever .. it is tricky 😛
07:54:34 <peter1139> Hmm, nvidia video encoding not working, damn it Linux.
07:54:51 <peter1139> CPU encoding such slow.
07:56:16 <peter1139> Pretty sure it should be possible to trim a video without reencoding, but...
07:56:55 <peter1139> /home/petern/src/openttd/src/town_cmd.cpp:115:23: warning: unused variable 'i' [-Wunused-variable] for (const Industry *i : Industry::Iterate()) {
07:57:10 <peter1139> Quantum asserts? Both enabled and disabled...
07:59:14 <truebrain> so you have WITH_ASSERT on, but not NDEBUG on, yet `assert` isn't a function? Funny
08:00:10 <peter1139> "RelWithDebInfo" is all I select.
08:00:57 <truebrain> funny 🙂 This assert stuff .. it keeps hunting us 😛
08:02:31 <truebrain> makes you wonder what has changed ... but yeah, with RelWithDebInfo you should have NDEBUG
08:02:37 <truebrain> and we have code that adds a new assert in that case
08:02:46 <truebrain> as we are weird, and have asserts when NDEBUG is on 😛
08:08:30 <peter1139> ./oipeError: Assertion failed at line 140 of /home/petern/src/openttd/src/core/pool_func.hpp: this->checked != 0
08:08:41 <peter1139> er. excuse that junk before Error...
08:09:33 <truebrain> so you do have asserts .. then that warning is oddddd 😛
08:10:11 <peter1139> `RoadStop *rs = new RoadStop(t);`
08:19:07 <peter1139> dwfreed, thanks, that was a lot quicker and a lot smaller.
08:19:35 <peter1139> Reencoding presumably used a higher quality than the original, 33% length was 80% filesize.
08:24:03 <peter1139> 11267 is weird, it's not like 11251 adds new things.
08:25:23 <truebrain> is it actually 11251? 🙂
08:27:32 <peter1139> Previous commit works fine.
08:28:11 <truebrain> so an unrelated change makes things go boom? 😛
08:29:19 <peter1139> Yes -- in fact those warnings I get disappear pre-11251 as well.
08:29:47 <truebrain> so what is in the nlohmann header file? 😄
08:29:59 <truebrain> are they doing something sneaky?!
08:30:19 <peter1139> Ah so those headers spread around a bit... :/
08:30:52 <truebrain> nlohmann header is included in script headers, which are included EVERYWHERE
08:31:01 <truebrain> might as well move it to stdafx when you add it to a script header 😛
08:33:18 <truebrain> lol, it includes cassert again ... I hope ... that that header has header protection ...
08:34:17 <peter1139> Is WITH_ASSERT meant to be 1 with RelWithDebInfo?
08:34:35 <truebrain> all except stable releases have WITH_ASSERT enabled
08:34:55 <truebrain> (remember, all but stable releases can assert, so "we can catch bugs with our RC/beta)
08:35:12 <peter1139> Couldn't remember :p
08:35:13 <truebrain> this is why with WITH_ASSERT and NDEBUG we define our own assert, as otherwise there is no assert 🙂
08:35:46 <truebrain> is how assert.h starts
08:35:54 <truebrain> so ... if you have a header protection .. THROW IT AWAY AND START AGAIN
08:36:01 <truebrain> ffs ... system headers that are idiotic ....
08:36:29 <truebrain> like ... that is not how headers should behave ...
08:36:43 <truebrain> so yeah, for some files, there is no assert, for others, there is
08:37:03 <truebrain> and now I am guessing that the check if a pool can allocate an item is on an assert 😛
08:37:24 <truebrain> in other words, we need to move nlohmann to stdafx, and include it before we do our assert tricks 🙂
08:37:36 <truebrain> I hate system headers ...
08:37:51 <truebrain> right, shopping time!
08:38:23 <peter1139> Or replace our assert with something custom that won't be overridden.
08:39:00 <peter1139> There's only 1724 of them.
08:42:53 <peter1139> Well, I guess I should not approve anything based on reviewing the code.
08:51:28 <peter1139> You all stopped using Chrome by now, yes?
08:59:26 <truebrain> been using Firefox for years, yes 😛
08:59:54 <truebrain> peter1139: this only shows up with release builds .. we are not going to test every PR if it works as a release build, sorry 😛 These bugs are rare and weird ..
08:59:59 <truebrain> anyway, you writing a fix peter1139?
09:00:54 <peter1139> Yeah, but I normally build with RelWithDebInfo, so that would have picked it up.
09:01:03 <peter1139> No, I'm on $work time at the moment.
09:06:19 <LordAro> truebrain: bit irritating to have to include it in every file...
09:07:48 <truebrain> completely untested, but let me enable the preview; that is a release build
09:08:47 <LordAro> because it's only needed by a couple of cpp files, right?
09:08:58 <LordAro> or perhaps it's more pervasive than that
09:09:05 <truebrain> no, a "couple" of header-files need them
09:09:09 <truebrain> which happens to be script_NNN.hpp
09:09:13 <truebrain> so ... yeah, most files already have it 😛
09:09:36 <truebrain> owh ... I now also forced the use of nlohmann for strgen and friends .. that might be overkill
09:09:52 <truebrain> (as in our CI we don't have that installed for those tools)
09:10:04 <truebrain> honestly .. we should vendor nlohmann ...
09:10:57 <peter1139> MakeJSON is only exposed for the unit test, so that could be handled differently.
09:11:12 <truebrain> except it is a member of a class 😉
09:11:35 <truebrain> similar for the event btw
09:11:36 <peter1139> What was that define we saw about unit testing the other day? :)
09:11:44 <truebrain> and the event header btw is the reason all files already kinda include it 😛
09:11:57 <truebrain> the issue with C++ is, you have 2 choices
09:12:04 <truebrain> either be like a good OO person, and add private members
09:12:07 <peter1139> I guess that doesn't work well because we'd then build openttd lib twice :p
09:12:17 <truebrain> or be like an evil person, and use static function, which you make non-static for testing
09:12:30 <truebrain> either way, it sucks 😛
09:12:51 <truebrain> another annoying issue is that `nlohmann::json` is not a simple struct or class .. so you can't just say `class nlohmann::json` in headers
09:12:59 <truebrain> which would also severely limit this issue .. but not resolve it
09:13:06 <truebrain> as it still means nlohmann needs to be included before stdafx
09:13:08 <peter1139> Could be a void pointer instead of a json reference. A bit nastier to use but...
09:13:10 <truebrain> which we really don't like doing
09:13:30 <truebrain> you really don't want it to be a pointer .. it is a `nlohmann::json &` for a good reason 🙂
09:13:34 <truebrain> it should never be a nullptr 🙂
09:13:46 <truebrain> kinda ruining C++ idiology otherwise 😄
09:14:46 <peter1139> Normally yes, but as a compromise for something that's only exposed for unittesting...
09:15:39 <LordAro> #ifdef UNIT_TESTING int MakeJSON...
09:16:11 <truebrain> all those ideas "work" till we have a json object we pass between non-test stuff
09:16:15 <truebrain> then we are back to where we are now
09:17:04 <truebrain> we aren't actually solving anything by avoiding the include of the header-file 🙂
09:17:11 <truebrain> header-files shouldn't have these side-effects
09:19:29 <peter1139> I think we made a boo-boo exposing nlohmann at all, to be honest.
09:19:44 <truebrain> (that sentence can be read in so many ways 😄 )
09:20:52 <peter1139> How json is created in script_admin should be internal to script_admin.
09:21:09 <truebrain> yes; but again, this has to do how we deal with OO
09:21:23 <truebrain> I mentioned before, you have 2 choices: static functions or private member functions
09:21:28 <truebrain> a lot of code does the latter
09:21:33 <truebrain> the older parts of the code the first
09:21:41 <peter1139> There's a rule about C++ -- we don't need to treat everything as an object.
09:21:49 <truebrain> and normally you bypass this issue with doing `class nlohmann` in the header .. but .. yeah .. no 😦
09:22:13 <truebrain> either way, the problem at hand is the assert .. even if you remove it from the header-file, the local source file still has the issue
09:25:07 <truebrain> so how about this, preventing the issue from ever happening no matter how we slice it?
09:27:34 <truebrain> it is just that, a workaround
09:27:39 <truebrain> at least it prevents this problem from resurfacing
09:28:24 <truebrain> next is the part I agree on with peter1139, we shouldn't broadcast our internals .. so if we agree on that, I can address that too in another PR 🙂
09:28:27 <peter1139> If it means nlohmann uses our own assert then it is the correct solution anyway?
09:28:50 <peter1139> (i.e. even if this problem hadn't come up)
09:28:52 <truebrain> we force it to do that, yes. Just a bit weird to have a piece of macro in your stdafx specific for a single library 😛
09:29:09 <truebrain> but I guess you are right, we do that for other places too
09:30:10 <peter1139> I have a 12.2% mine chocolate stout, for some time later... I hope it's nice.
09:30:58 <LordAro> that does sound like a "later" beer
09:32:12 <peter1139> Urgh, I better make a police report before they knock off for the weekend...
09:32:24 <truebrain> why .... do you need a police report? 😄
09:32:42 <truebrain> amyway, if you agree with that PR, please show that in the form of an approval or something? 😄
09:33:03 <peter1139> I was waiting for it to compile and confirm a fix.
09:33:16 <peter1139> stdafx changes take a while, even with -j 12 :D
09:41:50 *** Flygon has quit IRC (Remote host closed the connection)
09:42:51 <truebrain> that one is for you peter1139 😛
10:50:27 <LordAro> hang on though, regardless of whether the assert should've been there or not, it was still triggering
10:51:37 <LordAro> or, hmm, is it something weirdly assert specific
10:57:15 <truebrain> yeah, we sometimes call functions in asserts
10:58:12 <truebrain> ah, no, it is easier:
10:58:15 <truebrain> ```#ifdef WITH_ASSERT
10:58:15 <truebrain> assert(this->checked != 0);
10:58:15 <truebrain> #endif /* WITH_ASSERT */```
10:58:33 <truebrain> so if the header-file is compiled with nlohmann it does something different then without
10:58:39 <truebrain> I can imagine that giving fun results 😛
11:31:24 <peter1139> LordAro, I wondered that but cba to delve too much into it :)
11:31:49 <peter1139> andythenorth, good because I had salad.
11:36:26 <peter1139> An assert with side-effects.
11:36:33 <truebrain> don't you just love them?
11:37:04 <truebrain> we have many of those 😛
11:37:12 <peter1139> That was causing the issue, but the trigger was #L930.
11:37:32 <truebrain> yup, as the file that created the RoadStop class did have asserts enabled
11:37:50 <truebrain> that is what happens if parts of the code do and others dont have asserts 😛
11:38:10 <truebrain> hmm .. can I avoid leaking nlohmann in 20-ish places in my crashlog-json branch ..
11:38:26 <truebrain> we have a single class, one as interface to others, one as interface to OS overloads
11:38:31 <truebrain> and ofc they are in the same class / file 😄
11:53:30 *** wallaby2 has joined #openttd
11:55:54 <truebrain> nope; that would make for a bigger refactor than worth it
11:56:04 <truebrain> at least made things a bit more pretty while looking at it
11:58:01 *** wallabra has quit IRC (Read error: Connection reset by peer)
12:20:21 *** virtualrandomnumber has joined #openttd
12:20:57 *** virtualrandomnumber has quit IRC (Remote host closed the connection)
14:39:17 <locosage> does this count as a bug? xD
14:40:12 <peter1139> Assuming it's lots of vehicles rather than trails... probably no.
14:40:26 <locosage> it's one vehicle on ff
14:40:46 <locosage> but some earlier messages are on top of later ones
14:41:16 <peter1139> I guess the animation speed doesn't get scaled by FFWD (probably deliberately)
14:42:06 <peter1139> Although if the vehicle already has a text effect it should be able to cancel it for a new one. Hmm.
14:42:33 <locosage> what I mean is they should be like this
14:42:36 <locosage> z-index is messed up
14:43:28 <peter1139> Oh I see, you are really getting to the important point there...
14:47:56 <Eddi|zuHause> they should be sorted by creation time?
14:50:53 <peter1139> > The core of the problem is that setting the GUI scale (Game Options>Graphics>Interface size) also changes the default zoom for the game.
14:50:59 <peter1139> Incorrect analysis tbh.
14:51:36 <peter1139> The core of the problem is that OpenTTD prescales sprites, stores them in memory, and only goes up to 4x.
14:53:12 *** _zephyris has joined #openttd
14:53:12 <_zephyris> Well... one's from a user perspective, ones from someone who knows how OpenTTD works
14:56:38 <truebrain> Ah, a classic bug-but-actually-a-feature-request 😄
14:57:12 <peter1139> The prescaled sprite situation is pretty bad to be honest.
14:57:40 *** alfagamma7 has joined #openttd
14:57:40 <alfagamma7> Redesign openttd then? ( idk anything, I am nothing just an observer)
14:59:00 <truebrain> peter1139: Almost as if it is a game from 1994 😄
14:59:42 <_jgr_> Pre-scaled sprites aren't bad per se, but encoding sprites for every possible zoom level at once as is done now is problematic
14:59:43 <peter1139> It didn't prescale then ;)
15:00:34 <peter1139> My patch to allow non-powers-of-two scaling also completely ignores the prescaled sprites :)
15:00:51 <peter1139> truebrain, it had other issues that prescaling solved, of course.
15:01:28 <_zephyris> truebrain: I did put [bug(ish)] 😉
15:01:41 <truebrain> But it not even "ish" 🙂
15:02:03 <peter1139> Dynamically creating a sprite atlas to allow actual hardware accelleration is a tricky prospect too.
15:02:15 <truebrain> The problem with these kind of requests is that the list is endless. They are not invalid, but it makes for a long "issue" list
15:02:29 <truebrain> I wish GitHub had some better way of dealing with feature request
15:02:37 <_zephyris> Fair, feel free to delete!
15:02:41 <truebrain> So we can keep the issues focused on issues ..
15:02:46 <truebrain> No, it is not about that
15:03:07 <truebrain> It is just hars to keep overview sometimes
15:03:15 <_zephyris> Mm, I see what you mean
15:03:33 <truebrain> We used to send feature request to the forums, just because nobody looked there anyway 😛
15:04:18 <truebrain> Anyway, it is fine, I am just being grumpy 🙂
15:06:04 <alfagamma7> OpenTTD is close to 20 years I think??
15:06:08 <truebrain> Hmm .. github should allow issues to be filtered by default 😄
15:07:06 <_zephyris> A dumb solution is whole viewport pixel doubling/quadrupling, past some zoom level.
15:07:38 <truebrain> We just need someone to implement it 😛
15:07:51 <peter1139> We probably pretend to support hi-dpi mode ourselves, to avoid Windows automatically doing that scaling.
15:09:08 <truebrain> Can't OpenGL to cheap scaling?
15:11:29 <peter1139> But you then have multiple scaling choices to make :)
15:13:30 <_zephyris> Just don't expose the setting. Scale nicely from 1-4x, then just pixel double past that. This is a high resolution screen issue, so some approximations will work well.
15:14:26 <peter1139> That's not how it works though.
15:14:43 <peter1139> If you set interface scale to 4x, you'll still be stuck with the interface at 4x and the viewport at 4x.
15:15:02 <peter1139> You could then potentially pixel double, but then you'd get interface at 8x as well as the viewport.
15:17:19 <Eddi|zuHause> 4x extra zoom ought to be enough for anyone, they said :p
15:17:28 <_zephyris> peter1139: Yeah, I realise that doesn't fix the example I posted, but that's a very extreme DPI situation (320ish DPI).
15:17:37 <_zephyris> From a graphic design mentality/perspective, you'd (smartly) select the balance between true scaling and pixel doubling based on DPI and physical screen dimensions.
15:17:55 <_zephyris> Err, possibly just based on DPI.
15:18:04 <Eddi|zuHause> can't you just use OS-provided pixel doubling?
15:19:27 <peter1139> There's an option to allow hidpi for MacOS.
15:20:06 <peter1139> For Windows, it's overridden by openttd.manifest -- it's not configurable.
15:20:55 <peter1139> (There is an API to do it, but we don't use that.)
15:21:47 <peter1139> ((And it's not recommended))
15:23:48 <_zephyris> Eddi|zuHause: I'm trying to understand the manifest documentation for DPI awareness with my pixel pushing brain... Ugh, it's horrible!
15:24:01 <_zephyris> I'm trying to understand the manifest documentation for DPI awareness with my pixel pushing brain... Ugh, it's horrible!
15:24:47 <peter1139> _zephyris, if you want to edit the manifest and rebuild (I assumed you need to rebuild) then you can just remove the dpiAware/dpiAwareness entries.
15:25:10 <peter1139> (Basically the whole application block)
15:26:40 <Eddi|zuHause> if a game suggestion contains the phrase "i don't think it should be too hard to make", it's probably crazy hard...
15:31:34 <_zephyris> It's been fun poking into the codebase for the first time...
15:32:11 <_zephyris> Naively I thought adding two company colour support to base sprites - thinking depots, stations, etc. - would be easy.
15:32:46 <Eddi|zuHause> yeah, exactly that kind of suggestion :p
15:39:34 <LordAro> "how hard can it be?"
15:41:28 <peter1139> Btw, prescaling 16x sprites is 660KB per ground tile instead of 2KB.
15:41:52 <peter1139> (And also it'll be larger than the original viewport size :))
15:43:22 <Eddi|zuHause> 640x480 ought to be enough for anyone :p
15:43:41 <peter1139> I forgot about bytes per pixel
15:44:01 <peter1139> What are at these days, 6 bytes?
15:44:13 <peter1139> 4MB per ground tile sprite if so.
15:44:42 <peter1139> 3.4MB at the very least with 32bpp and 8bpp component.
15:44:45 <Eddi|zuHause> that was the memory of my first SVGA card
15:44:59 <peter1139> It's okay we don't use your SVGA card's memory ;)
15:45:44 <Eddi|zuHause> what's the average VRAM size today? 8GB?
15:46:02 <peter1139> We still don't use your VRAM.
15:47:21 *** HerzogDeXtEr has joined #openttd
15:48:00 <_zephyris> I'm sure I ran TTD on a PC with 4MB RAM back in the day...
15:48:25 <Eddi|zuHause> yes, i think that was the minimum requirement
15:51:14 <peter1139> I can run TTD in DOSBox too ;)
15:51:35 <peter1139> Mmm, emulated FM synthesizer.
15:52:36 <peter1139> Only 1x, 2x and 4x.
15:56:52 <Eddi|zuHause> i've run windows 3.11 in dosbox
15:57:27 <Eddi|zuHause> took a tiny bit of fiddling to find a useful graphics driver
16:53:30 <peter1139> Hmm, right now I need to remember how to check out a PR.
17:39:55 <peter1139> Maybe confused because it doesn't look like that one big Wiki system...
18:00:50 <Timberwolf> Weird thing for me running TT(D) in DOS is using it with Sound Canvas emulation feels wrong, because I spent so much time playing it with an OPL3 soundcard back in the day.
18:01:50 <Eddi|zuHause> i still have my sound card from those days, but no computer to put it in
18:03:11 <Timberwolf> The only hardware I retained is my Voodoo II.
18:03:31 <Timberwolf> In theory it should be complete in box, in practice I have no idea where the CDs for the pack-in games have gone.
18:28:06 <peter1139> Is using ~21KB to avoid a malloc/free worth it?
18:33:44 <andythenorth> Was it lunch though?
18:54:24 <kamnet> Hmmmm. I've got an OPL3 SA3 soundcard somewhere. It might be in my old Packard Bell, or in one of my old 486 or 586 systems.
18:59:02 <peter1139> I have an o.g. Gravis Ultrasound, for uselessness...
19:10:13 <andythenorth> does it prop your door open?
19:42:46 <peter1139> No, I don't have the box any more :(
19:47:36 <peter1139> andythenorth, is it cheese o'clock?
20:06:29 <kamnet> Mmmm what kinda cheese you got?
20:08:19 <kamnet> I would love a good cream cheese spread on a bagel right now. Sweet or savory, doesn't matter
20:26:01 <peter1139> Well I finished off the cream cheese -- it was marmite cream cheese.
20:43:28 *** Wormnest has joined #openttd
20:51:52 *** HerzogDeXtEr has quit IRC (Read error: Connection reset by peer)
21:08:43 <locosage> and, yes, it fixes that exploit
21:19:41 *** ketsuban has joined #openttd
21:19:41 <ketsuban> Looks like there's some debug prints left behind in economy.cpp?
21:20:19 *** ketsuban is now known as Guest2265
21:20:20 *** Guest2265 is now known as ketsuban[d]
21:22:08 <peter1139> Direction isn't the right term.
21:22:52 <peter1139> (Because we have the type Direction which is... just direction)
21:29:49 <locosage> well, vector is even more confusing imo
21:30:33 <locosage> there is TileIndexDiff but it doesn't seem to be used anymore for tile difference and diff is not a good term for vector either
21:40:26 <peter1139> Oops, accidentally read hacker news
21:41:50 <ketsuban[d]> So am I understanding this PR right that it makes cargo actually track its own movement tile by tile rather than just using the Manhattan distance between the source and destination?
21:42:15 <locosage> ketsuban[d]: no, it just uses a clever trick to skip stations
21:42:34 <locosage> it's still manhattan distance minus "teleportation"
21:45:11 <locosage> another way to see it is as a sum of vectors for each vehicle route (between loading and unloading tile)
21:45:40 *** Wolf01 has quit IRC (Quit: Once again the world is quick to bury me.)
21:46:00 <Eddi|zuHause> so you add up each tile movement, cancelling out loops?
21:47:08 <locosage> yeah, kind of, I don't sum up these vectors directly, but because of location-direction conversion they end up accumulating in the right way
21:50:17 <locosage> basically, instead of
21:50:17 <locosage> `(end1 - start1) + (end2 - start2) + ...`
21:50:17 <locosage> `(((-start1 + end1) - start2) + end2) - ...~`
21:51:50 <peter1139> a.k.a. end1 + end2 - start1 - start2
21:52:38 <locosage> yeah, but the way I'm doing can be calculated as vehicle goes without storing any extra info
21:53:10 <locosage> though I guess loaded_at_xy is stored anyway...
21:53:13 <peter1139> -start1 + end1 ... -start2 + end2
21:53:40 <peter1139> Who knows. It's not a direction, anyway...
21:55:23 <locosage> can change it to vector
21:55:38 <locosage> unless someone has better idea
21:57:20 <locosage> can change both actually, point-vector makes more sense than location-vector imo
22:07:55 <locosage> oh, actually, I'm doing
22:07:55 <locosage> `start1 - end1 + start2 - end2 +...`
22:08:07 <locosage> which is the opposite but doesn't matter since I only use length
22:09:49 <locosage> so each + start makes location(point), each - end makes direction(vector)
23:26:58 *** gelignite has quit IRC (Quit: Stay safe!)
23:28:09 *** Wormnest has quit IRC (Read error: Connection reset by peer)
23:29:17 *** Wormnest has joined #openttd
continue to next day ⏵
