TS2010 Session making competition - feedback

Now I know why Auran / N3V have been so busy - TS12 has been released.
That's great news too and I'm going to place my order later today for sure.

Hopefully the multiplayer bugs (sync issues, ghost consists, forever locked junctions and most of all the iTrainz server session problems) have been fixed, because I'm really looking forward to hosting some multiplayer sessions again to have some fun with others.

Can you tell us any news on the ruling on the session creation competition entries yet ?
Like in which timeframe we can expect to see the results for example ?

Tata
Mr.Jingles
 
Hi guys,

We'll be looking into this over the next fortnight. Can't wait to see what you've come up with :D

Hope you enjoy TS12!

chris
 
I'd like to thank everyone for their hard work on these sessions - we've got six interesting and fun sessions here.

During our evaluation of these sessions we have encountered several problems, some of which are gameplay breaking. We are going to make our final decision based on the versions on the DLS on Monday May 9th - that gives you 12 days (including two weekends) to address the points raised (and any others you have found):


CN Holly Subdivision Pontiac Yard Ops (<kuid2:32711:100101:2>)

I had some difficulty downloading this session.

Several assets related to "CMTM" by pguy fail to download on a fresh TS2010 SP3 installation. I would suggest adding the specific KUID revision of these assets to the KUID table of the session for TS2010 sessions. (TS12 can cope with downloading this asset set automatically so no workaround should be needed for future versions of Trainz.)

The session requires a driver command not listed in the KUID table (<kuid2:57145:81100:1>). I had to download this manually. This KUID should be added to the KUID table of the session.

The session requires a driver order that is not on the DLS (WaitUntilV2,<kuid2:41009:900005:2>). A copy of this order has been uploaded under a different KUID (Wait Until II,<kuid:32711:100025>) - but apparently, not every reference to it in this session has been changed. I would suggest ensuring that all references to this asset in the session are changed to the new KUID.

The Loco the user is driving does not look good. I suggest searching for an alternative.

The CMTM system offers an increase in prototypical gameplay and also provides a good reference - but has several annoying bugs. Overlaying the main menu with an unmovable window isn't acceptable. It also needs to update on couple/decouple as well as view change.

In this session, the second AI did not drop a train as expected, it ran straight through. I couldn't change to the AI to check what it's orders were.


CN Supplies Drop Off (<kuid2:106007:100015:1>)

One new wagon was downloaded that isn't an update of an existing vehicle.

There is a script error due to a missing or broken drivercharacter. If it is missing, it should be added to the KUID table. If it is broken, it should be swapped for a different one that doesn't generate this error.

The instructions can't be recalled if you close them at the last page. There is a script error if you hit left arrow on first page of instructions. This can be fixed by proper creation of the HTML and usage of the 'Display HTML Pages' and 'Set HTML Pages' rules. Compare with the built-in sessions for examples of how this is done. In particular, the button links should be added from the string table, not hardcoded in the HTML files themselves.

The locomotives the user is allocated look poor, and better looking alternatives should be chosen.
The consist would not move at all in cab mode - this may also be down to the locomotive choice, or other factors may be at work here.


Switching Grogan Loop (<kuid2:32711:100108:1>)

See CN Holly Pontiac Yard Ops for discussion of CMTM. All mentioned issues with this system are also relevant here.


Freight in, Freight out (<kuid2:46012:100035:2>)

This session penalised me repeatedly for speeding when I wasn't. I haven't found out why yet.

I got broken couplers at below the speed listed in the instructions - it lists 7mph, but it's actually set to 7kph - i.e. ~4mph.

The session does not allow switching of viewpoint from one train to another by clicking, nor does it specify a driver for the user loco. This means it's possible (and very easy) to get the view locked on the wrong side of a decouple. This breaks the session when it happens - the user is forced to quit/restart. This restriction should be relaxed or removed - the user should be able to click on the locomotive to return to it. In addition, a drivercharacter should be assigned to the train so that the user can return to the assigned loco easily from the driver list. This will also ensure the camera stays on the controllable side of the train when vehicles are decoupled.


Shift Race (<kuid2:106007:100028:1>)

Good concept "Do as much as you can in the time" - this encourages speed and efficiency without moving away from prototypical behaviour. I initially found it disconcerting that the instructions did not specify where the vehicles had to be left at each specific industry - but later realised it didn't matter, as I'd be delivering so many over the course of the session the challenge would be finding space to pack them in rather than looking for a precise location to spot them.

One new wagon was downloaded that isn't an update of an existing vehicle.

However, I got stuck at the first yard with an AI facing me. No advice was given about keeping specific yard tracks clear, yet I'd managed to put boxcars in his path while sorting my initial train out (as advised I may by the instructions). If AIs require specific tracks in "my" yard left free, I should be told to keep clear of those tracks.

The HTML caused 'Display HTML pages lib' to crash, (the HTML buttons have been hardcoded, rather than entered using the string table as is normal).
The HTML can vanish and not be recallable (likely to be a wrong option set in the 'set html pages' rule).


Run For The Money (<kuid2:299076:1003:2>)

This session has an interesting and fun storyline / scoring system, even if it does wander away from being truly prototypical.

In this session I got accused of derailing when I hadn't. It is likely that an AI somewhere did derail - I didn't get to see what had happened though as I got booted out of the session before I found it. I would suggest having a look at the AI orders to see if there is anything that may cause a derailment.
 
Hi guys,

Thanks for the excellent work on these sessions so far! I'd like to stress that we'll be undertaking the final review on our morning of Monday, May 9th. Please ensure that you allow for the time zone differences and time for the DLS upload process.

If in doubt, make sure that you have uploaded everything to the DLS on the Saturday.

cheers,

chris
 
Freight in, Freight out (<kuid2:46012:100035:2>)

This session penalised me repeatedly for speeding when I wasn't. I haven't found out why yet.

I got broken couplers at below the speed listed in the instructions - it lists 7mph, but it's actually set to 7kph - i.e. ~4mph.

The session does not allow switching of viewpoint from one train to another by clicking, nor does it specify a driver for the user loco. This means it's possible (and very easy) to get the view locked on the wrong side of a decouple. This breaks the session when it happens - the user is forced to quit/restart. This restriction should be relaxed or removed - the user should be able to click on the locomotive to return to it. In addition, a drivercharacter should be assigned to the train so that the user can return to the assigned loco easily from the driver list. This will also ensure the camera stays on the controllable side of the train when vehicles are decoupled.

I will try to reproduce the speeding and coupler breakage errors, but had no such issues during my testing.

About the missing driver character for the player - I didn't account in the possibility a player might get adventurous to wander off his train and uncouple the consist with the camera at the wrong end, so I'll be trying to loosen that up a bit if possible.
My thought to restrict it like this was to make sure the player cannot leave his train and sticks to it throughout the session and can only use this single locomotive. (Admittedly I only tested it with the camera sticking to the players locomotive throughout the session)

I believe I can look into it over the weekend and will post an update here when a new version is on its way to the DLS.

Thanks for the thorough testing so far. :)

Tata
Mr.Jingles
 
CN Holly Subdivision Pontiac Yard Ops (<kuid2:32711:100101:2>)

I had some difficulty downloading this session.

Several assets related to "CMTM" by pguy fail to download on a fresh TS2010 SP3 installation. I would suggest adding the specific KUID revision of these assets to the KUID table of the session for TS2010 sessions. (TS12 can cope with downloading this asset set automatically so no workaround should be needed for future versions of Trainz.)

The session requires a driver command not listed in the KUID table (<kuid2:57145:81100:1>). I had to download this manually. This KUID should be added to the KUID table of the session.


The session requires a driver order that is not on the DLS (WaitUntilV2,<kuid2:41009:900005:2>). A copy of this order has been uploaded under a different KUID (Wait Until II,<kuid:32711:100025>) - but apparently, not every reference to it in this session has been changed. I would suggest ensuring that all references to this asset in the session are changed to the new KUID.

These things I can fix. No problem.

The Loco the user is driving does not look good. I suggest searching for an alternative.

What constitutes a "good looking" locomotive? I figured being prototypical was enough to satisfy the most avid railroad fan. Your suggestions are welcome.

The CMTM system offers an increase in prototypical gameplay and also provides a good reference - but has several annoying bugs. Overlaying the main menu with an unmovable window isn't acceptable. It also needs to update on couple/decouple as well as view change.

If you had read page 2 of the Drivers Instructions, you would know that the window is gone with a simple press of the ESC key. It will reappear when you click on a different traincar. Thus, the main menu is one keystroke away. Is this not acceptable?

As far as updating on couple/decouple, I'll give it a try, but I am not an experienced programmer and am not sure how to go about making that happen.

In this session, the second AI did not drop a train as expected, it ran straight through. I couldn't change to the AI to check what it's orders were.

Yeah, isn't that frustrating. AI can be so unpredictable at times. I have run this session mutliple times and sometimes it runs fine. Other times AI doesn't seem to know which way is up. I see this on quite a few routes, I just figured it was the nature of AI.

Your advise please.

David
 
Last edited:
What constitutes a "good looking" locomotive? I figured being prototypical was enough to satisfy the most avid railroad fan.

This list isn't a list of requirements - you don't have to tick all of the boxes. But the more you tick, the better it will rate.

  • Correctly rotating wheels
  • Reasonable (not too high, not too low) polygon count
  • Modern materials (e.g. including specular and/or bump mapping)
  • Respectable looking texture (avoiding jagged edges, blocky text, badly represented logos and block colours with no weathering)
  • Prototypical for the area/company being represented
The CN RS3 and S2 don't hit the top four options. If you want to stick with CN, there is at least one CN diesel in the content set that does hit the top four points.

You may also wish to check the rolling stock you are using for rotating wheels.

If you had read page 2 of the Drivers Instructions, you would know that the window is gone with a simple press of the ESC key.
I did spot that. However, this doesn't allow me to move or resize the list.

It will reappear when you click on a different traincar. Thus, the main menu is one keystroke away. Is this not acceptable?
If that session had been developed internally, QA would not let it be released with that window position.

As far as updating on couple/decouple, I'll give it a try, but I am not an experienced programmer and am not sure how to go about making that happen.
It may also not be something you can fix - it may be an issue with the CMTM code that has to be fixed by CMTM's developer.

Yeah, isn't that frustrating. AI can be so unpredictable at times. I have run this session mutliple times and sometimes it runs fine. Other times AI doesn't seem to know which way is up. I see this on quite a few routes, I just figured it was the nature of AI.
There are things that can be done to smooth out the AI.

Use 'via' waypoint trackmarks when telling it to drive long distance. This offers two benefits - one, it slows down the rate the AI scans the track ahead, so it doesn't make it's decisions too early. Two, it forces it to take the route you want (via each waypoint).

Also consider your choice of 'navigate to/via' and 'drive to/via' orders carefully. 'navigate' does more thinking, and will deviate more from the optimal path to try and route around vehicles. This is vital for moving about in yards, but can sometimes be annoying on the mainline, where the trains move about, and often aren't where they were when the route was calculated. it will queue up behind traffic rather than trying to work it's way around it.

If you're having problems with the AI at junctions (it's getting stuck and/or going the wrong way) you may find that pre-setting a junction lever or two will help it out. It may not be the most obvious lever that needs to be set - watch the AI as it approaches the "problem" junction, and find the first lever that it doesn't attempt to switch that is pointing in the wrong direction. Once you find the junction it's getting wrong, try adding a rule to the session to change this junction to the opposite direction (don't lock it though, just set it the other way!). You may need to do this at specific times, or when specific things happen, rather than just "at the beginning of the session".

Another thing to bear in mind when working with the AI in a session like these - the typical player doesn't go roaming off around the map. So the AI traffic need only be "stage managed" in the area the player actually is - it doesn't have to traverse the entire map to get there.
 
I will try to reproduce the speeding and coupler breakage errors, but had no such issues during my testing.

The vehicle physics rule in your session is set to 7kph, but the HTML says 7mph. If you really meant 7mph (seems likely) you'd need to put in either 11kph or 12kph in the rule.

About the missing driver character for the player - I didn't account in the possibility a player might get adventurous to wander off his train and uncouple the consist with the camera at the wrong end, so I'll be trying to loosen that up a bit if possible.
It's fairly common for users to want to check the positioning of individual vehicles when making dropoffs - in the real world, this is often done by a second crew member communicating with the driver. ISTR this behaviour caught Auran's developers out back in 2002 or so when making the scenarios for UTC as well :)

Thanks for the thorough testing so far. :)
No problem. I wish I had more time to dedicate to playing all these sessions than I do. There's just not enough hours in the day...
 
This list isn't a list of requirements - you don't have to tick all of the boxes. But the more you tick, the better it will rate.
  • Correctly rotating wheels
  • Reasonable (not too high, not too low) polygon count
  • Modern materials (e.g. including specular and/or bump mapping)
  • Respectable looking texture (avoiding jagged edges, blocky text, badly represented logos and block colours with no weathering)
  • Prototypical for the area/company being represented
The CN RS3 and S2 don't hit the top four options. If you want to stick with CN, there is at least one CN diesel in the content set that does hit the top four points.

You may also wish to check the rolling stock you are using for rotating wheels.

OK, now you are expecting way to much. First, I had no idea you publish built-in content without rotating wheels. Guess I have never looked that close. I have no idea how to determine polygon count and I have no idea what you mean by " Modern materials (e.g. including specular and/or bump mapping)". I thought this was a session contest made with built-in assets. If there were certain assets that you felt didn't measure up to your internal standards, you should have spelled that out from the get go.


I did spot that. However, this doesn't allow me to move or resize the list.

If that session had been developed internally, QA would not let it be released with that window position.

It may also not be something you can fix - it may be an issue with the CMTM code that has to be fixed by CMTM's developer.

I just checked with the CMTM developer - that would be me - and as I said, I am not an experienced programmer - just a Trainzer who likes to model prototype operations. I have no idea how to make the window resizable or how to make it movable. You are welcome to make the changes you are recommending. Hitting the esc key seems to work for all the CMTM users. The window only needs to be open when you need to refer to the information.

There are things that can be done to smooth out the AI.

Use 'via' waypoint trackmarks when telling it to drive long distance. This offers two benefits - one, it slows down the rate the AI scans the track ahead, so it doesn't make it's decisions too early. Two, it forces it to take the route you want (via each waypoint).

Also consider your choice of 'navigate to/via' and 'drive to/via' orders carefully. 'navigate' does more thinking, and will deviate more from the optimal path to try and route around vehicles. This is vital for moving about in yards, but can sometimes be annoying on the mainline, where the trains move about, and often aren't where they were when the route was calculated. it will queue up behind traffic rather than trying to work it's way around it.

If you're having problems with the AI at junctions (it's getting stuck and/or going the wrong way) you may find that pre-setting a junction lever or two will help it out. It may not be the most obvious lever that needs to be set - watch the AI as it approaches the "problem" junction, and find the first lever that it doesn't attempt to switch that is pointing in the wrong direction. Once you find the junction it's getting wrong, try adding a rule to the session to change this junction to the opposite direction (don't lock it though, just set it the other way!). You may need to do this at specific times, or when specific things happen, rather than just "at the beginning of the session".

Another thing to bear in mind when working with the AI in a session like these - the typical player doesn't go roaming off around the map. So the AI traffic need only be "stage managed" in the area the player actually is - it doesn't have to traverse the entire map to get there.

Ahh, all the things that were left out of the users manual. I may have some time to take a look at this, but I can make no promises. I have a full time job and have a project that is requiring lots of overtime.
 
Run For The Money (<kuid2:299076:1003:2>)

This session has an interesting and fun storyline / scoring system, even if it does wander away from being truly prototypical.

In this session I got accused of derailing when I hadn't. It is likely that an AI somewhere did derail - I didn't get to see what had happened though as I got booted out of the session before I found it. I would suggest having a look at the AI orders to see if there is anything that may cause a derailment.

On the subject of derailing, the AI trains have pretty simple orders. They just drive from one trackmark to another, with none of them going near the end of a track or anything that could cause a derail.

I drove the session numerous times while developing it. The only time I had a derailing problem is if I was trying to save time (& get a bigger bonus) by kicking cars. Several times I kicked the cars down the track at the first industry (Romulus Engine). They looked like they were stopped, but in fact they were rolling at about 1/10th of a mile per hour. Thirty minutes or so later, they'd reach the end of the track and derail - ending the session with me baffled as to what had happened.

That's the only thing that I think could have happened. If a car was decoupled before the loco came to a complete stop, the car could roll very slowly down the track and not derail for quite a while.

I'll play it some more and see if I can identify a specific problem.

As for the storyline/scoring system. I was going for something different. I figured the obvious scoring concepts would be things like awarding points for cars delivered, trying to complete as many setouts/deliveries as possible in a set time, etc. I wanted to do something not seen before in Trainz.

Also, I figured that many of the players that prefer to just drive aren't super-hardcore railfans that demand only strictly prototypical sessions. They're likely to be gamers that like trains and are looking for fun more than realism.

Not that my session is just arcade-style fluff. It can be challenging to more experienced drivers. The session rewards engineers that are masters at controlling their engine. Some of the advanced techniques I use include kicking cars and a double Dutch-drop at Romulus (kick the brown boxcars down the siding, run around them at full speed then catch them on the nose of the loco).

Todd
 
OK, now you are expecting way to much.

No, we're really not. You're being judged on the overall quality of your product, not on a single metric such as "prototypical behaviour." You don't have to dot every 'i' and cross every 't', but the overall quality of the content that you use will reflect on the judgement of your session.


I just checked with the CMTM developer - that would be me - and as I said, I am not an experienced programmer - just a Trainzer who likes to model prototype operations. I have no idea how to make the window resizable or how to make it movable.

We're rating this as an overall experience. How experienced you are as a programmer has nothing to do with this, and your competition is in a similar boat.

To illustrate the point that we're making here, and not intended as a criticism of your work: Olympic gymnasts who over-reach and fall on their face get marked down. You are welcome to reach as far as you want in this competition, but if you fall on your face and others don't, you're going to be marked down. That doesn't mean that your work is not good, it just means that you didn't win on the day.

Regarding your specific questions, you'll want to look at the Browser.SetWindowStyle() function, and possibly also Browser.SetWindowGrow().


You are welcome to make the changes you are recommending.

We may help out after the competition is over, however beyond answering specific questions we will not be involved in working on sessions which are to be entered in the competition. That would be clearly unfair to everybody else.


I may have some time to take a look at this, but I can make no promises. I have a full time job and have a project that is requiring lots of overtime.

Sounds familiar. Do your best, that's all anyone can ask for. :)

chris
 
OK, now you are expecting way to much. First, I had no idea you publish built-in content without rotating wheels. Guess I have never looked that close. I have no idea how to determine polygon count and I have no idea what you mean by " Modern materials (e.g. including specular and/or bump mapping)". I thought this was a session contest made with built-in assets. If there were certain assets that you felt didn't measure up to your internal standards, you should have spelled that out from the get go.

TS2010 has a long history of content included in it - some dating back to Trainz v1.0. Because of this, we stated:

Use of graphically detailed locomotives and stock is highly recommended. We want the sessions to look graphically impressive.

The intent is to show off the better content we have, rather than focus on the older / out of date content. We want to see "graphically detailed" and "graphically impressive" content, particularly for the closest content to the user.

I just checked with the CMTM developer - that would be me
Ah, didn't realise that - saw lots of library assets by pguy being downloaded and assumed it may well be by him. Sorry, my bad.

and as I said, I am not an experienced programmer - just a Trainzer who likes to model prototype operations. I have no idea how to make the window resizable or how to make it movable.
Take a peek in the Browser class. There are comments next to each function definition which tell you how to use it. You'll find SetWindowRect() very helpful - this will allow you to specify the position of the left edge, top edge, right edge and bottom edge. SetWindowGrow() controls how much the window can be resized by the user. If you want to slim down the large default window border investigate SetWindowStyle() - you might choose the HUD style for a very minimal frame, for example. Calling SetRememberPosition() will make this window remember it's position in the display so that a user who moves the window about will have it appear where it was last put.
 
On the subject of derailing, the AI trains have pretty simple orders. They just drive from one trackmark to another, with none of them going near the end of a track or anything that could cause a derail.

I drove the session numerous times while developing it. The only time I had a derailing problem is if I was trying to save time (& get a bigger bonus) by kicking cars. Several times I kicked the cars down the track at the first industry (Romulus Engine). They looked like they were stopped, but in fact they were rolling at about 1/10th of a mile per hour. Thirty minutes or so later, they'd reach the end of the track and derail - ending the session with me baffled as to what had happened.

I wasn't that far into the session. I'd been told to slow down for the first industry (damn, I was just getting to a rise in speed limit, too...) but I hadn't actually got there yet.

That's the only thing that I think could have happened. If a car was decoupled before the loco came to a complete stop, the car could roll very slowly down the track and not derail for quite a while.
If this is a problem, adding a functional bumper to the end of track in the session layer would stop slow moving cars. On the other hand, you could consider it a part of the difficulty of the session, making sure each vehicle is securely stopped :)

As for the storyline/scoring system. I was going for something different. I figured the obvious scoring concepts would be things like awarding points for cars delivered, trying to complete as many setouts/deliveries as possible in a set time, etc. I wanted to do something not seen before in Trainz.
... and you've certainly achieved something different. It's a novel idea, which was what this competition was intended to highlight. It's also not that far removed from prototype too :)
 
The vehicle physics rule in your session is set to 7kph, but the HTML says 7mph. If you really meant 7mph (seems likely) you'd need to put in either 11kph or 12kph in the rule.

Fixed that. I must have overlooked that it was in metric units and not imperial units.
I changed the coupler breakage to 5 mph (8 kph) now because I still want it to be somewhat of a challenge and setting it to 11 kph would be no challenge in my opinion.
I also updated the HTML file to reflect that 5 mph coupling speed limit change in the help text.

It's fairly common for users to want to check the positioning of individual vehicles when making dropoffs - in the real world, this is often done by a second crew member communicating with the driver. ISTR this behaviour caught Auran's developers out back in 2002 or so when making the scenarios for UTC as well :)

I see. The free roam camera view wasn't enough then. :)
Anyways, I added a player character to the train now as requested, but that broke the camera script, so now the camera starts off in external view (even though I tried for quite a while to get it to fade in in internal view like it did before, without success now), but that's no show stopper in any case as the player can adjust the camera view to his liking as he sees fit.

I also re-enabled the player to be able to switch his view to other consists, so the problem that he gets "lost" on the wrong end of a decouple no longer exists.

No problem. I wish I had more time to dedicate to playing all these sessions than I do. There's just not enough hours in the day...

I guess you're glad though that it's just these few sessions you need to test instead of a few hundreds. (from a testing and time management point of view)
But from another point of view, hopefully the next competition raises more interest in the community to participate than just us 4 entrants.

Just as a small idea, perhaps more frequent session creation competitions can be run in small scale like quarterly or half-yearly with more "casual" prizes like 3 to 1 month FCT access giveaways.
I think FCT giveaways for session creation competitions would be a nice incentive for the community to participate and we would see a rise of quality tested sessions, but that's just an idea.

My upload is currently being processed, so by monday you should be able to test them (kuid2:46012:100035:3 is the session and kuid2:46012:100044:1 is the HTML file) again for any remaining problems.
Let me know if there's anything else that needs changing and I'll see what I can do.

EDIT: Forgot to mention - I tested the session for speeding issues again, but still am not able to reproduce why you get penalized for that.
As far as I can tell the speeding rule and speed limits are working as they should be and keeping to the announced track speed limits does not cause penalties for me. (at the 25 mph tracks for example I can run along at 29 mph without issues and get penalized at 30 mph and above, as I want it to be)
What I could think of is that maybe when you switch the external camera to one of the attached rolling stock, then decouple and return the camera to the loco, the consist will face the wrong direction, therefore also checking speed limits down the wrong way of the track (if that explanation makes sense), but there's nothing I can do about that except maybe plastering the entire map and each siding with correct speed limits, but I see this more as a bug then and not something for me to fix.

Tata
Mr.Jingles
 
Last edited:
But from another point of view, hopefully the next competition raises more interest in the community to participate than just us 4 entrants.

Just as a small idea, perhaps more frequent session creation competitions can be run in small scale like quarterly or half-yearly with more "casual" prizes like 3 to 1 month FCT access giveaways.

We would like to undertake regular content creation competitions- possibly changing the goals slightly each time so that it doesn't end up with just one or two people who really "get" a particular area of the game being the winners. One thing that this first competition has taught us is that it takes a lot of time on everybody's part (both you guys and the team here) to make this competition happen.

For such a complex subject, we don't want to simply have a single submission date and then say "sorry, none of them were good enough." I think the multiple-submission with feedback is definitely the way to go, but it does take more time. Perhaps a twice-yearly even might work.

cheers,

chris
 
I wasn't that far into the session. I'd been told to slow down for the first industry (damn, I was just getting to a rise in speed limit, too...) but I hadn't actually got there yet.

If this is a problem, adding a functional bumper to the end of track in the session layer would stop slow moving cars. On the other hand, you could consider it a part of the difficulty of the session, making sure each vehicle is securely stopped :)

A derail at that point in the session makes no sense. You hadn't thrown any switches that could cause a derail, one of the AI trains that was active at the start of the session is parked at a trackmark and the other is coupled to some cars waiting for you to return at the end of the session. All the other AI trains are parked waiting to be set in motion.

And, in looking closely, I notice that all of the track ends have bumpers. I tossed cars at them and the bumpers stopped the cars. So the derail issue I had while testing doesn't make sense, either!

I think one of your programmers snuck in a "Cause Random Problem Just To Frustrate Session Creators" subroutine into the Trainz code somewhere.:hehe:

I don't want to remove the derail error checking, as properly securing cars you are setting out is part of good train handling. I did alter how the session handles a derail. Instead of ending the session right away, you now get 1 minute before the session ends to give you some time to analyze why the derail happened. The Pause key does work during the 1 minute wait so you can effectively get as much time as you want. That way a player won't be frustrated that a derail happened and they don't know why.

The updated files are on the DLS: kuid2:299076:1003:3 and the HTML asset kuid2:299076:1006:2.

I'm going to stand on this version of my session.

Todd
 
Back
Top