IRC logs for #openttd on OFTC at 2023-09-09
β΄ go to previous day
02:05:44 *** Wormnest has quit IRC (Quit: Leaving)
02:15:43 *** Kitrana1 has joined #openttd
02:22:36 *** Kitrana has quit IRC (Ping timeout: 480 seconds)
02:26:22 *** Tirili has quit IRC (Remote host closed the connection)
02:57:19 *** debdog has quit IRC (Ping timeout: 480 seconds)
03:03:38 *** D-HUND is now known as debdog
06:50:43 *** HerzogDeXtEr has joined #openttd
06:57:13 *** gelignite has joined #openttd
07:39:46 <truebrain> that moment you start a game and forget you have cargodist active .. that was .... annoying π
07:40:53 <truebrain> lol, I now have a bus in a station that is loading, but it is not actually loading
07:40:57 <truebrain> it just .. sits there π
07:41:49 <truebrain> so I disabled cargodist, to make sure that has no influence ... but the bus refuses to get any cargo now π What did I do!
07:43:31 <truebrain> had to change the "full load" stuff a bit for a while, and now it is running again
08:30:47 <andythenorth> peter1139: read it on your MBP though, cheaper and simpler
08:30:59 <andythenorth> is that joke dead enough yet?
08:33:59 <andythenorth> wait, TB is playing the game?
08:34:13 <truebrain> no worries; I failed
08:38:25 <andythenorth> tutorial needed?
08:38:41 <truebrain> I found sufficient amount of bugs I wanted to fix that I closed the game again π
08:38:46 <truebrain> for example, if you minimize the year-report
08:38:50 <truebrain> it will reopen anyway every year
08:39:25 <andythenorth> did you file a report? π
08:39:42 <truebrain> remember last time I reported bugs? Some still havent been addressed π
08:40:00 <andythenorth> but you uncovered the need to change the default palette
08:40:14 <truebrain> you my friend, are welcome
08:40:51 <andythenorth> it's almost like the vendor doesn't care
08:41:01 <andythenorth> I am considering ending my subscription
08:41:28 <truebrain> you can file a concern in /dev/null if you like
08:45:09 <andythenorth> too busy playing OpenTTD
08:50:18 <andythenorth> what's the most l33t signal spacing?
08:50:26 <andythenorth> I thought there were articles about it
08:58:15 *** Smedles has joined #openttd
09:15:47 <alfagamma7> (Loooong consists)
09:20:24 <andythenorth> I use 3, probably because coop tests showed it was most leet or something
09:20:44 <andythenorth> but it makes ugly with flying junctions, where bridges need to be 4 tiles
09:28:43 <_jgr_> It's not really necessary to have them so close, you're just throwing money away on infrastucture costs
09:41:27 <andythenorth> this might be the answer I'm looking for
09:43:35 <andythenorth> I don't have really close headways on most lines
09:45:54 <_jgr_> The signal spacing I use has been gradually creeping up over the years. I tend to go for 5 - 7 these days
09:51:04 <andythenorth> with realistic braking? or without?
09:54:24 <_jgr_> With, but I was using a value of 5 even before I added that
09:54:33 *** emperorjake has joined #openttd
09:54:33 <emperorjake> Anything below 6 is ugly because the signals are too dense
09:55:03 <dwfreed> andythenorth: you mean trains don't stop on a dime?!
09:57:34 <andythenorth> it also makes signals faster
10:07:28 <johnfranklin> I use (train length + 1)
10:13:13 <dwfreed> that's a pretty good metric
10:13:26 <dwfreed> I use similar ones in factorio
11:19:22 *** Flygon has quit IRC (Read error: Connection reset by peer)
11:57:21 <peter1139> andythenorth, block signals every tile, right?
11:58:45 <truebrain> Fastest throughput!
11:58:57 <peter1139> I just use ships, no need for roads, tracks or signals.
11:59:24 <alfagamma7> Not the vanilla ships though
12:00:06 <andythenorth> peter1139: Should I?
12:01:43 <peter1139> Marmite on toast salad
12:02:15 <alfagamma7> That's a war crime
12:07:50 *** gelignite has quit IRC (Quit: Stay safe!)
12:08:53 <peter1139> Now you're talking.
12:11:14 <truebrain> never knew std::rotate existed, lol
12:15:30 <truebrain> ah, lol peter1139, well, that explains π
12:18:46 <truebrain> okay, so you do abuse the std::unique_ptr in a sense; sure π Still feels there should be a cleaner solution, but what-ever
12:18:51 <truebrain> not for this PR π
12:19:03 <peter1139> Well I did notice the line before it said "Memory for to ..." before, though.
12:19:45 <truebrain> and a very tiny nitpick; hope you don't mind
12:20:11 <peter1139> TBH when I used std::optional else where I had assumed it used a pointer internally. But then I noticed the sizeof indicates it allocates the storage alongside the flag for has_value.
12:20:40 <truebrain> yeah, I did not see it was an attempt to reduce memory of the object
12:20:52 <truebrain> also in the old code, I kinda didn't want to read there was a Malloc there π
12:20:56 <truebrain> so this is a good improvement π
12:21:38 <peter1139> I can document why it is unique_ptr instead of optional though :)
12:21:57 <truebrain> it is kinda implied, but making it explicit wouldn't hurt anyone
12:22:19 <peter1139> Yes, but the fact that you asked means it could be clearer.
12:23:10 <truebrain> that moment you ask a small thing in a PR (another PR, to be clear), and that person does something completely different .. which might be fine, but you go like: huh?! at first π
12:24:33 <peter1139> > Memory to store "old" states so we can revert them on the performance of test cases for commands etc.
12:24:38 <peter1139> So... what DOES that actually mean?
12:25:07 <truebrain> peter1139: I tried to verbalise it with my suggestion
12:25:22 <truebrain> but that was based on an assumption; didn't actually check what it was for π
12:26:15 <peter1139> Rubidium wrote it, maybe he can explain :D
12:26:37 <truebrain> I didn't want to say it earlier, but I wanted to make a snarky remark it could have been written by a Dutch person π
12:29:01 <truebrain> even after looking when ClearChanges is called, I still have no clue what it actually does π
12:32:07 <peter1139> No, there's SwitchMode which calls it, most of that seems to be world gen related.
12:32:50 <peter1139> But I think it may also be used if PSA is changed during commands with the CMD_TEST flag.
12:33:25 <truebrain> seems like a reasonable assumption
12:43:53 <truebrain> owh, wow, that is some nasty code right there ... it is funny, NewGRF's ReadByte does prevent reading after eof, but RandomAccessFile does not
12:44:25 <truebrain> the intention is that it starts to return zero .. but if failed at doing that properly π
12:45:05 <truebrain> we also do an `fread` of 1 byte
12:45:15 <truebrain> I was about to say: huh? π
12:45:20 <truebrain> but I should read properly
12:48:31 <truebrain> I also think we accidentially solved it π
12:48:51 <peter1139> Well my next step was to figure out who to ask on how to find out ;)
12:49:22 <peter1139> andythenorth would probably know but consider it a feature and will probably have developed longwinded workarounds.
12:50:38 <truebrain> yeah, with `GSAsyncMode` we mostly solved this issue
12:50:43 <truebrain> not really, but good enough, I would say
12:50:52 <truebrain> given it has been 4 years and nobody comments or voted on the issue
12:51:22 <truebrain> sorry for taking over the ticket peter1139 π
12:51:30 <peter1139> It was your ticket :p
12:53:29 <truebrain> haha, `SkipBytes(-385284605)` is called in the code
12:53:34 <truebrain> that is kinda a skipping, I guess ...
12:53:48 <truebrain> why ... can you do negative skips ...
12:54:28 <peter1139> Yeah, int bytes should be something else...
12:54:46 <peter1139> Oh, that was something else.
12:55:27 <truebrain> really odd, to have negative skips .. let's see what is causing that π
12:56:04 <truebrain> ah .. it is an `uint length`
12:56:09 <truebrain> given to a function that accepts an `int`
12:56:16 <truebrain> so this unintentionally does something very odd
12:56:31 <truebrain> bit surprised no compiler complains: trying to fit an uint in an int
12:56:41 <truebrain> clearly I have worked too much with Rust lately, which REALLY doesn't like you doing that π
12:56:52 <peter1139> There's a compiler flag for that, but, well...
12:57:22 <peter1139> SeekTo takes size_t.
12:57:28 <peter1139> SkipBytes should really too, I'd think.
12:57:49 <truebrain> internally it also does "ptr A - ptr B"
12:58:00 <truebrain> which is also casted to an int
12:58:05 <truebrain> fine, as they are always closeby
12:59:27 <truebrain> `Error: Okay... something went horribly wrong. I couldn't load the fallback sprite. What should I do?`
12:59:32 <truebrain> at least it doesn't crash anymore π
13:00:10 <truebrain> not exactly true .. well, it doesn't crash, but it does hang itself
13:00:16 <truebrain> in a completely different location π
13:00:31 <truebrain> `PerformanceMeasurer::~PerformanceMeasurer` barfs in glibc
13:02:25 <truebrain> and funny .. now it hangs on a `exit(1)`, waiting on a mutex internally in glibc π
13:06:34 <peter1139> We hit some undefined behaviour there :D
13:06:53 <truebrain> yeah, allocating memory while being in `exit(1)` seems to be a big no-no
13:07:02 <truebrain> which makes you wonder .. why does someone allocate memory in a destructor
13:07:09 <truebrain> I am not even willing to open that can of worms π
13:09:58 <andythenorth> peter1139: βProbably need to update the docsβ
13:11:15 <truebrain> spend more time typing the PR description than the code; that was a good bug π
13:12:23 <peter1139> (No doubt there'll be some warnings about passing an int into a function accepting size_t though...)
13:12:46 <truebrain> no caller used `int`, which was the problem π
13:13:45 <truebrain> (I even wrote that in the description! π π )
13:15:21 <truebrain> I keep wondering if 11274 is actually a bug that is being fixed. In fact, I could argue payment should be done from the tile that generated the cargo till the tile that finally accepted it. And the distance between those should be used. How long it takes you, even if you use stationwalking to get there ... just sounds like clever use of infinite-speed-to-transfer-stuff-between-station-tiles π
13:15:58 <truebrain> I find it weird you get paid for the amount of tiles you had stuff in your vehicles .. but that might be just me π
13:16:23 <peter1139> The idea of the patch is not clear to me.
13:17:16 <truebrain> code-wise, there are a few .. things to overcome. But before delving into that, I was first wondering if this was actually addressing a bug .. and that depends on how you look at the game
13:17:28 <peter1139> Source tile to dest tile would be interesting but not quite right either. You could have two industries 10 tiles apart, and load/unload at a station 1 tile apart...
13:17:54 <truebrain> yes, that is exactly my point
13:17:56 <peter1139> It's addressing an exploit in the game mechanics for sure.
13:18:03 <truebrain> if you have a producer at tile 1, and a consumer at tile 10
13:18:04 <andythenorth> WASM payment module
13:18:07 <truebrain> I don't care how you get it from 1 to 10
13:18:10 <truebrain> that is the distance traveled
13:18:22 <andythenorth> Not even saying that for lolz ^
13:18:29 <truebrain> but with stationwalking, you get "free" unlimited movement
13:18:38 <andythenorth> Trying to design the gameβ¦.brrr no
13:18:39 <truebrain> so the time you need to move cargo gets infinite small
13:18:43 <truebrain> and we consider that an "exploit"
13:19:04 <truebrain> yes, "we" , sorry π
13:19:09 <peter1139> Fair, at least that 1 to 10 would be consistent and not really exploitable -- it's only 10 tiles.
13:19:10 <truebrain> that is the thing I am challenging .. is it actually?
13:19:37 <truebrain> as on the other axis, you have fair gameplay, where you can say: no, you only get paid for the time you had it in your vehicle
13:19:50 <truebrain> so producer at 1, consumer at 10, your station is at 4 and 6, so you get paid for 4<->6
13:19:54 <peter1139> Your cargo packet storage would get interesting though, as the source xy space grows a lot.
13:19:54 <truebrain> the rest is done by "magic"
13:19:58 <andythenorth> Moddable economy
13:20:32 <peter1139> truebrain, it's an exploit if you can earn a lot of money from it.
13:20:36 <truebrain> and our current code already does 4<->6 btw, from station label to the next
13:21:20 <truebrain> this PR makes it so, from what I understand, it is from loading tile to unloading tile, instead of from label to label, or something
13:21:38 <truebrain> peter1139: well, yes, but the actual problem here is that cargo travels instantly between station-tiles, I guess
13:22:12 <truebrain> and it feels like we work around that issue, instead of addressing that issue (not sure how btw, just voicing an opinion)
13:23:00 <andythenorth> We could have tile-tile flow rate
13:23:17 <truebrain> to be clear, how I read the PR, what the game currently does: produce at 1, consumer at 100, station label A at 10, station label B at 90, you get paid for 10 -> 90. But the two stations could be 1 tile apart, because you have a very high station spread
13:23:42 <truebrain> so this PR changes that you would only get paid for 3 tiles (station - empty tile - station), instead of 10 - 90
13:23:59 <peter1139> truebrain, my view on the patch -- it makes cargo more complicated, not simpler, with very little actual explaining in code, and therefore I dislike it.
13:24:21 <truebrain> code-wise it is just .. yeah. Similar to the union in the CargoPacket, which is already very odd
13:24:37 <truebrain> this adds to the weirdness by doing the same with location, but having a single variable with 2 different units in them π
13:24:44 <truebrain> so the problem CargoPacket has is being extended π
13:25:03 <truebrain> but I was thinking about other solutions to address that, which brought me to the principle statement: what distance do we actually pay for?
13:25:12 <truebrain> the distance the cargo moved? or the distance the player moved it?
13:26:59 <truebrain> π Moddable economy it is π
13:27:41 <truebrain> the first is basically more "realistic". The second is easier to implement and explain.
13:27:47 <truebrain> Anything is between is just .. weird
13:28:36 <truebrain> well, no, the first is also easier to implement and explain. It is just more exploitable π
13:29:06 <truebrain> introduce a cost to move cargo between station-tiles?
13:29:12 <truebrain> introduce time to move cargo between station-tiles?
13:31:36 <andythenorth> Introduce moving cargo between tiles, and make stations a special case of it π
13:31:55 <andythenorth> Railroad Tycoon 3 did it π
13:32:00 <peter1139> > Temporary memory to store previous state so it can be reverted, e.g. for command tests.
13:32:01 <truebrain> how would you penalitize that "special case"?
13:32:06 <peter1139> Does that work better?
13:32:34 <truebrain> 1000 times, yes π
13:38:13 <andythenorth> truebrain: Not sure. RT3 had local (per tile) cargo pricing, and cargo would only move along a gradient (lower price > higher price)
13:38:58 <andythenorth> I would leave it like current OpenTTD personally because I am not running competitive MP servers
13:54:55 <peter1139> Thanks for your valuable input.
13:57:09 <peter1139> Lots of different cakes at the coffee stop this morning... and I only had a black coffee. Silly.
13:59:38 *** HerzogDeXtEr has quit IRC (Read error: Connection reset by peer)
14:03:37 <locosage> truebrain: nah, totally not a bug π
14:03:58 <truebrain> yeah, clearly no attention was given at all what I was actually saying
14:08:18 <locosage> truebrain: I was using union of TileIndex and TileIndexDiff initially but then someone broke TileIndexDiff so π€·ββοΈ
14:08:51 <locosage> truebrain: I mentioned 3 exploits, paying between industries solves one, the least important
14:08:57 <locosage> so what attention did you give? :p
14:12:39 <andythenorth> peter1139: wasn't amongst my finest was it π
14:15:20 <locosage> truebrain: it's also possible to view point as a vector from 0,0 so units aren't really that different
14:15:50 <truebrain> andythenorth: was it ChatGPT generated? π
14:15:56 <andythenorth> no, all my own work
14:16:09 <locosage> guess I can just static cast everything to TileIndexDiff ...
14:16:26 <andythenorth> a better way to put it would have been "I am going to STFU talking about something I don't understand and won't affect me" π
14:17:43 <andythenorth> hmm doing annual or rolling global 'amount of cargo X transported by your company stats" in GS
14:17:56 <andythenorth> cargomonitor for every cargo for every town, then sum them?
14:18:06 <peter1139> truebrain, CVE for #11275? ;)
14:18:16 <andythenorth> oh wait, I already do that I think, just for 3 months not 12 months
14:18:25 <truebrain> peter1139: ugh, please, no; I don't want to file any more CVEs in my life π
14:19:16 <peter1139> andythenorth, my partner brought home some halloumi fries... so I had some.
14:19:34 <andythenorth> what was I doing?
14:20:15 <peter1139> Convoluted scheme for 3CC
14:22:56 <andythenorth> that's a nice idea
14:23:25 <locosage> truebrain: it is addressing the issue by not counting movement between station tiles. it's actually makes it consistent with cargo aging that doesn't count station time also
14:23:30 <andythenorth> think it might be "add even more livery variants to Horse"
14:23:40 <andythenorth> why not make one grf seriously over-produced?
14:23:55 <andythenorth> ignoring the 5 unfinished grfs
14:29:05 <truebrain> right, a lot of text to understand a single PR.
14:29:25 <truebrain> I did add a tldr, so people can catch up quickly π
14:30:48 <truebrain> only after so much typing I realise that "ConvertAToB` actually meant: calculate Vector based on these two locations
14:31:34 <truebrain> too bad std::vector has nothing to do with a mathematical vector π
14:32:23 <truebrain> Direction -> DirectionAndLength would have made it more clear earlier .. well, whatever π
14:34:05 <truebrain> so after all that typing, most of the "abuse" mentioned in that PR can be resolved by simply calculating industry to industry, and forget about stations π Only the "teleportation" of cargo in stations remain, which honestly is just how the game works .. really not sure if we should actually fix or address that
14:34:37 <truebrain> keep your station-spread low, and the amount of abuse is low π
14:40:40 <truebrain> the longer you look at CargoPacket, the more interesting things you find .. union .. ctor .. source_id / source / source_type, where the middle one has nothing to do with the other two ..
14:40:42 <truebrain> stuff like that π
14:42:03 <peter1139> And then there's no cargo dest after all that anyway ;)
14:42:09 <truebrain> then all of a sudden the first and latter are called `SourceSubsidyType`
14:42:19 <truebrain> this is so random, this whole class π
14:44:29 <andythenorth> it's like it was just...organically modified over time? π
14:44:41 <truebrain> and again, and again, and again π
14:46:05 <truebrain> it also contains pretty nice things btw
14:46:09 <truebrain> just to set a balance here π
14:48:23 <truebrain> `LoadedAtXY` is defined but never used π Nice π
14:50:47 <truebrain> I have looked at this before, but I still can't find where `loaded_at_xy` is actually used ..
14:53:39 <peter1139> LOL. It's not is it...
14:54:27 <peter1139> loaded_at_xy is tested in AreMergable(), so it is needed.
14:54:53 <truebrain> yeah, okay, it is used there, but .. why would it remain 2 packets if there is nothing else different?
14:55:00 <truebrain> why can't it merge?
14:55:40 <truebrain> `SetTransferLoadPlace` suggests it does something for skipping orders while unloading
14:55:52 <truebrain> but I am missing what that "something" is π
14:59:20 *** belajalilija has joined #openttd
14:59:22 <belajalilija> still suffering tho
14:59:36 <truebrain> 22 ... I love my airco π
15:01:51 <belajalilija> sadly AC isnt a thing here in most houses
15:02:03 <truebrain> belajalilija: neither here, but I am not "most" π
15:02:58 <belajalilija> yeah but that's india
15:03:01 <belajalilija> you guys are used to heat
15:03:21 <alfagamma7> My mom isn't for some reason idk
15:03:25 <belajalilija> in the uk people bitch if it goes over 20 and below 5
15:03:41 <alfagamma7> The lowest I have seen is 12
15:04:18 <belajalilija> ive seen minus double didgets
15:04:24 *** michi_cc[d] has joined #openttd
15:04:24 <michi_cc[d]> So, if I understood #11274 right, the real deal breaker is station walking, right?
15:04:24 <michi_cc[d]> Place a station next to a cargo source, wait for cargo to accumulate at the station (which will not age yet), walk station over to destination (easier with higher station spread but always possible), make a two tile delivery and get insane profit. At least thatβs what I extracted.
15:05:03 <truebrain> "teleportation", is part of the issue that the PR tries to address, yes
15:05:14 <truebrain> next to using station-sign-location to get the loading/unloading tiles π
15:05:33 <truebrain> teleportation can be done in two ways, station walking or station spread
15:05:56 <michi_cc[d]> Yeah, but fixing the source to the industry wouldnβt change anything there.
15:06:16 <truebrain> that is also what I wrote, btw π
15:06:29 <truebrain> there is more than one bug and more than one fix in that PR, making a conversation really difficult
15:06:38 <truebrain> one of the things it addresses, is that station sign location is used
15:06:57 <truebrain> the other thing is the teleportation issue
15:07:12 <truebrain> totally disjunct, those two issues π
15:07:24 <truebrain> for simplicity, I suggest to make payment from industry to industry
15:07:36 <truebrain> doesn't resolve teleportation, but that needs addressing anyway, if we even want to address it
15:07:49 <truebrain> does that help? π
15:07:55 <peter1139> If station walking/modification means that the original industry is no longer in the catchment area, drop the cargo? Dunno.
15:08:19 <truebrain> the thing is, this vectorizing of movement is one way to solve teleportation; but there are others out there
15:08:26 <truebrain> if we split the problems, it is easier to look at them π
15:08:56 <truebrain> so deliberately my suggestion to do industry - industry payment does not address teleportation misuse, to state it more clearly π
15:09:25 <truebrain> it does solve the station sign issue, which can either be done by clever building or station walking
15:09:42 <truebrain> this makes the problem btw even more complex .. station walking has two problems π
15:09:56 <truebrain> the moving of the actual cargo in a teleportation way, and the station sign location being left on the old location
15:11:15 <truebrain> ah, no, I am wrong; the latter is no longer true
15:11:19 <truebrain> that has been fixed years ago π
15:11:27 <truebrain> station sign location is updated π Hihi .. I used the abuse the fuck out of that π
15:12:34 <truebrain> just existing cargo isn't updated
15:12:37 <locosage> truebrain: well, I was fixing teleportation, it just happened to solve station signs as well so I mentioned that
15:12:42 <truebrain> well, that is also something that can be addressed differently π
15:13:53 <locosage> I initially used vector distance with station signs but it didn't work at all
15:17:53 <truebrain> I scared michi_cc[d] away with my wall of text; sorry π
15:18:53 <peter1139> Hmm, TextEffectID is size_t, but INVALID_TE_ID is 0xFFFF.
15:18:55 <truebrain> peter1139: I still haven't found a reason why `loaded_at_xy` exists π¦ Time to dig through older sources ..
15:19:09 <locosage> it's for transfers afaict
15:19:21 <locosage> transfer payments, more exactly
15:21:07 <truebrain> okay, in 0.7.0 it was actually used to calculate cargo payment
15:21:23 <truebrain> in 1.0.0 LoadedAtXY was used for that
15:21:44 <truebrain> last seen in 1.9; removed in 1.10
15:22:14 <truebrain> yeah, it is no longer actually used π
15:28:06 <peter1139> truebrain, so can you reduce memory usage some more by removing that member? :D
15:28:18 <truebrain> it is in an union, so no π¦
15:28:43 <locosage> at least can drop the union
15:29:05 <truebrain> ugh, needs a savegame bump
15:29:56 <truebrain> well, I don't actually .. hmm
15:31:54 <locosage> does loader require all fields to be present in the save?
15:33:09 <locosage> loading old saves in new version shouldn't be a problem as it will just skip the field iirc
15:40:40 <truebrain> that was a lot more code I could drag out than I expected π
15:42:54 <peter1139> See, you can reduce the size as you no longer need the 32bit StationID ;)
15:43:12 <truebrain> lol, code-size, yes π
15:44:24 <locosage> 11274 needs some of that code though
15:44:37 <peter1139> Yeah, probaly not enough to shave anything off the existing 32 bytes.
15:49:18 <truebrain> okay, cargo can't really exist without an initial station
15:49:52 <truebrain> (I was looking if any of the other fields could be removed or something, but no)
15:50:28 <locosage> peter1139: is it aligned to multiple of 4 or 8?
15:50:37 <locosage> if 4 28 seems enough now
15:51:27 <truebrain> peter1139: what I could do is flip source_id with source, so source_id and source_type are close to each other again π
15:51:31 <truebrain> as their order no longer matters
15:55:58 <peter1139> truebrain, um, actually I just missed the relationship when reordering, those two could have been the correct way around.
15:56:12 <truebrain> I am going to rename them anyway
15:56:16 <truebrain> this is just confusing as fuck
15:56:21 <truebrain> two types of "source" with different meaning
15:56:37 <peter1139> Call one of them 'direction'? ;)
15:56:58 <peter1139> (I'm sorry but that might be my new meme...)
15:58:05 <truebrain> we are finally going to leave the MBP behind?
15:58:18 <truebrain> only if I can call it New Direction
16:01:22 <peter1139> Hmm, we don't have cloud saves. Sad ;(
16:03:52 *** Wormnest has joined #openttd
16:07:17 <peter1139> The only cold drink I have is a beer...
16:09:54 <truebrain> peter1139: public member variables or access function wrappers?
16:22:08 <peter1139> Hmm, depends if you are going for an API or not...
16:31:36 <truebrain> CargoPacket does the latter. Most of the code does the first. But I will leave it alone
16:34:19 <andythenorth> truebrain: it's time
16:42:20 <peter1139> truebrain, yes, unless doing a complete revamp I will follow the existing style, I hope.
16:42:32 <truebrain> `if (_text_effects.size() == INVALID_TE_ID)` .. this assumes INVALID is always the last item .. is that smart?
16:42:41 <truebrain> (honest question, to be clear π )
16:44:11 <truebrain> (basically, feels odd to compare an INVALID statement with a size)
16:45:27 <truebrain> and shouldn't it be `size() + 1`? Now item 0xffff exists in the list, but when that ID is returned it all of a sudden is invalid? I might be wrong .. again an 0-index thing, my head hurts π
16:47:02 <peter1139> So actually it's possibly not the last item, but only because #9235 increased the datatype from uint16 to size_t.
16:47:21 <peter1139> Or rather, currently it's possibly not.
16:48:20 <peter1139> If size is INVALID_TE_ID, then the last allocated id is INVALID_TE_ID - 1.
16:49:02 <peter1139> They are not allocated anywhere else so it's not possible for the vector to become larger.
16:49:52 <truebrain> ugh, 0-index, you are right
16:49:57 <truebrain> it so makes my pretty head hurt π¦
16:50:36 <truebrain> okay, so I guess I just want to see a comment, and I am fine with it π
16:51:41 <peter1139> I'm not sure if it's actually possible to reach UINT16_MAX of text effects to be honest, but currently the system can allocate one with the invalid ID, and nothing particularly bad would happen.
16:55:21 <peter1139> Hmm, if a vehicle is allocated INVALID_TE_ID, then it'll end up with two text effects as it will create another when the load percentage changes.
16:55:36 <truebrain> stop finding bugs! π
16:57:18 <peter1139> But the ID is only used to be able to update the string. The text effect itself will still scroll up and be removed like normal.
16:57:19 <andythenorth> just don't file them? π
16:57:34 <peter1139> I still think it's unlikely to be that many of them any way :D
16:57:46 <peter1139> Maybe someone has a test save for it.
17:01:26 <truebrain> `inline TileIndex SourceXY() const { return this->source_xy; }`
17:01:31 <truebrain> it doesn't even read `GetSourceXY`
17:01:36 <truebrain> that is kinda annoying
17:02:09 <peter1139> Heh, used to be a manually resized malloc/realloc'd pointer, starting at 20 entries, but grown by 25 entries, of course.
17:05:16 <truebrain> `/* Cargo names (fix pluralness) */`
17:07:37 <truebrain> I did not test it, sorry π
17:08:02 <peter1139> Oh should I do that too? ;0
17:12:26 <peter1139> (Should I squash that one...)
17:15:39 <truebrain> okay, now I can understand CargoPacket a lot better ..
17:17:00 <truebrain> `static_assert(sizeof(CargoPacket) == 32);` is still valid \o/
17:19:20 <truebrain> CargoPacket has `Source()`, and CargoList had `SourceStation` .. returned the same value
17:23:49 <locosage> 4 bytes can probably be shaved off by removing index as I don't thing cargo packet needs it
17:23:53 <locosage> but that comes with pool item
17:26:31 <locosage> why is it 32 though? I see 4 + 2 + 2 + 8 + 4 + 2 + 2 + 2 + 1 = 27
17:27:13 <locosage> after removing union I mean
17:28:25 <locosage> does it align to the multiple of 8?
17:28:37 <peter1139> (lldb) print alignof(CargoPacket)
17:28:38 <peter1139> (unsigned long) $0 = 8
17:28:55 <truebrain> 64-bit systems tend to align on 64-bits, yes π That is their whole concept π
17:29:27 <locosage> lol, right, 64-bits is 8 bytes
17:29:43 <locosage> I fixed money but forgot to think about alignment as well
17:29:47 <peter1139> I think if it was all 16 or 32 bit values it could have alignof 4.
17:29:57 <peter1139> But Money is 64 bits.
17:30:24 <truebrain> we could improve the speed ever so slightly most likely by moving the two StationIDs before Money
17:30:37 <truebrain> so it is (2 + 2 + 2 + 2) + 8 + ..
17:30:49 <truebrain> meaning feeding_share can have an access on an aligned border
17:30:50 <peter1139> No, the CargoPacketPool adds an index.
17:30:53 <truebrain> but not sure it actually matters π
17:30:59 <truebrain> ah, so that is already the case π
17:31:12 <peter1139> That's why I shuffled it to start with 2 uint16_t
17:31:21 <truebrain> you are a smart cookie π
17:31:27 <locosage> removing index would drop it to 23->24
17:31:30 <locosage> but that means changing pool
17:31:39 <peter1139> Not smart enough to document it :D
17:34:48 <peter1139> truebrain, compilers always aligning anyway, that's why the structs were larger.
17:35:16 <truebrain> I know structs are always aligned; what I am not sure about, is if 64bit objects in a struct are aligned or not
17:35:27 <truebrain> I know it is up to the compiler, but I don't know what most compilers do there
17:35:37 <peter1139> Yes they are. That's why the structs were larger before shuffling them around.
17:35:50 <truebrain> ah, like that; yeah, fair
17:36:10 <truebrain> sadly, I am a bit too familour that structs are aligned by default .. in OpenDUNE that was a terrible thing π
17:36:16 <truebrain> there are many `pack` statements there
17:36:31 <truebrain> familour .. lol .. wth?
17:36:32 <peter1139> locosage, index is requied for saveload.
17:36:57 <truebrain> tnx for not letting me feel alone
17:36:59 <truebrain> I appreciate it π
17:38:39 <truebrain> so, back to payments ... on one hand, I am still: do industry-to-industry, and just fuck teleportation. It just however does mean we have a ton of other places to fix, like if a station modifies, all cargo should move with it, and not keep the old location
17:38:58 <truebrain> although it would be tedious for anyone to constantly abuse that mechanic in a game, but still
17:39:25 <truebrain> -however .. weird place for that word without commas ..
17:40:35 <truebrain> on the other hand, I am well aware this is a game, and people are very used to the fact cargo payment happens based on station-location, not industry-location
17:44:48 <truebrain> so this vector-based approach, which is basically what 11274 is, would keep the current system in place while addressing the exploits. But what I don't l ike is how to explain it. And there are two sides to that: to the user, and in code. As it has to be clear that this vector position is a fictive position, and doesn't have any actual meaning on the map.
17:45:23 <truebrain> for the user, what might work better, is to explain it in reverse: you get paid for the distance travelled between source station and destination station, but not for the parts the cargo wasn't in a train.
17:50:25 <truebrain> oeh, I broke regression .. nice!
17:50:32 <truebrain> how did I do that ....
17:50:42 <locosage> peter1139: well, it can be stored as continuous array in theory
17:50:51 <locosage> though at that point you don't really need a pool I guess
17:51:35 <locosage> truebrain: yeah, same as before, just no teleportation
17:51:45 <locosage> very few users need that level of detail anyway
17:52:51 <alfagamma7> Does daylength screw up cargo dist?
17:53:33 <truebrain> how does a PR where I only rename things break regression .. lol .. well, I did initialize memory correctly
17:55:11 <truebrain> although Tzero is true for this object ...
17:55:43 <truebrain> owh .. worse .. it is still MallocT'd
17:56:55 <truebrain> owh, no, I renamed a field
17:59:00 <truebrain> okay .. so that leaves the question, can we get the code done in a way that it would be understandable
18:00:59 <andythenorth> truebrain: I was about to say 'nah' but actually sometimes I build very short routes, and the stations have to be place artificially far apart otherwise there's no profit π
18:01:05 <andythenorth> so yeah, what you said
18:02:01 <truebrain> lol, when you use vectors, you can make very very very long routes ... as in, you can "teleport" from Y=0 to Y=station-spread .. if you start at Y=0, and need to go to Y=0, you can use that to go a lot of times to station-spread, while only moving x=2 or something
18:02:08 <truebrain> can that be abused? π
18:02:28 <truebrain> we always think about making more money by having shorter routes we do quickly
18:02:33 <truebrain> but what if we have very long routes? π
18:02:40 <truebrain> the inverse exploit!
18:17:55 <locosage> truebrain: I can try but I guess I'll wait for 11276 and 11278 if you intend to merge them first anyway
18:20:46 <locosage> truebrain: I didn't understand any of this
18:21:07 <peter1139> It's possible we don't need the pools any more... that they are a left-over from C-style allocations.
18:27:32 <locosage> truebrain: you can make the route longer than it needs to be by the station spread on each station + catchment on the endpoints
18:28:24 <locosage> but it still means vehicle needs to travel that distance so it's quite meh as an exploit
18:28:34 <locosage> it can probably help exploiting very small maps
18:28:54 <locosage> where optimal profit is reached outside of the map size
18:28:55 <truebrain> Still, reverse of your exploit .. just needs long routes and fast trains
18:29:20 <truebrain> Can be solved by capping the distance to the source and dest tile as manhattan
18:29:31 <truebrain> But requires more data to be stored π
18:30:19 <locosage> it's not better than just running the train whole length non-stop
18:30:26 <locosage> if I understand what you even mean
18:30:44 <locosage> maybe something can be gained by reusing the rail though...
18:30:49 <truebrain> Except that normally your source and dest tile is taken
18:31:04 <truebrain> Because of vectors however, the dest becomes really far
18:31:20 <truebrain> I will make a drawing later, at mobile atm
18:35:29 <locosage> is this what you mean?
18:35:48 <locosage> getting 30+ tiles of distance by moving cargo just a few tiles on the map
18:39:37 <locosage> can be compacted to this
18:40:18 <locosage> it is a bit of a problem I guess but much less than station walking as you only save on the track, movement is still fair
18:40:22 <locosage> and lose some on transfers
18:42:02 <locosage> actually, it's no better than just unloading at the end so not an exploit at all
18:42:50 *** Wormnest has quit IRC (Ping timeout: 480 seconds)
18:45:26 *** gelignite has joined #openttd
18:46:13 <locosage> ugh, you reuse the same cargo though...
18:48:28 <locosage> right, and only needs two stations...
18:49:44 <peter1139> Oh bum, I forgot to get a PP3.
19:07:44 <michi_cc[d]> I know an easy fix for all the cargo exploits: "Remove: Money" π€£
19:10:47 <truebrain> Can I subscribe to your newsletter? π
19:12:03 <truebrain> the main issue with OpenTTD as a competitive game: only a single currency
19:12:14 <truebrain> how ever you slice that, it gives trouble π
19:12:44 <truebrain> there are some nice youtube series going in-depth about game economy, and what works, and why things don't work
19:12:48 <truebrain> was really interesting (to me)
19:13:35 <truebrain> locosage: I see you discovered what I meant π It is the reverse of your exploit, where you make a lot of money by going really really far; less of an impact now there is no longer a cap till a moment it is a flat-fee π
19:13:57 <truebrain> but really, easiest solution would be to do a std::min(virtual-distance, actual-distance)
19:14:06 <truebrain> it just requires keeping track of the latter, which consumes another 8 bytes π
19:14:28 <truebrain> peter1139: I am a bit dissapointed .. I review your PRs, you don't review my PRs! π π
19:16:38 <peter1139> I know. I went out and then I have been eating.
19:17:26 <truebrain> sounds like the right priorities π
19:18:44 <truebrain> _jgr_: too lazy to look this up, but you allow bigger maps; still, X is never above 2^16? (and Y never above 2^16?) So it still fits like vanilla in a TileIndex?
19:19:28 <locosage> truebrain: it's 4 bytes as just needs a TileIndex and would even still fit 32bit alignment
19:21:38 *** Wormnest has joined #openttd
19:22:13 <truebrain> grr, pressing submit before you are done typing
19:22:42 <truebrain> I have no games from 51-68 .. such a specific and small range π
19:22:49 <truebrain> but it should be good π
19:23:09 <peter1139> Oh, right, the NULLs are recorded elsewhere now.
19:23:19 <truebrain> no more nulls in the "normal" objects π
19:24:58 <peter1139> Less is more but I can't keep writing that in reviews ;)
19:25:57 <truebrain> so for a while VSCode allowed authentication via just clicking one button .. but now I have to enter a code again, press Authorize, do my 2FA ..
19:26:32 <peter1139> Are you using the GitHub plugin?
19:29:06 <_jgr_> truebrain: X and Y are allowed to be individually larger than 16 bits, however the tile index is still 32 bits
19:29:07 <peter1139> Hmm, I updated the code to clear unused bridge slots and it's a bit weird because there are no unused bridge slots :D
19:29:22 <truebrain> _jgr_: ah, k, tnx .. that is good to know π
19:29:31 <peter1139> (There is with an older PR that I ought to review again at some point)
19:29:53 <_jgr_> In practice such maps don't see a lot of use
19:31:05 <truebrain> the reason I ask more is because for the payment PR, a TileIndex is used for vector, where X and/or Y can also be negative
19:31:09 <truebrain> so sort-of a TileIndexDiff
19:31:19 <truebrain> so I was wondering how compatible that would be with JGRPP
19:31:33 <truebrain> and now I know the answer is: "its complicated, but most likely fine" π
19:32:07 <_jgr_> You needn't worry about my branch for things like that
19:32:30 <peter1139> Probably fine, a 2^31 map is unlikely to be usable.
19:35:29 <_jgr_> Currently the limit is 2^28 tiles in my branch, this ought to be enough for anyone
19:36:20 <truebrain> _jgr_: I know you do; but in this case it shows my concern is not invalid, and we need to be a bit careful how to deal with it π
19:37:16 <peter1139> That's only 3GB for the map. 2^31 would be a 24GB map. There'd be a lot of tileloop updates :)
19:38:22 <truebrain> small Tile you say?
19:43:12 <truebrain> seriously ... this is enough, I am going to do something else .. typing turns out to be impossible ... π
19:43:43 <peter1139> Bigger tile because people want more than 15 companies...
19:44:04 <peter1139> And that is somewhat an issue for level-crossings.
19:44:27 <truebrain> michi_cc[d]: map rewrite when? π
19:44:30 <truebrain> π π Sorry π
19:47:06 <locosage> tried that vector exploit
19:47:31 <locosage> though I did it a bit wrong
19:48:01 <locosage> doing it with two stations isn't really reliable
19:52:42 *** gelignite has quit IRC (Read error: Connection reset by peer)
19:54:00 <peter1139> Two weeks ago I was sitting here in a jumper... and I cycled with arm warmers on...
19:56:27 <truebrain> haha .. how times have changed π
20:27:19 <Eddi|zuHause> i don't know which was the bigger mistake... leaving the house at 5AM after not having slept at all, or wearing a jacket which i had to carry with me in my hands all day.
20:29:16 *** geli has quit IRC (Read error: Connection reset by peer)
20:29:18 <Eddi|zuHause> this must be the global warming everyone has been talking about :p
20:29:39 *** gelignite has joined #openttd
20:32:27 <talltyler> I suspect no sleep is a bigger issue than an extra jacket
20:49:56 <andythenorth> this feature π
20:50:11 <andythenorth> is very something
21:01:19 <johnfranklin> I have not been sleeping at all
21:01:47 <belajalilija> andythenorth: What is it?
21:02:13 <andythenorth> group-by-shared-orders
21:04:56 <peter1139> Oops, I may have agreed to a 200km ride tomorrow... I had been thinking of a day off...
21:06:18 <peter1139> Group by grouped shared livery refit orders
21:06:34 <andythenorth> group by variant
21:09:58 *** HerzogDeXtEr has joined #openttd
21:15:16 *** keikoz has quit IRC (Ping timeout: 480 seconds)
21:21:28 <truebrain> sorry sir; was sure I enabled auto-merge π
21:21:50 <peter1139> That always needs about 5 clicks more than expected...
21:27:06 <andythenorth> I should draw more objects
21:27:08 <andythenorth> to fill the gaps in
21:30:46 <peter1139> Draw objects that look like rail tiles.
21:31:01 <peter1139> Eh, someone's probably already done that.
21:51:50 *** HerzogDeXtEr has quit IRC (Read error: Connection reset by peer)
22:07:07 *** Wolf01 has quit IRC (Quit: Once again the world is quick to bury me.)
22:15:27 <talltyler> Since when does the blast furnace have an outpost? Or is there just a layout that doesnβt?
22:21:31 <peter1139> How does HouseClass / _class_mapping work, and what is it for? It appears to only be read via act2 variable 0x66.
22:23:06 <peter1139> Okay, it's definitely broken.
22:34:02 <talltyler> Define broken, since I use house classes in ITL Houses and they seem to work as I expect them to
22:34:25 <peter1139> They're never reset.
22:43:43 <peter1139> So if you start one game with one house NewGRF, then start another game with another house NewGRF, the mappings from both are still in place.
22:44:22 <peter1139> Eventually all the mapping slots will be used up, but there's about 400 of them, so you probably wouldn't notice.
22:57:26 <talltyler> Huh, that sounds very broken indeed
23:10:32 <talltyler> I assume you have tested, etc
23:21:03 *** gelignite has quit IRC (Quit: Stay safe!)
23:30:56 <truebrain> We learnt this week we don't actually test our work
23:31:03 <truebrain> It the New Direction
23:35:07 <truebrain> Looks at that .. constexpr and functions, working together! π
23:35:20 <truebrain> You like it yourself too?
continue to next day β΅