IRC logs for #openttd on OFTC at 2024-08-22
⏴ go to previous day
02:12:01 *** debdog has quit IRC (Ping timeout: 480 seconds)
02:44:59 *** gnu_jj_ has joined #openttd
02:48:09 *** gnu_jj has quit IRC (Ping timeout: 480 seconds)
03:55:15 <johnfranklin> Just found success.
03:55:15 <johnfranklin> X2000 finds himself happily running at 184 km/h at a 1.5-tile turn.
04:00:53 <johnfranklin> No, still no. When the turn is 0.5 tiles, only the head car wants to travel at 111 km/h, others are still 88 km/h.
04:59:12 <_pruple> from the briefly visible debug window, it looks like the property isn't set for the coaches? Perhaps you're setting it, then unsetting it again.
05:05:43 <johnfranklin> Not really? The x2000 is using same MU wagons as those non-tilt MUs. The problem is the MU wagon cannot be set `curve_speed_mod` value from `livery_override`.
05:06:58 *** brickblock19280 has joined #openttd
05:06:58 <brickblock19280> You could look at the parent if it's available as regular callback
05:07:39 <johnfranklin> `curve_speed_mod` cannot be set as callback
05:08:13 <_pruple> johnfranklin: I bet it can. Alternatively, why not set it to the maximum value any vehicle uses, if the value for the whole train is the lowest?
05:08:28 <johnfranklin> No, I remembered it wrong. It can be set as callback but not in a switch.
05:11:01 <_pruple> sets like NARS, UKRS etc with tilting train sets would always have TRAIN_FLAG_TILT set for the passenger wagons, and it only applied if the loco had it set too.
05:12:31 <johnfranklin> _pruple: If that, different consists of the train will have different speed when passing the curve. For non-tilt MUs, when the front part is passing the curve, it behaves normally; when the MU-cars part is passing, it will behave as tilt trains
05:12:45 <_pruple> that's not what the spec says
05:13:06 <_pruple> "If different vehicles in a train have different curve speed modifiers, the lowest value wins. "
05:13:11 <johnfranklin> johnfranklin: When the front part is passing, it is 111 km/h as tilt, when the MU-cars part is passing, it is 88 km/h
05:13:49 <johnfranklin> This is strange and not as said in the spec
05:13:55 <_pruple> have you tested it in regular openttd, rather than jgrpp?
05:23:11 <johnfranklin> same, notice there is a "111 km/h" when the head passing the curve, but "88 km/h" when the mu wagons
05:25:13 <_pruple> I'll make an extreme case test grf and try it out
05:27:47 <johnfranklin> But for 1.5-tile turn, it is happy passing at 184 km/h. So I doubt it is openttd-itself problem.
05:28:47 <_pruple> if the carriages have the prop set to 0, the train shouldn't be getting any corner speed boost on any curve
05:29:48 <johnfranklin> NO, other trains are also 184 km/h instead of 132 km/h
05:41:55 <_pruple> well, it seems to work as advertised here, but it takes a little while for the train to slow down when it hits the curve - it's not instant. So that might be what you're seeing as a phantom "111 km/h"
05:43:50 <_pruple> if you set the prop on the passenger wagons, does everything work as expected? ie, do the non-tilt MUs still go around at 88 km/h, and the tilt MUs faster?
05:45:59 <_pruple> Sure. set it as the default property for the vehicle.
05:53:20 <johnfranklin> Yes, success! Train 2 is non-tilt, it can only go at 88. Train 1 is tilt (curve speed mod 0.2), it goes at 105 as expected 88*1.2.
05:54:50 <johnfranklin> But the problem is, why is the default speed of 1.5-tile turn 184 instead of 132?
05:57:35 <_pruple> maybe because your carriages are made up of multiple small articulated parts, so the curve sections are more "vehicles" apart.
05:58:03 <johnfranklin> Thanks for information
06:48:22 <peter1138> Rail types also have a curve speed value.
06:48:49 *** ChanServ sets mode: +v tokai
06:49:36 <peter1138> But indeed, the curve calculation does not seem to take vehicle length into account.
06:50:34 <peter1138> Not sure it needs to.
06:50:43 <peter1138> It just counts the number of curves the train covers.
06:51:45 <peter1138> Hmm. there is a one bit that does.
06:55:38 *** tokai|noir has quit IRC (Ping timeout: 480 seconds)
07:02:32 <peter1138> Also the curve slow down actually only happens when the train is fully on the curve.
07:02:54 <peter1138> When only the lead engine is on the curve, it's only seen one curve at that point, and that isn't enough to trigger a slowdown.
07:09:09 <peter1138> I misread. The whole thing depends on it 😄
07:12:11 *** HerzogDeXtEr has joined #openttd
07:12:21 <peter1138> Back in the day this wasn't really noticable becuase things like UKRS had shortened wagons that already had a low speed limit.
07:22:36 <johnfranklin> Oh? This is considered by Peter as a bug 😄
07:36:33 *** gelignite has joined #openttd
07:37:19 <peter1138> I did include the keyword spacebars...
07:39:12 <johnfranklin> This should be a bug
08:00:31 <truebrain> I expected pics of spacebars
08:25:06 *** Smedles has joined #openttd
08:27:08 <johnfranklin> Yes, CR400BF is promoted!
08:44:42 *** mindlesstux has joined #openttd
10:10:00 <peter1138> 265GB virtual memory. dotnet is quite aggressive...
10:17:39 <truebrain> can't map in enough memory! 🙂
10:32:49 *** mindlesstux has quit IRC (Ping timeout: 480 seconds)
10:37:55 *** mindlesstux has joined #openttd
10:40:18 *** akimoto has joined #openttd
10:54:20 *** gelignite has quit IRC (Read error: Connection reset by peer)
10:56:03 <peter1138> johnfranklin: Maybe there's past-history of someone deciding current behaviour is correct. Hmm.
10:57:44 *** gelignite has joined #openttd
11:02:47 *** reldred has joined #openttd
11:02:47 <reldred> I don't think that's necessarily a bad thing.
11:14:28 *** akimoto has quit IRC (Remote host closed the connection)
11:21:33 *** gelignite has quit IRC (Quit: Stay safe!)
11:32:14 <peter1138> Memory or behaviour?
11:41:35 <reldred> Beddie-bye times though
11:48:58 <peter1138> Well I'm confused what you mean then 🙂
11:51:43 <reldred> More suggesting I don’t think it’s necessarily a bad thing for a dev to decisively decide what the correct behavior should be
11:56:06 <_pruple> having the speed be different for shorter wagons can't be logically justified, imo, since people use shortened wagons to represent both shorter and longer vehicles (eg, a 9-long coach made up of 3 3-length parts)
11:57:18 <_pruple> so the change is a good one
11:57:36 <reldred> Probably just hasn’t had anyone take a magnifying glass to it in a really long time
12:30:12 <audigex> Yeah I doubt it was properly intentional - likely just carried over from TTD days when varying lenghts weren't really a thing
12:33:18 *** HerzogDeXtEr1 has joined #openttd
12:39:46 *** HerzogDeXtEr has quit IRC (Ping timeout: 480 seconds)
12:39:55 <peter1138> "everyone knows it does that" 🙂
12:40:05 <peter1138> And the speed limit stuff is not from TTD, so we can't blame that 🙂
14:18:22 <peter1138> Anyway, me making a PR to fix an issue is not the same as "me deciding" unilaterally 🙂
14:18:23 <talltyler> And the fact that it's exposed to GRF authors is the reason calendar speed can't be faster than 12 minutes per year
14:20:24 <peter1138> Ooof, I remember fixing waypoints. Must be in a stash...
14:21:31 <peter1138> talltyler: Just because it's there doesn't mean it's used?
14:24:41 <peter1138> talltyler: It's not listed as a variable in NMLC
14:26:37 <peter1138> There's also room between 0x24 and 0x40 to add global vars.
14:27:42 <peter1138> Plus some gaps for whatever reason.
14:28:27 <talltyler> I don't think it should be added, if nobody has ever asked for it
14:28:44 <talltyler> I am replying to a question about why time can't go faster
14:28:56 <peter1138> Because everything breaks 😄
14:29:09 <talltyler> And wondering if that's really the case, or if TB and I were just overly cautious with NotDaylength
14:29:41 <talltyler> My original algorithm just scaled the number of `date_fract` ticks per day, and it worked fine 😄
14:30:34 <talltyler> But was theoretically a problem for any NewGRF which assumed the possible values of `date_fract`
14:30:50 <peter1138> Better to be cautious then allow it later than the other way.
14:31:01 <talltyler> That is my thinking
14:31:05 <peter1138> Just becuase NML doesn't expose it doesn't nothing using it in NFO.
14:31:11 <peter1138> But I somehow doubt it is used.
14:31:46 <peter1138> You can add a test to the varact2 code to check for the variable being accessed.
14:31:57 <peter1138> And then load a load of NewGRFs...
14:32:01 <talltyler> Me too, and if someone was using it for animation or something (instead of the animation counter like they should do) it would already be broken by the calendar going slower 🙂
14:32:47 <peter1138> Updating the animation counter marks the viewport dirty, so should really only done if the graphics are different.
14:35:49 <peter1138> Anyway, there's var 0x0A which is called "Animation counter" in OpenTTD's code. Hmm.
14:36:08 <peter1138> Yeah, that's the one to use.
14:36:33 <peter1138> I added some comments about not using the animation frame as a counter 🙂
14:36:40 <peter1138> I doubt FIRS has been updated yet though.
14:37:53 <talltyler> ...does FIRS do that?
14:39:14 <peter1138> It regularly animation frames, yes.
14:39:49 <peter1138> It wasn't until a few commits ago that updating an animation frame to the same value would also mark tiles dirty.
14:42:33 <peter1138> Personally I would just use fast-forward to speed up time 🙂
14:42:54 <peter1138> Definitely not the same though.
14:47:19 <_pruple> allowing GS to cheat the date sounds like the easiest solution to the use case
14:53:55 <peter1138> That's okay for skipping chunks of date but not really practical for regularly skipping half a day or whatever.
15:31:41 <peter1138> static void cheat_tntammox(buf)
15:31:49 <peter1138> I should stop looking at such old code.
15:33:46 <talltyler> I should stop making bugs.
15:34:37 <_jgr_> Nah, I hear that move fast and break things is trendy these days 😛
15:35:16 <_jgr_> I wouldn't stop doing stuff just because of fear of bugs
15:36:13 <truebrain> Since when did you get a job at CrowdStrike? 😛
15:37:52 *** XYZ has quit IRC (Ping timeout: 480 seconds)
15:41:25 <_glx_> I hope they finally learnt "do not trust any external input even if it's supposed to be your own"
15:42:48 <johnfranklin> What does external input in this sentence mean?
15:43:02 <johnfranklin> For example, the GitHub repo?
15:43:17 <_glx_> file or anything you read to do things, like updates
15:45:43 <johnfranklin> You cannot trust your own words?
15:46:03 <_glx_> in openttd world it would be opening network save without any validation
15:48:39 <_glx_> and we don't do that because it's stupid
15:49:03 <johnfranklin> “You cannot trust anyone on an openttd server including yourself?”
15:49:37 <peter1138> _glx_: Uh, well... 🙂
15:49:57 <_glx_> it's read as a savegame, with all savegame checks
15:50:09 <peter1138> Yes. Those are not exactly complete.
15:51:01 <_glx_> but we don't crash if there's an error 🙂
15:51:27 <johnfranklin> It’s read as a savegame, but it is actually virus?
15:52:01 <_jgr_> _glx_: That seems optimistic
15:52:59 <_glx_> yeah we may have some asserts in unfortunate places
15:53:28 <_glx_> but we run in user mode, not kernel mode
15:53:40 <LordAro> johnfranklin: conceivably, but it's more likely just to be some corruption
15:53:51 <LordAro> some bit flipped somewhere in the middle of the file
15:55:15 <_glx_> IIRC in crowdstrike case it was an update file full of garbage and the tool assumed it was properly formatted
16:09:02 <peter1138> > python3: error while loading shared libraries: libcrypt.so.1: cannot open shared object file: No such file or directory
16:12:45 <peter1138> I've never had a debian upgrade do this before.
16:22:52 <peter1138> > up 576 days, 23:38
16:22:56 <peter1138> That was a bit long.
16:26:59 <johnfranklin> Is Debian 13 out?
16:32:05 <Rubidium> and I'd expect Debian 13 in about a year
16:40:53 <Rubidium> you can even dist-upgrade Debian without requiring a reboot, which I must have done given the uptime's longer than the time this Debian version has been released
16:41:13 <LordAro> probably not especially recommended
16:42:15 *** gelignite has joined #openttd
16:44:22 <Rubidium> probably true, but if you can't update the kernel as that not in your control, a reboot does not do much more than when you just restart the services
16:48:45 <peter1138> Anyway that was buster (10) to bookworm (11). Now for 12.
16:49:08 <peter1138> That was a bad idea.
16:49:11 <peter1138> No wonder if broke.
16:49:17 <peter1138> I got the wrong release lol
16:49:37 <LordAro> did you not read the upgrade process ? :p
16:50:12 <peter1138> I know the process but got the wrong release name.
16:50:36 <peter1138> Not bad though, only 1 breakage.
16:51:17 <johnfranklin> I admire those who only use Linux
16:52:12 <peter1138> Should I look at FIRS' source?
17:01:26 <peter1138> > sprite: 3079 + (animation_frame / 4);
17:01:36 <peter1138> Hmm, so frames 0-3 use the same sprite.
17:01:54 <peter1138> > hide_sprite: animation_frame > 19;
17:02:07 <peter1138> And anything after that is invisible until it loops again.
17:02:15 <peter1138> But it still refreshes the tile.
17:03:52 <peter1138> This one-industry-tile-per-industry is... a pretty bad idea, tbh.
17:05:27 <peter1138> `chemical_plant_object_06_view_0_spritelayout_0` has 9 buildings on it, some conditional based on temp registers.
17:05:32 <peter1138> We created a monster.
17:13:52 <peter1138> I guess Frosch came up with this advanced sprite layouts stuff. It's ingenious. But hideous at the same time.
17:15:32 <peter1138> When you disable the dodraw flag...
17:16:08 <peter1138> But: OpenTTD is animating this tile (and marking it dirty) through all those frames even though it's not normally visible.
17:34:11 <peter1138> Not sure what is animating on this thing but it's redrawing enough?
17:36:11 <_glx_> crane might animate, not sure
17:48:16 <talltyler> Looks like the "sketch" animation style that's all the rage in corporate videos these days
17:55:38 <peter1138> It's possible to do all this without using the animation frame as a counter. But it would probably need a rewrite :S
17:57:55 <peter1138> talltyler: A quick & dirty hack to show what's being redrawn without using the block method.
18:08:45 <andythenorth> that industry has been copied from one that had smoke
18:08:52 <andythenorth> it probably shouldn't have animation set at all
18:09:19 <andythenorth> I have made a note here to audit for those
19:44:46 <peter1138> I'm making a note here, huge...
19:57:51 <andythenorth> GPT: please take a note
20:19:10 <peter1138> Hmm, I guess I should delete this branch that gets rid of variants.
20:33:43 *** HerzogDeXtEr1 has quit IRC (Read error: Connection reset by peer)
21:24:46 *** Smedles has joined #openttd
21:26:12 *** Smedles has joined #openttd
21:29:24 <andythenorth> I think you missed a parameter somewhere
21:30:23 *** keikoz has quit IRC (Ping timeout: 480 seconds)
21:31:37 *** nielsm has quit IRC (Ping timeout: 480 seconds)
21:54:11 *** gelignite has quit IRC (Quit: Stay safe!)
22:07:32 *** Wolf01 has quit IRC (Quit: Once again the world is quick to bury me.)
23:26:44 *** shield_wall has joined #openttd
23:26:44 <shield_wall> Is there some clear model for how costs are calculated in this game for a map?
23:28:47 <audigex> Depends what you mean. The code is open source so you can literally calculate it exactly how the game does, so that’s about as clear as that gets I guess
23:28:47 <audigex> But it’s not like you can just enter some parameters in an existing form and it’ll pump out some numbers for you
23:29:36 <shield_wall> I just wanted a boiled down model :}
23:32:23 <_pruple> things have a basecost, basecost is multiplied by things.
23:36:08 *** Flygon has quit IRC (Quit: A toaster's basically a soldering iron designed to toast bread)
23:55:11 <audigex> shield_wall: Income is based on distance travelled, but reduced by the amount of time taken. Take things a fairly (but not excessively) long way quickly and you'll make a lot of money
23:55:11 <audigex> Costs are mostly just set by the vehicle (which could be the base set, or a newGRF), they're relatively fixed
23:55:11 <audigex> To make money, keep your vehicles fairly full and use fast vehicles. Fundamentally OpenTTD's economy is pretty simple and most people end up finding they can "beat" the game easily and instead treat it as a sandbox to set themselves their own goals to achieve
continue to next day ⏵
