Click and drag for way objects

[jamespetts]

Since the incorporation of the feature allowing players to build ways by clicking and dragging, rather clicking once on the start point, and again on the end point, building ways has become much easier, more pleasant, and more user-friendly.

Would there be any possibility of extending the same system to way objects, such as electrification? Having one system (click and drag) for laying ways, and a different system (click twice) for laying way objects is confusing, and the click and drag method (with the estimated building costs) is much more helpful and easier to use.

[gerw]

I support this request. But at least for power rails, it is necessary to extend zeiger_t by get_after_bild. Or is there an other class, which can be used instead of zeiger_t?

[Dwachs]

This extension would be not too massive, I guess

[prissi]

Any ding has a get after bild. Extending zeiger is only logical for OOP.

[gerw]

Any ding has a get after bild. Extending zeiger is only logical for OOP.

Yes, of course. I only wanted to say, that you have define the (virtual) function get_after_bild for zeiger_t, since it isn't defined yet.

[gerw]

You can find a patch at http://simutrans-forum.de/forum/thread.php?postid=50586#post50586.

[jamespetts]

Gerw,

excellent work! I have tested it and it works marvellously. Thank you!

Edit: Now implemented into Simutrans-Experimental version 3.12. Thank you, Gerw!

[gerw]

Thank you, JamesPetts.

Here is a new version with new (internal) features:

- a new class two_click_werkzeug_t for tools, which needs two clicks. It also allows dragging. In the current version way and way object building are implemented as two click tools. But now, other tools can also easily support dragging.

- a new class koord3d_vector with two little helper functions.

- way and way object building now allows rotating between the two clicks (this is buggy in current versions).

You can find the patch at www.tu-chemnitz.de/~gerw/drag_wayobj_v2.patch.

Can someone move this thread to 'patches'?

[z9999]

One problem.

1. Choose way tool
2. Click empty land
3. Click on a building
4. Click another empty land

Result:
Way was build from first clicked empty land to last clicked empty land.

Note:
When I clicked on a building, zeiger on the first clicked land will be removed.
But tool itself is not canceled.  This should be canceled.
This problem will happen with dragging, too.
And also wayobject tools have similar problem.

[gerw]

Thank you for testing.

It's now fixed (only one line...)

[z9999]

Thank you. Another small thing about estimate tooltips.

- Way tools show positive value but wayobject tools show negative value.
- Upgrade wayobject doesn't show correct estimate value on tooltips. If I drag on lower wayobject, it shows zero. But if this estimate would be difficult, it's Okay.

[gerw]

Thank you again. Both fixed.

See www.tu-chemnitz.de/~gerw/drag_wayobj_v3.patch

[gerw]

Now also the forest and the wayremover tool are implemented as two_click_tools.

www.tu-chemnitz.de/~gerw/drag_wayobj_v4.patch

[jamespetts]

Gerw,

what do you mean by two click tools?

[Dwachs]

Tools that use click-and-drag ... ie tools that give you a preview of the result (as the original waybuilder).

[gerw]

Tools that use click-and-drag ... ie tools that give you a preview of the result (as the original waybuilder).

That's not the whole truth Two click tools are tools that need two koord3d in order to work. I've implemented a new class, which directly support this. The implementation of the tools itself only need to declare two methods, one that provide a preview (more or less optional) and one method, which does the real work. In the trunk version, the code in some tools (way builder, way remover, forest builder) was doubled, so I decided to derive a tool class, which does this work.

[z9999]

One small problem.
If I drag to outside of the map (outside sea) and mouse up, tool works.
But when I move back cursor to inside of the map, a new zeiger will appear at end position.

[gerw]

Thank you for your "little problems"

www.tu-chemnitz.de/~gerw/drag_wayobj_v5.patch

[z9999]

Solved. Thank you.

[prissi]

Since there are more koord list, I would suggest to add the koord_vector and koord3d_vector to koord.h/cc and koord3d.h/cc as the logical places for them. Defining a new file with a single most trivial derived class for use in almost only one place seems too much. That way also the factor kood lists (and other too) could be unified; this would also make the code much cleaner.

[gerw]

Is there any drawback when putting this classes in an extra file? So I would prefer an extra file for this class, since there would be more members in this class in future and therefore it's more clear in an extra file.

[prissi]

The class is derived from koord3d. It is used currently at one position. Making a new file for this purpose imho adds more confusion and clutter than adding it to koord3d directly. (Since the rotation is defined there anyway.)

You do not put any C function is a seperate file, if it is just a printf and an addition, do you?

On a side note, rather hang_t should get its own file, but is currently a member of koord ...

[gerw]

Don't let us argue about such small things. I've now put it in kood3d.h.

With this new patch, the wayobjects get connected automatically.

www.tu-chemnitz.de/~gerw/drag_wayobj_v6.patch



BTW: What sense have the wkz->move messages with buttonstate==0? They are only called after dragging, when releasing the mouse button (but not when you release the mousebutton outside the map - as z9999 showed).



What about sending wkz->move also when no button is pressed? Then we could have a way builder preview even without dragging. Of course, this would have any drawbacks, if you want to build a way over the whole map.

If tested it and it works (at least for way builder/remover, wayobj builder):

www.tu-chemnitz.de/~gerw/drag_wayobj_v6_advanced_move.patch

[prissi]

The waybuilder without dragging is very consuming on the CPU and will put Netbooks into big troubles. Especially when no route is possible. Dragging needs to be optional.

wkz->move was once intended for more. Do to bugs and errors in the implementation it ended like this. Before, there was also no call to wkz->work.

[gerw]

The waybuilder without dragging is very consuming on the CPU and will put Netbooks into big troubles. Especially when no route is possible. Dragging needs to be optional.

Yes, of course, this is true. But in my opinion, it is more comfortable to build ways without dragging and with preview. I've tested it yesterday and it was some kind of easy I think, making it configurable would be a good idea, but will also blow up the config...

wkz->move was once intended for more. Do to bugs and errors in the implementation it ended like this. Before, there was also no call to wkz->work.

What was the intention of wkz->move? Should we simply remove this call with buttonstate==0 (all tools ignore this) or is there an idea, which could be completed?

[z9999]

As reported in other problem report, in Windows GDI version, there is a performance problem with CRTL key on pause mode.

[prissi]

The call with buttonstate==0 was done for moving without dragging. I would suggest to keep it for now.

[gerw]

The call with buttonstate==0 was done for moving without dragging. I would suggest to keep it for now.

Like in the advanced move patch above?

As reported in other problem report, in Windows GDI version, there is a performance problem with CRTL key on pause mode.

Only with this patch? And which version of this patch?

[gerw]

New version of the patch. Now you can also delete way objects with dragging. It's included in the wkz_wayobj_t, since it uses almost the same code. But of course, it's sometimes hard to read.

Lines for your menutab.conf:

Code Select Expand

general_tool[33]=,1,11,
toolbar[2][11]=general_tool[33],16,,2


www.tu-chemnitz.de/~gerw/drag_wayobj_v7.patch