Updated scripted signal issue.

[justinroth]

I've recently transferred a route from tane to 2022. The route had signals from pre tane sp3 and the script was broken. I updated the signals to a newer version of this (tested on a blank route) script however, the script properties don't show up correct. I can place a completely identical signal down and all is well with the newly placed signal, however the same exact signal that exists still has the incorrect script properties editing window. I tried bulk asset replacing to no avail. I already have the signals placed and as far as I can tell the only way forward is to delete and replace each signal even though they are the exact same (kuid) signals. Perhaps someone with more script knowledge can enlighten me on what is happening. It may be worth note that there are other signals still on this route that use the older script. Is it possible this is causing issues?

 

[Hemler]

script properties don't show up correct

Are they showing the old signal script properties in the editing window?

If so did you change the name of script to something different. Not the old signal script name?

 

[justinroth]

Are they showing the old signal script properties in the editing window?

If so did you change the name of script to something different. Not the old signal script name?

They are showing the new script, kind of. There are options missing and the default display of info is more like the old script. The new script is an updated version of the old script by a different author with a different kuid.

 

[justinroth]

I've tried deleting all signals using the older script and a database rebuild but the problem still persists. The script properties on the right are for the old signal and they still contain original script settings (under "route" which appears for advanced settings). The old script wouldn't look like this in 22. The script on the left is the new signal and script settings window. Notice the absence of "Ruleset:" settings on the old signal (there should be options for norac/nw/southern). The only other initial difference is the setting for "plate" defaults to (-) or in the state it is showing the properties (this happens with the new script not the old). In the old script this was hidden and had to be selected - not a big deal but it is a difference. These are the same asset so somewhere, stored with this route is some info that is making this happen as these signals test just fine on a blank route. I'm stumped.

 

[pcas1986]

Assuming the original signals saved some data to the route/session, I wonder if the new script is misinterpreting what existed before. I've written, and seen other similar scripts, that interrogate the saved data (SetProperties) and looked for a version number. If the correct version exists then fine, but if not then the script defaults what values.

i.e. when saving the object properties to the session soup using GetProperties() you save something like:

public Soup GetProperties(void) {
  Soup soup = inherited();
  soup.SetNamedTag("version",2);
  // add other stuff to the soup?
  return soup;
 }
  
 public void SetProperties(Soup soup) {
  
   inherited(soup);
   int version = soup.GetNamedTagAsInt("version",0);
   if (version == 0) {
     // original
     // default some values?
   }
   else {
     // this is a newer version and you may need to test the version
     // number further
   }
 }

Code has not been tested.

 

[justinroth]

Assuming the original signals saved some data to the route/session, I wonder if the new script is misinterpreting what existed before. I've written, and seen other similar scripts, that interrogate the saved data (SetProperties) and looked for a version number. If the correct version exists then fine, but if not then the script defaults what values.

i.e. when saving the object properties to the session soup using GetProperties() you save something like:

public Soup GetProperties(void) {
  Soup soup = inherited();
  soup.SetNamedTag("version",2);
  // add other stuff to the soup?
  return soup;
 }
 
 public void SetProperties(Soup soup) {
 
   inherited(soup);
   int version = soup.GetNamedTagAsInt("version",0);
   if (version == 0) {
     // original
     // default some values?
   }
   else {
     // this is a newer version and you may need to test the version
     // number further
   }
 }

Code has not been tested.

I am at best an F- scripter. I didn't write nor update "fix" it to work post tane sp2. Are you saying the original script still has something in the soup? Is my only solution to delete and replace each signal individually? Would backing them up, deleting and re-installing them help?

 

[justinroth]

Perhaps I should do what I contemplated and convert them to use something stable...like the JR script. I would miss being able to set slow and restricting states though I guess the JR script allows an unbonded option. Oof. What a chore.

 

[stagecoach]

Have you deleted the old, obsolete asset?
If you did not up the version of the asset, then the already placed assets will not get updated. I found this out with my drivable ships. If I placed a ship and then needed to raise or lower it, and changed the script to correct it, it would not change already placed ships, only newly placed ships.
Bulk replace an unused asset for the faulty asset and then bulk replace the unused asset for the original asset.

 

[norfolksouthern37]

It is a matter of the new script looking for soup properties that do not exist on the previous ones? any of this would be difficult to determine without the code.

Perhaps I should do what I contemplated and convert them to use something stable...like the JR script. I would miss being able to set slow and restricting states though I guess the JR script allows an unbonded option. Oof. What a chore.

I wouldn't mind making operational changes to the code to cover more variants, but nobody else at JR does signal logic or scripting at that level so I only get to it when I get to it.

 

[justinroth]

It is a matter of the new script looking for soup properties that do not exist on the previous ones? any of this would be difficult to determine without the code.



I wouldn't mind making operational changes to the code to cover more variants, but nobody else at JR does signal logic or scripting at that level so I only get to it when I get to it.

Yeah it's time consuming for sure. I attempted to fix the current "fixed" script I'm using to work for both NW cpls and modern signals in NW territory but gave up. Perhaps the "ruleset" function is not necessary and a different script for each signal pack/rule set would be simpler....I dunno. A new JR script to allow for extended states/forced aspects would be awesome. As is it's already great and user friendly. Perhaps a modification similar to the super script I'm using with basic/advanced modes of setting routes/aspects/other signal properties. I have a whole butt-ton of signal meshes sitting on routes not working.

 

[justinroth]

Have you deleted the old, obsolete asset?
If you did not up the version of the asset, then the already placed assets will not get updated. I found this out with my drivable ships. If I placed a ship and then needed to raise or lower it, and changed the script to correct it, it would not change already placed ships, only newly placed ships.
Bulk replace an unused asset for the faulty asset and then bulk replace the unused asset for the original asset.

So I need to create new versions AND bulk replace/bulk replace?