Transport Tycoon Forums

BW89 wrote:Found a little Bug/Glitch in 0.23.

This should be fixed now, thanks for the report. Disaster vehicles tend not to be used/tested much these days.

Bump trunk base from r27963 to r27698.

Uh... Is this supposed to be the other way around?

SimYouLater wrote:

Bump trunk base from r27963 to r27698.

Uh... Is this supposed to be the other way around?

It should be r27968. It was pointed out on github and fixed in the repo but I hadn't got round to editing it here.

Does your latest version on the first post have the slot feature in the restricted signals? I downloaded it and wanted to check how it works but it doesn't seem to be in there.
Also what does the "wait at PBS signal" I see in the commits do?

KeldorKatarn wrote:Does your latest version on the first post have the slot feature in the restricted signals? I downloaded it and wanted to check how it works but it doesn't seem to be in there.
Also what does the "wait at PBS signal" I see in the commits do?

These were both added in v0.19.0, so are in the version in the first post.
Both are these are hidden in the UI by default (as they non-trivial to use correctly).
There's a setting to show them in Interface -> Signals (advanced).
Wait at PBS is mostly useful when used together with slots (e.g. to conditionally wait if a slot is in a certain state without actually trying to acquire it).

I see, I'll play around with those. I'm thinking about including them in my pack if it's useful enough

JGR wrote:

German_RLI wrote:The load/unload by cargo type orders are great, however the auto-refit with this feature is broken - it tries to refit vehicles regardless of that setting, which results in train reffited to cargoes that wouldn't load. It is somewhere in economy.cpp HandleStationRefit() function (or in callees of that) but I have no idea how to fix that.

Thanks for letting me know. This only required a minor change which I've pushed to the repo.

Still doesn't auto-refit to allowed cargo if current cargo of vehicle is "no load", even if there are no cargo going to next station. May be it is related to initializing new_cid to current cargo of vehicle, but most probably, not - if I initialize new_cid = 1 at FIRS 3.0 Extreme, I get coal (allowed to load) vehicles refitted to alcohol (I think it is CargoID for Alcohol in that economy), and other vehicles (empty, with no_load cargo capacities) does not refit as with old initialization.

German_RLI wrote:

JGR wrote:

German_RLI wrote:The load/unload by cargo type orders are great, however the auto-refit with this feature is broken - it tries to refit vehicles regardless of that setting, which results in train reffited to cargoes that wouldn't load. It is somewhere in economy.cpp HandleStationRefit() function (or in callees of that) but I have no idea how to fix that.

Thanks for letting me know. This only required a minor change which I've pushed to the repo.

Still doesn't auto-refit to allowed cargo if current cargo of vehicle is "no load", even if there are no cargo going to next station. May be it is related to initializing new_cid to current cargo of vehicle, but most probably, not - if I initialize new_cid = 1 at FIRS 3.0 Extreme, I get coal (allowed to load) vehicles refitted to alcohol (I think it is CargoID for Alcohol in that economy), and other vehicles (empty, with no_load cargo capacities) does not refit as with old initialization.

I hadn't thought of this use case, I will look into it when time permits.

I looked at the Slots Feature and see how it works. Somehow I still can't think of an actual use case for it. Do you have any screenshots and short explanations of stuff you used it for?

Also.. would it maybe make sense to also introduce a conditional order checking slot occupancy?


If I didn't know how to ensure savegame compatibility I'd for your version and re-add my few changes. most of our stuff is identical anyway and I keep copying your code which feels a bit redundant. Oh well.

I think I found the reason of non refitting of no_load cargo vehicles.
After unload part of LoadUnloadVehicle() there are and if current cargo is OLFB_NO_LOAD GetLoadType() returns OLFB_NO_LOAD and cycle proceeds to next vehicle without refitting, never getting to HandleStationRefit.
Moving this check after refit part solves the problem. May be a check for VF_STOP_LOADING before refit part would be usefull

KeldorKatarn wrote:I looked at the Slots Feature and see how it works. Somehow I still can't think of an actual use case for it. Do you have any screenshots and short explanations of stuff you used it for?

Also.. would it maybe make sense to also introduce a conditional order checking slot occupancy?


If I didn't know how to ensure savegame compatibility I'd for your version and re-add my few changes. most of our stuff is identical anyway and I keep copying your code which feels a bit redundant. Oh well.

Which is why I think it is hidden in advanced settings lol.

Not JGR, and I think JGR has different use cases than mine (he mentioned that he uses it for complex junction), but I use it mainly for single-track route. The most useful usecase for me is to set UP and DOWN slots for a single track route, and increase slots limit. This allow multiple train to enter single-track section in same direction. (Of course, the single-track route also needed to be divided by two-way block signal/path signal). The downside, however, is that I have a lot of slots because each track between passing points need two slots.

I also it in simple signal-track section with level-crossing (to prevent blocking level crossing for too long). This is similar to how IRL Train Token works.


And, samegame compatibility is easy with JGR IMO. Each addition is guarded by feature-specific version number, and you can hook in special code to upgrade each feature to newer version. As a player, I'd love to see your patchpack being combined (though I know your approach to auto separation is totally different) I actually went to your patchpack first, but the killing feature for me is JGR's automatic timetabling.

That single line = two slots thing is pretty much the only use case I could think of as well, and that somehow doesn't feel worth it...
I mean you can do some stuff with allowing only so many coal trains into a station e.g. but... what good does it do if I block the ones coming after.. they'll wait in front of the station blocking. Better to use conditional orders to check free platforms or restrict the platforms with signals and back the trains up into a depot, letting them wait there for a free path.

I also can't think of any junction that can't be done with the existing routing restrictions... one way track really seems to be the only thing that comes to mind. And for that I feel it would suffice to just make a signal store a counter and let a route restriction result increase or decrease that counter and be able to share the counter value with another signal. That would be enough. ONe signal would count up, the other down, and the let a train pass by comparing the value to something. I dunno. The slots seem a bit overkill.

Single-track slot is worth it for me because I run a really long single track main line on a not so busy part of my network, or in geographically challenging area. Also you kinda need to limit the slot occupancy by the available free platforms.

Though I actually agree, I mainly just use it as a counter as well.

ino wrote:As a player, I'd love to see your patchpack being combined (though I know your approach to auto separation is totally different) I actually went to your patchpack first, but the killing feature for me is JGR's automatic timetabling.

In that case you might be in luck... check my patchpack thread in a bit.

On slots, see this post for some explanation and usage examples.

Most of my use of slots are various kinds of queuing sidings which look like: I also use them for wider-area deadlock prevention, junction prioritisation, and such.


Other than that, I'm going to be busy with other larger responsibilities for a while, so won't have that much time for patchpack development.

I read that post, I still don't see how slots are needed for qeueing sidings... the conditional orders would be more appropriate I think. But oh well... stole the departure boards instead and adjusted the timetable automation to work with my separation (which I still consider superior )

Btw, I think there's still a bug in the departure boards, unless I couldn't see your commit fixing it, all the commits in the branch for it still contain the bug.

In the departure_gui when the widget is drawn, the game simply uses the terminus.station and the via station without checking if they're valid. That can cause yet another crash if the departure board is open while the station is deleted. I had that crash when I imported the code into my version. THe stations are initialized using Station::Get instead of using Station::GetIfValid with a validity check afterwards. That needs to be added, then it's bugfree I think.

Also regarding the vehicle type buttons. I'll probably add ctrl click behavior like in the industryminimap.. if you ctrl click a button it gets activated exclusively while the other ones are deactivated. That should make it easier to just filter for trains. I'm also thinking about introducing a variable to a station that stores the departure board settings. Also the departure window needs that button that lets you save the standard size.

I'll add those probably, so those would be my suggestions how to improve the boards in your patch too.

Is the industry generation of cargo also scaled to the town generation of cargo? If not, could you add it in?

What does the development branch in the source do? Im trying to add a logic signals patch to it but idk if its going to work because its a very old patch and not maintained. But then SVN tortoise told me that dev branch is closer and asked me to patch that then i realized that this patch im trying to add is already in the dev pack it seems??

If JGR wants to add those, I have them in my pack so he can take a look at my current code. there were a lot of bugs in it, but I am pertty sure I got them all. Unfortunately I didn't make a branch for them back then, but they're not a HUGE feature I think, so it should be able to sift through my code and figure it out.