Started by Ranran, March 12, 2019, 03:11:18 PM
0 Members and 9 Guests are viewing this topic.
Quote from: Ranran on April 13, 2019, 01:53:24 PMAt least the current extended does not consider the case where the bidirectional = 1 locomotive is single headed.For example, this type of locomotive never works properly (if you treat this vehicle as two cars).https://en.wikipedia.org/wiki/SBB-CFF-FFS_Ae_8/14
Quote from: jamespetts on April 14, 2019, 11:06:50 PMOne thing that might be helpful once this has been finalised is to put up a post somewhere explaining what each of the symbols mean, with pictures of what each of them look like, in a list format.
QuoteThe explanation should also be in the in-game help files, although unfortunately I do not believe that it is possible to have pictures in these.
Quote from: Ves on April 28, 2019, 10:14:23 AMnot get the numbering system, in the picture it appears to count backwards or am I missing something?
Quote from: Vladki on April 15, 2019, 10:22:41 PMI think it would be better to have the code more generic and not dealing with specific exceptions. There are other configurations that behave similarly. E.g. a DMU/EMU with regular waggons attached at the end. It is a working configuration, but the DMU/EMU loses the very quick reversal, as it has to shunt to the other end, but it should move as-is. I will prepare a sample - I have the class 131 in pak128.cs, but I ca't get the whole pakset working (see my report a few days ago)
Quote from: Ranran on April 16, 2019, 04:23:15 PMThis is a clutter job (Including the latest in-game demo), but we can display the legend when nothing is selected.I'm not an English speaker, so I can't make of an appropriate English text, but I think it's preferable to be as short as possible.Considering the minimum display width of 64px pakset, it may be better to describe only the shape of the bar.And add the difference between powerd and unpowerd and fixed coupling thing.What do you guys think about this?
QuoteI hope that help text can extend the description in html format for added color description and symbol description.
Quote from: Ranran on April 27, 2019, 11:59:06 AMI am working slowly. (´・ω・｀)I tried adding information of formation to convoy detail window.I will explain in order from the top.As I do not know the correct English expression, I will add Japanese sideways. (´・ω・｀)In Japanese, "編成図" is the best word.(´・ω・｀)この編成図は常に左側が先頭です。This formation picture is always head on the left.- Car no. (号車番号)The locomotive and others are numbered separately. The letters before the locomotive number can be changed by the translation file.In case of return trip, car numbers will be in reverse order except locomotive.The car numbers of vehicles that can be upgraded will turn purple.- Formation picture (編成図)This is the same as the depot dialog, but it is used to represent vehicle conditions. i.e. outdated vehicle or not. It does not display the error of coupling.- Boarding rate indicator (混雑度表示)Those that do not carry cargo, such as locomotives and caboose, are displayed in gray.Yellow is empty. 100% boarding rate is orange. The boarding rate over 100% is dark purple. Other than those is lime green.If there are multiple classes, they will be integrated.(´・ω・｀)らんらん♪
Quote from: Ves on May 11, 2019, 12:20:45 AMI dont think we would need a -1 for the "has_front/rear_cab".
Quote from: Ranran on May 11, 2019, 01:49:38 PMThank you for your advice. That's very helpful.I changed the legend based on your advice.Does this change make sense?
QuoteAbout Permanent Coupling:It is conscious of the form of looking at two separate things as one. The existence of jagged edges become a lie, so we need to hide it. So I cover it with a black vertical bar.This will be used mainly in the following cases- a pair of unit- one vehicle is divided into two because the cargo category is differentThis is especially useful if players want to understand the formation of EMU. Many trains today are unitized.For example, when remove it from the assembling convoy in the depot, it is obvious that deselecting one will simultaneously release the permanently coupled vehicles.
QuoteThe -1 setting exists for compatibility. When using a new makeobj, it is necessary to describe the presence or absence of a cab on all vehicles if the absence of a cab is determined forcibly.By setting the default to auto, only the minimum necessary description is required. I have already finished changing the minimum .dat of the britain pak. It will not require many .dat changes.
QuoteI ran into merge conflicts
QuoteOne query with this is how you intend can_lead_from_rear to interact with has_rear_cab; is the idea that has_front_cab and has_rear_cab will supersede can_lead_from_rear, which will be retained for legacy compatibility, or is the idea that they will continue to retain distinct and useful functions?
Quote from: Phystam on May 17, 2019, 12:35:11 PMRanran, Can you help anything related to this? Check list is most helpful for me.
QuoteI dont know how you are doing the bars, wether it is all png graphics or if the shapes are coded directly in the code.
QuoteI have a feeling we can discuss this on and on and on why I think its a bad idea and you think it is a good idea.
QuoteI see all cases of two vehicles that would be fixed to each other as "a pair of units", no matter if I could have chosen five different vehicles to "fix" to the initial vehicle or only one. It doesnt make any differense.
There are two types of Class 385, a four-car trainset and a three-car train set. The four-car train sethas two motor cars (M) and two trailer cars (T) inwhat is called a 2M2T configuration. For a three-cartrain set, in contrast, sufficient traction capacity isprovided by 1.5 M cars. Accordingly, the Class 385adopts a system in which the traction unit (converter)is split into two drive systems, with each car havingtwo motor bogies that are controlled separately (seeFig. 4). This means that three-car train sets can havea 1.5M1.5T configuration in which one of the bogieson one of the two M cars is a trailer bogie, therebyeliminating two traction motors and one traction unitdrive system. This configuration reduces the weight ofa three-car train set by approximately 1.5 t.
Quote from: Ves on May 18, 2019, 07:22:12 PMBut if, say, such a unit had a variation for whatever reason, hence triggering the "fixed" symbol instead, you could not rely on the symbol anymore to detect those units (since the "permanent coupling" symbol only appears when there is exactly one (available?) vehicle in the constraint specification). Then some of those units would have the "permanent coupling" marker and others have just the "fixed coupling" marker for no other reason than the unit exists in two variants. Wouldnt you find that inconsistent?
Quote from: Vladki on May 18, 2019, 10:33:07 PMSo imho it is not worth creating a coupling that can never be decoupled. Otoh it might be worth to charge for decoupling fixed/permanent coupling in depot.
QuoteThen some of those units would have the "permanent connection" marker and others have just the "fixed coupling" marker for no other reason than the unit exists in two variants. Wouldnt you find that inconsistent?
QuoteBut in practice you still can swap the parts.
QuoteThat would still require a visit to the replacer window to find out.
QuoteBut due to some variations that have existed (seat configurations, catering capabilities, power variants etc) I need to make the initial unit able to connect to all of them and vice versa.
Quote from: jamespetts on May 19, 2019, 12:11:46 PMOne thing that I notice on loading the Pak128.Britain-Ex demo game is that, on entering the depot, the 4-SUB unit does not appear to conform to the description of the symbols, in that the intermediate vehicles have the symbol showing that they can be at the rear of the train, yet they cannot. However, is this the expected behaviour when the pakset has not been compiled with the dedicated version of makeobj?
QuoteIf so, I wonder whether some different defaults might be useful, as I cannot immediately see how a vehicle that does not have either no "next" constraints or a "none" constraint should ever show the symbol for allowing it to be at the rear of a train.
QuoteI have noticed some overlapping text in the details window, where "LOCO_" (something, which I cannot read because of the overlapping) overlaps with the numbers for the individual vehicles. This can be seen in convoy no. 101 in the Pak128.Britain-Ex demo game.
Quote from: Ranran on May 19, 2019, 07:05:54 AMI use the expression "permanent connection" as proposed by ACarlotti.
Quote from: Ranran on May 19, 2019, 07:05:54 AMIt is treated as fixed because one side is not fixed but the other side does not allow disconnection.
Quote from: Ranran on May 19, 2019, 07:05:54 AMAt least the "permanent connection" sign serves as an expression of "automatic coupling" or "automatic back to storage" in the depot.Changing yellow bar to another color does not solve this problem. This is not supported for back to storage. All convoy's already assembled are usually show green bar.
QuoteI also think it can give a notice to display the information when implementing the function to display the total of the vehicles combined together when selecting a vehicle in the depot.That is, the total length and price are displayed when the player hovers over the vehicle having that symbol. So you can check before you purchase.
Quote from: ACarlotti on May 19, 2019, 12:45:08 AMI have two suggestions that might help. Firstly, I would change the name to 'permanent connection'. This avoids the word 'coupling', which to me implies that it is possible to uncouple (though not necessarily everywhere).And secondly, I think a much better example of a 'permanent connection' can be found in ships. In pak128.Britain, it is common for ships to have space for multiple holds - these holds can then potentially provide for a number of different goods types. Since the hold is literally built into the structure of the ship (presumably upon construction), then it would be infeasible to switch holds between different ships (in a much more fundamental way than applies to trains or any other convoy that can bend between vehicles). This need not prevent changing what a ships can carry, but such changes would need to be made by converting (upgrading) one type of hold to another. Furthermore, this would have a meaningful effect on gameplay, unlike an example of a rigid vehicle represented as two vehicles in Simutrans with a unique configuration, where the potential to swap vehicle halves would have no benefits (compared to not swapping halves).
Quote from: Ranran on May 19, 2019, 07:05:54 AMOne more example, this articulated locomotive is a permanent connection. They never swap with other same class ones. On the front is the car's serial number 4, but of course on the other side shows also serial number 4.But that of pak.CS may not be, idk.
Quote from: Ranran on May 19, 2019, 07:05:54 AMIn many cases the term permanent was also incorrect. This is also expressed as semi-permanent in Japanese.
Quote from: Vladki on May 19, 2019, 01:30:09 PMQuote from: Ranran on May 19, 2019, 07:05:54 AMIt is treated as fixed because one side is not fixed but the other side does not allow disconnection.Now you confused me even more. I thought that fixed/permanent coupling is something that is the same on both sides. What you describe seems that it can be decoupled easily, but will leave one part unable to move without the other. That is imho not what fixed/permanent coupling should mean.
Quote from: Vladki on May 19, 2019, 01:30:09 PMBut in my view rail cars with half passenger and half mail are a good example of truly permanently coupled vehicles (and those exist in pak.CS)
QuoteI don't think it's necessary to distinguish between real units.
QuoteThere is also a large discrepancy in representing the passenger and mail compartments in the same vehicle as two vehicles. (As ACarlotti points out)It is sufficient for the meaning of the symbol to have only one coupling partner.
QuoteIn that way, I think there are some situations where this distinction is useful. And since it doesn't look much different than a fixed couple, it won't be too confusing.Rather, I think the difference in GUI behavior will continue to cause a confusion if we don't make this distinction.Since "permanent connection" also has the characteristic of "fixed couple" there is not much difference in the meanings of the two symbols.
QuoteI don't think so. "Power units" usually do not separate.There is a description in Japanese here, but unfortunately there is no similar description in the English version.For example, a plurality of dedicated cables are provided between a motor car equipped with a pantograph and a motor car not equipped with the pantograph, but it is not required between the power unit and another car. And a device on one side controls eight motors. And there's no need to use a normal coupler between them, and they are fixed by bar and bolts together.
QuoteIn addition, vehicles that are permanent connections often share maintenance information (Upgrades and timing of retirement), and it is worthwhile to be able to read it from picture.For example, vehicles of different types may be mixed, but the unit vehicles of permanent connection are almost the same class.On the other hand, the fixed relationship may simply be EMU or DMU, or a vehicle manufactured at a completely different time.
Quote from: Vladki on May 19, 2019, 08:22:33 PMBut please do not use the words fixed/permanent coupling for vehicles that are just constrained in way that triggers automatic purchase of the next unit. It just causes confusion.
QuoteRanran, I did tell you that the autobuy feature can indeed be disabled, I showed where in the code in this thread.
QuoteIt is neccessary to distinguish between real units! Unless you want the pakset author to have multiple copys of the same first unit because the second unit exists in several variations. That is an unfair assumption to make and very difficult for the author to draw the line where it should be permanent and only fixed.Therefore every unit has to be its own entity by default.
QuoteNO units in a DMU or EMU usually separate
QuoteWrong, implying there is a difference, makes the player also think there is a difference, most likely a difference bigger than just the autobuy.
QuoteBut given enough effort, all units in a DMU or EMU can separate
Quotea) a bug in simutrans (perhaps shared with standard) that the autobuy/autosell is triggered when it should not (or not invoked when it should be)
QuoteWhen it is in a relationship of A→←B→C,BC is automatically purchased when you buy A.B is not purchased automatically when C is purchased in Insert mode.removing C from ABC's convoy then automatically remove A and B.Selling A or B will sell all ABC, but selling C will not automatically sell A and B.