Objects in an animated container disappear in Routeviewer and OpenBVE after the insertion point of the .animated file

This bug is easier to explain in video, so I made a video of it:

https://www.youtube.com/watch?v=z4VvYvYOQIA

I would assume this is actually a bug. The route package can be found here for testing:

https://drive.google.com/file/d/1CXxqn1A6afnhnRyWyzBmGdePE9zJ-Izz/view?usp=sharing

As I said it in the video, the mentioned .animated object is placed at 6950 metres, it is Freeobj number 3221. It is in an If() structure (that's why it's present twice in the route. The If() serves the purpose of being able to arrive at different platforms of the station). I don't think that the If() matters, but I thought I'd mention it.

Here's the animated object itself, linked from Pastebin. I used the Position option to place certain parts of it.

https://pastebin.com/tQDxkNPB

To complicate things a bit more, the With Track section is separated into 4 include files (because this way it's easier to get to all those If() commands). The part where this problem is present can be found in Railway/Object/Solyomvar/OpenBVE/Solyomvar_Track_Szakasz-2.include.

Options.ObjectVisibility is set to 1.

Haven't dug to your files deep yet, but I suspect such a problem is often caused by Options.ObjectVisibility.
Have you tried setting this?

Code:

Options.ObjectVisibility 1

If not so, openBVE will deliberately hide project once their "insertion point" is passed, as this was what BVE4 did, and some developers of BVE4 used this skill to make simple animation before the introduction of .animated by openBVE.

Thank you. Yes, of course, Options.ObjectVisibility is set to 1. No other objects disappear at block borders, only this one and only in the latest four OpenBVE versions (1.7.0.0 through 1.7.1.3).

The object is displayed correctly in earlier versions of the game.

Down into the rabbit hole

I think the current build now has this right in all cases, but my head is spinning......

Related, I've found with some large object files (such as large buildings) that they can disappear like a witch's cat before I wanted them to. I've sort of fixed that by inserting a blank texture and/or face at a position well in advance or well further from the main items within the object file.
 This "may" prevent premature disappearance.  It's worked for me on the occasional tower block or big factory.

Yes, it fixes the problem Chris, thank you. However, I found problems with TFOXML in this build (OpenBVE daily 2020-04-14) and I made a video of that too:

https://www.youtube.com/watch?v=KscjHEDGr4Q

The route is available here: https://bve.hu/kiralyliget

I wonder if I should start a new thread with this, but if it's a quick fix I might not.

Thanks, I've asked S520 to take a look at what's happening.

I apologize for any inconvenience.

I've tried to fix issues with changing speed and rail index while driving at TFO in the pull request below.
https://github.com/leezer3/OpenBVE/pull/449

I think the problem you found is due to this pull request.

To investigate this issue, please tell me the filename of the TFO xml where the issue occurs.

Thanks for your kind help. I'll start up my desktop and come back to you in 5-10 minutes.

OK, here I am. So the route is Királyliget, available from https://bve.hu/kiralyliget

The two TFOXML files in the video are these:

Railway/Object/Kiralyliget/AI-Trains/MagyarszentpeterSzemelyvonatErkezik.xml
Railway/Object/Kiralyliget/AI-Trains/MagyarszentpeterMozdonyACsonkarolVonatraJar.xml

Thank you for your cooperation.

First, let's discuss the problem that trains arriving at the platform on the left do not leave.
The TFO specifications I considered do not assume acceleration from the end point.
But until now, bugs have made it possible.

Another issue is under investigation.

Thank you for your cooperation.


First, let's discuss the problem that trains arriving at the platform on the left do not leave.
The TFO specifications I considered do not assume acceleration from the end point.
But until now, bugs have made it possible.


Another issue is under investigation.

I'm sorry to have posted it twice.

The second issue is due to typos.

"ArrivalTime" in the line below is a mistake of "DepartureTime".
https://github.com/leezer3/OpenBVE/blob/master/source/OpenBVE/Game/AI/AI.TrackFollowingObject.cs#L448

S520 wrote:First, let's discuss the problem that trains arriving at the platform on the left do not leave.
The TFO specifications I considered do not assume acceleration from the end point.
But until now, bugs have made it possible.

I see. That was I think my very first TFOXML file, I probably missed that, and as I saw that it departs after closing doors, I didn't bother. I'll update the route file.

For the second problem, please download the fixed version from the link below and give it a try.
https://drive.google.com/open?id=1gK72IVSnWH1Nmt7a8V28myZNpTBBsY1U

If there is no problem I will create a pull request.

In addition, I would like to document the specification that caused the first issue.

Testing as we speak...

In this version the Siemens Taurus doesn't jump, so that is good and fixed.

On the other hand, I don't fully understand why the train on the left should not depart after closing doors. Here's my Stops section:

Code:

   <Stops>
      <!--Start-->
      <Stop>
        <!--Deceleration[km/h/s]-->
        <Decelerate>0</Decelerate>
        <!--In-game distance of stop position[m]-->
        <StopPosition>20725</StopPosition>
        <!--Door that open at this point-->
        <Doors>0</Doors>
        <!--Time to keep stopping[hh.mmss]-->
        <StopTime>00.0000</StopTime>
        <!--Acceleration[km/h/s]-->
        <Accelerate>1.71</Accelerate>
        <!--Speed after acceleration[km/h]-->
        <TargetSpeed>40</TargetSpeed>
        <!--Progress direction [1: forward, -1: backward]-->
        <Direction>-1</Direction>
        <!--Traveling track-->
        <Rail>1</Rail>
      </Stop>
      <Stop>
        <!--Deceleration[km/h/s]-->
        <Decelerate>1.65</Decelerate>
        <!--In-game distance of stop position[m]-->
        <StopPosition>20175</StopPosition>
        <!--Door that open at this point-->
        <Doors>R</Doors>
        <!--Time to keep stopping[hh.mmss]-->
        <StopTime>00.0010</StopTime>
        <!--Acceleration[km/h/s]-->
        <Accelerate>1.71</Accelerate>
        <!--Speed after acceleration[km/h]-->
        <TargetSpeed>60</TargetSpeed>
        <!--Progress direction [1: forward, -1: backward]-->
        <Direction>-1</Direction>
        <!--Traveling track-->
        <Rail>1</Rail>
      </Stop>

To me the second Stop section says that the train decelerates at 1.65 km/h/s and stops at track position 20175. Then it opens the doors for ten seconds. After that it accelerates to 60 kph and goes on in -1 direction, that is backwards on Rail 1. Isn't this correct? At what point is my understanding wrong?

TFO does not accelerate at the end point because "TargetSpeed" and "Accelerate" related to the acceleration of the last Stop are ignored.

I see. I guess I should add a third Stop section then? What should I put in it?

Maybe this is the correct implementation, however I tend to feel that a logical reading of the code in my second Stop section would mean it departs after closing doors because of the acceleration and target speed values. And if I don't want it to depart, I would have to put 0 as an acceleration value and 0 as a targetspeed as well. So the behaviour up to OpenBVE 1.7.1.3 seems to be the logical way of it to me.

I mean I find it a bit strange that after setting an acceleration value and setting the target speed I have to add another Stop section.

Am I wrong here?

Or do I have to think like this:

• 1st Stop section: appearance of TFO train
  
• after that there is one stop section for every movement
  

For example in the case of the train on the left:

• first Stop section is just there to put the TFO train into the route and accelerate it (therefore Decelerate value is ignored?)
  
• second Stop section is to decelarate it, stop it and make it open the doors (therefore Accelerate and TargetSpeed are ignored? Is Direction also ignored here?)
  
• third Stop section would be to accelerate the train again (so StopPosition, Doors, StopTime values would refer to a further, in this case non-existing stop point down the line?)
  

Can you explain this a little bit so that I fully understand the correct implementation? Thank you!
Also, can I leave out lines/values that would be ignored or unnecessary, or do I have to put all lines/values into the file?
Sorry to have so many questions here.

I decided to add a third Stop section to two of my AI trains so that they travel further on after stopping. These are:

- Railway/Object/Kiralyliget/AI-Trains/001_MagyarszentpeterSzemelyvonatErkezik.xml
(This is the train on the left that we were talking about, I just changed the file name a little bit.)

- Railway/Object/Kiralyliget/AI-Trains/003_MagyarszentpeterAlsoSzemelyvonatErkezik.xml
(This is an AI train which arrives at the second station when our train arrives. It is supposed to go on after stopping and opening/closing doors.)

Quite interestingly, they do not travel on after closing doors in OpenBVE 2020-04-14 and the test version you sent me. However, they do travel on in OpenBVE 1.7.1.3.

The updated route is here now:
https://drive.google.com/file/d/1i9EhlFTrKkhtjhF5djrxBPIjcLzVuy4Y/view?usp=sharing

The two TFOXML files are here to make things quicker:
- 001_MagyarszentpeterSzemelyvonatErkezik.xml: https://pastebin.com/FY1FN8Sa
- 003_MagyarszentpeterAlsoSzemelyvonatErkezik.xml: https://pastebin.com/VyCyE5D1

Take a look at the "Stops" section below.

Code:

   <Stops>
      <!--Start-->
      <Stop>
        <!--This element is included in the first Stop section, so it is ignored.-->
        <Decelerate>0.0</Decelerate>
        <StopPosition>1800</StopPosition>
        <Doors>1</Doors>
        <StopTime>00.0020</StopTime>
        <Accelerate>1.71</Accelerate>
        <TargetSpeed>60</TargetSpeed>
        <Direction>-1</Direction>
        <Rail>1</Rail>
      </Stop>
      <Stop>
        <Decelerate>1.71</Decelerate>
        <StopPosition>1000</StopPosition>
        <Doors>B</Doors>
        <StopTime>00.0010</StopTime>
        <Accelerate>1.71</Accelerate>
        <TargetSpeed>60</TargetSpeed>
        <Direction>-1</Direction>
        <Rail>1</Rail>
      </Stop>
      <!--Goal-->
      <Stop>
        <Decelerate>1.71</Decelerate>
        <StopPosition>200</StopPosition>
        <Doors>0</Doors>
        <StopTime>00.0030</StopTime>
        <!--This element is included in the last Stop section, so it is ignored.-->
        <Accelerate>0</Accelerate>
        <!--This element is included in the last Stop section, so it is ignored.-->
        <TargetSpeed>0</TargetSpeed>
        <!--This element is included in the last Stop section, so it is ignored.-->
        <Direction>-1</Direction>
        <!--This element is included in the last Stop section, so it is ignored.-->
        <Rail>1</Rail>
      </Stop>
    </Stops>


This sample leaves the first station, stops at the second station, starts backwards, and stops at the last "Stop".
Accelerate after stopping at the second "Stop", so I guess this is what you wanted to do.

Also, "Accelerate", "TargetSpeed", "Direction" and "Rail" are used if the train has passed the "Stop" that contains it.
Those included in the last "Stop" will be ignored because the train will not cross it.

And, you can then omit it if you want to use the same default value for each item.

Also, I checked the routes you updated with my test version and v1.7.1.3 and couldn't see the difference.

Thank you for taking the time to write that explanation. It makes things clear.

So in the first Stop section only Decelerate is ignored, after that basically there is a "linear reading" of what's happening and in the last Stop section Accelerate, TargetSpeed, Direction and Rail are ignored.

I wrote a Hungarian language tutorial on TFO trains, I'll update that with this information.

You're welcome.

The problem seems to be solved, so I created a pull request.
https://github.com/leezer3/OpenBVE/pull/461

It should work fine in nightly builds after it is accepted.

The fix has been accepted.
It is applied from the nightly build below.
https://vps.bvecornwall.co.uk/OpenBVE/Builds/OpenBVE-2020-04-19.zip