IRC logs for #openttd on OFTC at 2023-04-06
⏴ go to previous day
00:00:06 *** Elouin has quit IRC (Quit: Ping timeout (120 seconds))
00:00:50 *** WormnestAndroid has quit IRC (Remote host closed the connection)
00:00:55 *** WormnestAndroid has joined #openttd
00:36:18 *** WormnestAndroid has quit IRC (Ping timeout: 480 seconds)
00:37:16 *** WormnestAndroid has joined #openttd
00:53:28 *** WormnestAndroid has quit IRC (Ping timeout: 480 seconds)
01:32:29 *** WormnestAndroid has joined #openttd
02:00:58 *** WormnestAndroid has quit IRC (Ping timeout: 480 seconds)
02:59:42 *** debdog has quit IRC (Ping timeout: 480 seconds)
04:41:26 *** WormnestAndroid has joined #openttd
05:49:36 *** sla_ro|master has joined #openttd
05:55:16 <pickpacket> petern: happy belated birthday :D
06:36:05 *** D-HUND is now known as debdog
07:09:50 <petern> andythenorth: That seems like an option that shouldn't be an option...
07:23:52 *** nielsm has quit IRC (Ping timeout: 480 seconds)
07:45:34 <andythenorth> it has that air about it
07:46:07 <andythenorth> although it might be working, Chrome is now using less than 1GB
07:48:18 <andythenorth> I don't have any open tab for that
07:53:01 <andythenorth> was it breakfast?
08:08:37 <petern> I've had breakfast, or at least coffee.
08:09:59 <andythenorth> right OpenTTD time
08:10:18 <andythenorth> I need to date cheat backwards for fake daylength
08:14:26 <andythenorth> playing first proper variants game 😛
08:51:30 <petern> It should be new enough to have variants in it.
09:41:51 <andythenorth> I want variants of daylength
09:41:59 <andythenorth> summer should be slower than winter
09:45:10 <EmperorJake> We need a day night cycle first
09:47:07 <andythenorth> oops broke all my FIRS objects again
09:47:15 <andythenorth> stupid nml auto-assigned IDs
09:52:22 <andythenorth> it's supposed to make it easier for new authors
09:52:31 <andythenorth> obvious idea, with less obvious failure mode
09:52:53 <andythenorth> "I hope you didn't like your savegame too much"
09:54:36 <dP> I was thinking of doing some auto-assigning in grf-py recentlly
09:54:48 <dP> but yeah, needs to be quite more complex to deal with compatibility
09:54:57 <dP> probably go along with version management
10:15:33 <andythenorth> I am only using it for objects, because I can't be arsed to manually assign 254 IDs
10:24:04 <dP> I need auto-assignment because I do stuff like auto-articulation for length > 8
10:33:24 <andythenorth> Rubidium_: it's self-inflicted 😛
10:36:04 <petern> > Modify your extension so it’s compatible with the version 22.1.54915.0
10:36:24 <petern> Yeah, would be nice if you told me how to compile against the new version which isn't released yet...
10:37:00 <petern> auto assign ids: id labels?
10:41:12 <andythenorth> maybe GPT can do it
10:41:24 <andythenorth> did we integrate GPT into NMLC yet?
10:45:41 *** Orang has quit IRC (Quit: User went offline on Discord a while ago)
11:01:11 <FLHerne> When is andy not obsessed?
11:02:00 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
11:02:24 *** WormnestAndroid has joined #openttd
11:08:41 <andythenorth> how broken is it? 🙂
11:09:59 <TallTyler> That said, daylength typically has a two-pronged usecase of slowing down calendar progression and reducing production and costs so it's easier to keep up with the game (and often for scheduling roleplay), so I'm looking into the correct way to do that. I suspect it may require splitting into three time units (calendar = date, admin = real-time units, economy = never shown) where economy speed can also be changed, to do industry/to
11:10:27 <andythenorth> does Horse need more random?
11:10:35 <andythenorth> engine isn't random 😛
11:11:26 <petern> Reducing production seems to be separate from daylength to me.
11:11:32 <TallTyler> That link should be 100% functional, I was ready to PR it but wanted to present a solution to aforementioned economic scaling usecase at the same time. I did cargo scaling and station ratings, then realized I might be going about it the wrong way: https://github.com/2TallTyler/OpenTTD/tree/economy-scale
11:12:05 <TallTyler> The economy scale branch is also fully functional and improves the game significantly for me
11:13:40 <TallTyler> But I worry that those things can technically be done in NewGRF (but not actually, some house sets aren't GPL so it would be a question of decompiling to NFO, learning to make changes there, and then only being able to use it in private games)
11:15:41 <TallTyler> I was actually considering scaling cargo values with the economy, so everything happens slower but you get paid that much less for it 🙂
11:19:28 <TallTyler> EmperorJake: We briefly discussed daylength the other day; what are your use cases for slowing down the entire economy? (town/industry cargo, station ratings, maintenance costs, etc)
11:22:06 <andythenorth> have to double track everything
11:22:40 <andythenorth> what even is this game? v
11:23:05 <andythenorth> just loads of train tracks everywhere, how do I win? 😛
11:23:37 <petern> Place block signals every tile.
11:23:39 <TallTyler> Slow down cargo production, then you can do single track 🙂
11:29:27 <EmperorJake> TallTyler: Exactly one of the reasons why I prefer a slowed down economy, you need far fewer trains 😉
11:30:00 <andythenorth> I looked at upstreaming JGR's object-per-grf limit patch
11:30:21 <andythenorth> but it's more than I understand right now
11:33:02 <EmperorJake> TallTyler: I just find a slower paced game a more pleasant experience, you're no longer limited by the classic TTD meta of needing to provide fast, frequent service to all of your industries. Like I said I have cargo generation at about 1/10th in proportion to day length, and the slowed station rating decay means the trains can be much less frequent. This makes the game feel more realistic as cargo trains aren't very frequent in
11:33:44 <andythenorth> I could just nerf FIRS production for the same effect 😛
11:34:04 <TallTyler> EmperorJake: Would simply scaling cargo and then using the 100% station ratings GRF give the same effect? Are there other things you'd miss?
11:34:10 <EmperorJake> Town cargo on the other hand, I will turn up much higher than industry cargo, because I want my commuter trains to be full and requent
11:34:57 <TallTyler> andythenorth: The first commit you linked looks a lot like #10408 🙂
11:35:06 <petern> Scaling values vs scaling intervals. I suspect scaling intervals would work better for < 100%
11:35:07 <EmperorJake> TallTyler: I'm not quite sure, I'll have to give it a playtest
11:35:40 <petern> If you produce "5", but the scaling is 10%, you need to produce 0.5, which is, er...
11:35:52 *** JohnFranklin has joined #openttd
11:35:52 <JohnFranklin> I use day length factor 20, all cargo generation factor 0.5 (sqrt 2)
11:35:57 <petern> If you limit to "at least one", then your scaling is 20% for that...
11:37:17 <JGR> TallTyler: I cherry-picked that PR before I increased the per-GRF limit
11:37:51 <TallTyler> Yes, scaling intervals is probably the way to go, which is why I'm considering "scale the entire economy"
11:39:08 <petern> Or scale value but store a remainder somewhere.
11:41:04 <TallTyler> Dealing with remainders seems unnecessarily complex, I'd rather just scale the interval
11:41:56 <TallTyler> One big difference between full daylength and scaling just the economy while still using real-time administrative intervals is that the slowest speed is about 12.5%, so industries always produce at least once per month
11:41:58 <FLHerne> oh, I forgot to update the regression thing
11:42:05 <JohnFranklin> I don't know programming, but I just want to ask what is "bump trunks from 72fev46edf9e1gf to sd6f35er2gf7r1gr" in each update
11:42:36 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
11:42:51 *** WormnestAndroid has joined #openttd
11:44:42 <andythenorth> JGR: also the feature testing would be needed?
11:44:43 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
11:45:30 *** WormnestAndroid has joined #openttd
11:47:01 <JGR> andythenorth: You'd need something along those lines, my feature test scheme is not in vanilla or the spec, and I doubt that there'd be interest in upstreaming it
11:48:31 <TrueBrain> lol, bit of a tricky one to upstream .. any GRF that uses an ID of more than 0x80 ruins the normal approach, I guess 😛
11:49:05 <petern> The extendedbyte scheme is just 0xFF.
11:49:21 <TrueBrain> so: any GRF that uses 0xFF ruins it 😛
11:49:27 <petern> The spec allows for 255 objects, which is 0 to 254.
11:49:35 <TrueBrain> all reads should just have read extended bytes!
11:49:39 <glx[d]> Issue is for 0xFF in non extended version
11:50:03 <petern> So I think that should be fine to treat as extended, but maybe there's issues elsewhere.
11:50:30 <TrueBrain> `limited to 255 to allow extending Action3 with an extended byte later on.` it is even in the docs!
11:50:38 <TrueBrain> but that would make upstreaming it rather trivial, not?
11:51:22 <JGR> I didn't fancy checking all the object GRFs to see if they try to use ID 0xFF anyway
11:51:35 <TrueBrain> I can understand that fully 🙂
11:52:04 <TrueBrain> especially as nothing seems to validate if it isn't 😛
11:52:31 <TrueBrain> just silently ignored, if I am reading this right?
11:53:02 <andythenorth> the worst that happens is some object doesn't get shown if it used 0xFF
11:53:13 <TrueBrain> andythenorth: no, the GRF will be invalid 🙂
11:53:15 <andythenorth> it's out of spec, just break the grf 😛
11:53:18 <JGR> It should print a message at grf debug level 1
11:53:35 <petern> I'm willing to risk it 🙂
11:53:51 <TrueBrain> I can scan all current BaNaNaS content to see if it ever happens 🙂
11:54:03 <TrueBrain> but that is just for content on BaNaNaS, ofc
11:54:28 <andythenorth> grf authors should pay an SDK license for that level of service 😄
11:55:03 <glx[d]> If a grf uses 0xFF it will error anyway it extended byte is introduced, not enough data
11:55:08 <petern> if (id + numinfo > NUM_OBJECTS_PER_GRF) { would catch it
11:58:16 <TrueBrain> petern: that is on the action 0
11:58:21 <TrueBrain> the action 3 would still allow 0xff, not?
11:59:37 <petern> Yes, but it's an out-of-bounds read of objectspec if it doesn.
11:59:53 <TrueBrain> owh, don't get me wrong, it returns an error on `-dgrf=1`
12:00:11 <TrueBrain> but it would be valid; where after changing it to a extended byte it would be an invalid grf
12:00:46 <petern> I think "undefined" is better than "valid"
12:01:03 <TrueBrain> "it will load" vs "it will not load" is what I meant 😉
12:01:22 <petern> If you used 0xFF you'd hit an undefined out of bounds object spec, because you can't define it in the action 0, and, well it's out of bounds.
12:02:10 <TrueBrain> in general, the action3 seems to be missing some validation, doesn't it?
12:02:26 <TrueBrain> you can read out-of-bound pretty easily, or am I missing a validation somewhere?
12:02:54 <TrueBrain> I assumed `objectspec` was a fixed size, but it isn't 😛
12:03:02 <TrueBrain> so now I am somewhat scared of the code I am reading ..
12:03:24 <petern> It is a fixed size, but it's only allocated if objects are defined
12:03:44 <TrueBrain> `_cur.grffile->objectspec.resize(id + numinfo);` exists
12:03:53 <petern> That's not in vanilla 🙂
12:04:09 <TrueBrain> sometimes GitHub confuses me 😄
12:04:25 <petern> I do actually have a branch that changes it all to be vectors, but I've not PR'd that yet.
12:05:04 <petern> There's also the other fun fact that for many of these things there's an global array that is used, and the data is copied into there, but it's also left in the newgrf data as well. Duplicated.
12:05:21 <TrueBrain> petern: I am not surprised, not even in the slightest 😛 😛 😛
12:05:52 <petern> Anyway, we have a long Easter weekend, so maybe I can get it up to date 🙂
12:06:00 <petern> (It's only months old rather than years...)
12:06:22 <TrueBrain> okay, so in vanilla a 0xff would be an out-of-bound read
12:06:30 <TrueBrain> so yeah, what-ever we do, we would improve the situation 😛
12:06:38 <TrueBrain> any GRF that breaks, would already do .... weird shit
12:09:15 <petern> It's possible my branch already has stuff like that.
12:09:30 <TrueBrain> so get going already 😄
12:10:50 <TrueBrain> GitHub doesn't like me loading newgrf.cpp it seems ... in blame mode 😛
12:11:31 <TrueBrain> guess in JGRPP it is also missing a check if buf->ReadExtendedByte() is within uint16, just to warn authors when they do something silly there .. it is now just silently casted to an uint16
12:12:20 <petern> hmm, 50cm cables are surprisingly short.
12:12:21 <FLHerne> in PR ^, can anyone suggest why it's decided to add a zero offset to the Action5?
12:12:38 <FLHerne> (which is what regression is objecting to)
12:12:54 <FLHerne> I think it's harmless, but I don't see why my change causes it
12:12:57 <petern> I wonder if they included the length of the connectors.
12:13:19 <JGR> An extended byte is an inherently 16 bit value
12:13:39 <TrueBrain> Then ... I have to make some fixes in TrueGRF 😛
12:14:24 <petern> Yeah, there's no ExtendedWord leading up to 32bits.
12:14:28 <TrueBrain> I keep being surprised by NewGRF specs .. it is so illogic 😛
12:14:36 <petern> ... but maybe we should reserve that.
12:15:19 <glx[d]> Yeah it's byte 0x00-0xFE or little endian word if 0xFF
12:15:21 <TrueBrain> so we have bytes, words and dwords .. and extended byte can only become a word .. yeah, I just .. what-ever. It is what it is 🙂
12:16:17 <glx[d]> Utf8 encoding for numbers ?
12:16:53 <TrueBrain> at least that wastes less byte s:P
12:17:16 <glx[d]> And openttd knows how to parse that already
12:18:05 <JGR> That'd probably be "fun" with action 6 😛
12:18:29 <glx[d]> But extended byte stuff is mostly intended for human writing nfo
12:19:10 <TrueBrain> it is just silly; but old things are old!
12:19:46 <glx[d]> And it's also simpler to handle on decode side
12:20:33 <glx[d]> 0xFF? Read the next 2 bytes as a word
12:23:23 <petern> Stations have the same bounds issue 🙂
12:24:24 <JGR> Stations are a bit more complicated because of the text ID stuff, and the wacky layout mechanism
12:24:42 <petern> I'm just looking at MapSpriteGroup here.
12:25:16 <glx[d]> Stations can reference layout from other stations
13:18:38 <andythenorth> what if player could select the amount produced for each output cargo at an industry
13:19:23 <andythenorth> the rubber cargo here won't be used, it's nowhere near the consumer industry
13:19:45 <andythenorth> these are ports, maybe each one should have a single output cargo 😛
13:21:31 <petern> Hmm, I'm not sure how to layout my synths and keyboards 😒
13:23:17 <dP> andythenorth: you mean if you don't want to take rubber it produces more of other stuff or what?
13:23:46 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
13:23:50 <andythenorth> like a slider for the output on each 😛
13:24:05 <dP> I'm very much missing the way to make station start accepting cargo in steeltown though
13:24:27 <andythenorth> you trying to use 'refit any available'?
13:25:12 <dP> I think jgrpp has it, maybe can be ported
13:25:20 <andythenorth> so what if the industry produces depending on other nearby industry count?
13:25:35 <andythenorth> so if I plant a 'rubber silo' nearby, the port produces rubber
13:25:35 *** WormnestAndroid has joined #openttd
13:25:47 <andythenorth> otherwise it's 0
13:26:53 <JGR> I pretty much never use refit any available
13:27:24 <andythenorth> it's prone to making a mess with cdist
13:38:50 <petern> I don't think I've ever used station refit.
13:42:25 <dP> well, in vehicle goal it's pretty handy
13:42:59 <dP> otherwise you need bajillion of stations and lines
13:46:49 <andythenorth> industry window -> open story book -> choose which cargos to produce
13:47:07 <andythenorth> "that will go well in multiplayer" 😛
13:50:22 <dP> chose by nearby station type
13:50:37 <andythenorth> not sure there's a var for that 😛
13:51:34 <andythenorth> I could make production adapt to the % transported
13:54:36 <EmperorJake> I use "refit to available cargo" more and more lately, of course it often loads stuff you don't want it to but you can filter it out with "load by cargo type"
13:54:37 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
13:55:54 *** WormnestAndroid has joined #openttd
13:56:30 <petern> dP: That's the point of the game 😉
13:57:32 <andythenorth> the point of the game is decorative objects
13:57:54 <andythenorth> unrelated: the FPS is lolz when that is on the game viewport
13:58:49 <JGR> You don't need separate lines or stations for everything
13:59:24 <JGR> Single use point to point infrastructure is a bit dull
14:03:15 <dP> petern: I prefer to play the game where the point is transporting stuff, not building stations :p
14:04:23 <andythenorth> I should delete the gif eh 😛
14:58:46 *** sla_ro|master has quit IRC ()
15:14:54 *** gelignite has joined #openttd
15:41:43 *** garlic_bread42 has quit IRC (Quit: User went offline on Discord a while ago)
15:52:58 *** WormnestAndroid has quit IRC (Ping timeout: 480 seconds)
15:53:34 *** WormnestAndroid has joined #openttd
16:01:35 *** gelignite has quit IRC (Quit: Stay safe!)
16:34:15 <TrueBrain> `/* FIXME -- GetTileTrackStatus_Station -> animated stationtiles hardcoded.....not good */`
16:34:17 *** sla_ro|master has joined #openttd
16:34:21 <TrueBrain> I just love reading one of our old comments 😄
16:44:40 *** Wormnest has joined #openttd
16:57:43 *** gelignite has joined #openttd
17:24:56 *** tokai|noir has joined #openttd
17:24:56 *** ChanServ sets mode: +v tokai|noir
17:31:52 *** tokai has quit IRC (Ping timeout: 480 seconds)
18:48:54 *** HerzogDeXtEr has joined #openttd
19:31:06 <petern> Hmm, anyone know of a NewGRF that breaks one of the bounds we were discussing earlier...
19:42:47 *** lobstarooo___ has joined #openttd
19:50:51 *** lobstarooo___ has quit IRC (Ping timeout: 480 seconds)
20:07:09 *** lobstarooo has joined #openttd
20:14:10 <glx[d]> if it exists it's not working anyway
20:18:10 <pickpacket> I’m not sold on the idea of having to use a separate station for each cargo type. On the other hand I try to never use a station for more than one type of cargo anyway
20:18:31 <pickpacket> *separate station type
20:24:27 <glx[d]> as long as your station always has at least one available platform for drop off, it's not an issue to not use separate stations
20:56:32 *** nielsm has quit IRC (Ping timeout: 480 seconds)
21:20:00 *** Flygon has quit IRC (Quit: A toaster's basically a soldering iron designed to toast bread)
21:21:25 <petern> More than my main work project.
21:21:51 <andythenorth> most of my commits are like this:
21:24:11 *** Kuhnovic has quit IRC (Quit: User went offline on Discord a while ago)
21:24:32 <TrueBrain> So much like his work project :p
21:34:45 *** lobstarooo has quit IRC (Remote host closed the connection)
21:36:04 *** virtualrandomnumber has joined #openttd
21:37:02 *** virtualrandomnumber has quit IRC ()
21:43:41 *** keikoz has quit IRC (Ping timeout: 480 seconds)
21:50:18 *** sla_ro|master has quit IRC ()
22:14:46 <petern> Bah at secrets that require an 'arch-vile jump'
22:31:13 *** HerzogDeXtEr has quit IRC (Read error: Connection reset by peer)
22:39:18 <andythenorth> oh wait, no, that's bad 😛
23:03:53 *** WormnestAndroid has quit IRC (Remote host closed the connection)
23:03:55 *** WormnestAndroid has joined #openttd
continue to next day ⏵
