PDA

View Full Version : Major Bug in MSTS Bin 1.6.10 or Higher?



Swissie
02-03-2007, 03:53 PM
Dear collegues,

me and my betatesters have run into an ugly situation. We've got an engine that works perfectly and as designed under MSTS 1.4. (i.e. non bin), but its - fully default compatible - light settings do crash the sim immediately when the lights are turned on under MSTS bin 1.6.10 or higher.

Here's the narrative: I've been working on a Milwaukee project over the last half year or so, and therefore remained with the MSTS Bin version which was current when I started the project, which was MSTS bin 1.6.092213. The project involves some EF-1 boxcab motors, and the frame-work of the project is to keep all the files compatible with MSTS 1.4., but of course to also offering bin users the benefits of non-conflicting additional features such as bi-directional cabs etc.

Keeping the .eng and .wag files compatible with MSTS 1.4. means using only the default conditions in the lights section.

All works fine under MSTS 1.4. and under MSTS bin 1.6.09. But now beta-testers using later bin versions report that the lights - all set up to work under non-bin conditions, and they do so - do crash the sim under bin 1.6.10 or higher. I also updated from 1.6.09 to 1.7.02 first and the sim promptly crashed. Same with 1.6.10. which according to George is the latest, stable release. I am aware that headlights have repeatedly been an issue in this bin forum, and I hope I haven't missed a post similar to my problem.

The pecularity is as follows:

The EF-Freight motors by Tim W. Muir are set up as two shape files.
1) Frontmost is a shape file of the pilot truck and first driver wheels. This must be defined as a .wag file because due to its shortness it runs far too jerkyly in the sim to contain the .cvf. In as far as the lights are concerned, this .wag file which by default always is the first unit in a consist (Unit (2)) must contain the settings for the cone of light: The cone of light cannot be included in another file, such as the following .eng file which comes second in the consist (Unit (0)), as this would lead to problems with the light cone when double-heading a train, or using mid-train helpers. As the cones of light were Unit (0) as well, the light cone would always come on with the rearmost of the helpers instead of at the point of the consist. This of course due to the fact that when loading a consist, MSTS places the rearmost car onto the starting point of the path, and then adds the rest of the consist from rear to front, using the only available light cone with the first unit fulfilling the conditions set-out for it.
2) All the remaining lights are defined within the .eng file of the main body of the locomotive, to avoid the light

effects of the headlight moving relative to the carbody when going through curves.

The result is the following light arrangement:

First in a consist is pilot truck Milw_EF-1_ExxA-a.wag:
Contains two light entries for the cone of light:
Type ( 1 )
Conditions (
Headlight ( 2 )
Unit ( 2 )
)
for dim, and
Type ( 1 )
Conditions (
Headlight ( 3 )
Unit ( 2 )
)
for bright.

Second in the consist is the main body of the engine Milw_EF-1_ExxA.eng:
Contains all the remaining light entries for the "bulbs":
Type ( 0 )
Conditions (
Headlight ( 2 )
Unit ( 0 )
)
for dim, and
Type ( 0 )
Conditions (
Headlight ( 3 )
Unit ( 0 )
)
for bright.

This light arrangement, I repeat, works neatly and error-free in MSTS 1.4. and MSTS bin 1.6.09. As soon as I upgrade to a newer bin version, the sim immediately crashes when I press the 'H' key to turn on the lights. If I comment out the light section of the pilot truck's .wag file, the lights can be touched, and the sim works without crashes, but of course with me driving in total darkness.

Sorry for putting it this way, but I am under the impression that this constitutes a major bug in MSTS bin that absolutely needs correction. After all those light settings are compatible with the original MSTS 1.4. and in line with the instructions of the MSTS TechDocs.

Of course it is legitimate to introduce new features with MSTS bin that are not backwards compatible on non-bin installations. But I expect MSTS bin to work with any file designed and proven to work under MSTS default, if not better then at least as reliably as in MSTS default; or in other words I expect that MSTS bin is 100% forwards compatible (does this term exist?) rather than crashing the sim when a file designed for MSTS default is loaded under bin. I would find it hard both from a user's and an author's point of view if any one of us had to painstakingly identify, delete or modify all the files in a MSTS installation that used to run fine in default mode or under the last MSTS bin, but now suddenly crash the sim in a newer version of MSTS bin because some existing, stable program parameters were altered or accidentally corrupted.

Therefore I hope my reporting of the case is worthy of investigation, and I do sincerely hope that George could find a cure to this unexpected but desastrous bug. Especially as the same constellation would probably also create problems for any other consists where a .wag file with lights / light cones preceeds the player .eng, such as a snow plow .wag that has to be pushed by the player engine.

Please excuse my ranting, I got quite a bit frustrated when this unexpected issue raised its ugly head. If access to the beta file of the engine in question was needed on behalf of George or anyone assisting him in further developing MSTS (and generally improving the sim), then please drop me a PM and I'll gladly provide the link (Note: link will expire Feb 6).

Lukas a.k.a Swissie

drjoe
02-03-2007, 05:32 PM
Lukas,

I know that there are problems with the "Unit ( )" parameter in Bin. Some of the lighting on Locos does not work the same in Bin as in 1.4 MSTS. Two extra numbers were added to the parameter to allow for reversing. I suspect that cone of lights are what have this problem. As you may know, there is a problem ( supposedly being fixed ) with the penalty cone of light in Marc Nelson's F units. I am wondering whether the new code does not "allow" a cone of light to be added to a .wag file rather than an .eng file. I suspect that there may be a similar problem with some steamers I use that have a "rear" cone of light in their tenders for use when backing up. I will do some testing and report in this thread.

As to what might be done to correct your problem, perhaps you could make the first section a "powerless" engine instead of using a .wag file. I could live with that solution, and could even convert my tenders that have rear light cones to zero power engines. The "rules" would just be that only .eng files can have cones of light, just like making cabooses have smoke. If however, it doesn't work as an .eng file, then there truly is a bug needing to be fixed. I like you believe that what works in 1.4 should work in Bin, but I would be willing to live with only using cones in .eng files. I was going to do a whole big thing on the unit parameter not working correctly with picture examples, but when I heard that the penalty cone thing was going to be fixed, I decided to wait and see what comes of that "fix". Perhaps it will fix your problem as well, but I am curious to know if changing it to a powerless engine will make a difference.

Swissie
02-03-2007, 06:18 PM
Hi Joe,

thanks for replying. I didn't think of tenders yet, but my gosh, of course, there's even a more serious problem than the very occasional plow in front of the player!

What kept me off from turning that pilot truck into an .eng file is that this would automatically imply that I have to also make it the player driveable unit. But the shape file is so short that it behaves extremly jerky on the tracks, and it is very disturbing to drive a consist from that unit. Of course, bin users could then switch to the cab of the second .eng file, but not default users.

What rather seems like a solution to me (after cooling down a bit and getting my brains into gear) is to create -MU.eng versions of the various engine bodies, that would be identical to the leading .eng file except for being bare of headlight entries. Trailing units and helpers would need to use this .eng file. That would allow me to add the cone of light to the leading, non -MU .eng file with Unit ( 0 ), by-passing the problem of the cone being active with a unit further back. OK, that (again) inflates the number of .eng files in each folder, but has the benefit that all but the leading engines can run with a smaller and thus more ressource-friendly .eng file.

Got to wait a bit but if that's the only solution...

Lukas a.k.a Swissie

tpilot
02-03-2007, 07:07 PM
There was a lighted snow plow problem when BIN first came out and I think the fix was to make it a non-powered engine. I'm going to dig up the thread now.

Also, the penalty light problem indicates that BIN is not always backward compatible (is what you meant), but George has identified the problem and posted that it will be fixed in the next BIN revision.

Update (thread found - Joe was correct): http://www.trainsim.com/ts/dcboard.php?az=show_topic&forum=32&topic_id=507&mesg_id=507&listing_type=search

Similar problem when I was looking for thread: http://www.trainsim.com/ts/dcboard.php?az=show_topic&forum=32&topic_id=507&mesg_id=507&listing_type=search

Swissie
02-05-2007, 04:43 AM
Thanks for the links, tpilot! I appreciate it, and will try both approaches (pilotttruck.eng instead of pilottruck.wag; and body-MU.eng variation for midtrain units).

I hope the issue is ultimately solved so that back-wards compatibility can be fully safeguarded, but I understand that George has done a tremendously good job at fixing up all the other loose ends in MSTS, so if the light issue remained, I must and can swallow it as "price" for all the other benefits.

Lukas a.k.a Swissie

streamline
02-05-2007, 05:16 PM
Hallo!
We had the same problem with the German E94 loco by Heiko consisting of three parts, the front and rear being defined as tenders. First the engine (as well as the ProTrain E94) could be made drivable under the patch by deleting the light cone in the front part. But meanwhile an MSTS-Bin version of the engine has been uploaded to http://www.train-sim-werk.de/ There are non-bin files in the upload, too, so maybe you can find out by comparing how the authors solved the problem.

Keep on steamin'!
Dietmar

Swissie
02-06-2007, 07:36 AM
Hallo Dietmar,

danke! I'll have a look at her as well! That 194 will fit into my European Mini-MSTS Install anyways.

I'm still hoping to find a solution that releaves the user from the burden to select the proper version of .eng files as I do not want to answer a cascade of E-Mails of users that failed to read the ReadMe and installed the wrong version, or upgraded to bin later and suddenly face crashes.

So far I have made the necessary changes to remove the light cone from the .wag files and add them to the .eng files, with the logical downturn that they'll be on regardless of the position of the unit. At least that makes the Boxcab compatible again.

Unfortunately, the documented conditions

Control (1) (the player is not control of the unit, i.e. it is a helper locomotive or wagon)
Control (2) (the player is in control of the unit), quoted directly from MSTS TechDocs including the grammar error,

don't seem to make a difference. An .eng file used as helper with Control ( 2 ) responds synchronously to light switch changes by the player on the lead engine, although it shouldn't, if I interpret the TechDocs as Condition ( 2 ) = Player Unit Only correctly (probably not)...

Lukas a.k.a Swissie

mdeming
02-06-2007, 08:34 AM
I have noticed that the rs3 units from Richard Cowen do not operate under Bin as well. They do work on a default version of msts. Thankfully I do not use these engines very often so its no big deal, and I have other engines of his that work with no problem. Other engines that I have that use the freightanim line work with no problem, so that is not the issue, but it is just those locomotives that have the problem, I have 5 different rs3 locomotives of his and all of them crash the sim. Anyone know why this is, or is there another rs2 that has the detail of his that I can use?
Mike

Swissie
02-06-2007, 09:06 AM
Hi Mike,

I just ran one of his engines using the later shape file (I think - the one also used for the Canton RR Switchers) under MSTS bin 1.7. and it performed well for some 120 miles or so. That was the B&O S-2 by Michael Stephan bo_s2.zip. Only modification was that I changed the .cvf to alias to the cab of Andre Ming's A&M RS-1 coming with the payware A&O Sub instead of to the default GP38 cab.

One strange thing I noticed however was that its cone of light (sic!) caused strange effects on some alpha-channels, mainly of trees: Whatever transparent surface was lighted by the cone became invisble while "inside" the cone. Couldn't isolate the problem yet, but might be related.

You may try it and see what it does on your system?

Lukas a.k.a Swissie

mdeming
02-06-2007, 12:40 PM
>Hi Mike,
>
>I just ran one of his engines using the later shape file (I
>think - the one also used for the Canton RR Switchers) under
>MSTS bin 1.7. and it performed well for some 120 miles or so.
>That was the B&O S-2 by Michael Stephan bo_s2.zip. kas a.k.a Swissie
>

I have an s2 that he made that runs with no problem. It is the rs3 that causes the problem. Different engine :)

drjoe
02-06-2007, 04:35 PM
Now I know what I am testing tonight.

mdeming
02-07-2007, 09:03 AM
I did some testing and found out that it is the order in which the shapes are loaded that affect THIS unit. If you load the main shape first it crashes the sim. If you rename them and load the -body.s first with the main as the FreightAnim shape it works fairly well. The attached screen shot will show my results which while they work for obvious reasons render said engins unusable.

http://www.trainsim.com/vbts/Attachments/up1/115240.jpg

I found that the main shap will crash the sim even if it is just a wag file with no FreightAnim line reverse them and at least the sim will not crash.

drjoe
02-07-2007, 09:35 AM
Have run the Canton RS-3's with no problems. Which shape file are you using? Mr. Cowen has "safe" and "advanced" shapes, with the advanced shapes crashing many computers, even pre-Bin. I suggest you go back to the "original" from Mr. Cowen, and make sure that your problem is not the "advanced" shape. What version of Bin are you running?

mdeming
02-07-2007, 01:15 PM
I was using the advanced shape. I switched to the safe one and every thing works as it should. Am curious tho as to what differences there are between the shapes.
Thanks for the help
Mike

Swissie
02-08-2007, 09:50 AM
Hi again,

let me take it back onto the topic... Dietmar and Horst, thank you both for pointing me to the German 194 locos. I have inspected their files, and did notice that the bin version has the same shortfall as my previous attempt: The cone of light is defined with Unit ( 0 ) in the .eng file which comes second in the consist, meaning that when double-heading, the rear loco's cone of light will be the active one.

The .wag files defined as tenders do not differ in set-up from the .wag files I set up as carriages, so that doesn't seem to offer a solution either.

To make things worse: Attempting to run two bin-configured 194s in a Multiple Unit lash-up produced severe problems. MSTS bin 1.7. would load the consist only in 3 out of 5 attempts, and froze upon loading in the other instances.

In case it loaded, all was fine until I turned on the lights and tried to uncouple the two locos. MSTS froze immediately once I clicket onto the coupler symbol in the F9 window. I therefore modified any lights using new MSTS bin parameters to just standard MSTS configuration, and now I could load without problems. And uncouple, sort of. But immediately after uncoupling, the three parts of the rear unit dis-integrated, with the main body moving vigurously forward and through my player engine, and the two trucks speeding backwards or derailing after bumping into each other. Even though these three parts are - sorry, were - actually bar-coupled among themselves!

So there definitely is something wrong apart from the lights, and my primary suspect is the .eng file which defines the length of the main body of the engine at just 1cm. That is way under the default minimum coupling distance of 30cm, imposing that any .eng or .wag file should at least be 30.1cm long (Sniper could sing a few songs about the headaches his 1cm long InvisoCar.wag caused him about four years ago until he extended its length...).

To make things short: I left the 194s at that point to play around more with their files when I feel fit for it. But as far as the EF Boxcabs are concerned, I have decided to settle for creating a _MU.eng version for each of the Boxcab's A and B units. The _MU.eng will only feature pantograph sparks and markers, but no headlights. Trailing units in a multi-unit-lashup will have to use the _MU.eng file variation for the light cones on the leader to work properly. OK, that adds a bit to the confusion of users that do not read the documents before assembling their first consist, but at least all files remain compatible with MSTS 1.4. up to MSTS bin 1.7.01.

Ah, yes, sample consists will be included for the ones willing to learn ;-) .

Just a quick update to keep ye informed
Lukas a.k.a Swissie

drjoe
02-08-2007, 12:13 PM
Lukas,

Otto's default.wag ( the same that I use except for what I am describing ) uses a minimum coupling distance of 2 cm. While I am not "thrilled" by this, Bill Prieger's work has shown no problems with that short coupling distance ( and may even help with uncoupling while moving the train ). Otto was attempting to minimize the stickiness of the rear coupler on single locomotives. I gave him my default.wag paramaters ( which were derived from Jim Ward's work ), and he added the 2cm distance based on someone else's recommendation. That is the one that Bill Prieger's team used in their coupler work, and they reported no problems. Jim showed that my values from the Canton Geeps eliminated the rear coupler problems when using a single locomotive, so I didn't need the 2cm distance. But, the 2cm minimum did work well with a variety of coupler settings and Bin, so that is what Bill is releasing with the coupler packs. Jim Ward didn't like the 2cm setting either, but frankly I haven't found any problem with it during my testing. I don't know that it is necessary to go that low, but it doesn't seem to hurt, and given your post, there may be goo reason to use it, so that the length of these loco parts doesn't have to be increased quite as much.

tpilot
02-08-2007, 05:01 PM
Joe,

What were your previous values, just out of curiosity?

drjoe
02-08-2007, 05:51 PM
I am actually using 40cm as the minimum distance now. I think I am going back to the default 30cm. The 40 was actually to give a greater range to the pre-Bin front coupler, in other words, a greater distance to attempt to couple. I think Jim Ward is actually using 40 with Bin, but I am not sure.

OTTODAD
02-08-2007, 06:45 PM
Hi Joe !

The 2 cm Default.wag and other settings in it was suggested by George and he also advised to synchronize the r0 ( 0 2cm ) line with it !

I haven't a clue what the logic behind doing this is, you probably do, but it is working perfectly ! ;-)

O t t o