Advanced Terraform - Drag&Draw (r13116)

[Roujin]

Update: Drag and Draw v2 is here!
Download in first post.

Changelog:

Features:
- Rivers! Drag-and-Draw is now activated for rivers in scenario editor. Hold CTRL and draw yourself some nice rivers

Changes:
- The terraform command is now only executed if you moved to another tile. This also allows (with a minor codechange) a
different raise and level behavior that some of you asked for, BUT there is a currently unavoidable problem with this;
Maybe I will make a post later with screenshots so you can see for yourself what it's about.

Bugfixes:
- Sound fixed (sound was played continuously). Now only when moving to another tile.
(why didn't anyone report this to me? I only tested with sound turned off...)
- Error message is now displayed properly.
- red error tile from previous failed operation was not removed - now it is.


---
Please comment and report bugs, if any have fun

[Roujin]

Update: v3
Download in first post.

Changelog:

Features:
- Clear Tile (= Dynamite). Both in the scedit and normal game, including the dynamite in the rail/road/airport/dock building window.
- Rocks. In scenario editor select the rock placing tool and hold CTRL to draw rocky area.
(The same could be applied easily to desert and canal if they didn't have a CTRL function already)

Changes:
- [big change] changes the raise and lower tools (BOTH area and draw!) so that their behavior is more like the BIG raise/lower tools in the scedit. In effect, the raise tool will never lower land and the lower tool will never raise land.
- a lot of internal stuff, now it'S cleaner and better to understand i think
- big terraforming in scedit is now handled by my command function as well. If they should be scrapped, because now raise_area/lower_area behaves exactly like big_raise and big_lower, i don't know.

---
Please comment and report bugs, as usual... (or rather, unlike usually when I didn't get any feedback really *cough*)

[FooBar]

Sounds promising. Especially this "the raise tool will never lower land and the lower tool will never raise land" stuff. I sure will give it a spin this evening, if I don't get caught up in playing GTA Vice all night long....

[Gonozal_VIII]

the patch causes assertions with revisions >= 12075 because of the changes in the command enum, i fixed that

[Roujin]

Thanks, added a Link to your post with the fixed version for r12078 in the first post.

[Roujin]

Long time no bump.
Updated to revision 12968.
Only cosmetic changes.

Have fun

[belugas]

I see a lot of copy and paste here and there.
Or duplicated code, anyway...
Anyway to reduce these occurences?

[Roujin]

I guess that can be done in some places.. e.g. the switch-cases

Also I could split this up, I've already split off something and put it on flyspray that's actually just a small fix. http://bugs.openttd.org/task/1987
Maybe I could next split the unify scedit terraforming part off.

[belugas]

yeah, i noticed that one.
In fact, i'm going to commit it tonight.
Been watching that code movement for quite sometime now

[Roujin]

Ok, I've revised my code again and cleaned it up a bit.

One thing that's included in this patch that I could split off now is a change in the behavior of the raise/lower area tool.

Right now (in trunk), it takes the tileheight of the start_tile of the selection, adds/subtracts one and sets all tiles in the selection to that height. People have complained about that behavior (because it's possible to RAISE something with the lower tool and vice versa) and asked me to change it to the behavior the "BIG"-terraform tool in scedit shows. (That is, only raise the tiles of the lowest tileheight / only lower the tiles with the highest tileheight - by one).

My patch here does that, and I could split it off - introducing a new Command for raising and lowering an area. What do you think?


edit: That's also a step towards unifying the BIG-terraform used in the scedit.

[Roujin]

Here's the split off patch.

It introduces a new command function CmdRaiseLowerLand, with a behavior similar to the scedit behavior, and removes the raise/lower behavior (specified with parameter p2) from the CmdLevelLand (which I introduced back in my Area Terraform patch).
Dragging with the Raise/Lower tool now invokes the CmdRaiseLowerLand instead of the CmdLevelLand with appropriate p2.


I emphasise that this _does_ change ingame behavior. Please tell me if it is acceptable/wanted or not.

[Wolf01]

I don't have enough time to look at the patch, but does that allow this: http://www.tt-forums.net/download/file.php?id=88651 ?
If yes it is a great feature I would like to use (give a look at this: http://wolf01.game-host.org/OTTD_relate ... _land.diff which you should know it, because you helped me to fix it )

[Roujin]

Yes, sort of.

It's basically cut/fill, but only by one level, not to the level of the start tile.
So if you select the whole map with the lower tool, it will search for the highest mountain(s) and cut them all off by one.

edit: so to archieve what's in the lower two screens of your example image, you'd have to lower the area twice.

[Wolf01]

Yes, sort of.[...]
edit: so to archieve what's in the lower two screens of your example image, you'd have to lower the area twice.

mmmh that's a lot of work, like planing an oak tree to obtain a table, instead of break it directly in 2 parts (and then cut away glitches) -> http://www.comune.valsavarenche.ao.it/m ... icnic2.jpg
Ok, I hate it, but... CTRL to level the area to the start tile?

[Roujin]

Wolf01: Honestly speaking, I don't think what you're describing is really necessary. I'd prefer keeping CTRL free for something else.

---
@devs:
Regardless of the other patch which changes behavior, you could safely include this patch which I added to flyspray yesterday:

http://bugs.openttd.org/task/1999

It's just some consistency fix like the last one.

[Roujin]

Thanks for including the last one. Here's more split off stuff.

1) This is a little codechange that ensures that terraforming actions in the scenario editor cause no brown tiles. Currently it is inconsistent: the raise and lower tool cause no brown tiles, but the level tool does. http://bugs.openttd.org/task/2002

2) Now here's the big one... this introduces the drag&draw feature, but (as SmatZ suggested) only available in the scenario editor for raise and lower. No CTRL modifier used anywhere... http://bugs.openttd.org/task/2001

edit: I updated the second one to current trunk, utilizing window class functions like rubidium introduced them in trunk.

[Roujin]

I understand that (part of) the devs are pretty busy converting the window system to OO, but I'd really appreciate some feedback on my split off drag&draw patch.

[Roujin]

As of request, I've updated the whole patch. Have fun

[Roujin]

I'm currently updating the split off drag & draw patch (that I hope has chances to go to trunk) to the changes made to the window system. I've already made good progress, but now I've got to make a change to an existing function so I'd like to discuss with you (devs! yes I know you're here, don't go hiding!) what is preferred:

I need information about the end_tile of the selection in Window:OnPlaceDrag. This is because with drag&draw, I want to execute the wanted command on every mouse movement (if the underlying tile has changed, that is), not only when the mouse is released again.
It currently has:

Code: Select all

OnPlaceDrag(ViewportPlaceMethod select_method, ViewportDragDropSelectionProcess select_proc, Point pt)

Compare to OnPlaceMouseUp, which has:

Code: Select all

OnPlaceMouseUp(ViewportPlaceMethod select_method, ViewportDragDropSelectionProcess select_proc, Point pt, TileIndex start_tile, TileIndex end_tile)

Now I have two possibilities: Either change Window:OnPlaceDrag to include at least the end_tile in its parameters, or change "void VpSelectTilesWithMethod" (which is usually called in OnPlaceDrag to "TileIndex VpSelectTileWithMethod(...)", to return the TileIndex of the end tile of the selection.

Which one of these two would be preferred? Currently, I have chosen the second possibility, but I'm not sure if it's the right way. The other option would need changing the class function though...

Here's my current .diff:

new_dragdraw_v1_r13185.diff

new dragdraw v1 for r13185

(10.36 KiB) Downloaded 172 times

new_dragdraw.diff

for r13265

(10.43 KiB) Downloaded 165 times

I've really put effort into this now to make it clean and small and nice and understandable.. please don't let me die here, devs..
PS: SmatZ, weren't you interested in this short time ago? I've done what you suggested, so where are you now?

edit: updated to r13265

[fonso]

As there is no trunk-compatible version of advanced terraform, I thought, I'd do something about it. Now I like the old diagonal levelling better than drag&draw, so I decided to update it to current trunk. Here it is. I know it's a hack, but it works.