Author Topic: Wayobj 255 (Decoration way)  (Read 1856 times)

0 Members and 1 Guest are viewing this topic.

Offline An_dz

  • Web Admin
  • Administrator
  • *
  • Posts: 2593
  • Total likes: 289
  • Helpful: 89
  • D'oh
    • by An_dz
  • Languages: PT, EN, (it, de)
Wayobj 255 (Decoration way)
« on: March 07, 2017, 08:32:13 PM »
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.

Offline Ichou

Re: Wayobj 255 (Decoration way)
« Reply #1 on: March 07, 2017, 11:42:18 PM »
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?

Offline An_dz

  • Web Admin
  • Administrator
  • *
  • Posts: 2593
  • Total likes: 289
  • Helpful: 89
  • D'oh
    • by An_dz
  • Languages: PT, EN, (it, de)
Re: Wayobj 255 (Decoration way)
« Reply #2 on: March 08, 2017, 12:13:25 AM »
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.

Offline Ichou

Re: Wayobj 255 (Decoration way)
« Reply #3 on: March 08, 2017, 12:26:17 AM »
Wow, great!
But I'm ashamed to say that I don't know how to use .patch file.

Offline DrSuperGood

Re: Wayobj 255 (Decoration way)
« Reply #4 on: March 08, 2017, 12:41:27 AM »
Quote
But 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.

Offline Ichou

Re: Wayobj 255 (Decoration way)
« Reply #5 on: March 08, 2017, 01:16:57 AM »
Quote
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.
Thank you!

Offline Leartin

Re: Wayobj 255 (Decoration way)
« Reply #6 on: March 08, 2017, 06:39:48 AM »
Is it christmas already? Many Thanks!

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?
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.

Offline An_dz

  • Web Admin
  • Administrator
  • *
  • Posts: 2593
  • Total likes: 289
  • Helpful: 89
  • D'oh
    • by An_dz
  • Languages: PT, EN, (it, de)
Re: Wayobj 255 (Decoration way)
« Reply #7 on: March 08, 2017, 02:07:04 PM »
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.

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.

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.

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.

Offline Leartin

Re: Wayobj 255 (Decoration way)
« Reply #8 on: March 08, 2017, 02:16:39 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.

Offline An_dz

  • Web Admin
  • Administrator
  • *
  • Posts: 2593
  • Total likes: 289
  • Helpful: 89
  • D'oh
    • by An_dz
  • Languages: PT, EN, (it, de)
Re: Wayobj 255 (Decoration way)
« Reply #9 on: March 08, 2017, 11:09:15 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.

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.

Offline prissi

  • Developer
  • Administrator
  • *
  • Posts: 8753
  • Total likes: 305
  • Helpful: 229
  • Languages: De,EN,JP
Re: Wayobj 255 (Decoration way)
« Reply #10 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 ...

Offline An_dz

  • Web Admin
  • Administrator
  • *
  • Posts: 2593
  • Total likes: 289
  • Helpful: 89
  • D'oh
    • by An_dz
  • Languages: PT, EN, (it, de)
Re: Wayobj 255 (Decoration way)
« Reply #11 on: March 09, 2017, 12:33:29 AM »
Ok, drawing bug fixed, new patch attached.

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.

Offline Leartin

Re: Wayobj 255 (Decoration way)
« Reply #12 on: March 09, 2017, 06:14:31 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.

Offline Ters

  • Coder/patcher
  • Devotee
  • *
  • Posts: 4685
  • Total likes: 171
  • Helpful: 108
  • Languages: EN, NO
Re: Wayobj 255 (Decoration way)
« Reply #13 on: March 09, 2017, 04:50:54 PM »
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.

Offline Leartin

Re: Wayobj 255 (Decoration way)
« Reply #14 on: March 09, 2017, 07:13:11 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.

Offline An_dz

  • Web Admin
  • Administrator
  • *
  • Posts: 2593
  • Total likes: 289
  • Helpful: 89
  • D'oh
    • by An_dz
  • Languages: PT, EN, (it, de)
Re: Wayobj 255 (Decoration way)
« Reply #15 on: March 23, 2017, 05:35:35 AM »
Here's an update where it electrifies both tracks now, previously it was electrifying only one.

Offline THLeaderH

Re: Wayobj 255 (Decoration way)
« Reply #16 on: March 25, 2017, 01:45:04 AM »
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
Code: [Select]
obj=way-object
name=test-dec
copyright=teamhimeH
#
waytype=decoration
own_waytype=decoration
#
cost=45700
maintenance=10000
topspeed=999
...

Offline An_dz

  • Web Admin
  • Administrator
  • *
  • Posts: 2593
  • Total likes: 289
  • Helpful: 89
  • D'oh
    • by An_dz
  • Languages: PT, EN, (it, de)
Re: Wayobj 255 (Decoration way)
« Reply #17 on: March 25, 2017, 02:33:11 AM »
You need to add wayobj(255) in the menuconf.tab so they show in any or some of the menus.

Offline THLeaderH

Re: Wayobj 255 (Decoration way)
« Reply #18 on: March 25, 2017, 02:40:05 AM »
I got it! Thanks ;)

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

Offline sheldon_cooper

Re: Wayobj 255 (Decoration way)
« Reply #19 on: March 25, 2017, 04:52:40 PM »
Is that correct?

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

Offline Leartin

Re: Wayobj 255 (Decoration way)
« Reply #20 on: March 25, 2017, 05:09:35 PM »
No, you need to put it in the menuconf.tab, in the right position (after toolbar[6][11]), and without '#'

Offline sheldon_cooper

Re: Wayobj 255 (Decoration way)
« Reply #21 on: March 25, 2017, 06:59:54 PM »
Thanks The pak appeared on the menu! :) :D

Offline An_dz

  • Web Admin
  • Administrator
  • *
  • Posts: 2593
  • Total likes: 289
  • Helpful: 89
  • D'oh
    • by An_dz
  • Languages: PT, EN, (it, de)
Re: Wayobj 255 (Decoration way)
« Reply #22 on: March 25, 2017, 08:29:25 PM »
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.

Offline Vladki

Re: Wayobj 255 (Decoration way)
« Reply #23 on: March 25, 2017, 09:14:18 PM »
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.

Offline THLeaderH

Re: Wayobj 255 (Decoration way)
« Reply #24 on: March 26, 2017, 01:26:42 AM »
Quote
No, 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.

Offline An_dz

  • Web Admin
  • Administrator
  • *
  • Posts: 2593
  • Total likes: 289
  • Helpful: 89
  • D'oh
    • by An_dz
  • Languages: PT, EN, (it, de)
Re: Wayobj 255 (Decoration way)
« Reply #25 on: March 26, 2017, 01:56:32 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.

Offline An_dz

  • Web Admin
  • Administrator
  • *
  • Posts: 2593
  • Total likes: 289
  • Helpful: 89
  • D'oh
    • by An_dz
  • Languages: PT, EN, (it, de)
Re: Wayobj 255 (Decoration way)
« Reply #26 on: March 29, 2017, 10:47:02 PM »
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.

Offline Dwachs

  • DevTeam, Coder/patcher
  • Administrator
  • *
  • Posts: 4224
  • Total likes: 168
  • Helpful: 148
  • Languages: EN, DE, AT
Re: Wayobj 255 (Decoration way)
« Reply #27 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?
Parsley, sage, rosemary, and maggikraut.

Offline Vladki

Re: Wayobj 255 (Decoration way)
« Reply #28 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?




Offline prissi

  • Developer
  • Administrator
  • *
  • Posts: 8753
  • Total likes: 305
  • Helpful: 229
  • Languages: De,EN,JP
Re: Wayobj 255 (Decoration way)
« Reply #29 on: April 04, 2017, 07:52:43 AM »
subtype is stored elsewhere. But I agree, it should be a high number, like 250, but not the invalid one.

Offline An_dz

  • Web Admin
  • Administrator
  • *
  • Posts: 2593
  • Total likes: 289
  • Helpful: 89
  • D'oh
    • by An_dz
  • Languages: PT, EN, (it, de)
Re: Wayobj 255 (Decoration way)
« Reply #30 on: April 04, 2017, 07:58:41 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.

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.