[Goku]

disc, on 09 October 2015 - 10:49 AM, said:

It seems yes. One hungarian route uses it.

So maybe I will have to add compressed .w file support. But not now.

[Csantucci]

Goku, on 09 October 2015 - 10:40 AM, said:

Compressed .w files probably will not be supported. Any route except KUJU routes uses them?

Yes, there are other routes using compressed .w files,e.g. the Bernina freeware, NECV4, the German WupperExpress11 and I am quite sure a good amount more.
Maybe you can study in the OR source code how to uncompress .w files.

[vince]

Re; Editing existing routes.
May I respecfuly suggest that 32 years in the business taught me it is not good development practice to test new code, the new OR Router Editor in this case, on an unknown test bed, i.e. any add-on routes.

I feel that possible unknown coding errors in an add-on route may lead Goku down a false path leading to the question; ' Is this error I see the route I'm using as a test or is it my editor?

I do agree that the original default routes (including the Tutorial Route ) do have some minor left over uncorrected errors (most found by now) but would not one of them serve as a more stable platform for testing the edit and build functions for a new editor?

I see this happening a lot in OR where the coding errors in MSTS rolling stock has caused users to question OR operation when in fact it's the original MSTS content that throwing sand in the gears.

Carry that problem via unintended coding differences in an add-on route could impact the new editor by throwing out false trails. Goku, We don't need you getting frustrated by chasing supposed editor bugs that are actually bugs in the route you are using to test your editor functions.Please consider keeping your edit existing routes testing to a route that wont jump up and bite you. :buffalobill:
That'd be any of the default routes or your newly created route. The keep it simple process.
:sign_thanks: and
best regards,
vince

[roeter]

Problems reading sigcfg.dat.

In particular, the program does not like the following signal shape definition :

	SignalShape (
		"NF_Theatre_1.s"
		"NF Theatre 1"
		SignalSubObjs ( 28
			SignalSubObj ( 0
				"HEAD1"
				"Signal"
				SigSubType ( SIGNAL_HEAD )
				SignalFlags ( DEFAULT )
				SigSubJnLinkIf ( 1 1 )
				SigSubSType ( "NF_THEATRE_1" )
			)
			SignalSubObj ( 1
				"LINK1"
				"Route Linked"
				SigSubType ( LINK1)
				SignalFlags ( OPTIONAL )
			)
			SignalSubObj ( 2
				"NOSHOWSTP"
				"No show on Stop"
				SigSubType ( DECOR )
				SignalFlags ( DEFAULT OPTIONAL )
			)
			SignalSubObj ( 3
				"USELINK"
				"Use Link"
				SigSubType ( DECOR )
				SignalFlags ( OPTIONAL )
			)
			SignalSubObj ( 4
				"INVLINK"
				"Use Inverse Link"
				SigSubType ( DECOR )
				SignalFlags ( OPTIONAL )
			)
			SignalSubObj ( 5
				"USEJNSIG"
				"Use Junction Signal"
				SigSubType ( DECOR )
				SignalFlags ( OPTIONAL )
			)
			SignalSubObj ( 6
				"USETOP"
				"Display on Top Jn"
				SigSubType ( DECOR )
				SignalFlags ( OPTIONAL )
			)
			SignalSubObj ( 7
				"USEMID"
				"Display on Middle Jn"
				SigSubType ( DECOR )
				SignalFlags ( OPTIONAL )
			)
			SignalSubObj ( 8
				"USELOW"
				"Display on Low Jn"
				SigSubType ( DECOR )
				SignalFlags ( OPTIONAL )
			)
			SignalSubObj ( 9
				"USEASPECT"
				"Use Next Signal Aspect"
				SigSubType ( DECOR )
				SignalFlags ( OPTIONAL )
			)
			SignalSubObj ( 10
				"USECL2"
				"Display on CLEAR_2"
				SigSubType ( DECOR )
				SignalFlags ( OPTIONAL )
			)
			SignalSubObj ( 11
				"USECL1"
				"Display on CLEAR_1"
				SigSubType ( DECOR )
				SignalFlags ( OPTIONAL )
			)
			SignalSubObj ( 12
				"USEAP3"
				"Display on APPROACH_3"
				SigSubType ( DECOR )
				SignalFlags ( OPTIONAL )
			)
			SignalSubObj ( 13
				"USEAP2"
				"Display on APPROACH_2"
				SigSubType ( DECOR )
				SignalFlags ( OPTIONAL )
			)
			SignalSubObj ( 14
				"USEAP1"
				"Display on APPROACH_1"
				SigSubType ( DECOR )
				SignalFlags ( OPTIONAL )
			)
			SignalSubObj ( 15
				"USERES"
				"Display on RESTRICTING"
				SigSubType ( DECOR )
				SignalFlags ( OPTIONAL )
			)
			SignalSubObj ( 16
				"USESPR"
				"Display on STOP_AND_PROCEED"
				SigSubType ( DECOR )
				SignalFlags ( OPTIONAL )
			)
			SignalSubObj ( 17
				"USESTOP"
				"Display on STOP"
				SigSubType ( DECOR )
				SignalFlags ( OPTIONAL )
			)
			SignalSubObj ( 18
				"RTE01"
				"Display on Route 1"
				SigSubType ( DECOR )
				SignalFlags ( OPTIONAL )
			)
			SignalSubObj ( 19
				"RTE02"
				"Display on Route 2"
				SigSubType ( DECOR )
				SignalFlags ( OPTIONAL )
			)
			SignalSubObj ( 20
				"RTE03"
				"Display on Route 3"
				SigSubType ( DECOR )
				SignalFlags ( OPTIONAL )
			)
			SignalSubObj ( 21
				"RTE04"
				"Display on Route 4"
				SigSubType ( DECOR )
				SignalFlags ( OPTIONAL )
			)
			SignalSubObj ( 22
				"RTE05"
				"Display on Route 5"
				SigSubType ( DECOR )
				SignalFlags ( OPTIONAL )
			)
			SignalSubObj ( 23
				"RTE06"
				"Display on Route 6"
				SigSubType ( DECOR )
				SignalFlags ( OPTIONAL )
			)
			SignalSubObj ( 24
				"RTE07"
				"Display on Route 7"
				SigSubType ( DECOR )
				SignalFlags ( OPTIONAL )
			)
			SignalSubObj ( 25
				"RTE08"
				"Display on Route 8"
				SigSubType ( DECOR )
				SignalFlags ( OPTIONAL )
			)
			SignalSubObj ( 26
				"RTE09"
				"Display on Route 9"
				SigSubType ( DECOR )
				SignalFlags ( OPTIONAL )
			)
			SignalSubObj ( 27
				"RTE10"
				"Display on Route 10"
				SigSubType ( DECOR )
				SignalFlags ( OPTIONAL )
			)
		)
	)

More particular, it does not like the name for SignalSubObj 11 ("USECL1").
Seems to me you do not read enough characters from the name string, which makes the name for 11 equal to the name for 10 ("USECL2"), and that crashed the program.

By the way, this is a 'private' route, not available anywhere and it can't be shared - even zipped it's over 4 Gbyte.

Regards,
Rob Roeterdink

[James Ross]

Csantucci, on 09 October 2015 - 12:40 PM, said:

Maybe you can study in the OR source code how to uncompress .w files.

The compressed (binary) format is pretty simple, as formats go, but it may require an entirely separate parser depending on the code's architecture.

[Goku]

roeter, on 09 October 2015 - 12:40 PM, said:

In particular, the program does not like the following signal shape definition

Quote

SignalSubObj ( 1
"LINK1"
"Route Linked"
SigSubType ( LINK1)

My parser does not like no space after LINK1) . Change it to LINK1 ) and it works. I'll fix it later.

New version. Fix for all string) bugs.

http://koniec.org/ts...SRE5_v0.603.zip

----

And another question: how I deal with this:
SignalFlags ( DEFAULT OPTIONAL )

I was thinking that if flag is DEFAULT -> subObj is created during signal placing and checkbox is disabled. And if flag is OPTIONAL then subObj is not created during signal placing and user can check/uncheck it.
It depends on existence of 'SigSubSType' not value inside signal flags?
----

James Ross, on 09 October 2015 - 12:59 PM, said:

The compressed (binary) format is pretty simple, as formats go, but it may require an entirely separate parser depending on the code's architecture.

Yes - it require entirely new parser. I made my parser 7 years ago without knowledge about coreids.tok file and it supports only text format. Reading some binary files like .s/.ace I did by guessing what is inside.
Now if I know attributes ids it seems to be easy and I will do it, but I prefer finish other features first.

[roeter]

Quote

And another question: how I deal with this:
SignalFlags ( DEFAULT OPTIONAL )

I was thinking that if flag is DEFAULT -> subObj is created during signal placing and checkbox is disabled. And if flag is OPTIONAL then subObj is not created during signal placing and user can check/uncheck it.
It depends on existence of 'SigSubSType' not value inside signal flags?

This is how it works :

• ( DEFAULT ) means head is set by default and fixed, it cannot be switched off.
  
• ( OPTIONAL ) means head is not set by default but can be switched on.
  
• ( DEFAULT OPTIONAL ) means head is set by default but can be switched off.

So a head with ( DEFAULT OPTIONAL ) is generated by default, the checkbox is enabled with the 'tick' set but it may be switched off.
For existing signals, the related flag indicates if the head is set or not; in both cases, the checkbox must be enabled with the 'tick' set on or off as applicable.

Quote

My parser does not like no space after LINK1) . Change it to LINK1 ) and it works

Well, that's not what I found.
I removed the subobjs down from no. 12, and changed USECL2 to CL2 and USECL1 to CL1, and then it worked. Changing the names back to USECL2 and USECL1 made the program crash again. Never changed the LINK1 line.

Regards,
Rob Roeterdink

[Goku]

roeter, on 10 October 2015 - 12:33 AM, said:

I removed the subobjs down from no. 12, and changed USECL2 to CL2 and USECL1 to CL1, and then it worked. Changing the names back to USECL2 and USECL1 made the program crash again. Never changed the LINK1 line.

You found wrong. In c/c++ really weird things happen if error is ignored and code goes outside allocated array memory. After reading LINK1) instead of LINK1 one ) was missing, so parser was thinking that all remaining SignalSubObj was attributes of SignalSubObj #1.
Next it was looking for missing SignalSubObj exceeding allocated byte array. Finally causing Segmentation Fault after exceeding application heap.
When you shorten these Strings, weird thing happen and sigcfg script finished his work before end of application memory, so no crash.

[roeter]

Quote

In c/c++ really weird things happen if error is ignored and code goes outside allocated array memory.

Which is why I never liked to work with C/C++.

Anyway, it loads now, but that's it.
If I select a track, I get 'unsupported Trackobj'. I'm using UK-finescale. Is this what is to be expected?
When I select an existing signal, the program crashes without any hint of what it's doing. It makes no difference if I select the signal marker or the related signal object, the program crashes either way. It makes no difference what signal I select, either.

Regards,
Rob Roeterdink

[Goku]

I did reading compressed world files. It was trivial with knowing coreIds.

roeter, on 10 October 2015 - 05:24 AM, said:

If I select a track, I get 'unsupported Trackobj'. I'm using UK-finescale. Is this what is to be expected?

Yes. It means only that I didn't make UI Form for this type of object yet, and only properties window does not support it.

roeter, on 10 October 2015 - 05:24 AM, said:

When I select an existing signal, the program crashes without any hint of what it's doing.

Do you use new version with 'string)' fix ? Maybe you can send me this route? My editor doesn't need textures at all so route without textures will be easy to send.

I think that problem may be in UI form. I have only 10 forms for signal subobjs and inside your sigcfg file are signals with a lot more :)