News:

Simutrans Chat Room
Where cool people of Simutrans can meet up.

Wayobj 255 (Decoration way)

Started by An_dz, March 07, 2017, 08:32:13 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

An_dz

Here's the patch I made for adding the way-obj 255.

There are two bugs:
1) the wrong crossing graphic might be chosen in crossings between two different way types (e.q. A road+rail crossing and you build the 255 over both)
2) If you create an electrified waytype 255 it wrongly shows in the way info as being electrified, though it's not.

As it's a new way type, it actually allows creating anything that uses the waytype parameter.

Ichou

Thank you for making such a wonderful patch!

I have a question: Do we have to edit pak file with hex editor? Or can we make proper pak file with makeobj?

An_dz

You can use makeobj with the patch, I only hex edited before because I had not yet done the makeobj patch and needed to test how a decoration wayobj would work.

Ichou

Wow, great!
But I'm ashamed to say that I don't know how to use .patch file.

DrSuperGood

QuoteBut I'm ashamed to say that I don't know how to use .patch file.
Download from the SVN then apply the patch to the SVN then build. On Windows I recommend TotoiseSVN to download and then apply the patch as it has a UI.

Ichou

QuoteDownload from the SVN then apply the patch to the SVN then build. On Windows I recommend TotoiseSVN to download and then apply the patch as it has a UI.
Thank you!

Leartin

Is it christmas already? Many Thanks!

Quote from: An_dz on March 07, 2017, 08:32:13 PM
1) the wrong crossing graphic might be chosen in crossings between two different way types (e.q. A road+rail crossing and you build the 255 over both)
Could you implement a check to see on which bordering tiles a 255-waytype exists to circumvent that?
Does the same problem arise with trams on roads?
Quote from: An_dz on March 07, 2017, 08:32:13 PM
2) If you create an electrified waytype 255 it wrongly shows in the way info as being electrified, though it's not.
Isn't the bug that it's not electrified, rather than that it's shown as electrified?


Is the drawing order between this generic wayobj and the specific wayobj set? If not already, it probably works same as with road&tram - please place the generic wayobj outside.

An_dz

Quote from: Leartin on March 08, 2017, 06:39:48 AM
Could you implement a check to see on which bordering tiles a 255-waytype exists to circumvent that?
Yes, a fix is needed, but I'm not familiar with drawing code.

Quote from: Leartin on March 08, 2017, 06:39:48 AM
Does the same problem arise with trams on roads?
You are comparing oranges with apples, tram ways surely don't make any check as to which track is beneath them. But a wayobj does.

Quote from: Leartin on March 08, 2017, 06:39:48 AM
Isn't the bug that it's not electrified, rather than that it's shown as electrified?
Yes, it could also be changed to electrify the track, but it would need to be a careful fix to not break other uses, like a rail electrification does not give energy to the road it's crossing. It's also complicated as to how it would electrify two way types at the same time when there's a crossing or tram tracks over roads.

Quote from: Leartin on March 08, 2017, 06:39:48 AM
Is the drawing order between this generic wayobj and the specific wayobj set? If not already, it probably works same as with road&tram - please place the generic wayobj outside.
As I said before, I'm not familiar with drawing code.

Leartin

Quote from: An_dz on March 08, 2017, 02:07:04 PM
You are comparing oranges with apples, tram ways surely don't make any check as to which track is beneath them. But a wayobj does.

I was not clear on that: I meant 255-wayobj placed on tiles where both road and tram already exist. Since a tram curve can be on a straight road  and vice versa, it seems to have the potential for the same issues you get with crossings, but a bit more complicated.

Quote[...]like a rail electrification does not give energy to the road it's crossing.
What's the harm? It's not like any vehicles require non-electrified ways, so if something becomes electrified accidentially, it's not a big issue.

An_dz

Quote from: Leartin on March 08, 2017, 02:16:39 PM
I was not clear on that: I meant 255-wayobj placed on tiles where both road and tram already exist. Since a tram curve can be on a straight road  and vice versa, it seems to have the potential for the same issues you get with crossings, but a bit more complicated.
Yes, that's the behaviour. But the cause is probably the same, I still need to find where the ribi choice code is.

Quote from: Leartin on March 08, 2017, 02:16:39 PM
What's the harm? It's not like any vehicles require non-electrified ways, so if something becomes electrified accidentially, it's not a big issue.
I've not expressed clearly, what I mean is that it's still a wayobj so it follows the rules of wayobj. So far a wayobj only electrify 'one' way, the way it has the same waytype. This new one could, or should, electrify all ways it's built on, but the code might not be so flexible on this regard. In the end the choice will probably be the easiest solution.

prissi

I think, if you electrify wayobj 255, it should be rather count as a power line. So you can route power lines through ciies ...

An_dz

Ok, drawing bug fixed, new patch attached.

Quote from: prissi on March 09, 2017, 12:29:46 AM
I think, if you electrify wayobj 255, it should be rather count as a power line. So you can route power lines through ciies ...
That's a nice idea.

Leartin

Quote from: prissi on March 09, 2017, 12:29:46 AM
I think, if you electrify wayobj 255, it should be rather count as a power line. So you can route power lines through cities ...

It sounds neat, but I see issues:
In order to look good, these wayobj power lines would need to somehow connect either with regular power lines or with transformers. There is completely new code required. Is the amount of work required to make connecting power lines out of wayobj really worth it and easier than having special code for 'elevated powerlines' so they would not cut stuff under them? Think about it - power lines are currently a kind of way. If you want to place a way over a way, use an elevated way - that would make perfect sense.

Rather confusing, on the other hand, is the relation of power lines and electrification to begin with. How many beginners tried to connect electrification to the power grid? Is it smart to fuel that confusion by introducing electrification power lines?

Ever since power tunnels, powering factories in cities can be done rather easily, so I don't think this is required for gameplay reasons. If it's for looks, I'm sure telegraph poles will be an early wayobj to be made, they can double as non-functional power lines.



I would rather have electrification electrify all ways on a tile.

Ters

Quote from: Leartin on March 09, 2017, 06:14:31 AM
I would rather have electrification electrify all ways on a tile.

That was my first thought as well, but trams run in the middle and trolley buses run on the sides, so the wires for each would be in different places. One could of course just let players who cares about such things have three variants of each overhead wire style, and have them enforce the right use on themselves.

Leartin

Quote from: Ters on March 09, 2017, 04:50:54 PM
That was my first thought as well, but trams run in the middle and trolley buses run on the sides, so the wires for each would be in different places. One could of course just let players who cares about such things have three variants of each overhead wire style, and have them enforce the right use on themselves.

If we talk about the 255-wayobj, this is an issue either way. I can't imagine any kind of wayobj that could truly fit all ways, especially since ways for airplanes cover the full tile, and any kind of wall is a way, too. The players will have to restrict themsellves to the right use on their own anyway.

If we talk about tram and trolleybus electrification - We already have two different kinds of overhead wire - for trams and trolleybusses, nothing would change about that. But currently, if you build the wrong one, the tram/trolley finds no route, and it's rather hard to visually see why. Especially for new players, that might be frustrating. Now if the electrification would electrify every way, if you used the wrong one, iit only matters visually. And even visually, I don't think it would be a big deal if you had the wrong wire - they are only one pixel thick and might get even thinner now with transparency; what you mostly see about the overhead wire is just the posts.

An_dz

Here's an update where it electrifies both tracks now, previously it was electrifying only one.

THLeaderH

Thank you for making a nice patch.
I made a way-object whose waytype is "decoration". However, it seems that the icon of decoration way appear in nowhere. How can I use decoration way in simutrans?

Here is a part of dat file

obj=way-object
name=test-dec
copyright=teamhimeH
#
waytype=decoration
own_waytype=decoration
#
cost=45700
maintenance=10000
topspeed=999
...

An_dz

You need to add wayobj(255) in the menuconf.tab so they show in any or some of the menus.

THLeaderH

I got it! Thanks ;)

Can I use decoration way as a marker of overtaking_info? (in OTRP project)

sheldon_cooper

Is that correct?

I added the '' toolbar [6] [12] = wayobjs (255) '' to the last line of simuconf.tab (microsoft office word)

Leartin

No, you need to put it in the menuconf.tab, in the right position (after toolbar[6][11]), and without '#'

sheldon_cooper

Thanks The pak appeared on the menu! :) :D

An_dz

Quote from: THLeaderH on March 25, 2017, 02:40:05 AM
Can I use decoration way as a marker of overtaking_info? (in OTRP project)
No, that would be a terrible implementation. I'm already looking in creating a new type or subtype for OTRP.

Vladki

Quote from: An_dz on March 23, 2017, 05:35:35 AM
Here's an update where it electrifies both tracks now, previously it was electrifying only one.

Thank you An_dz. I really like it. I think there will be quite a lot of use for that - street lamps, trees along the road, or noise barriers. Although most of them would probably be useful only on roads, this allows them to be combined with another wayobj - electrification.
I hope it will be soon incorporated into both simutrans standard and extended.

THLeaderH

QuoteNo, that would be a terrible implementation. I'm already looking in creating a new type or subtype for OTRP.
Oh, that's great. Though I already released v9, it's not a integration candidate. When a new type is added, I'll fix OTRP so that it'll match with this patch. I'm considering reverting the integration of this patch. Thank you.

An_dz

Quote from: THLeaderH on March 26, 2017, 01:26:42 AM
Oh, that's great. Though I already released v9, it's not a integration candidate. When a new type is added, I'll fix OTRP so that it'll match with this patch.
Well, I've been wanting to help your patch with a new way-obj that then will only be able to be built on roads to reduce any conflicts and to allow both one-way and decoration wayobj in the same tile.

But - also answering Vladki now - I first want to check the integration with makeobj I'm still not convinced adding it on get_waytype.cc is the best option. After that I'll integrate this patch.

An_dz

I looked around the code and so decided that the current patch is good to be committed. I'll do so as soon as I get access to the SVN as my ISP is even crappier today.

Now I'll start working on the new waytype for OTRP patch. I need to check if it's not better to use it as own_waytype. Then THLeaderH and I can incorporate on OTRP and have a system where cloned ways won't be necessary and to be able to place the decoration wayobj along with the one-way wayobj.

Dwachs

Defining decoration_wt as 255 is a source of potential errors: When converted to 8 bit integer types this will be equal to invalid_wt. Can this happen somewhere?

Edit: I would like to change this value to something like 230. any objections?
Parsley, sage, rosemary, and maggikraut.

Vladki

Wouldn't there be the same problem with already existing walls that are rails with subtype 255?

Sent from my ONEPLUS A3003 using Tapatalk


prissi

subtype is stored elsewhere. But I agree, it should be a high number, like 250, but not the invalid one.

An_dz

Quote from: Dwachs on April 04, 2017, 06:19:47 AM
Defining decoration_wt as 255 is a source of potential errors: When converted to 8 bit integer types this will be equal to invalid_wt. Can this happen somewhere?

Edit: I would like to change this value to something like 230. any objections?
Only place I've found where it's 8 bit is when saving/loading the pak and that's unsigned. And it can never be invalid. But yeah, to be on the safe side we can lower the value to some other random number.

Quote from: Vladki on April 04, 2017, 06:48:40 AM
Wouldn't there be the same problem with already existing walls that are rails with subtype 255?
Yes, if there was a subtype -1, but it does not.