It may not be just the Dash 9...

[SMMDigital]

This morning, I got a small update from Steam. Now, the lights on my C39-8's are fubar, and they don't even use any files or aliases from the Dash 9! I had the locomotives in the German rolling stock scenario, at night, as I have been testing the lights. When I fired up the scenario this morning, the scenario had reset itself to daytime and the C398's were gone. I replaced them, but now the smoke emitter on the Long Hood Forward units is in the wrong spot, and the headlights are backwards! What is even weirder is that on the NSAND, everything is normal - all lights and smoke emitters are in their correct positions. HOWEVER, I placed one of the units on the B-SB route, and the lights are screwed up again!!! I have also found that I can't reposition the lights by changing the positions in the Blueprints through RW Tools.

When the grilles on the SD70's and SW1500's went missing, RSC said it was a core game change. I'm wondering if this is also a core problem with the Dash 9. I'm also wondering for the 15th time in as many days if I should say to heck with RSC and their bug-ridden game.

[artimrj]

I have no idea what the problem could be, but how could it be a core problem if some people have it working? That is the part I do not understand. Doc has his working and I don't. We both have about the same amount of DLC, same routes and all that. His work and mine don't. Totally baffled. When the grilles were gone, they were gone for everybody. I have now deleted, reinstalled, redeleted, reverified, changed servers and everything else I could think of. Even went exploring in the registry. Nothing will make them work. I have 4 different copies of RW. One is completely virgin, another is for the NERW VR and all it's associated equipment. Another is for my new route and another is EVERYTHING I ever downloaded and bought. The D9s do not work on any of them.

[Machinist]

... but now the smoke emitter on the Long Hood Forward units is in the wrong spot, and the headlights are backwards! What is even weirder is that on the NSAND, everything is normal - all lights and smoke emitters are in their correct positions. HOWEVER, I placed one of the units on the B-SB route, and the lights are screwed up again!!! I have also found that I can't reposition the lights by changing the positions in the Blueprints through RW Tools.

If a loco is running fine in a route but not in another, usually is a problem related to blueprint/flyout provider/product not duely checked. In the children section, if one child file is missing the next (or two nexts or even more) child will fail (wrong color, wrong place etc.). Usually children sections starts with drivers, horn, cab sound, engine sound, exaust and headlights, so you may have a problem in the exaust or engine sound (or earlier) causing the headlight being placed as the next child (mostly the rearlights) for example. If it's in the correct place but facing backwards, then editing the matrix usually will fix it (If the gizmo object is of the same provider/product).

Since the lights are children objects you can still freely change positions in the blueprints' matrix using RWTools, I've been doing this over than 1K hours so far, flawlessly. What started to happen silently (a new behavior since feb update) is that sometimes is no long enough just edit the bin files (before was) to see the changes; now you have to often clear the game cache even if the bin file is already cached. For this purpose I use my "CLEAR cache.bat" included in the 2-Clikz pack, so eveytime I edit a bin I run the batch before reload the scenario with no need of close/restart the game, and then changes show up.

To check deeply your problem only checking in the files, just PM me whenever (and if, of course) you want.

I noticed that one my previous enhanced engines (SD40-2 Santa Fe Pack, on BAB route) is now with problem, and I didn't touch them since a couple months. Maybe they changed (again silently, like a nuclear submarine moving in the deep, to avoid be detected by ordinary destroyers, us) something contaminating some files/folders. That's what I'm doing this week, checking the whole LEP pack to publish it.

Cheers,
Doc.

[wackyhuman]

Doc, you ran my scenarios. You know what that means... your system is now haunted

[SMMDigital]

I just dont understand, and it ticks me off, what is going on here. Yesterday, everything worked fine, everything in its place. Now, the rear projectong headlight is functioning as the front headlight, and the front headlight is under the locomotive fuel tank! (The light lens objects themselves are showing up fine) Usually, I can use RW tools to move them into a different position, but they will not budge. I've cleared cache, restarted railworks and steam, even restarted the computer.

The only thing that has worked so far is re-compiling the loco through the Asset Editor. Once I again I will emphasize everything worked fine before this mornings update, whatever that was.

[Chacal]

Honestly, I think it's best to just let it rest while RSC figures it out.
Otherwise you're just wasting your time.

[PapaXpress]

SMM there is something amiss. Micaelcorleone created a scenario for me using the RSC GP9 and default stock for my route. It was working fine before the update, and after the update I get a consist error. I haven't had time to investigate further, but all the files appear to be in their proper place.

[Machinist]

I just dont understand, and it ticks me off, what is going on here. Yesterday, everything worked fine, everything in its place. Now, the rear projectong headlight is functioning as the front headlight, and the front headlight is under the locomotive fuel tank! (The light lens objects themselves are showing up fine) Usually, I can use RW tools to move them into a different position, but they will not budge. I've cleared cache, restarted railworks and steam, even restarted the computer.

The only thing that has worked so far is re-compiling the loco through the Asset Editor. Once I again I will emphasize everything worked fine before this mornings update, whatever that was.

Jerry, what your are describing is exactly missing file(s) of a child object in the children section, so some children objects are out of their due place, It's for no avail edit the matrix's position, clear cache, restart game or computer etc (those are not your problems). I didn't have any update, but if you had maybe some files were deleted/renamed, and causing now failures in your children chain. Search for each bin file of your children (for sure at the beggining: driver, horn, cab sound, engine sound or exhaust), and check it they still are in your \railworks folder on the due place. I bet that's your problem. I've seen this here on RWA three times before, I concluded for the same diagnosis, prescribed the same recipe, and they got the thingy cured. I'm a Doc, remember?!

Edit later: if there is a new breaking thing in the engine core, it can be investigate further with new exams. So far, let's apply first the oridinary solution for a ordinary problem, your problem is not new. Maybe caused by a new update, or someawhat, but the fixing (cure) is known.

[SMMDigital]

While we are on the subject, is there a limit on the number of Children a locomotive can have? The first ten Children have Matrix info (exm -7.1234, .20456), the ones beyond that have just 1's and 0's, even though they are positioned on differing parts of the loco body.

RW updates should not be affecting my loco lights and child objects, as they were made by me and are located in my Provider / Product folders. However, I did name one of the light Geo files the same as it is named in the SD75 DLC. Even though it's not the same geometry or texture, the update could have singled it out for change. Unlikely, but with this game, its worth investigating.

[Machinist]

While we are on the subject, is there a limit on the number of Children a locomotive can have? The first ten Children have Matrix info (exm -7.1234, .20456), the ones beyond that have just 1's and 0's, even though they are positioned on differing parts of the loco body.

The values are in meters, so is not worth go beyond the 3rd digit after the dot. Examples:
1.2345 = 1 meter, 23 centimeters and 45 milimeters. You dont need to tweak child objects positions in milimeters, huh? I did it rarely;
1 (or 1.0 or 1.0000000 etc.) = one meter; and
0 (or 0.0 or 0.000) etc. = zero meter (from the central point of the basic model).

However I never saw (and also never used) before ".20456" (exactly as you posted) I guess it doesn't work and maybe is breaking your child. The correct is "0.20456", if was not a typpo when you posted above.

I usually go till the 2nd digit after dot (that's more than enough for children objects, once their position doesn't need to be milimetrically adjusted), and 2.30 is the same of 2.3.

For the limit of child objects within the children section, I'm not aware of any. In some of my enhanced engines I have over than 50 different children lights objects.

[Machinist]

the ones beyond that have just 1's and 0's, even though they are positioned on differing parts of the loco body.

I forgot that....

The position on differing parts of the loco body is determined by the last four values in the bottom of matrix. If all you have on your lights child on those four bottom positions' values are only 1's and 0's, then I would say you have a problem, indeed. However if they are other sort of objects (sounds, smoke particles etc.), "maybe" they are right (or not). Houston out!

[SMMDigital]

Day two of this puzzling weirdacy. I've checked all my light child objects, and they are in their folders where they should be. As a precaution I renamed my bulb object to lessen the possibility that RSC updates will latch onto and corrupt it.

I've prepared a few photos to illustrate what is happening since yesterday morning. First pic is from the loco, with all lights re-positioned and accounted for, on the US Horseshoe Curve route.

LightProblem1a.jpg

Then, the same loco, WITHOUT ANY MODIFICATIONS, placed on Test Trak.

LightProblem2a.jpg

Soooo i'm thinking that it may not be such a good idea to use Test Trak as a, well, Test Trak for my models, which I have been doing in order to avoid fubaring other routes and scenarios. I get the same results now out of SB-B and the NSAND. Lights in the redone locos all in place.

The next set illustrates what I was talking about in a previous post. Once locomotive with a light that has positional data in it's element matrix, and the same light on another locomotive has no positional data, yet is in place and operational.

LightProblem3.JPG

LightProblem4.JPG

[PamBrooker]

those distances could easily just be what you would see from two different reference datum positions. A reference datum point is a point from which distances of objects are measured logitudinally, latitudinally and vertically from. its quite common to see two otherwise identical objects have completely different measurment sets because a different point was used for referencing those distances.

However, that being said, if what i say is the case, then that short hood has everything hung exactly on its reference datum point and all bunched together in one ugly group..

[Machinist]

Day two of this puzzling weirdacy. I've checked all my light child objects, and they are in their folders where they should be. As a precaution I renamed my bulb object to lessen the possibility that RSC updates will latch onto and corrupt it.

OK. You are placing your lights.bin files (in case PointCabLight.bin) within your Provider/Product (SMMDigital/C398), if they (the bin’s) are there (and they are, otherwise you wouldn’t get the pic on HSC) is fine.

The bulb object: do you mean what is called “gizmo”? I never saw one of that color (grey), but that’s not the problem also. Rename it is good precaution (everything is possible) but that should not be a problem as well, even they change the .geo file of gizmo.

TestTrak is a UK route. If the gizmo is placed (for example) in RSC/HorseShoeCurve or Kuju/RailSimulatorUS you’ll get the bulb vanished and no lights. In a UK route both these Provider/Product are unchecked by default, if you wanna see lights of an US route on TestTrack you have to check the correct Product folder on the blueprint flyout.

What is the command line of the gizmo you are using? For example, the gizmo below (spot_light.GeoPcDx) of HSC GP-7 (within GP7_Headlight.bin) won’t show up in TestTrak until you check RSC/HorseShoe Curve:

Code: Select all

                <GeometryID d:type="cDeltaString">RSC\HorseshoeCurve\Lights\[00]spot_light</GeometryID>

Soooo i'm thinking that it may not be such a good idea to use Test Trak as a, well, Test Trak for my models, which I have been doing in order to avoid fubaring other routes and scenarios. I get the same results now out of SB-B and the NSAND. Lights in the redone locos all in place.

You can use TestTrak, since you check the Provider/Product of the light (bulb) gizmo you are using (RSC/HorseShoeCurve?!).
I didn’t understand… In BSB and NSAND the lights are working fine? If yes, then I guess the gizmo is of RailSimulatorUS, something like this (of SD40-2_Main_Headlight.bin):

Code: Select all

                <GeometryID d:type="cDeltaString">Kuju\RailSimulatorUS\System\[00]spot_light</GeometryID>

I never used Asset Editor (is the graphic tool?) to place lights once I never had a basic model to work with. Maybe in Asset Editor you need also to have checked the correct Provider/Product, otherwise the tool doesn’t find the gizmo (the light .GeoPcDx file) and then the tool fullfills the bottom positions with zeros (0, 0, 0, 1), instead of 1.11, 3.25, 8.25, 1.

Anyway, you can edit manually the Short Hood’s matrix (code below) with RW Tools with the positions the child shoud have (same matrix of Long Hood):

Code: Select all

                               <e d:type="sFloat32" d:alt_encoding="000000000000F03F" d:precision="string">1</e>
                              <e d:type="sFloat32" d:alt_encoding="0000000000000000" d:precision="string">0</e>
                              <e d:type="sFloat32" d:alt_encoding="0000000000000000" d:precision="string">0</e>
                              <e d:type="sFloat32" d:alt_encoding="0000000000000000" d:precision="string">0</e>
                              <e d:type="sFloat32" d:alt_encoding="0000000000000000" d:precision="string">0</e>
                              <e d:type="sFloat32" d:alt_encoding="000000000000F03F" d:precision="string">1</e>
                              <e d:type="sFloat32" d:alt_encoding="0000000000000000" d:precision="string">0</e>
                              <e d:type="sFloat32" d:alt_encoding="0000000000000000" d:precision="string">0</e>
                              <e d:type="sFloat32" d:alt_encoding="0000000000000000" d:precision="string">0</e>
                              <e d:type="sFloat32" d:alt_encoding="0000000000000000" d:precision="string">0</e>
                              <e d:type="sFloat32" d:alt_encoding="000000000000F03F" d:precision="string">1</e>
                              <e d:type="sFloat32" d:alt_encoding="0000000000000000" d:precision="string">0</e>
                              <e d:type="sFloat32" d:alt_encoding="000000606666EA3F" d:precision="string">1.11</e>
                              <e d:type="sFloat32" d:alt_encoding="000000400A571040" d:precision="string">3.25</e>
                              <e d:type="sFloat32" d:alt_encoding="0000004033B31B40" d:precision="string">8.25</e>
                              <e d:type="sFloat32" d:alt_encoding="000000000000F03F" d:precision="string">1</e>


Bottom line: what is (and where is placed) the .geo file (for example: point_light.GeoPcDx) you are using as bulb (gizmo) object?

[PapaXpress]

In the case for child objects their placement is measured from the center of the parent plus its world coordinates which were set when it was modeled. An example of this is is the head of a signal, where is has 1 and 0 for its placement, yet it was designed to sit relative to where the rest of the post. And you can have children stack on each other.

Kali made an excelent post about poistioning child objects out on UKTS: http://forums.uktrainsim.com/viewtopic. ... 0#p1549720

I still think we are missing something. I just can't see it.