News:

The Forum Rules and Guidelines
Our forum has Rules and Guidelines. Please, be kind and read them ;).

Distinguish "Multiple unit" into another tab

Started by Ranran(retired), March 03, 2019, 11:40:04 AM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Ranran(retired)

Hi. I am sorry for extended developers busy with a serious bug but I cast out a new agenda. (´・ω・`)
There is no need to hurry.

"Multiple unit" - I want this distinction in the depot, especially the train depot.
Point is, I want to distinguish between passenger carriages (coaches) and DMU.

I am sure this will be useful for convoy re-combination system. Because DMUs and coaches operate differently.
Players will look for DMUs to couple the DMU.
Players will look for coach to add convoy consisting of coach and locomotive.
Because of the control train line it is rarely to connect DMU and coach. And doing that will not benefit too much.
They are used for different purposes because they have different characteristics. It will become more prominent as re-combination becomes possible.
For example, each detached DMU heads to a different location.
The separated coach is waiting at the station or yard until the next turn. Because it can not move alone.


What do you guys think about such separating tab? Is this a Galapagosization?
BTW, in Japan, coaches were wiped out by the Shinkansen. Yes, that's JALAPAGOS!  8)




Anyway, I tried to implement it.



This bumped into a big problem. (´・ω・`)
(From here it's a matter of code)
Vehicles that do not have engine_type set on dat are treated as diesel. (engine_type = 1)
That means that vans and coaches are classified as diesel cars.  ::(
So the image above distinguishes vehicle which has power, but that is not right.  ::-\
engine_type = 0 is steam. When is a van given engine_type = diesel?
Is this an extended specification?
ひめしという日本人が開発者達の助言を無視して自分好みの機能をextendedに"強引に"実装し、
コードをぐちゃぐちゃにしてメンテナンスを困難にし(とりわけ道路と建物関連)、
挙句にバグを大量に埋め込み、それを知らんぷりして放置し(隠居するなどと言って)別のところに逃げ隠れて自分のフォーク(OTRP)は開発を続けている
その事実と彼の無責任さに日本人プレイヤーは目を向けるべき。らんらんはそれでやる気をなくした(´・ω・`)
他人の振り見て我が振り直せ。ひめしのようにならないために、らんらんが生み出したバグや問題は自分で修正しなくちゃね(´・ω・`)

accord2

This is a great idea!
EDIT: Maybe James could allow you to be part of the team?
Son of a railroad man,  growing up in train stations, lover of trains

Ves

I highly agree that there is a need for something that distinguishes multiple units from ordinary vehicles. I am running into that issue myself in the vehicle manager that I'm programming.

But I don't think there is an easy way out, and I don't even think that it is possible without more fundamental alterations to the code.
A multiple unit is something that cannot disconnect or reconnect the units easy outside the depot/workshop but in simutrans there is no concept for what vehicles can (theoretically) disconnect and reconnect outside the depot, nor have there been any need for such distinction since vehicles anyway could only be assembled in the depot.
It would not work just to look at the constraint next/prev since that would give false positives and negatives. Alot of the vehicles in pak Britain has extensive constraints and cannot be left either at the front not the back, and it could look like such a vehicle is a DMU of some sort to Simutrans even though it is just a regular car. And then, especially with the first generation units, they where really only motorized cars that could attach and pull other cars, just like a locomotive, including goods cars.

In the same manner it is not possible to just look at train vehicles that has power and carry passengers, mail or good, since in many cases not all vehicles of the DMU has power or are coded as electric (which would put them into the electrics tab).

What I think is needed is some new datfile parameters which determine whether vehicles can detach outside the depot (along the lines of fixed_coupling_next=1 and fixed_coupling_prev=1) and if any of those are true, the vehicle is considered a multiple unit of some sort and can be further sorted into DMU's, EMU's, articulated vehicles etc later.

But for now I believe that we just will have to stick with what it looks like at the moment I'm afraid...

Skickat från min ONEPLUS A6003 via Tapatalk


jamespetts

This is a useful addition, even if it does not solve all of the problems to which Ves refers.

I will look into integrating this when I have a little more time and the bug fixing work is more advanced, but one small thing that I note is that "railcar" would be a better term than "multiple unit" here, as "railcar" can include a single vehicle, whereas "multiple unit", as the name suggests, requires two or more vehicles.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Ranran(retired)

Thank you for your thoughts.  :)
I think that the first article was somewhat lacking in explanation - my apology. (´・ω・`)

Quote from: jamespetts on March 03, 2019, 10:23:18 PMbut one small thing that I note is that "railcar" would be a better term than "multiple unit" here, as "railcar" can include a single vehicle, whereas "multiple unit", as the name suggests, requires two or more vehicles.
I agree that railcar is better.
After all what I meant was a distinction between "passenger/mail cars to be pulled by locomotive" and "passenger/mail cars which can run without relying on locomotives and without restriction of electrification".


@Ves
My intention is not to extend the system but to improve usability. When I wanted to use DMU in the depot it is buried in a lot of coaches.
I was expecting that this could be realized without changing the currently vehicle data. It seems to be another problem, not to discriminate whether it can be detached outside the depot.
However, since the operation method is different as described above, I think this is useful for re-conmbination.


I assumed that vehicles like van and couch were set to engine_type = NULL or unknown.
So I planned to extract things that are not electric and others (eg diesel, petrol, fuel cell, battery) and move to another tab.
For passengers/mail vehicles that are supposed to be pulled by the locomotive, the power scheme depends on the locomotive, so it should not have power and unique engine_type.

Meanwhile, electric cars that do not have power are properly distinguished as engine_type=electric, not diesel.
DMU vehicles that should be joined together regardless of whether they have power or not should be in the same tab.
For example, a head car having the power of BR Class 251 and an intermediate car having no power.
If DMUs without power are on different tabs, players will be more likely to miss it.

For BR Class 251, the intermediate car does not have power, but engine_type = diesel is properly set.
https://github.com/jamespetts/simutrans-pak128.britain/blob/master/trains/br-251.dat

I thought that DMU vehicles that do not have power can also be distinguished by specifying engine_type = diesel like EMU.
However, contrary to my expectation, all vehicles not specified as engine_type like van or couch have values of diesel. (get_engine_type() returns 1)
I wondered this, so I looked it up, and I found out that makeobj write it when making a pak file.
Then I modified makeobj to set unknown for vehicles with unset engine_type, and tested it.
It works well and seems to cause no problems in particular.
With this fix, coaches return get_engine_type() = -1 (255).
At the moment, engine_type of non-powered vehicle seems to have no influence at all except for electricity.
I think it is also useful for Ves's vehicle manager to properly distinguish them by data structure.

With this fix, railcar without power can also be included in the tab of railcar, but in order to make separations work correctly paks written with new makeobj are needed.
I upload this testing Makeobj-Extended  60.01 for windows.

About testing makeobj:
- In order to clarify the correspondence between pakset and makeobj, I increased the extended revision by one.
- The version of makeobj is 60.01. This is because the current standard is 60.2. In order to be more than 60.1 we will need to incorporate changes from standard.
- Since it only changes coach 's engine_type from diesel to unknown, it should have no effect on the current version.
- It will be able to distinguish them when new railcar tabs are added.


As of now I have made railcar tab correspond to only just track / tram / narrowgauge, but by using different conditions it is possible to separate tabs in other waytypes.
For example, to isolate creatures for road, to make mail a different tab from passenger etc. Any good idea?  :idea:

The branch of my github is here.
https://github.com/Ranran-the-JuicyPork/simutrans-extended/tree/add-railcar-tab
ひめしという日本人が開発者達の助言を無視して自分好みの機能をextendedに"強引に"実装し、
コードをぐちゃぐちゃにしてメンテナンスを困難にし(とりわけ道路と建物関連)、
挙句にバグを大量に埋め込み、それを知らんぷりして放置し(隠居するなどと言って)別のところに逃げ隠れて自分のフォーク(OTRP)は開発を続けている
その事実と彼の無責任さに日本人プレイヤーは目を向けるべき。らんらんはそれでやる気をなくした(´・ω・`)
他人の振り見て我が振り直せ。ひめしのようにならないために、らんらんが生み出したバグや問題は自分で修正しなくちゃね(´・ω・`)

Ves

Well in that case you did solve a way to identify them!  :P
Yes I will match the tabs system in the vehicle manager eventually.

jamespetts

Thank you for your work on this.

I am not entirely clear about the function of the revised makeobj. Is it not possible for the code as to the tabs to identify non-powered vehicles which only connect to multiple units and display those in the appropriate tab notwithstanding whatever their engine type may be set as without having to alter makeobj?
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Ranran(retired)

The problem is that coach is treated as diesel at present.
This is because the current makeobj gives the coach the attributes of diesel.
It writes engine_type = 1

Although it is theoretically possible, I think that it needs complicated processing.
It is because there is no simple way to distinguish a coach and a intermidate DMU car which does not have power.
At present pak file has data as "diesel" car that does not have power in either example.
For example, BR - 251 Second Parlor is a DMU, but it does not have power. It is difficult in the present situation to distinguish this from coach.
It is feasible if it has constraint with a powered DMU and identifies it as a DMU, but I think it is very troublesome.
ひめしという日本人が開発者達の助言を無視して自分好みの機能をextendedに"強引に"実装し、
コードをぐちゃぐちゃにしてメンテナンスを困難にし(とりわけ道路と建物関連)、
挙句にバグを大量に埋め込み、それを知らんぷりして放置し(隠居するなどと言って)別のところに逃げ隠れて自分のフォーク(OTRP)は開発を続けている
その事実と彼の無責任さに日本人プレイヤーは目を向けるべき。らんらんはそれでやる気をなくした(´・ω・`)
他人の振り見て我が振り直せ。ひめしのようにならないために、らんらんが生み出したバグや問題は自分で修正しなくちゃね(´・ω・`)

Ranran(retired)

I made a patch that requires a makeobj update, so I think it might be better to go along with it.
ひめしという日本人が開発者達の助言を無視して自分好みの機能をextendedに"強引に"実装し、
コードをぐちゃぐちゃにしてメンテナンスを困難にし(とりわけ道路と建物関連)、
挙句にバグを大量に埋め込み、それを知らんぷりして放置し(隠居するなどと言って)別のところに逃げ隠れて自分のフォーク(OTRP)は開発を続けている
その事実と彼の無責任さに日本人プレイヤーは目を向けるべき。らんらんはそれでやる気をなくした(´・ω・`)
他人の振り見て我が振り直せ。ひめしのようにならないために、らんらんが生み出したバグや問題は自分で修正しなくちゃね(´・ω・`)

jamespetts

I have now had a chance to test this. This is very good - it does make selecting vehicles in the depot much easier. I have not found any problems with this, so I have incorporated it, and it will be in the next nightly build. Thank you for your work on this.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.