The International Simutrans Forum

 

Author Topic: Introduction of new waytypes  (Read 2015 times)

0 Members and 1 Guest are viewing this topic.

Offline Phystam

  • *
  • Posts: 418
  • Pak256.Ex developer
    • Pak256 wiki page
  • Languages: JP, EN, EO
Introduction of new waytypes
« on: February 05, 2019, 04:36:19 AM »
Hello everyone!

We pak256-ex team are thinking introduction of new waytypes.
1) decoration waytype:
Code: [Select]
waytype=decoration
Among Japanese simutrans players, "building station(stop)s on the way(canal)" is famous way to build various station, like follows:


But I think that canal should be used as canal, and it is inconvenient when using station filter. In order to construct various type of stations or pedestrian way, I would like to introduce a new waytype.

2) narrowgauge tram waytype:
Code: [Select]
waytype=narrowgauge_tram_track
or
waytype=narrowgauge_track
system_type=7
Narrow gauge should be similar to track, but there is some restriction than normal track waytype.
In the early era, narrow gauge track on road existed like this picture:

Currently we could not construct it. If narrowgauge tram waytype exists, it would be more flexible for construction.

How do you think about them?

Offline Vladki

  • Devotee
  • *
  • Posts: 3244
    • My addons, mostly roadsigns, pak128.cs
  • Languages: EN, CS
Re: Introduction of new waytypes
« Reply #1 on: February 05, 2019, 07:44:35 AM »
For decorations there are already some addons like noise barriers, that use way type track, system type 255. (look for french pak128 addons)

Also you can also make decorative wayobjects which are not providing electricity, like street lamps (pak128.cs)

Narrow gauge tram is not possible but I would like it too. That would need some change in code.


Offline Phystam

  • *
  • Posts: 418
  • Pak256.Ex developer
    • Pak256 wiki page
  • Languages: JP, EN, EO
Re: Introduction of new waytypes
« Reply #2 on: February 05, 2019, 09:23:51 AM »
Noise barriers are just a waytype for wayobj -- it is currently unable to use as a way.
What I need are:
1) not connected with other waytype such as track, road and so on;
2) the stop for new waytype acts like an extension of station;
3) can be constracted above existing station.

Offline jamespetts

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 19687
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Introduction of new waytypes
« Reply #3 on: February 05, 2019, 10:35:04 AM »
Narrow gauge tram track would be a worthwhile addition; I do not have the time to code this myself at present, as there is a very long queue of bugs and balance critical features, but if you would like to code this, do go ahead.

Incidentally, if you are adding new way types, it might be worthwhile considering altering the way in which way types are represented in the code so as to allow arbitrary way types  so that future way types can be added just by changing configuration files rather than changing the code each time.

Narrow gauge tram track was used in the British isles, too: the Birmingham trams were all narrow gauge, and the Manx Electric Railway in the Isle of Man is a narrow gauge electric tramway, albeit one travelling between small towns on that island rather than within a large town as in Birmingham.

Offline ACarlotti

  • *
  • Posts: 483
Re: Introduction of new waytypes
« Reply #4 on: February 05, 2019, 04:01:57 PM »
This sounds like something that wouldn't be out of place in Standard, so I'd suggest checking whether they'd want it. If they do, then you can develop it in a form that they would accept too.

Offline jamespetts

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 19687
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Introduction of new waytypes
« Reply #5 on: February 05, 2019, 04:36:44 PM »
This sounds like something that wouldn't be out of place in Standard, so I'd suggest checking whether they'd want it. If they do, then you can develop it in a form that they would accept too.

This is probably sensible - I believe that this has been discussed for Standard in the past.

Offline Phystam

  • *
  • Posts: 418
  • Pak256.Ex developer
    • Pak256 wiki page
  • Languages: JP, EN, EO
Re: Introduction of new waytypes
« Reply #6 on: February 05, 2019, 05:06:06 PM »
Thank you, probably I can bring the feature of narrowgauge tram to Standard.

Now, maybe I successed to construct narrowgauge on road and make schedules as same as tram_track.


However I cannot load existing save data; I will try to fix it.
--
version increments:
Code: [Select]
EX_VERSION_MINOR 4
EX_SAVE_MINOR 6
MAKEOBJ_VERSION "60.1"

---
now I could open existing file.
I pushed it to https://github.com/Phystam/simutrans-extended/tree/narrowgauge_tram_track.
I prepared pak256-Ex pakset for the test:
https://github.com/Phystam/pak256-release/tree/test_for_narrowgauge_tram_track.
« Last Edit: February 05, 2019, 05:57:02 PM by Phystam »

Offline jamespetts

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 19687
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Introduction of new waytypes
« Reply #7 on: March 13, 2019, 01:28:30 AM »
My apologies for not having had time to get to this for a while: I see that quite a lot of work has gone into this.

One initial thought is this: I see that the narrow gauge tram track is defined as waytype no. 9, which is immediately following a number of existing waytypes. One concern is that, if Standard adds a waytype (other than narrow gauge tram track), this number might clash with Standard's implementation. May I ask whether this addition has been canvassed with Standard?

One thing to consider is whether it is worthwhile having code for adding arbitrary waytypes rather than just specifically narrow gauge tram track. Indeed, the only reason against doing this that I can see is if this would be too much work to make it worthwhile and if narrow gauge tram track is likely to be the only way type that anyone adds in the foreseeable future.

Narrow gauge trams might be useful for Pak128.Britain-Ex; I know that Birmingham had them, as did the Isle of Man.

I will review the patch fully when I have time after we have discussed and resolved the issues regarding the addition of a single new way type in Extended only.

I do take into account that there is demand for this in respect of Pak.256, and I should very much like to see that pakset flourish, as it can only be good for the Simutrans community generally for there to be multiple actively maintained Simutrans-Extended paksets, and I know that Simutrans is very popular in Japan.

Offline Vladki

  • Devotee
  • *
  • Posts: 3244
    • My addons, mostly roadsigns, pak128.cs
  • Languages: EN, CS
Re: Introduction of new waytypes
« Reply #8 on: March 13, 2019, 07:57:32 AM »
Is the narrow gauge tram compatible with narrow gauge railway? Can they connect and pass vehicles from one to another?

Offline Phystam

  • *
  • Posts: 418
  • Pak256.Ex developer
    • Pak256 wiki page
  • Languages: JP, EN, EO
Re: Introduction of new waytypes
« Reply #9 on: March 14, 2019, 01:50:52 AM »
Thank you for your comments.
What I called “narrowgauge tram” is just the way of “narrowgauge track on road.”
The system is just a copy of tram_track. Vladki, Don’t worry about that.

The waytype number should be considered again. If the waytype is also incorporated in Standard, we don’t have to change the waytype number for narrowgauge tram.

Anyway, I will ask for standard developers.

Thank you.

PS. please separate the topic for narrowgauge tram and new customizable waytype from this thread.

Offline jamespetts

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 19687
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Introduction of new waytypes
« Reply #10 on: March 14, 2019, 02:01:55 AM »
Thank you for your thoughts. Do let me know when you have had feedback from the Standard developers.

As to separating the topics, I am not entirely sure what to separate, as the two topics are very closely related; perhaps they had better remain unified for the present.

Offline Phystam

  • *
  • Posts: 418
  • Pak256.Ex developer
    • Pak256 wiki page
  • Languages: JP, EN, EO
Re: Introduction of new waytypes
« Reply #11 on: March 14, 2019, 04:02:24 AM »

Offline Phystam

  • *
  • Posts: 418
  • Pak256.Ex developer
    • Pak256 wiki page
  • Languages: JP, EN, EO
Re: Introduction of new waytypes
« Reply #12 on: December 28, 2019, 05:02:00 PM »
Recently I considered about this issue.
For the new decoration waytype, it can be one of another "system_type." system_type is used only for identifying ground level / elevated / tram ways, or runway / taxiway. Additionaly we can introduce new system_type for decoration, which is assigned to 31 (ground) and 32 (elevated) for example.
And at the same time, pakset mantainer or user can introduce new system_type for flexible use using simuconf.tab or aother setting file.

Offline jamespetts

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 19687
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Introduction of new waytypes
« Reply #13 on: December 28, 2019, 05:47:47 PM »
I can certainly see that having a dedicated system type for a decoration waytype would be sensible. I wonder whether thought should be given to synchronising this with Standard, too?

Presumably, decoration waytypes would usually be built at no cost to the player, since they would generally have no in-game economic benefit?

Offline Phystam

  • *
  • Posts: 418
  • Pak256.Ex developer
    • Pak256 wiki page
  • Languages: JP, EN, EO
Re: Introduction of new waytypes
« Reply #14 on: December 28, 2019, 06:56:06 PM »
For standard, if the diffrence of source code is not so large, maybe one can synchronise it. I think that feature to use it for pak256-Ex. So implementation for standard is not considered.

Decoration way system type itself (like a base, pedestrian way) doesn't have any benefit, but when a player constructs a "stop," it will attract some passengers and mail. So, that have indirect benefits.

Offline jamespetts

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 19687
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Introduction of new waytypes
« Reply #15 on: December 28, 2019, 07:42:03 PM »
Decoration way system type itself (like a base, pedestrian way) doesn't have any benefit, but when a player constructs a "stop," it will attract some passengers and mail. So, that have indirect benefits.

I am not sure that I fully understand the economics (or mechanics) of this: would this mean that each individual tile of way would be added to the passenger destination list? In what sense are these fences, etc. destinations in themselves?

One issue with decoration waytypes is this: even if the way itself has no cost to the player, it must be built on land, which ordinarily would have a cost to the player. So, either the player has to pay money for land to store something of no economic benefit, or the player gets to reserve land for free, when this is normally chargeable. Perhaps decoration waytypes might be thought of as an alternative way of reserving land, when compared to signs, for example?

Offline Phystam

  • *
  • Posts: 418
  • Pak256.Ex developer
    • Pak256 wiki page
  • Languages: JP, EN, EO
Re: Introduction of new waytypes
« Reply #16 on: December 28, 2019, 08:40:26 PM »
Stop is a building type, so it can have population_and _visitor_demand_capacity and employment_capacity. Therefore it has a potential to attract passengers. Note that the “stop” is like a part of station building which contains commercial shops.

I don’t think that the way can be constructed without payment. Yes, there is forge costs. Even if the way itself is free, players have to pay it. And, yes, it would be a alternative way to reserve sequential tiles.

Offline jamespetts

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 19687
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Introduction of new waytypes
« Reply #17 on: December 28, 2019, 10:18:29 PM »
Stop is a building type, so it can have population_and _visitor_demand_capacity and employment_capacity. Therefore it has a potential to attract passengers. Note that the “stop” is like a part of station building which contains commercial shops.

I don’t think that the way can be constructed without payment. Yes, there is forge costs. Even if the way itself is free, players have to pay it. And, yes, it would be a alternative way to reserve sequential tiles.

Is the idea then that there would be specific types of stops for these decoration waytypes?

Offline Phystam

  • *
  • Posts: 418
  • Pak256.Ex developer
    • Pak256 wiki page
  • Languages: JP, EN, EO
Re: Introduction of new waytypes
« Reply #18 on: December 29, 2019, 05:01:19 AM »
Yes, we will newly introduce ‘decoration_stop’ building type in order to separate menu bars.

Offline jamespetts

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 19687
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Introduction of new waytypes
« Reply #19 on: December 29, 2019, 12:51:19 PM »
Interesting.

Incidentally, what was the ultimate decision regarding the narrow gauge tram waytype and its possible interaction with Standard?

Offline Phystam

  • *
  • Posts: 418
  • Pak256.Ex developer
    • Pak256 wiki page
  • Languages: JP, EN, EO
Re: Introduction of new waytypes
« Reply #20 on: December 29, 2019, 04:03:13 PM »
I have not seen the standard code, so I cannot say anything about Standard.
If the narrow gauge tram waytype will be implemented to standard, it is rather better.

The last reply of prissi was:
My guess is that at some places the implicit assumption of system_type=7 means track must be removed; maybe just adding 16 in this case to the waytype and change waytype 7 (the olf tram_track) to 18. That way also maglev etc. could get road tracks. I think the changes might be not so big as that they could not easily port to experimental. Probably also with makeobj support (system_type=7 means adding 16 too base waytype.)

I rather expect experimental to have more troubles, since there are much more options to be considered. Or the other way round, if the changes were simple, one could do a similar thing in standard manually.