[Patch] "Design mode" for route building

[falconne]

This is the first iteration of a patch I'm working on to create a kind of "route design" mode; to allow you to build multiple legs of a route in "preview" mode and apply the design once you're satisfied with it. It's not perfect yet, but I thought I'd get some feedback before I got too far into it, in case people think some fundamental changes are necessary.


Currently it only supports the "way building" tools (roads, rails, monorails, trams) and doesn't work in network mode. To activate design mode you have to ctrl-click on an applicable toolbar button, such as a railroad or road button (not the most convenient way to do it, I welcome any alternate suggestions) and you will get a dialog appearing on the top right, as shown in the screenshot. The dialog shows the estimated construction cost and monthly maintenance for the route you are building. You can now build your route as normal and the tracks or roads will appear, but they are only preview graphics and you don't get charged. The total estimated costs in the dialog will update as you go. The dialog has an Undo button that will get rid of the last section of route that you laid. For the moment that's the only way to modify your design. When you're satisfied with it, you click the Apply button to build the whole route and you get charged. Or you can click Discard to cancel the whole design. Both Apply and Discard will dismiss the dialog and cancel design mode... you will be back in normal build mode. To design another route of the same type, ctrl-click on the same road or rail button on the toolbar. While in design mode, if you choose any other tool (or manually close the dialog), the design is discarded and you are put back into normal building mode (ctrl-clicking another road or rail tool will dismiss the current design, but also open a new design mode with the new tool).


The current limitations I still need to work on are:

   
• Click and drag isn't supported in this mode. You have to use the "click start point, then end point" for each leg. I'll have that fixed in the next upload.
• Network mode is not supported. I saw that the "click and drag" method isn't supported in network mode either and my patch uses a similar technique as that, so I disabled this feature when in network mode. I haven't investigated the reason for this yet.
• You can only design with one type of route tool at a time - you can't make one design with multiple road types, for example. When I fix that, it should allow even bridges and tunnels to be added into the design so you can design a very complete route before applying it.
• What you see is not always what you get. You can see this effect on the top right of the two screenshots. The problem is that when the game calculates the route for a given section, the pathfinding algorithm obviously isn't taking into account the "preview" route sections you've put down - they aren't properly part of the map yet. When the design is applied, each section is built one after the other (a point to point build is done for each section) and the pathfinder might change it's mind a little for later sections as it takes into account the earlier sections now built. It shouldn't affect the outcome much though, but I will work on making the previews more accurate.

Building in design mode:





Apply button clicked:

[wlindley]

Will the bulldozer (erase) tool work while in this mode, so you can weigh the effect of several possible alignments, or a straighter path if a house were to be removed?

[Dwachs]

Network mode is not supported. I saw that the "click and drag" method isn't supported in network mode either and my patch uses a similar technique as that, so I disabled this feature when in network mode. I haven't investigated the reason for this yet.

Click-and-drag is supported in network mode. With the exception of click-and-drag for bridges / tunnels / elevated ways (this restriction can be removed as well if anybody would write a patch for it)

[Fabio]

Best ui would be a different button, so that after you press it you can select all a variety of tools.

[Isaac Eiland-Hall]

That makes sense - a button to put it in pre-build mode, do yer stuff, set it, approve it, and it should pop back out into regular mode?

[prissi]

Any tool should be ultimately compatible with the network mode. And I think this should not be too difficult in this case, as those built commands can be sent over the net.

Just the way of a dialog with button to confirm certain building actions is not very much simutrans UIish. I that case, I would also rather favour an "planning mode" by a button like the underground mode. (That could be even connected with the smart cursor ... )

[jamespetts]

This is an excellent idea. As to the UI for it, my view is that this system should be the only way of building things. It is only by historical accident that the computer gaming world has defaulted almost universally to the instant build common to all these types of games. The original Sim City, released in 1989 but designed in 1985, the common ancestor of this type of computer game, was developed by chance when a tool to create environments for a shoot-em-up game was found to be more fun than the game for which it was a tool. In that context, it made perfect sense that laying a road, for example, should be instantaneous.

A more realistic game would have people plan things in a preview mode of the sort that Falconne is designing here, then click the "Apply" button as in Falconne's dialogue box and wait a realistic number of game months for the things to be built. Each type of way, building, bridge, tunnel and each sort of ground engineering tool (raise/lower land, etc., which, incidentally, ought also be included) ought have a specification in their .dat files as to how long that they take to build (the expectation being that newer types take less time to build). There could do with being an "under construction" graphic for buildings, ground works and each base type of way (e.g., rail, road, canal, etc., rather than each specific type of railway, road and canal), and, preferably, each such graphic should have an introduction date, so that we do not see bright yellow bulldozers in 1830 or gangs of navvies with wheelbarrows in 2005.

If making this feature (and the associated building delay) is not thought suitable for Standard, then I am more than happy to make the necessary accommodations for it to be an Experimental only feature.

[prissi]

It was discussed several times already, that waiting for completion takes actually the fun out of construction for a fair number of player. But lets not stray too far from the topic, i.e. on how integrating a planing mode in a friednly way into the game.

[sdog]

how is the patch to automatically build bridges, tunnels and carve slopes to some extent doing by the way? Some of you (Dwachs?) were working on it about a year ago, i think.

i'm asking it here, as it would truly make this patch usefull.

[Severous]

Nice work again falconne.


Do you think we could use the landscaping tools with this feature? 

I often find I spend more money on land works than track (I tend to play on rough maps though).  Its no fun when half a mountain disappears costing 60k when all you meant was one slope. 

For example: lay some track, landscape a bit, lay some more track on the new land, bridge..then check and accept or discard?

[prissi]

This could be easily activated, as the AI uses it. Could you please focus on the design mode. I know christmas is coming, but ...

[isidoro]

Refocusing on the design mode again,  would it be possible/desirable that the plans are only seen by the player doing them and others in the network game would see them only if they are committed?

[sdog]

what should happen if two players desig something in design mode that interferes with each others construction?

[jamespetts]

It was discussed several times already, that waiting for completion takes actually the fun out of construction for a fair number of player.

It could easily be made optional, one way or another.

Refocusing on the design mode again,  would it be possible/desirable that the plans are only seen by the player doing them and others in the network game would see them only if they are committed?

This seems sensible to me: there is no reason why players should see other players' plans, after all.

what should happen if two players desig something in design mode that interferes with each others construction?

The first to commit to building it should get exclusive rights to use the land in question.

[Isaac Eiland-Hall]

Maybe affected tiles could have some sort of overlay like station coverage, or maybe some border highlighting like when you hover over a tile with a stop? That way, other players would see the tiles affected, which would be 'locked' until the constructing player set the change or cancelled the mode?

[falconne]

Just answering some questions and to give my own opinion on the matter:

Will the bulldozer (erase) tool work while in this mode, so you can weigh the effect of several possible alignments, or a straighter path if a house were to be removed?

It's not that complex yet, though I do want to make it so in the future, where paths can be dynamically recalculated if you change something. You can't use the bulldozer right now, or any other tool while in design mode. The undo button is the only way to change things, but again, it's something for the future.

Click-and-drag is supported in network mode. With the exception of click-and-drag for bridges / tunnels / elevated ways (this restriction can be removed as well if anybody would write a patch for it)

Ahh right, I must have have been looking at tool classes for one of those rather than the way building tool. That's good, it means I can enable it for network mode, but not just yet, as there're are more complications in making this work multiplayer.

Just the way of a dialog with button to confirm certain building actions is not very much simutrans UIish. I that case, I would also rather favour an "planning mode" by a button like the underground mode. (That could be even connected with the smart cursor ... )

Well the dialog is a placeholder because that's the easiest way to work on this patch. Any other way would involve toolbars and that means changing pak files and having new graphics.... for now my focus is just the functional side. The way I originally envisaged it working was you'd have a toggle button on the main toolbar, like the show grid button, which puts you into design mode and opens a new toolbar with at least 3 buttons on it, for apply, discard and undo. The costs can be shown as a mouse pointer tooltip. And you'll stay in design mode until you toggle off the design button or close the design toolbar. Maybe the cursor graphic would also change in design mode to make it clear.

A more realistic game would have people plan things in a preview mode of the sort that Falconne is designing here, then click the "Apply" button as in Falconne's dialogue box and wait a realistic number of game months for the things to be built. Each type of way, building, bridge, tunnel and each sort of ground engineering tool (raise/lower land, etc., which, incidentally, ought also be included) ought have a specification in their .dat files as to how long that they take to build (the expectation being that newer types take less time to build). There could do with being an "under construction" graphic for buildings, ground works and each base type of way (e.g., rail, road, canal, etc., rather than each specific type of railway, road and canal), and, preferably, each such graphic should have an introduction date, so that we do not see bright yellow bulldozers in 1830 or gangs of navvies with wheelbarrows in 2005.

Actually I was thinking of something similar, but not involving construction times. What if, for the first month or so after building certain infrastructure, if you demolish it you get all the money back without any demolish cost? It avoids a whole lot of problems that my current method has to deal with, will work in multiplayer mode and require a lot less code change. I'd like to hear what people think about that because it might save me a whole lot of work if I just do it that way instead (assuming there's not too many complications adding an extra "build date" field to various dinge objects).

Refocusing on the design mode again,  would it be possible/desirable that the plans are only seen by the player doing them and others in the network game would see them only if they are committed?

That's how it would work now if I enabled network mode, but I actually thought it might be useful if other players did see you planning your route, to help avoid conflicts. I wanted to see if I could make the preview tracks and roads semi transparent, like hidden trees, so it's more obvious to everyone they are not physical yet.

what should happen if two players desig something in design mode that interferes with each others construction?

Right now, when you apply, each section of route is built one after the other, exactly like you manually built it, point to point. In this situation, the section that overlapped another player's would not get built. I don't know exactly how to deal with this. I was thinking maybe check if the route can be fully built before applying any change and if not, give the user a warning and not apply the change, allowing them to go back and fix the conflict.

[jamespetts]

Actually I was thinking of something similar, but not involving construction times. What if, for the first month or so after building certain infrastructure, if you demolish it you get all the money back without any demolish cost? It avoids a whole lot of problems that my current method has to deal with, will work in multiplayer mode and require a lot less code change. I'd like to hear what people think about that because it might save me a whole lot of work if I just do it that way instead (assuming there's not too many complications adding an extra "build date" field to various dinge objects).

I rather prefer a construction times approach (which, as suggested above, might be made optional), as it more accurately simulates the realistic amount of time that it takes to build things in the world. The problem with the idea of getting a full refund if one destroys it within a month is - what if one's vehicles have traversed it in the meantime? Indeed, would it not be possible in theory to keep rebuilding and demolishing sections of one's network within a month such that one never has to pay for an entire route at all?

[prissi]

The waiting for construction annoys people who want to play their model railway simutrans. But back on topic, in network mode imho the other player should not see the construction. Otherwise building will be lacky and a bunch of new problems will arise (like how to save such stuff when a new player joins ... ) If sent to the server is one run, very likely the first sender will win. That way it works even now, when you drag something and another player built something on that just then.

[falconne]

I rather prefer a construction times approach (which, as suggested above, might be made optional), as it more accurately simulates the realistic amount of time that it takes to build things in the world. The problem with the idea of getting a full refund if one destroys it within a month is - what if one's vehicles have traversed it in the meantime? Indeed, would it not be possible in theory to keep rebuilding and demolishing sections of one's network within a month such that one never has to pay for an entire route at all?

Well if you send vehicles over it that would be your own fault and you can't really exploit this easily by constantly building and destroying a path, because you can't make any money from something you're constantly destroying.

But you can solve both issues by having the "build date" variable be cleared the moment a vehicle uses an infrastructure tile. That way you have the option of getting a full refund for one month, or until you run a vehicle on it, whichever comes first.

I'm not against build times in general, but I don't think they would be accepted in standard, so I think they'd have to be an experimental feature. I just want to find something that's going to work for standard first. Even to implement build times, you need this functionality anyway (adding a "build date" variable to each infrastructure object) so it's still a step in that direction.

I would like to know what the devs think about this, because it's much easier to implement and it means you can build the whole route, bridges and all, mould it how you like, without having to create a whole preview mode.

[TurfIt]

The demolish refund idea sounds more like expanding of the undo function to give refunds than 'design mode'.

"build date" is probably best not added to the objects. The ding definitions are one area where memory size is very important. Adding bytes that consume memory for the whole game just for a variable that has meaning for one month is not very good use of system resources. Perhaps maintain a list of recently built objects instead?

[falconne]

Yeah actually a list would be fine, as it would only contain the dings less than a month old and this check would only happen at all if the list contains any items, so the performance impact is minimal.

It's no longer a design mode, but the point wasn't to have a design mode... the point is to be able to not worry about accidental mouse clicks or the difficulties of making a long route... essentially let you plan and design your route without wasting money. And it's not the same as undo because undo will just remove the last action. With this method, you get to do what you like.

[Dwachs]

I would like to know what the devs think about this, because it's much easier to implement and it means you can build the whole route, bridges and all, mould it how you like, without having to create a whole preview mode.

Imho, the refund feature should be limited to 1  Minute real time. (Maybe 5 minutes, maybe no refund if already vehicles used it). One month game time is way too long. When I built something accidentally then I realize this immediately and un-do it. Much more annying are accidental undo's, where a piece of track at the other end of the map gets deleted and screws up the network.

Implementing these would require 'only' an enhancement of the current undo capabilities: undo more actions than just laying tracks, keep a whole undo history. Maybe with undo-redo functionality.

[prissi]

Way statistics are sint32. And I think there will be never 0xFFFFFFFF vehicles per month. Just put the built them the the second month of the statistics ...

An extended UNDO (maybe with an expiration data set be the server) is certainly a great idea (but also an effort, as most object to be deleted are rather first copied into a lsit, and deleted later. That will give a whole new headache for the cleanup funktions. So please continue in another thread an extended UNDO.)

One the design mode, personally an additional toolbar would be nice. Or even the last two three buttons of any building toolsbar. Or adding to the landscaping tools. I really would have input from the players on that.

And of course this need to be made network save ...

[merry]

Well, this is _definitely_ a good idea.
I am solidly with Jamespetts (although we do seem to be in a minority): a delayed build would enhance realism - and arguably the fun of a planning game's playability(humour me here...).

The option of getting a refund if demolishing built items straight away is a horrible kludge, and doesn't take into account that building infrastructure requires a contractual commitment to the people building it - so cancelling your civili engineering contract has a significant cost. E.g. the british navy is building frigates to scrap them because it's cheaper than cancelling the build. D'oh!

Anyway, back to playing the game: if a route is built, it generally needs new vehicles (except a deviation). That takes tie to do and while you're procuring your new trains/buses/whatever, the build can be carrying on. So the wait will not really be annoying, indeed the increased realism would set simutrans apart from the toy games...but it would be a new way of playing. I would welcome the need to plan!
Come to think of it, there should be a delay before my newly ordered vehicles are delivered. Unless I buy 'used' vehicles of course (which implies the creation of a market in used vehicles - something new for network play?...but that's getting OT).

Now, this will upset the train-set players: no worries, there can be an enable/disable for the 'build delay' behaviour and everyone can be happy. Indeed, the delay could be configured in the .ini file so the experimental paks can specify long builds while the standard ones can specify shorter ones, and anyone can customise their environment.

Anyway, moves in this direction - at least the planning tool - are great. it would overcome one very tedious aspect of ST infrastructure building :-)

Cheers,
merry

[jamespetts]

Merry makes good points. Incidentally, I do plan on having a market in secondhand vehicles in Experimental when I get the time to code that feature.

[falconne]

So that's a "no" on the time limited refunds then? That's a shame as it achieves the same objective with far less complexity and code change required.


As for the design mode then, is it worth being able to do a single design with multiple tools? Right now if you change tools the design is cancelled. There are a number of complications with allowing tool changes, such as when a player chooses a tool that doesn't have a design mode, like "Build Depot". I'd either have to disallow that, or come up with some nice way of reminding the player if they build a depot it's built then and there and is not part of the design. Also, if I allow landscape changes in design mode, I might need to recalculate each path after each change.

[Dwachs]

So that's a "no" on the time limited refunds then? That's a shame as it achieves the same objective with far less complexity and code change required.

An extended UNDO (maybe with an expiration data set be the server) is certainly a great idea (but also an effort, as most object to be deleted are rather first copied into a lsit, and deleted later. That will give a whole new headache for the cleanup funktions. So please continue in another thread an extended UNDO.)

Where do you read a "no"?

If the your goals of the design mode could be easier to achieve by extending undo functionality, then it would be a good idea to proceed into this direction. A possibility would be to add to each tool (werkzeug_t)  an undo method, that reads custom data, which is produced when the tool is executed.

Also, if I allow landscape changes in design mode, I might need to recalculate each path after each change.

There is also what you mentioned in your first post: ways might be different after building due to changed weights in the way-builder.

[jamespetts]

Why wouldn't the depot building tool also be part of design mode? But, yes, a multiple tool design mode is important for it to work properly, especially with things such as bridges, tunnels and elevated ways, but also stops, etc., so that people can see the full costs of their projects before commencing them.

[prissi]

The biggest errors can be made by routes. Imho a route design mode only is good enough for the start. Depots (or even stations) you won't built too many compared to way tiles.

[falconne]

Where do you read a "no"?

If the your goals of the design mode could be easier to achieve by extending undo functionality, then it would be a good idea to proceed into this direction. A possibility would be to add to each tool (werkzeug_t)  an undo method, that reads custom data, which is produced when the tool is executed.

Extended undo is different to my refunds suggestion... what I was suggesting is that if you use the bulldozer to destroy infrastructure and you do it a short while after building it and it hasn't been used by vehicles, then you get the full cost refunded and no demolish cost. Essentially you pretend you're in "planning mode" for that grace period. Extended undo would force you to remove entire sections, in reverse order of building and you still have to deal with time limits and tracking if vehicles have used the section. A bulldozer refund allows you to fine tune your route however you wish for a short time.

Nobody seems to be in favour of that though...

Why wouldn't the depot building tool also be part of design mode? But, yes, a multiple tool design mode is important for it to work properly, especially with things such as bridges, tunnels and elevated ways, but also stops, etc., so that people can see the full costs of their projects before commencing them.

That would be too much for now. Adding a preview mode for every tool is more work and is likely to introduce a lot of bugs. I like to keep my patch scopes small and iterative, so that hopefully the basic stuff will get some thorough testing before I add extra features. I think I will just need to prevent the player from choosing non design tools while in that mode.

[jamespetts]

Extended undo is different to my refunds suggestion... what I was suggesting is that if you use the bulldozer to destroy infrastructure and you do it a short while after building it and it hasn't been used by vehicles, then you get the full cost refunded and no demolish cost. Essentially you pretend you're in "planning mode" for that grace period. Extended undo would force you to remove entire sections, in reverse order of building and you still have to deal with time limits and tracking if vehicles have used the section. A bulldozer refund allows you to fine tune your route however you wish for a short time.

Nobody seems to be in favour of that though...

That system would have its merits, but I think that an express design mode (as indicated above, preferably one that can at least optionally be made to be on permanently) would be clearer (and allow for delayed actual construction). On the other hand, the bulldozing system might at least deal with the issue of conflicts between different players' building projects, although it would be important to have a good UI to show clearly in graphical form (1) which tiles can be deleted at full refund; and (2) the total cost of those tiles that can be deleted at full refund. I do wonder, though, whether a time based system is adequate here: it might take longer than a month (especially if a player were to design at a relaxed pace - and we are not providing a fun gaming experience if we force players not to do things at a relaxed pace) fully to design a complicated, say, rail network.

I suppose, as a sort of intermediate to the two, one could simply have a flag in all tiles of construction status: this need only be a uint8 member. One could define 0 as "planned", 1 as "under construction" and 2 as "built". On laying any item using the normal tools, it would be flagged as 0. One could then access a works dialogue which would show the cost of building all that has been planned, and give a button for "build all". It would then switch to "under construction" for a time specified in the .dat file (default: zero time), and, once that time has elapsed, switch to "built". Different graphics should be available for each state.

Careful consideration should be given to how to prevent "planned" ways being used to block other players for free, or at least, costlessly reserve space that might in the future conflict with other players' designs way into the future. One possibility is to enable one player to mark "planned" tiles of another player as conflicted, notify the other player of the mark, and have those tiles expire a month after being marked if construction has not started. Another possibility is to have "planned" tiles in network games appear and be stored only in the local computer of the player planning them, not transmitted over the network, and only transmit over the network when the command to build is sent. If any ways (etc.) are transmitted from the network as being under construction on the same tiles as the local player has planned, a warning dialogue should be presented, allowing the player to make changes to the plan before committing it.

Edit: It should also be possible using this technique to define different building projects, by having the whole range of, say, 0 - 63 reserved as planning types, and use 64 and 65 (or perhaps even 254 and 255) as "under construction" and "built". A UI would then define different building projects by number, and the works screen would enable one to name the projects (storing the names, perhaps, in a fixed array in the player class) and give prospective costings for all of them, as well as indicate whether any tiles have been built over (as described above) since planning commenced.

[sdog]

Nobody seems to be in favour of that [extended undo] though...

i think it's a brilliant idea, i did not post because i thought it's such an obvious sollution, without any drawbacks that it doesn't need much discussion.

Towards James' concerns:
In effect both, extended undo, and design mode are equivalent from the economic aspect of the game. (At least as long a you don't include design times, which would interfere with playability, to the extend to make the game impossible to play -- seriously: wait 15 to 25 years for a stretch of rail to be finished in 2000? perhaps 10 years in 1900) Your concern can be addressed quite easily, assume that at the point of construction in game, in the model it would have been planned and designed two decades before. This only breaks down for short term fixes for acute problems in the game. (but there we want it the most, just imagine the frustration of a blocked railway, and the 5 years it would take to fix it.)

The extended undo itself is nothing different from a design mode in effect: You build a rail setup with full for test, if it is sufficient it becomes active, in the design mode by pressing buttons, in the undo mode by doing nothing, or sending a convoy over the new way. The difference is in the ease of implementation, the broadth of its application (extended undo can be increased to much more, eg stations) and last but not least the ease of use. (design mode will be a concept adding a step between construction and use, certainly causing quite a couple of help requests.)

[Fabio]

I like planning mode as proposed by James as it is much more realistic.

On commits, if one or more tiles become unfree, they should be marked and commit be suspended. The player will then be able to revise his plans an commit again.

Planning mode would also preserve trees. It would be nice if it could also deal with terraforming. IMHO it should allow slope tools, which operate on a single tile, but not rising/lowering, which involve more tiles.

[jamespetts]

One further extension to my suggestion above: if one defined 64 "projects", one could then simply apply a mask by adding 0, 64, or 128 to the number to give those 64 numbered projects to each of the three states (with the possibility of a fourth state with 192 for some as yet undefined future use) to allow for the tracking of the costs attributable to particular bits of infrastructure (and, eventually, to allow the tracking of costs and profits generally by user defined cost centres).

[prissi]

Could we please focus on the design mode as it is now, and the addition needed to make it work with the network mode and on the UI whether using a dialogue or a new toolbar.

All other extension request which do not contribute to coding or implementation at all, please discuss - as the name suggests - in the extension requests.

Always going for the nextnext step will get you not much progress in the end.