Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Harken]

It'd be cool if you could manually assign a mine cart to be pushed from it's station to another, rather than just waiting for the conditions to be met.

Similar to lever pulling: [Q] -> 'Push'

[ I'm assuming this isn't currently possibly, if so sorry.]

[lethosor]

You could always set the departure conditions of a stop to "always", assuming the minecart is already assigned to a route.

[Larix]

As lethosor says, it's already possible, but you have to do it through the hilariously intransparent and clunky "h"auling interface.

What would possible interface improvements be?
I could imagine route stops (perhaps only on top of track stops?) elevated to actual normal-map "buildings", allowing to move carts/edit depart conditions as "q" interaction options.
Another i could think of would be assigning multiple carts to the same route, for large-scale stone hauling and the like.

Other ideas?

[zubb2]

+1

[Harken]

You could always set the departure conditions of a stop to "always", assuming the minecart is already assigned to a route.

Its been a few years since I've played around with mine carts so I'm rusty with the deeper dynamics. I've recently setup a simple system to cart coal which is where is suggestion stems from.

By the 'always' condition I'm assuming this means a ( push cart ) task is repeatedly added to the job que whenever a cart reaches a track stop? If so this seems a bit inefficient particularly when this is only necessary on rare occasions.

I think it would be nice to simply be able to Q and Push to handle abstract situations while the 'h'auling interface handles the standard operations. 

[GavJ]

intransparent

opaque?

What would possible interface improvements be?

It could easily be 20x simpler:

1) Hit a button for a new route.
2) Select start point
3) Select end point
4) Menu comes up asking you what type of stuff to move

The end.

Dwarves automatically build tracks between them (using existing tracks as low pathfinding cost to encourage re-use of track lines), build stops, assign a free minecart, and choose the most safe and typically reasonable options by default (dump at end and guide to destination, embark at 50% full OR 1 week), as well as filling in all the silly technical details that nobody ever hardly cares about, such as making a stockpile at the start and endpoints that match the materials transported (this shouldn't even be a thing... sure as an option, not needed by default. Or at worst, auto-generated by the game.)


***IF*** you want other options, then have increasingly complicated menus as you get to more and more esoteric options, but none of them are necessary at all if you don't. And, unlike now, the most common non-default options are better arranged to be only one menu layer deep (push versus guide is one layer deep, but timing for instance is not despite being just as common to change).

[Bumber]

I've recently setup a simple system to cart coal which is where is suggestion stems from.

Couldn't you just use a "when % full" condition? I'm sure you could also set something up with levers and drawbridges/rollers.

A manual override feature wouldn't hurt, of course, but I just don't see the application. What carts really need is easier automation, such as multiple carts per route, dwarves using them intelligently for transportation and item hauling jobs, and the ability to filter track stop dumping. Track stops could realistically sort items by size, and I think conveyor belts are planned (possibly sort by weight and auto-load carts.)

[Harken]

I've recently setup a simple system to cart coal which is where is suggestion stems from.

Couldn't you just use a "when % full" condition? I'm sure you could also set something up with levers and drawbridges/rollers.

A manual override feature wouldn't hurt, of course, but I just don't see the application. What carts really need is easier automation, such as multiple carts per route, dwarves using them intelligently for transportation and item hauling jobs, and the ability to filter track stop dumping. Track stops could realistically sort items by size, and I think conveyor belts are planned (possibly sort by weight and auto-load carts.)

Before we talk about adding additional complexity to the current system it would make sense to add something so basic as a Q -> Push.

[Bumber]

Before we talk about adding additional complexity to the current system it would make sense to add something so basic as a Q -> Push.

Q would only work on track stops. What if you wanted to push a cart that got stopped on track (e.g. due to a collision) instead of hauling the entire thing back to the beginning?

[GavJ]

Before we talk about adding additional complexity to the current system it would make sense to add something so basic as a Q -> Push.

Q would only work on track stops. What if you wanted to push a cart that got stopped on track (e.g. due to a collision) instead of hauling the entire thing back to the beginning?

You can't do that, because they wouldn't know which way to push it in that case. The beginning of the route specified which way.

Imagine you have an "S" curve and it's in the middle, pushing it toward the closest direction to the end stop will be incorrect. Even if you search along tracks, then what if the track has pressure plates that are necessary for shifting directions, etc.? The search for path will be incorrect. Etc.

If you had a manual option for each direction of push, then ok.

[Bumber]

If you had a manual option for each direction of push, then ok.

That was the idea. Only issue is how to implement it without unnecessary UI overhaul. If we can use the added functionally on other items then that's fine. (For example, wrestle/pickpocket specific item off a unit, use item as projectile. It fits well with future Fort-Adventure merge.)