IRC logs for #openttd on OFTC at 2026-05-03
⏴ go to previous day
00:44:08 <Tirili> In CityBuilder mode, what can I do, if my station does not accept mail? It's a truck station right next to my HQ-city.
00:44:28 <mmtunligit> build it closer in
00:44:40 <mmtunligit> or get the city to grow to it
00:44:46 <mmtunligit> or use transfer orders
00:45:07 <mmtunligit> or turn on cargodist
00:48:44 <Tirili> My station is already in the center of the town. The town needs mail to grow, so I cannot grow it, can I? What can I do with transfer orders when no station accepts mail?
00:49:43 <Tirili> *OpenTTD.pro* CityBuilder 2K|2000pop|Temperate|1960|BETA
00:52:02 <mmtunligit> is it a bus station or a truck station
00:52:17 <mmtunligit> bus stations will only eve accept passengers
01:15:03 <talltyler> We all know andythenorth’s MacBook runs our OpenTTD infrastructure, but what if it could host real transit web infrastructure, specifically a GTFS feed?
01:21:03 *** WormnestAndroid has quit IRC (Remote host closed the connection)
01:21:22 *** WormnestAndroid has joined #openttd
01:21:35 *** WormnestAndroid has quit IRC (Remote host closed the connection)
01:21:47 *** WormnestAndroid has joined #openttd
01:50:58 <Tirili> mmtunligit, I had a combination of bus- and truck-station.
01:52:14 <mmtunligit> probe around with the build truck station tool until it tells you that it accepts mail, id expect it to be automatic in the middle of a city but you never know
01:52:28 <mmtunligit> when youre building it the build window gives you a preview of acceptance
02:03:34 <reldred> if you're using a truck station and still can't find mail acceptance one of your mods you've loaded has broken your cargo table
02:04:12 <reldred> mods are not pokemon and often times more like STI's and you should not attempt to 'catch them all' in a single game...
02:05:07 <emperorjake> Could be a bug in the house set too
02:06:18 <emperorjake> Seeing as it's a citybuilder server it's unlikely to be bugged because of changing GRFs
02:07:44 <reldred> Yeah, I missed the part about it being a server, I just thought it was citybuilder client which shouldn't have any impact by itself.
02:15:24 *** Wormnest has joined #openttd
02:36:58 <mmtunligit> honestly asking the other people on the server is probably the best bet
02:44:30 *** MinchinWeb[m] has quit IRC (Read error: Connection reset by peer)
02:44:47 *** MinchinWeb[m] has joined #openttd
03:01:24 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
03:01:26 *** WormnestAndroid has joined #openttd
03:01:35 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
03:01:40 *** WormnestAndroid has joined #openttd
03:01:43 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
03:02:05 *** WormnestAndroid has joined #openttd
03:43:27 *** Philemon has joined #openttd
03:46:56 *** Phileman has quit IRC (Ping timeout: 480 seconds)
04:31:21 <Tirili> mmtunligit, reldred, and emperorjake, thank you for your answers! Next time, I should check the preview of acceptance.
05:38:44 *** Tirili has quit IRC (Quit: Leaving)
05:39:50 <DorpsGek> - Update: Translations from eints (by translators)
06:35:18 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
06:38:05 *** WormnestAndroid has joined #openttd
06:57:09 <locosage> general advice for cargo acceptance in city-builder is to cover as many houses as possible with the station possibly with spread stations if allowed
06:57:57 <locosage> since houses have partial cargo acceptance you need to get enough of them in the coverage area for station to start accepting it
06:58:58 <locosage> but sometimes if city-builder mode is poorly designed you just can't get acceptance no matter what you do
08:26:27 *** Etua has quit IRC (Remote host closed the connection)
10:07:31 *** planetmaker has quit IRC (Ping timeout: 480 seconds)
10:07:31 *** XeryusTC has quit IRC (Ping timeout: 480 seconds)
10:10:24 *** planetmaker has joined #openttd
10:10:46 *** planetmaker is now known as Guest8503
10:14:21 *** XeryusTC has joined #openttd
11:01:34 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
11:01:52 *** WormnestAndroid has joined #openttd
11:49:24 <peter1138> Nethack 5 released :o
12:45:39 <ahyangyi> Hmm, so NetHack 4 used up the version number, and NetHack had to jump from 3 to 5?
12:56:19 <reldred> Never really got into Netbank but the various angband and its variations were always intriguing. ADOM I probably put the most hours into.
13:27:49 *** MinchinWeb[m] has quit IRC (Ping timeout: 480 seconds)
13:29:37 *** MinchinWeb[m] has joined #openttd
14:23:44 *** Wormnest has joined #openttd
14:35:39 <andythenorth> 4500 automated currency conversions to approve on a billing system
14:39:39 *** HerzogDeXtEr has joined #openttd
14:47:29 *** HerzogDeXtEr has quit IRC (Read error: Connection reset by peer)
14:51:53 *** HerzogDeXtEr has joined #openttd
14:53:48 <will_marshall_> This (flipping articulated vehicles in the depot) works great now, and the code isn't total gore. Obviously I'll need to do a lot of testing, but I'm wondering what the best approach might be to gather a list of state that is normally delegated to the 'lead' vehicle of an articulated unit, since that's not always apparent from the definition in Vehicle.
14:54:15 <will_marshall_> don't ask me why I didn't show it with a steam locomotive, I am still very stupid.
14:55:38 *** HerzogDeXtEr has quit IRC (Read error: Connection reset by peer)
14:59:27 <will_marshall_> There's obviously some logic in common with CmdMoveRailVehicle here, and there's variables that are obviously wrong if you don't swap them between the two ends of the articulated vehicle (subtype, status, max_age...). If it's just "read and understand the purpose of every var in Train" then I'll just get started.
14:59:28 *** HerzogDeXtEr has joined #openttd
15:01:29 *** HerzogDeXtEr has quit IRC (Read error: Connection reset by peer)
15:03:23 *** HerzogDeXtEr has joined #openttd
15:26:06 <andythenorth> best feature ever
15:26:21 <andythenorth> backwards garratts
15:26:40 <will_marshall_> what do you think the porthole on the back of the corridor tender is for?
15:26:40 <andythenorth> backwards torpedo cars
15:27:40 <will_marshall_> just have the courage to make your torpedos non-symmetrical.
15:28:10 <will_marshall_> asymmetric, that's what I meant.
15:28:26 <andythenorth> backwards tank engines
15:34:13 <will_marshall_> i'm detecting some sarcasm
15:48:51 <andythenorth> not about the feature 🙂
15:49:14 <andythenorth> more just being silly
15:49:27 <will_marshall_> jail for silly
15:49:42 <andythenorth> feature genuinely good
15:49:57 <will_marshall_> feature genuinely not surviving first contact with the enemy (other newgrf authors)
15:50:24 <peter1138> I see no complaints. Yet.
15:50:33 <will_marshall_> not going to post images I think that'd be picking on people
15:50:52 <will_marshall_> but i need to go look at how other sets are handling multiple units because it is obviously not how I expected.
15:51:22 <peter1138> Some sets do this weird thing where the entire train is built from a single consist of articulated vehicles.
15:51:47 <peter1138> Because heaven forbid the player build one that one carriage too short or too long compared to real life.
15:52:01 <will_marshall_> yeah, i'm looking at one of those and wondering why flipping one of those consists upsets things
15:59:30 *** gelignite has joined #openttd
16:07:31 <andythenorth> "did I say that out loud" 😮
16:37:21 *** merni has quit IRC (Quit: User went offline on Discord a while ago)
16:52:14 <andythenorth> Grfs optin to articulated flip? 😬
17:03:08 <will_marshall_> andythenorth: I'd rather not but that's the obvious last resort.
17:04:18 <will_marshall_> I just need to work out if I've made a mistake or if the grf is... malformed.
17:12:44 *** gelignite is now known as Guest8522
17:12:48 *** gelignite has joined #openttd
17:18:55 *** Guest8522 has quit IRC (Ping timeout: 480 seconds)
17:21:30 <will_marshall_> I guess this is a bug in the set - sets using position_in_vehid_chain interchangably with position_in_articulated_veh
17:21:58 <will_marshall_> (0x41 rather than 0x4D)
17:25:27 <andythenorth> might be a mistake, but I think 0x4D also was a later addition IIRC
17:25:35 <andythenorth> is it an old grf?
17:27:54 <will_marshall_> I think the origins of the set are very old and there's been a fair bit of copy and paste incremental evolution. It might just be luck of the draw as to what got used.
17:31:23 <peter1138> Well, for compatbility, should those other vars handle the flippedness
17:35:14 <will_marshall_> they don't for non-articulated vehicles... if I try to modify the semantics of those vars it's going to be weird, but I guess the idea would be to make those read the position in the vehid chain (for example) relative to the oritentation of the vehicle rather than absolute within the formation?
17:35:59 <peter1138> I don't know, it was just a question :)
17:36:12 <will_marshall_> no, valid question 🙂
17:36:13 <peter1138> Is it that the grf is wrong, or that the spec is wrong.
17:38:37 <andythenorth> position within articulated veh chain should be relative to nominal front
17:38:54 <andythenorth> external context changes, internal content does not
17:39:34 <peter1138> I think that's a given.
17:40:38 <will_marshall_> my plan is to swap the bytes of var 4D for a flipped articulated vehicle, but I wouldn't dream of messing with var 40 or 41.
17:42:19 <will_marshall_> it's possible for the grf author to handle it with some sort of `vehicle_is_flipped ? position_in_articulated_veh_from_end : position_in_articulated_veh` type deal but that seems awkward to me?
18:06:35 <audigex> Those kinds of switch chains are always pretty awkward, especially if doing something complex
18:06:35 <audigex> It's not too bad if you just have one set of sprites and maybe a headlight overlay, but if you've got something more complicated it can get rather unwieldy rather quickly
18:06:50 <audigex> I've not tried that specific setup to comment on whetherit's grossly unwieldy or just a bit of a faff
18:24:50 *** gelignite is now known as Guest8525
18:24:55 *** gelignite has joined #openttd
18:31:41 *** Guest8525 has quit IRC (Ping timeout: 480 seconds)
18:32:02 <peter1138> will_marshall_, "some sets may not support this, in which case players can simply not flip these vehicles until the author fixes it" ;-)
18:51:36 <will_marshall_> As previously discussed, I am leaning towards the "you control the buttons you place" option.
19:13:04 *** MinchinWeb[m] has quit IRC (Remote host closed the connection)
19:13:21 *** MinchinWeb[m] has joined #openttd
19:20:57 <rito12_13> > Compatibility: Vanilla OpenTTD: >= 1.6.0, < 1.2.0
19:20:57 <rito12_13> How does that work?
19:28:43 <_glx_> if things work as expected it's not visible in content download for 1.3-1.5
19:32:44 <rito12_13> I don't see it in Online Content in 15.3
19:33:36 <_jgr_> I assume that the author wanted it to not be available at all in favour of the v2 GRF
19:34:30 *** WormnestAndroid has quit IRC (Remote host closed the connection)
19:34:40 *** WormnestAndroid has joined #openttd
19:40:55 <peter1138> Hmm, should NewGRF vehicle var 0xFE/0xFF return the individual vehicle's DrivingBackwards flag, or the consist's flag?
19:42:05 <peter1138> It currently returns the former, but the flag is never set individually.
20:03:54 *** HerzogDeXtEr has quit IRC (Read error: Connection reset by peer)
20:13:34 <audigex> Is there a functional difference?
20:13:48 <audigex> Wouldn't they both be the same at any given time, since it's distinct from reversed?
20:31:46 <peter1138> The functional difference is that the flag is never set on individual vehicles, only the first vehicle in the consist. The game logic always uses the state from the first vehicle in the consist, but the NewGRF variable, currently, uses the state from the current vehicle in the consist.
20:32:43 <peter1138> So my question really is... is that correct and does that make sense, or should it be more like the game logic and always test the flag from the first vehicle in the consist.
20:33:06 <audigex> Ah okay, I'm not sure I understand the nuance enough to give an informed opinion
20:33:26 <_jgr_> I assume that it's just an ordinary bug and it should read from the first vehicle
20:34:18 <_jgr_> Given that the flag isn't guaranteed to be in any particular state on the other vehicles
20:36:18 <will_marshall_> Should probably always be the consist lead vehicle's flag, just reduces the cognitive overhead on the grf author.
20:36:19 <audigex> My instinct would be that it should be for the consist since the rear vehicle seems unlikely to be going in a different direction to the first
20:36:41 <audigex> Unless we go down a route later with shunting where we can join trains
20:37:02 <will_marshall_> still holds even if you can split/join trains
20:37:43 <audigex> If you can split and join then plausibly you could join a train going backwards to a train going forwards, and have two states within the consist
20:37:43 <audigex> But presumably they'd just keep their own state
20:39:17 <will_marshall_> I think I follow you.
20:40:30 <peter1138> If you consider that was "two consists joined together" then it's still the consists state, I guess... But that's not really correct because the entire thing is the consist :D
20:40:58 <will_marshall_> Yeah, this is further to the discussion we had the other day.
20:41:35 <will_marshall_> The alternative to that, Peter, is that two consists joined together (front-to-front, say) you need to invert the flip state on one half of them so that the vehicles relative directions are correct?
20:41:43 <will_marshall_> Academic discussion I know.
21:02:48 <peter1138> Hmm, I wonder if the mess of Vehicle can be made a bit saner.
21:03:02 <peter1138> e.g. EffectVehicle and DisasterVehicle do not need nearly all of that stuff...
21:08:01 <audigex> peter1138: Yeah it would presumably need a new name to differentiate
21:08:01 <audigex> Essentially my "vision" is that you'd join two (or more) independent Consists/Trains into a (something), but each train would still have it's own orders and identity, properties etc... they'd just happen to run together
21:08:01 <audigex> I don't even know if it would be necessary, it was just a thought experiment response to a conversation about how it might be hard for the game to conjure new trains up when splitting, so I figured the solution might be to keep the two logical trains separate but merge them into a physical single (thing) while running together
21:08:01 <audigex> With that said, I don't want to get bogged down in this because it's just a vague thought on a feature I doubt will ever happen
21:34:30 *** Wolf01 has quit IRC (Quit: Once again the world is quick to bury me.)
21:52:35 *** WormnestAndroid has quit IRC (Remote host closed the connection)
21:52:37 *** WormnestAndroid has joined #openttd
22:43:52 *** MinchinWeb[m] has quit IRC (Ping timeout: 480 seconds)
22:45:48 *** MinchinWeb[m] has joined #openttd
23:25:15 *** WormnestAndroid has quit IRC (Ping timeout: 480 seconds)
23:25:43 *** WormnestAndroid has joined #openttd
23:51:30 *** Flygon has quit IRC (Quit: A toaster's basically a soldering iron designed to toast bread)
continue to next day ⏵
