IRC logs for #openttd on OFTC at 2022-11-30
⏴ go to previous day
00:32:48 <petern> Urgh I can't see how to solve this 😄
00:57:33 <petern> Not even sure it is properly solvable.
01:05:13 <petern> If we swap an 8 with a 4, we need to move the train forwards by 2 to get it in the right place. But if that's at the edge of a tile with an intersection, which track do you follow....
02:18:18 *** Wormnest has quit IRC (Quit: Leaving)
03:11:44 *** D-HUND has quit IRC (Ping timeout: 480 seconds)
03:24:33 <dP> PeterNviaGitHub: Seems related to #6503
04:20:50 *** WormnestAndroid has quit IRC (Ping timeout: 480 seconds)
04:20:56 *** WormnestAndroid has joined #openttd
04:21:04 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
04:21:06 *** WormnestAndroid has joined #openttd
04:22:37 *** ShreksHellraiser has joined #openttd
04:23:18 <ShreksHellraiser> Hi, I'm working on a patch to add an alternative mode for right-click closing windows that doesn't close pinned windows. This is implemented by changing the right-click close windows option into a dropdown with 3 options, however since I changed the type of the setting from a bool to an int, the player will recieve a warning about an invalid setting until it is updated. With this issue, would
04:23:24 <ShreksHellraiser> this be acceptible to be put into a PR? I'm not sure of how I'd solve that problem otherwise.
04:38:57 <dwfreed> convert the config before the warning is generated
04:46:11 <ShreksHellraiser> Where would I start to do that?
04:58:26 <ShreksHellraiser> I have found a single mention of "converter"s in /settings.cpp, I'm not sure how to define one of these
05:02:30 *** ShreksHellraiser has quit IRC (Quit: leaving)
05:33:59 *** Tirili has quit IRC (Quit: Leaving)
05:58:57 *** WormnestAndroid has quit IRC (Ping timeout: 480 seconds)
06:01:20 *** WormnestAndroid has joined #openttd
06:09:22 *** WormnestAndroid has quit IRC (Ping timeout: 480 seconds)
06:09:36 *** WormnestAndroid has joined #openttd
06:21:25 *** Smedles has quit IRC (Remote host closed the connection)
06:25:47 *** Smedles has joined #openttd
06:50:04 *** HerzogDeXtEr has joined #openttd
08:54:08 <petern> #8424: 2008 comes back to haunt me 😄
09:04:06 <petern> Either we need to check neighbouring tiles (so testing 9 instead of 1 bucket, and we need to test vehicle length), or put vehicles in 2 buckets at once when their extents cross boundaries instead of x_pos/y_pos.
09:27:27 <petern> I tend to think the latter would be better.
09:28:36 <petern> Also. People who write "revert" when they mean reply...
09:37:02 <petern> Also not sure 2 buckets can work. Oh well.
09:45:24 <petern> May work but needs reworking, as the hash "bucket" is actually stored in each vehicle in the hash.
09:46:26 <dP> won't it need reworking either way?
09:48:57 <dP> storing bucket in a vehicle is kind weird anyway
09:49:21 <petern> It avoids memory allocation
09:49:31 <dP> though compared to the rest of vehicle running logic it's pretty normal xD
09:50:01 *** sla_ro|master has joined #openttd
09:51:00 <petern> Also, to solve the reversing thing probably will need knowledge about where the end of the train is (not the same as the position of the last wagon in the train)
09:51:57 <petern> Might be easier to not turn the train around, just make it run backwards...
09:53:05 <dP> have you looked at #6503 btw?
09:53:17 <dP> I tried to make some sense of vehicle coordinates
09:53:24 <dP> though barely remember anything anymore
09:55:19 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
09:55:51 *** WormnestAndroid has joined #openttd
09:56:08 <petern> It's probably the same thing as 10193. Vehicle reversing doesn't work correctly for shorter lengths. (Nothing to do with articulation in the subject)
09:56:59 <petern> For odd-length wagons, their sub-position needs to be adjusted when they reverse, even by themselves, which the reversing code does not take care of.
09:57:41 <petern> And to adjust the position you need to follow track which means if you reach an intersection you need to know which track to follow.
09:57:43 <dP> iirc it doesn't even reverse even lengths correctly
09:57:58 <petern> Even lengths by themselves are fine.
09:58:10 <petern> And even lengths where they are all the same length are fine.
09:58:24 <dP> well, the image in #6503 is for length 8
09:59:21 <petern> Logically an odd-length vehicle can be reverse without adjusting its position.
10:00:29 <petern> I think it's an off by one everywhere.
10:05:10 <dP> petern: iirc _initial_tile_subcoord shifts vehicles depending on direction so you can't just flip direction and leave vehicle in place
10:05:19 <petern> Maybe. You might also notice that trains appear to be able to drive off the end of the track by 1 sub position
10:05:19 <dP> changing direction moves trains
10:06:09 <dP> petern: that's exactly the first point of #6503
10:06:13 <petern> If you change the direction of an 8-length single train it doesn't get moved.
10:06:37 <petern> Okay, so if it's driven off the end (rather than being reversed off the end) that's a separate issue.
10:18:52 <andythenorth> petern: Boris Johnson does that
10:19:20 <andythenorth> strictly it's proper English, according to the dictionary
10:29:30 <petern> It's listed in any dictionary as "Indian English"
10:35:47 *** reldred has joined #openttd
10:35:47 <reldred> God my new South African manager does that too
10:38:41 <Pruple> something about doing the needful
10:42:24 <reldred> Kindly do the needful
10:42:42 <reldred> My new South African manager really doesn’t like the Indian workers we have.
10:42:57 <reldred> Though to be honest most of them are quitting on their own lately.
11:18:43 *** sla_ro|master2 has joined #openttd
11:24:59 *** sla_ro|master has quit IRC (Ping timeout: 480 seconds)
11:38:18 <FLHerne> it's a thing that turns SimCity 2000 worlds into Minecraft ones, someone's carefully made voxel replicas of all the pixel buildings
12:26:02 <petern> Okay, replacing the tile hash with an array of std::list (so it's a linked list without custom memory allocation) is so slow 😄
12:42:25 *** WormnestAndroid has quit IRC (Read error: No route to host)
12:46:40 *** WormnestAndroid has joined #openttd
14:02:25 <petern> Yeah, seems that all the vehicle enter tile stuff works based on the centre of the front engine, not the front of the front engine.
14:02:56 <petern> TrainCheckIfLineEnds seems to be the only function that takes account of length.
14:03:40 <Eddi|zuHause> that's why you could crash into opponents' trains in old versions, because engines stick over the edge of the track
14:04:01 *** ChanServ sets mode: +v tokai
14:04:37 <Eddi|zuHause> i'm not sure how we hacked that out
14:04:41 <petern> The more I look the more it's a major rework.
14:05:19 <petern> /* do not crash into trains of another company. */
14:05:19 <petern> if (v->owner != tcc->v->owner) return nullptr;
14:05:36 <petern> Literally just an owner check.
14:11:09 *** tokai|noir has quit IRC (Ping timeout: 480 seconds)
14:14:26 <dP> petern: yeah, you need some manual list over array implementations for it to work fast
14:15:07 <TallTyler> If the Highscore button were to disappear from the Intro GUI, where would it go? (#10203)
14:17:26 <dP> just put it next to exit 😜
14:19:56 <Eddi|zuHause> why do we need a highscorebutton anyway?
14:20:09 <dP> though removing hs button entirely kinda makes sense now with league tables
14:20:27 <dP> hiscores will be in the game if appropriate
14:20:42 <dP> if not replaced with custom league table
14:21:15 <petern> dP: I thought I'd go for simple-no-reimplementation first.
14:21:29 <petern> But that's obviously a no go, and with all the other issues, is only a band-aid anyway.
14:22:49 <dP> I got the same impression when I poked vehicle code years ago
14:24:54 <Azusa> TallTyler: May I suggest shoving it in a corner of the screen?
14:26:49 <dP> worst part imo is that vehicles don't even have reliable logical coordinates for movement, they move in screen coordinates
14:27:19 <dP> if for trains it's still possible to work out some semblance of a logical coordinate from them then for rv's I failed at it
14:28:14 <petern> Screen coordinates? I don't think that's right.
14:28:25 <petern> x_pos / y_pos are sub-tile positions.
14:29:10 <dP> yeah, so they're almost pixel coordinates except isometric
14:29:50 <dP> then for rvs you have cardcoded paths in those screen coordinates
14:30:05 <Eddi|zuHause> where's the problem with that?
14:30:06 <petern> sub-tile positions are the internal coordinates, they are not screen coordinates. o_O
14:30:11 <dP> and some wonky code that figures how to move in-between
14:30:43 <petern> They are easily converted because it would be silly not to be.
14:30:58 <Eddi|zuHause> you have a "large" coordinate grid in terms of tiles, and then you have a small 16x16 grid inside the tiles
14:32:14 <Eddi|zuHause> the 16x16 grid is kinda coarse when you consider extra zoom, though
14:32:29 <dP> they're made for visuals, you have different coordinates for different driving sides for example
14:32:44 <dP> or symmetric curves of different length xD
14:32:49 <petern> They're not made for visuals.
14:33:07 <petern> I think you're confusing sprite offsets, which are of course visual, with coordinates
14:33:48 <Eddi|zuHause> the hardcoded paths are just "which subtile coordinates belong to this lane"
14:33:58 <Eddi|zuHause> and different lengths are rounding issues
14:34:29 <dP> I'm not confusing with sprite offsets
14:34:48 <dP> in coordinates made for logic different lengths would be impossible
14:34:53 <Eddi|zuHause> to fix the different lengths you need to put the lanes at 0.5 offsets
14:34:58 <dP> as length of a curve would be a constant
14:35:35 <petern> Do you know how a differential works?
14:35:59 <petern> The inside turn is shorter than the outside turn...
14:36:41 <dP> how is that suddenly relevant?
14:36:53 <dP> you want to add full phy sim for each wheel?
14:36:56 <Eddi|zuHause> i think he means a left turn from NW to NE is different length than a left turn from NE to SE
14:37:33 <Eddi|zuHause> where he'd rather have rotational symmetry
14:37:40 <dP> yeah, there was even an issue somewhere for it
14:38:11 <petern> Anyway, sub-tile positions are not screen coordinates, they are a bit coarse though.
14:38:12 <Eddi|zuHause> like i said, to properly fix that you'd need to have a lane offset of 0.5
14:38:25 <petern> Where are the lanes at the moment?
14:38:35 <Eddi|zuHause> dunno, it's really irrelevant
14:39:47 <petern> 0 is tile edge, 16 is tile edge. Therefore 8 is tile centre. 4 is 1/4 and 12 is 3/4. I dunno.
14:40:10 <Eddi|zuHause> should be 6 and 10 or something
14:40:33 <Eddi|zuHause> in theory you can put 4 vehicles next to each other on one tile
14:43:34 <petern> I mean, it's pretty obvious the internal position of a vehicle would eventually end up being used for visuals...
14:44:15 <Eddi|zuHause> dP: it's made for efficient conversion, the game was meant to run on computers from 30 years ago
14:44:37 <petern> 8 is the centre of a tile.
14:45:12 <dP> petern: well, look at that table, sometimes it's 7 :p
14:45:55 <Eddi|zuHause> because it really should be 7.5
14:46:02 <petern> Probablk related to diagonals 8, 16 would be the next tile over, so the first entry for this tile is 7, 15.
14:46:36 <petern> 7.999 15.999, just a bit coarse...
14:46:40 <dP> anyway, try to convert those "logical" coordinates in any way that makes vehicle to have a smooth path :P
14:46:52 <dP> for rv's I couldn't find any, they jump all around
14:47:02 <dP> for trains it's also tricky
14:47:18 <Eddi|zuHause> sometimes it's better to round 7.5 to 8, and sometimes better to round to 7
14:47:31 <Eddi|zuHause> but at some point the rounding error will show
14:48:37 <dP> if you do coordinates for movement not visuals you can have as much precision as you like :p
14:48:45 <petern> pt = MapXYZToViewport(vp, veh->x_pos, veh->y_pos, veh->z_pos);
14:48:52 <petern> ^ NOW you have a screen coordinate.
14:49:07 <petern> the coordinates for movement are based on a 16x16 sub-tile.
14:49:20 <dP> that is basically just isometric projectionn
14:49:33 <LordAro> was it TB who was talking about having sub(sub)tile movement?
14:49:35 <Eddi|zuHause> dP: we can't have precision. we're limited to integer
14:49:50 <dP> rotating 45 deg and squishing hardly makes them less screen-ish :p
14:50:14 <dP> Eddi|zuHause: integers with more than 4 bits exist :P
14:50:56 <petern> If they were screen coordinates, you could just use them without conversion.
14:51:05 <Eddi|zuHause> dP: that just makes the rounding error smaller, it won't disappear
14:51:28 <dP> ok, whatever, forget word "screen", let's just call them dumb coordinates :p
14:51:37 <Eddi|zuHause> it'll still be 1 step different, whether you're in a 16x16 grid or a 256x256 grid
14:51:59 <petern> Okay, so lets remove coordinates.
14:53:25 <Eddi|zuHause> dP: which problem does that solve?
14:53:43 <Eddi|zuHause> dP: you could have arbitrary lane patterns with that. maybe.
14:55:05 <dP> problem of being nearly impossible to change anything about vehicle movement
14:55:35 <Eddi|zuHause> is this the point where i mention "state machine"?
14:55:45 <Eddi|zuHause> and the discussion detoriates?
14:55:51 <andythenorth> what does your state machine say about that? 🙂
14:56:03 <andythenorth> surely it knows the state, and next step?
14:56:20 <andythenorth> /me wonders if life is a state machine
14:57:00 <Eddi|zuHause> on some quantum level, the universe could be a state machine
15:02:07 *** Flygon has quit IRC (Quit: A toaster's basically a soldering iron designed to toast bread)
15:13:40 <petern> That definitely looks like a bodge working around something, not a fix.
15:14:09 <petern> If your radiuses are different, then the time to traverse them should be different.
15:14:21 <petern> Of course, whether the radiuses should be different or not is another matter.
15:18:36 <dP> how are those radiuses different? they're just different rotations of same turn?
15:19:06 <dP> they're different visually because of the projection, and that's, what I assume caused the difference in logical length
15:19:17 <dP> and why I call them screen coordinates
15:19:35 <petern> curves of different lengths
15:19:36 <dP> though reading the comments in the code it would be correct to call them map coordinates
15:21:54 <petern> Okay, so what a curve of different length.
15:26:08 <petern> So when driving on the left, driving from S to N is shorter than driving from N to S?
15:26:49 <petern> Would that be because the radius of the turn is different?
15:27:09 <petern> N->S is a tighter radius than S->N
15:27:14 <dP> that piece is symmetric, why would it be different?
15:27:36 <dP> they both have short curve and long curve
15:28:00 <dP> just curves have different number of steps in different directions
15:28:40 <petern> With drive on left, blue is N->S, red is S->N. Red is shorter than blue.
15:29:03 <dP> that distance is for full road with 2 pieces
15:29:26 <dP> lengths of individual curves are in the same pr before that
15:30:08 <petern> That's 2 curves, you never said 2 curves.
15:30:39 <petern> Anyway, just because the movement code is messed up doesn't make those screen coordinates :p
15:31:08 <dP> well, why else do you think those curves have different length?
15:31:26 <petern> Because the movement code is messed up when it comes to moving things diagonally.
15:31:43 <petern> Because the sub-tile resolution is not good.
15:32:06 <dP> why does it depend on sub-tile resolution at all?
15:32:26 <petern> Because vehicles existing on sub-tile points.
15:33:07 <petern> They can only move from one sub-tile position to another, they cannot be inbetween sub-tile positions.
15:33:11 <dP> Core movement function DoUpdateSpeed returns only one uint - the distance vehicle drove this tick (yes, it's fantastically named). Converting it into two dimensions is already moving from logic to visuals
15:34:05 <petern> It's taking a vector and applying it to coordinates. (Badly due to rounding)
15:34:50 <petern> So a state machine with f(progress) sounds great.
15:35:01 <petern> Where do you define f?
15:35:33 <petern> Which f applies when you're half way over a tile. Hmm.
15:36:27 <dP> important part is to have f as one-way function so movement is based on progress and visuals on x,y
15:36:42 <dP> and x,y are never used for movement logic
15:36:54 <petern> But then you don't know where a vehicle is.
15:37:13 <petern> TileIndex is just x & y after all.
15:37:36 <petern> TileIndex can be converted to screen coordinates, so it's just a screen coordinate, you say.
15:38:19 <petern> Why does Windows' Snipping Tool do strange things to the image when you draw on it...
15:38:32 <dP> well, yeah, you still need another coordinate at some point
15:38:54 <dP> but basically full logical coord would be (current_curve, curve_progress)
15:38:54 <petern> Assume tileindex is the centre of the tile.
15:39:24 <dP> where current_curve can be replaced with a tile and some direction in current impl
15:39:51 <petern> Better to be explicit.
15:41:25 <petern> And for the purposes of where we came from, you also need the current curve and the previous curve, perhaps.
15:41:44 <petern> Are curves "linear" Hmm.
15:42:05 <dP> yeah, and ideally even more than previous
15:42:54 <dP> yeah, would be nice to have max length for vehicle > 8
15:42:56 <petern> Also need the front and the rear for each part.
15:43:17 <dP> also iirc some road curves were 7 step long initially
15:43:37 <petern> Hmm, what's the curve for exiting a depot... pom te pom.
15:43:58 <dP> dP: though looking at Samu's PR I'm not sure where I got that impression
15:44:39 <dP> petern: some special "depot" curve?
15:44:58 *** sla_ro|master2 has quit IRC ()
15:45:53 <petern> What resolution for progress? 😄
15:46:12 <dP> I'd just use whateven doupdatespeed returns
15:46:21 <dP> no need to rewrite it too xD
15:46:23 *** sla_ro|master has joined #openttd
15:48:06 <petern> front = f(progress), rear = f(progress - veh_length). Assume no drifting...
15:48:44 <petern> Except when progress is shorter than veh_length, then it needs a different tile/curve. Oof.
15:50:04 <dP> yeah, may also not be a good idea to calculate coordinates backwards
15:50:30 <dP> or, rathet move progress backwards even if for coords
15:51:17 <petern> A front curve and a rear curve, progress them both at the same rate, the rear curve just lags behind by veh_length
15:52:17 <dP> I just thought of an idea of wagons passing current curve to each other
15:52:30 <dP> looks silly at first but may not be xD
15:53:03 <dP> if wagon has no curve just reuse prev
15:56:18 <petern> Extra bonus: angle is automatically determined based on f(front) f(rear) vector. Works mostly for trains with bogies but a little weird for RVs (but not particularly worse than currently)
15:56:42 <petern> Extra extra bonus: snap that angle over multiple parts to get rigid extra long vehicles 😛
15:57:13 <petern> Then allow more than 8 directions, because it's just visual. Christ, this is a different game.
15:57:55 <dP> oh, actually I remembered where I saw curve length 8, iirc they were like that but it was a problem for artuculated vehicles because while calculating movement first part leap one curve ahead so next part couldn't figure out where to go. So a hack was added to double first and last step of each curve that made them 10 long.
16:00:03 <dP> petern: yeah, and rvs can calculate coords based on some round curve formula and turn infinitely smooth on any zoom
16:00:38 <dP> well, not infinitely, progress resolution kind of infinite but eh
16:01:35 <petern> Progress for slow vehicles would benefit, and that's where it's painful now.
16:01:51 <dP> just make some assumptions on progress
16:02:06 <dP> actually even currently that can be done
16:02:24 <petern> Right, you can draw based on estimated progress, even if for collisions etc you only use the real progress.
16:02:49 <petern> Downside: rewriting shedloads
16:03:25 <dP> oh, more bonuses: 3d map becomes much simpler ;)
16:03:42 <petern> I saw a patch for that already
16:03:48 <Eddi|zuHause> at the cost of how much performance?
16:04:29 <dP> well, it doesn't take much performance by itself, depends on 3d map impl
16:05:01 <petern> Well ignore 3d maps, the cost to do the rest is more interesting.
16:05:27 <Eddi|zuHause> i mean the calculations needed to convert "progress" into map coordinates
16:05:40 <dP> worst case you can just cache it entirely
16:05:57 <petern> Potentially you only need to do it for drawing
16:06:01 <Eddi|zuHause> a "cache" still needs to be updated every game tick
16:06:34 <dP> no, cache is for curve shape, as it is progress resolution is at most 256*18 per curve
16:06:41 <pickpacket> what is a "backbone hub" and why would I want one? 🤔
16:07:23 <petern> You've already determined only 18 curves are needed?
16:07:40 <dP> per curve, max 18 steps atm
16:08:00 <petern> pickpocket, assuming openttdcoop, no you don't want one.
16:08:01 <dP> if we assume logical length doesn't change much in the PR that will be it
16:09:33 <dP> after the change 258*18, smooth ennough
16:10:02 <dP> if you want to change 18 you need to change vehicle speed calculations
16:10:27 <petern> Right, 256 progress is for 1 sub-tile step I guess.
16:11:23 <petern> So a straight NW/SE tile would be 16 * 256 long. But it's only needs 2 interpolated coordinates.
16:12:32 <dP> any curve can be interpolated, only issue is performance
16:12:45 <dP> but considering it's only for rendering probably no need to cache anything at all
16:13:34 <petern> You need to know where the curve is for collisions, but I guess that isn't too frequent.
16:14:19 <dP> collision don't happen on turns so just linear interpolation can be enough
16:15:01 <dP> yeah, you can't have rail intersection with road turn
16:15:14 <dP> so just assume it's a line
16:15:14 <petern> RVs need to not drive into each other too
16:15:44 <dP> rvs should use use logical coords ofc for that
16:15:53 <petern> Don't forget to add smooth cruves
16:16:03 <petern> ... larger radius curves
16:16:46 <dP> that makes them possible but I'd say out of scope of first pr :p
16:18:03 <petern> Curve for a non-drive through road stop could be interesting.
16:18:04 <dP> for smooth curves imo it would be better to take the next step and separate infra from tilemap
16:20:43 <petern> curves with elevation too, oh no.
16:22:57 <petern> Who cares if Wentbourne drops down to 1fps anyway...
16:23:48 <dP> 3d curve intersections with different vehicle heights
16:24:54 <dP> it all isn't that computational heavy, especially on movement logic
16:25:02 <dP> it may as well even run faster
16:25:42 <dP> you just add progress and swap curves
16:25:53 <dP> instead of shuffling sub-tile coords
16:27:48 <dP> btw, interesting question is how overtaking would be done in curve logic
16:28:48 <dP> my first idea would be to make some overtake coord and move it, say, 0->1->0 when overtaking
16:29:06 <dP> and shift to opposit lane curve when calculating f()
16:29:54 <dP> basically f_cur(progress)*(1-overtake) + f_opposite(smth(progress))*overtake
16:30:44 <dP> proper collisions would be tricky though
16:36:31 <petern> Curve for driving on the opposite side (useful for highways anyway) and then a curve to switch from one side to the other.
16:37:09 <petern> Path finding though... is that track bits or curves... hah
16:41:34 *** Tirili has quit IRC (Ping timeout: 480 seconds)
16:45:22 <FLHerne> petern: if you're totally rewriting vehicle movement, there's also the EZ smoothness thing
16:45:30 <FLHerne> unless that got fixed and I missed it
16:46:55 *** ShreksHellraiser has joined #openttd
16:47:40 <FLHerne> at 4x zoom, slow-moving vehicles are (were?) noticeably jerky because the movement steps are quite large
16:50:21 <FLHerne> (luckily someone fixed the website!)
16:50:41 <petern> There's a lot to read but we covered that
16:51:34 <FLHerne> oops, so you did, sorry
16:51:45 <petern> Hmm am I feeling ill or just lethargic....
16:52:02 <FLHerne> probably lethargic, it's this stupid dark-at-4pm thing
16:54:20 <dP> petern: for pathfinding you only need to know what curve continues to what
16:56:50 <TallTyler> Anyone working on a title game entry? There are only two entries besides mine and one of them uses a NewGRF and is therefore invalid. 😦
16:58:39 <FLHerne> pickpacket: for context, openttdcoop was a community that, among other things, organised co-op multiplayer games with the focus entirely on implementing high-efficency rail networks of various kinds
16:59:33 <petern> dP: But also the current way would still give you a path anyway.
17:00:15 <dP> yeah, if we're just talking removing subtile coords it probably won't affect pf at all
17:00:57 <dP> well, it needs to understand current position so a little bit but that's probably it
17:01:44 <dP> though it may not even need that, it's not like there are any options while on a curve
17:02:21 <dP> so curve progress is kinda irrelevant for pf
17:06:59 <petern> Hmm, how to define a curve...
17:12:32 *** Wormnest has joined #openttd
17:14:31 <dP> in the current feature set a curve is Trackdir afaict
17:14:42 <dP> the curve -> (TileIndex, Trackdir)
17:14:50 <ShreksHellraiser> Hi, I'm working on a patch for OpenTTD. I've changed the type of a setting from a bool to a uint8 and whenever the game is launched with the prior setting values you get a warning about a mismatch in type. I posted about this yesterday and was told to "convert it before the warning appears", I've been looking through the source and I found a mention of "converters" in a comment in settings.cpp,
17:14:56 <ShreksHellraiser> but I can't find where these "converters" are defined.
17:15:32 <mlt> Chatbots realy have come a long way
17:15:41 <dP> though I guess may need to add depot "curves" as such
17:17:21 <FLHerne> is settings conversion in saveload? I guess for settings stored in existing games there must be something in there
17:20:39 <TallTyler> Might be worth poking around through `src/saveload/afterload.cpp` to see if there are other settings conversions in there
17:21:35 <FLHerne> settings_sl.cpp looks relevant at a glance
17:22:08 <FLHerne> not sure if the warnings is in loading savegames or just the INI files on game start though
17:23:17 <ShreksHellraiser> The warning message is created in settings.cpp, after checking if a "converter" exists by checking the many_cnvt value in this
17:23:38 <ShreksHellraiser> It checks for a nullptr, and if it's not then it runs the function
17:25:17 <ShreksHellraiser> I'm pretty unexperienced with C++, so I'm having difficulty finding where one of these "OneOfManySettingDesc" objects is created
17:26:43 <LordAro> looks like it's the "load" values within the ini files
17:26:49 <LordAro> i.e. ConvertLandscape
17:28:29 <JGR> In general changing the type of things in the config file must be done carefully, as the config file is not versioned
17:29:19 <FLHerne> as of last year the config file seems to be versioned?
17:30:58 <FLHerne> although having a single incrementing number seems like it's asking for the same fun as savegame versions once patchpacks start using it
17:31:46 <TallTyler> I guess the other option is not changing the setting and adding a modifier key to also close pinned windows, like with the Delete key. Some users may be forced to change their workflow slightly but it would be more consistent with the Delete hotkey and https://xkcd.com/1172/ applies 😛
17:31:54 <JGR> I don't plan on touching that number
17:32:50 <ShreksHellraiser> Well if I wanted to add a modifier key to close pinned windows with right-click, what's the difference between that and closing the window by just clicking the x?
17:33:45 <ShreksHellraiser> I'm looking at the patch made by JRG to the settings loader, I'm hoping to target the main branch with this patch and I'm not sure that modifying the setting loading is the right way to go about this
17:34:19 <FLHerne> JGR: and you've pretty much put all the other patchpacks out of the running, so that solves it :D
17:58:12 <ShreksHellraiser> Alright I'm attempting to use the load field in the ini to run a function to convert from the bool to an int
18:17:25 <ShreksHellraiser> I added a ConvertRightClickClose function to settings_table.cpp right below the ConvertLandscape function. I then added the function as the load entry in gui_settings.ini for my setting. Whenever building I get a warning that the function is unused, and the printf I put in there for testing seemingly never gets called.
18:18:36 <ShreksHellraiser> Oh the function signature is defined in settings.h
18:19:54 <ShreksHellraiser> Well that's an automatically generated file, so I'm not sure how I add my function to it.
18:21:45 <ShreksHellraiser> Ah settings.h.preamble it seems
18:28:40 <ShreksHellraiser> whoops 1500 lines of errors again
18:42:06 <FLHerne> you might want to clear the build dir and re-run cmake
18:42:19 <FLHerne> sometimes it doesn't notice it needs to re-generate stuff
18:42:38 <FLHerne> there's probably a cleverer way than "wipe it and start over" but I don't know it :p
18:46:03 <ShreksHellraiser> It did end up regenerating the files, however the issue is that I was using [SDTC_VAR] instead of [STD_OMANY] like the settings that define load do
18:46:50 <ShreksHellraiser> But changing to [STD_OMANY] means there's a lot more changes I need to do
19:12:25 *** ag[d] has quit IRC (Quit: User went offline on Discord a while ago)
20:01:50 <andythenorth> work is over for the day
20:01:54 <andythenorth> what shall we do for lolz?
20:14:44 <ShreksHellraiser> Well thanks for the help everyone, I've submitted the PR (as the bot said), and I've gotta go now.
20:14:47 *** ShreksHellraiser has left #openttd
20:58:55 *** Montana has joined #openttd
21:37:11 <petern> Huh, tt-forums manages to do something odd that resets my zoom level...
22:09:31 <petern> Which side of the track is that bounding box on?
22:12:24 <petern> Hmm, waypoint is 0-5 and 11-16, so train is 7 to 10... very centred.
22:33:44 <Pruple> there's probably a reason (tm)
22:33:57 <Pruple> tunnel and bridge clipping?
22:34:02 <petern> Appeasing the sprite sorter is the main thing that springs to mind.
22:35:13 <Pruple> andythenorth: draw newgrfs
22:36:21 <Pruple> no voxels, just processing
22:38:24 <Pruple> hmm, some of those parts are drawing in the wrong order. sprite sorting strikes again.
22:39:02 <Pruple> or maybe they're not... no, they're fine. the towers are higher than the lintel.
22:43:28 *** Wolf01 has quit IRC (Quit: Once again the world is quick to bury me.)
22:50:39 *** nielsm has quit IRC (Ping timeout: 480 seconds)
23:21:02 *** HerzogDeXtEr has quit IRC (Read error: Connection reset by peer)
23:29:49 <LordAro> FLHerne: if cmake doesn't notice, that's a bug
continue to next day ⏵
