[Genma Saotome]

Peter, to be clear, is the convention that OR will simply keep the last two coupler entries is finds (as it does now for all other duplication) or is there some other criteria being used?

Any circumstances where the .wag winds up with no couplers?

Keep in mind I do not use the extra folder in the .wag directory... I've no need whatsoever for MSTS considerations anymore as I'm running a pure OR environment..

[steamer_ctn]

Genma Saotome, on 07 May 2019 - 07:13 AM, said:

to be clear, is the convention that OR will simply keep the last two coupler entries is finds (as it does now for all other duplication)

Yes, that is the outcome aimed for.

Genma Saotome, on 07 May 2019 - 07:13 AM, said:

Any circumstances where the .wag winds up with no couplers?

Not that I am aware of.

Genma Saotome, on 07 May 2019 - 07:13 AM, said:

Keep in mind I do not use the extra folder in the .wag directory... I've no need whatsoever for MSTS considerations anymore as I'm running a pure OR environment..

I am not sure what the significance of this is. Hopefully it should work for all INC files.

[copperpen]

Fine, but there are circumstances where a wag is required NOT to have couplers and the player consist pass over or through the object which is usually an invisowag with a scenic item attached specifically for an activity. MSTS does this very well, why is it not possible for OR to do the same. If it were possible and a bit of sideways thinking out of the box were used, it should be possible to set up fuel and water points for steam trains in the modern era without having to modify a route.

[steamer_ctn]

copperpen, on 08 May 2019 - 03:59 AM, said:

Fine, but there are circumstances where a wag is required NOT to have couplers and the player consist pass over or through the object which is usually an invisowag with a scenic item attached specifically for an activity. MSTS does this very well, why is it not possible for OR to do the same. If it were possible and a bit of sideways thinking out of the box were used, it should be possible to set up fuel and water points for steam trains in the modern era without having to modify a route.

Having no couplers would not guarantee that a train can pass through the object as it is suggested that MSTS does. The wagon (minus couplers) would still occupy some space, and therefore the player consist would still crash into it.

I suspect that what you are seeking is for the Invisowag to present a presence for signalling purposes, but not to occupy a physical space in the Sim. I suspect that it would need to be set up as a special wagon form, and that the coding for this would be more complex then just leaving the couplers off.

[Csantucci]

Open Rails does not react as MSTS does, and will consider fake wags on a path, even if their shape is completely out of it. To perform tricks like the one mentioned by copperpen does not work. A feature should be added in OR to place some objects along the tracks in an activity-dependent way.

[copperpen]

I think the difference between ORTS and MSTS is in collision detection. MSTS uses the bounding box and by setting the BB below rail height it avoids collision with the player or other train passing that spot. ORTS uses the shape size, so I am wondering if it is possible to make an invisowag for activity purposes that sits underground and thus avoids collision detection. Its worth a shot, so that will be my weekend project.

[copperpen]

steamer_ctn, on 08 May 2019 - 09:18 PM, said:

Having no couplers would not guarantee that a train can pass through the object as it is suggested that MSTS does. The wagon (minus couplers) would still occupy some space, and therefore the player consist would still crash into it.

I suspect that what you are seeking is for the Invisowag to present a presence for signalling purposes, but not to occupy a physical space in the Sim. I suspect that it would need to be set up as a special wagon form, and that the coding for this would be more complex then just leaving the couplers off.

The invisowags that I am referring to have zero impact on signalling. They merely have attached a scenic object to be used within the specific activity and not have it as a permanent presence, things like personnel in a yard, or MOW equipment beside the tracks at a certain time on a specific day when the player passes.

[Genma Saotome]

copperpen, on 09 May 2019 - 03:23 AM, said:

I think the difference between ORTS and MSTS is in collision detection. MSTS uses the bounding box and by setting the BB below rail height it avoids collision with the player or other train passing that spot. ORTS uses the shape size, so I am wondering if it is possible to make an invisowag for activity purposes that sits underground and thus avoids collision detection. Its worth a shot, so that will be my weekend project.

It might work but to ensure the trick is not revealed when the train passes over a bridge you'd need to offset the shape (up or down) a considerable distance to make sure it properly deceives.

[darwins]

Quote

The invisowags that I am referring to have zero impact on signalling. They merely have attached a scenic object to be used within the specific activity and not have it as a permanent presence, things like personnel in a yard, or MOW equipment beside the tracks at a certain time on a specific day when the player passes.

In terms of MSTS activities not working in OR, I think we are going to have to accept that some activities will just not work in the same way. There seems to be a lot of effort to make sure that MSTS legacy items (those that had funny tweaks) are functional in OR and I feel that effort could be better put into other things.

In the case of things like tools, headboards, headlamps, tail lamps, loco crew, destination boards and destination blinds I think these could be addressed much better in OR by developing the freight anim concept further.

OR has already advanced significantly over MSTS by allowing multiple freight anims for one eng or wag file. The next step could be finding a way to change those during an activity or timetable. Could we perhaps specify that on arrival at a terminus the destination boards or headcodes change? The way that lights are currently defined might help with this - dependent on if the unit is at the front or rear of a train, in service, not in service, time of day etc. A first step might be to try to apply this to freight anim objects.

https://trello.com/c...d-freight-anims

[copperpen]

Genma Saotome, on 09 May 2019 - 10:36 AM, said:

It might work but to ensure the trick is not revealed when the train passes over a bridge you'd need to offset the shape (up or down) a considerable distance to make sure it properly deceives.

As the main part of the object by definition of its name is invisible, I don't think you would need a major offset.