Crash Detection code

[Guest GerrishGray]

Hi allIt might be useful if we could collate information on the correct use of the various commands for crash detection in scenery BGLs. (This follows on from a mention in another current thread, and an earlier thread that never reached a proper conclusion.)Mental Health Warning: This stuff is a bit techie ... you might not want to get involved if you're not a bit of a 'codehead'!!!The particular question that has arisen is whether the CrashIndirect command is necessary to 'activate' crash detection code encapsulated in a library object. This command was introduced when library objects first appeared. The SDK never explained what the command actually does, but the implication was that it was required to initialise crash detection monitoring, and this separate command was necessary because of the slightly different nature of 'section 10' library objects rather than traditional section 9 objects.There have been several reports, however, that some FS2002 library objects will generate crashes even without a CrashIndirect command in the section 9 calling sequence to turn the crash detection on.Sometimes this is probably a result of the methods different designers and/or design tools use for crash detection. For example, FSDS doesn't use the 'standard' crash detection commands but instead checks the distance from the centre of the object in the x,y,z directions by checking three global variables with the IFIN3 (IfVarRange3) command. This code probably doesn't need any separate initialisation anyway.So the immediate questions are[ol][li]What exactly do the Crash (opcode 0x94) and CrashIndirect (opcode 0x95) commands do?[/li][li]Are they still required in FS2002?[/li][li]And if the answer to 2. is "sometimes", which crash detection methods require this initialisation and which don't?[/li][/ol]If nobody knows the precise answers - and I suspect that this will prove to be the case - then some testing and even a bit of constructive speculation might help!Anyone got any information (beyond what the SDKs fail to tell us properly!), ideas, experiences or useful thoughts ...?!CheersGerrishPS. I rarely bother with crash detection in stuff I design anyway - so I don't know much about this topic. But it would certainly be interesting to know more!

[ShezA 176]

This is a topic I have been wondering about. My alternative add-on question is why there is an option for Crash Detection in GMAX and it does not work when converted through MakeMDL. Does it work in aircraft?In my DCA scenery I also ignored the crash detection basically because I tried a few things and it did not activate so just thought I would leave it.I am not a techie but if you want me to try the code then by all means let me know what is your desired direction.RegardsShez

[rhumbaflappy 113]

Hi all.Here's a small SCASM code that places a library object. The object's code ( in the default 'scenery_fs_sco.bgl' library ) contains older "CrashBox" code. The placing bgl requires no crash detection, and the sim registers the crash:

; ----------------------------------------; DelavanStateCapitol.sca ( Sco_statecapital1 ) ; ----------------------------------------Header( 1  N42:38:01.80 N42:38:01.80 W088:36:33.00 W088:36:33.00 )LatRange(  N42:38:01.80  N42:38:01.80 )Area( A N42:38:01.78 W088:36:33.00 100 )	IfVarRange( :  0346 2 32767 )	PerspectiveCall( :_PlaceObject_1 )	ShadowCall( :_PlaceObject1 )	Jump( :EndA ):_PlaceObject_1	RefPoint( rel :ReturnObject_1 0.50 N42:38:01.80 W088:36:33.00 V1= 0 V2= 187 )	RotatedCall( :CallObject_1 0 0 0 )	Return:CallObject_1	CallLibObj( 0 C545A292 11D2E2EC 1000849C 2AE60C5A ):ReturnObject_1	ReturnEndA

Dick

[arno 1]

This reply is a bit off topic (meant as a reply on Shez, but I now see it doesn't appear there :)), but when you include crash detection in GMax your object will certainly have it.BUT, I think you placed your objects with FsRegen and a lib? And FsRegen only takes the object information from the _0.asm file, while the crash information is in the other file (that also places the object). This means that you will not see crash detection then (unless you add some code to your calling API to get it back again).And for Gerrish, just like you say, I have never wondered much about the crash detection (and left it out most of the time, because it is more annoying then usefull), so I can't add much usefull info about the different commands to the discussion.Arno

---

Member Netherlands 2000 Scenery Team[a href=http://home.wanadoo.nl/arno.gerretsen]http://home.wanadoo.nl/arno.gerretsen/banner.jpg[/a]

[rhumbaflappy 113]

Hi Arno.You are exactly right.When using fsregen to create the object library, it doesn't include the crash detection code that actually lies in the example.asm, not the example_0.asm. So it never gets to the library. That can be cured by copying the crash routine to preceed the start of the library object code:; Library Compiler - fsregen v0.31b by G.Ioannu ; Freeware. Commercial use is prohibited.; header label word dw 0001 dd 000989D57H dd 0FF6914C5H dd 07FFFFFFFH dd 080B60B62H dw 22 dup(0) dd (offset LIBRARY_DATA) - (offset header) dw 10 dup(0) dd 0B86CAFDAh dd 049133A72h dd 0B86CAFDAh dd 049133A72h dw 14 dup(0)LIBRARY_DATA label word dd (offset LIBRARY_0) - (offset LIBRARY_DATA) dd 0B86CAFDAh, 049133A72h, 085C23CA8h, 0D335043Fh dd 0,6,8 dd (offset LIBRARY_DATA)LIBRARY_0 label word dd 0B86CAFDAh, 049133A72h, 085C23CA8h, 0D335043Fh db 100 dd (offset LIBRARY_0_HE) - (offset LIBRARY_0) dd (offset LIBRARY_0_END) - (offset LIBRARY_0_START) dd 263 dd 131072 dd 0 dd 0 db "HouseObject" dd 0LIBRARY_0_HE label wordLIBRARY_0_START label word; i; fsregen labels !!!! DO NOT REMOVE THIS LINE !!!;--------- WARNING - WARNING - WARNING - WARNING - WARNING - WARNING ---------;; This file was automatically generated from C:Program FilesgmaxgamepacksFlightSimHouseObject; using the MakeMDL tool. Do not edit by hand, re-run the; tool instead.;; generated on 12/12/02 09:01:39;;--------- WARNING - WARNING - WARNING - WARNING - WARNING - WARNING ---------; BGL model for C:Program FilesgmaxgamepacksFlightSimHouseObject;; $Header:$;;----------------------------------------------------------------------------model_crash label BGLCODE BGL_CRASH_START model_crash_end, 481 BGL_CRASH_OCTTREE crash_end_1 dw CRASH_FLAG_OBJECT ; crash type dw 113 ; nodes used real4 -344.344849,0.000000,-342.940613 ; Box x,y,z real4 680.296814,296.904022,519.955750 ; Box w,h,d dw 1, 24, 24, 45, 62, 72, 72, 97 ; base offset into node table, one for each top-level branch ; So if you take branch 2 (count from 0), you add 24 to indices you encounter on that branch ; Nodes (254=empty 255=full, else an index into branch) OCTTREE_NODE 0, 255, 0, 0, 0, 255, 0, 0 ; node 0 OCTTREE_NODE .........and so on........crash_end_1 label wordmodel_crash_end label word;; Final Status: 82 polys; Alpha Status: 0 polys; Light Status: 0 polys; Library Status: 0 polys;; Start Time: 12/12/02 09:01:39; Stop Time : 12/12/02 09:01:39;; Modeling units = 2.0000; Radius = 262.0722; Radius in meters = 262.0722; Radius in modeling units = 525;HouseObject_topG0 label BGLCODE BGL_BEGIN 0800h ; version = 8.00 TEXTURE_LIST_BEGIN TEXTURE_DEF TEXTURE_AIRCRAFT , <255,255,255,255>, 234.702213, "HOUSE.BMP" ; 0 TEXTURE_DEF TEXTURE2_NIGHT , <255,255,255,255>, 234.702213, "HOUSE_LM.BMP" ; 1 TEXTURE_LIST_END MATERIAL_LIST_BEGIN MATERIAL_DEF 1.000000,1.000000,1.000000,1.000000, 0.392157,0.392157,0.392157, 0.000000,0.000000,0.000000, 0.000000,0.000000,0.000000, 0.000000 ; 0 MATERIAL_LIST_END VERTEX_LIST_BEGIN VERTEX_DEF -344.344025, 199.640015, 176.584015, -1.000000, 0.000000, 0.000000, 0.363202,0.965067 ; 0 part= 1 prim=0.........If you note where I pasted it in the library.asm, you'll see that it performs the crash routine before the object is created. Works perfectly.This also needs no Crash routine in the Library Object placing BGL... the crash is essentially part of the object:; ----------------------------------------; DelavanHouse.sca ( HouseObjectLib2.bgl Library object Placer ) ; ----------------------------------------Header( 1 N42:38:01.80 N42:38:01.80 W088:36:33.00 W088:36:33.00 )LatRange( N42:38:01.80 N42:38:01.80 )Area( A N42:38:01.78 W088:36:33.00 100 ) IfVarRange( : 0346 2 32767 ) PerspectiveCall( :_PlaceObject_1 ) ShadowCall( :_PlaceObject1 ) Jump( :EndA ):_PlaceObject_1 RefPoint( rel :ReturnObject_1 0.3 N42:38:01.80 W088:36:33.00 V1= 0 V2= 187 ) RotatedCall( :CallObject_1 0 0 5 ) Return:CallObject_1 CallLibObj( 0 B86CAFDA 49133A72 85C23CA8 D335043F ):ReturnObject_1 ReturnEndA-------------------------------------------Of course, now there is a decision to make: Is it better to include the crash detection in the Library object, or should it be part of the placing BGL ( or placing API )?For a single tree or house, it wouldn't matter. But if I were to recreate my hometown, I need thousands of buildings and tens of thousands of trees... do I want crash detection with them all? I don't know what the CPU overhead is with the crash dection routine, but multiplied by thousands, it might be a problem, even if the sim's crash detection is turned off! The sim will probably still process the detection routine.So perhaps the Gmax-fsregen method is best... to have the crash routine outside the Object Library code.Dick

[arno 1]

Maybe I am wrong, but I thought that the library.asm file from FsRegen included the _0.asm file of the object? So then the object code is not part of the library.asm file and the easiest way is probably to paste the crash code at the top of the _0.asm file.Arno

---

Member Netherlands 2000 Scenery Team[a href=http://home.wanadoo.nl/arno.gerretsen]http://home.wanadoo.nl/arno.gerretsen/banner.jpg[/a]

[rhumbaflappy 113]

Hi Arno.Yes... could be done.; Library Compiler - fsregen v0.31b by G.Ioannu ; Freeware. Commercial use is prohibited.; header label word dw 0001 dd 000989D57H dd 0FF6914C5H dd 07FFFFFFFH dd 080B60B62H dw 22 dup(0) dd (offset LIBRARY_DATA) - (offset header) dw 10 dup(0) dd 0B86CAFDAh dd 049133A72h dd 0B86CAFDAh dd 049133A72h dw 14 dup(0)LIBRARY_DATA label word dd (offset LIBRARY_0) - (offset LIBRARY_DATA) dd 0B86CAFDAh, 049133A72h, 085C23CA8h, 0D335043Fh dd 0,6,8 dd (offset LIBRARY_DATA)LIBRARY_0 label word dd 0B86CAFDAh, 049133A72h, 085C23CA8h, 0D335043Fh db 100 dd (offset LIBRARY_0_HE) - (offset LIBRARY_0) dd (offset LIBRARY_0_END) - (offset LIBRARY_0_START) dd 263 dd 131072 dd 0 dd 0 db "HouseObject" dd 0LIBRARY_0_HE label wordLIBRARY_0_START label word; Paste the Crash Code here ( or make an 'include HouseObjectCrash_0.asm' , and create "HouseObjectCrash_0.asm" which contains just the crash code ripped from "HouseObject.asm" ). That would make the code a bit more readable, and 'modular' in nature. include C:Program FilesfsregenHouseObject_0.asmLIBRARY_0_END label word dd 0,0,0,0Dick

[arno 1]

I know it CAN be done, but I thought that FsRegen always did it that way. :)Arno

---

Member Netherlands 2000 Scenery Team[a href=http://home.wanadoo.nl/arno.gerretsen]http://home.wanadoo.nl/arno.gerretsen/banner.jpg[/a]

[ShezA 176]

I see so we will then have to hand code each (finalised) library object within the 0asm so when it compiles it will have crash detection. A novel way to bypass FSRegen I guess. I wish Giorgio was around to do this as a routine in FSRegen...:-( Shez

[rhumbaflappy 113]

'object_0.asm' is the object itself, from the Gmax derived code. 'object.asm' is placing code, and which contains the crash routine.Fsregen "includes" the original Gmax-derived 'object_0.asm' code in the library.asm, which now defines the object, but not the crash-code.Fsregen doesn't put the crash code anywhere, so that's why Shez has no crash detection for his Gmax-Fsregen library objects.So the crash routine must be manually added to the library.asm code ( or "included" in the library.asm code ), or put in the placing API. The placing API is SCASM, so it would be difficult to place the original crash-code there, as the crash-code is in BGLC format. But it can be done if you're willing to hand-translate the BGLC-ASM crash code to SCASM equivalents. ( BGLAnalyze doesn't seem to be able to handle the conversion ).Dick

[Guest GerrishGray]

Hi guysFrom what you say, Dick, and from other previous reports, it is begining to appear that including the CrashIndirect command in the calling sequence is entirely unnecessary in FS2002 and that crash detection in a library object will always work in FS2002 without this initialisation (or whatever it was supposed to do). The only contra-indication will be if someone reports results of some testing where removing/omitting CrashIndirect turned crash detection off for a particular model ...In the new CRASH_START, CRASH_OCTTREE sequence, CRASH_START seems to be the only initialisation required, and its function seems simply to be to say where the crash detection code ends and to do a simple 'crash sphere' test before embarking on the full-scale crash detection, so that the crash detection overhead is minimised and only takes effect when close to the object anyway.In the examples I have examined, there is usually a Return after the Crash OctTree, which seems logical, but I notice that you have omitted this in your example - was that intentional? Mind you, it's not entirely clear what address those Returns actually return to. Perhaps CrashStart pushes the label address onto the scenery engine's stack so that it becomes the return address to be used. That would work (but is a rather unusual way of doing things). It could also explain why your sample code might still work correctly without a Return, because the net effect would be the same apart from a failure to pop the unused address off the stack. This wouldn't matter as long as the rest of the code in the object was correctly structured, because I suspect that the stack structure used within an object is automatically cleaned up at the end of the object anyway (simply by discarding it). This would also account for the some of the tolerance of the engine to missing returns and other structural errors.I think this modern crash detection code is probably quite efficient and the overhead and frame rate effect may be fairly minimal, as long as one keeps the radius argument to CRASH_START as small as possible.As regards CrashOctTree, I believe that the node branch addresses are always relative to the current node, allowing 0 to be used as a recursive re-entry, and also explaining why 254 is used as the 'empty' value rather than 0. This use of recursion makes an octtree a really efficient data storage structure for 3D spatial data. The wording in the SDK appears to be a bit misleading as it seems to suggest that the offsets are relative to the base node, which I don't think can be correct?But one thing that still needs confirming is the spatial arrangement of the eight cells in each node of the octtree structure. Perhaps CrashOctTree should be discussed in a separate thread. Otherwise, as usual, we could end up hiding important conclusions within a great long thread dealing with a different topic ... :-)CheersGerrish

[rhumbaflappy 113]

Hi Gerrish.There are 3 older ways of adding a crash to an object: BGL_CRASH ( 0x94 ) is to be used as part of the object before the ADDOBJ command. It allows a density activation level. It is NOT to be used as part of a library object.BGL_CRASH_INDIRECT ( 0x95 ) is used when you are "calling" an object ( library or other ), and is to be NOT to be used as part of that library code, but should be used in the "placing" BGL ( library placing API ), for a library object that doesn't have it's own crash-code. It allows a density activation level.BGL_CRASH_START ( 0x96 ) is used as part of a library object ( and I don't see any density activation level ).--------------------------- Here's some library code from CFS1:

; Library Object #4, Offset 0x15A8, size 17752 (= 0x10000); ----------------------------------------ObjID( 9797FC57 8A930060 11D14AC5 A028DBB3 )LibObj( 	PWR   0	SIZE  6	SCALE 0.100	TYPE  1024	NAME   "AM75MM"	)	CrashStart( :L0015FB 23 ); offset to end of crash code  +  radius of 23	CrashBox( :L0015F9 -9 0 -29 9 23 29 0 0 0 ); failure return  +  the box	SetCrashCode( 14 ); set to CRASH_BUILDING_PLANE ( Gmax sets it to 20 ? )	Return:L0015F9	Return:L0015FB;--------------------------- end of crash code	IfVSize( :L001611 18 1 )	IfVSize( :L00162B 3 2 )	Jump32( :L001A4D ):L001611	Points( 0			0	0	 0;   0	)	LineColor( 00 F0 )	Dot( 0 0 0 )	Return:L00162B	VecPoints( m 0		  -11	0	19 -32767	  0	  0;  0.........

This Library object would NOT be called with BGL_CRASH_INDIRECT, as it already contains crash code from SCASM's CrashStart ( BGL_CRASH_START ).-----------------------I think most default library objects already have crash detection in the library object, and so don't need a BGL_CRASH or BGL_CRASH_INDIRECT calling routine.-----------------------Apparently, the newer BGL_OCTTREE can be used either as part of a library object, or as part of a non-library object ( I have tried both ). I don't know if BGL_OCTTREE can be used outside the object, as part of an API (?) or library object placing routine for a crashless library object. That would be the next logical place to check, as that would allow us to create libraries with non-crashing objects, and API-place them with the more advanced OCTTREE Crash detection ( which we could cut'n'paste from a Gmax-derived ASM ).------------------------Meanwhile, what is FSDS2 using for crash detection, and where is it placed?-----------------------And, does the shadow placement affect the crash for any of these methods, as that does call a library object.Dick

[Guest GerrishGray]

Hi againThe crash detection code properly belongs with the object in the library - it would be silly to put it in the calling API - rather goes against the idea of using library objects in the first place!There is no problem coding the CrashStart(), CrashOctTree() crash detection method in SCASM if one wants, though - the only reason that BGLAnalyse has problems decoding many of the default FS2002 library objects into SCASM code is because there is a mistake in the coding of those objects with an extra, redundant, Return command that gets BGLAnalyse confused. I guess this comes from a mistake in makemdl.exe (another one!).Returning once again to my favourite hobby-horse: the only valid reasons for working with BGLC rather than SCASM are (a) creation of TMF, or (:( hacking/creating/enhancing the assembler code output by gMax/makemdl.exe Using BGLC for anything else is just plain masochism (unless one is deliberately trying to learn a little about assembler coding - although using BGLC doesn't really teach you much about that beyond a few basic principles). Incidentally, this is the reason why it is relatively difficult to lay your hands on a copy of MASM these days and why it is no longer sold as a separate product - not that many people in the programming world have much use for it any more, and those that do usually get a free copy bundled with their C++ development suite anyway.CheersGerrish

[rhumbaflappy 113]

Hi Gerrish.The only advantage of a no_crash library object, would be if it were found that the crash-detect subroutines were causing a large CPU hit.For example, if you were to place 20,000 of your trees from crashless library objects, would they have less of a CPU drag than placing 20,000 from a library object that has crash detection? I suspect the crashless objects would be less of a burden for the sim... but I don't have any idea what the amount of difference would be.Also, there might be the possibility of crashing into invisible objects by fooling with the density-level activation.... a rather evil usage of 'exterior' crash detection. :-wink2 P.S.The whole TMF-TDF BGL creation process would be helped if it were incorporated into SCASM's code. I'm not very fond of BGLC either.I thought an ASM_SCASM translator would be a good idea, especially for GMAX-derived code. Shez, and other Gmax users, are now forced to hack the ASM up to make proper library objects. And George won't be updating Fregen.Dick

[Guest GerrishGray]

Hi DickThe current problem with SCASM is that it has no provision for including a pointer to section 8 structures in the BGL header. If someone could persuade Manfred to do this, then you could provide some SCASM macros for the TMF stuff and it would also be possible to write a BGLC to SCASM translator as you suggest.A BGLC to SCASM translator for non section 8 code shouldn't be too difficult to write though, if somebody has the time and will to have a try ...I believe that the SCASM alternative, FreeSC, actually is able to generate code for any BGL section. I've tried writing to the author, Takuya Murakami, expressing interest and offering to help with the future development/documentation of his project, but have received no reply. Perhaps someone else who knows Takuya better might have more luck? FreeSC also has the facilities you need for writing your TMF stuff as 'SCASM' commands - it's potentially a great alternative to SCASM if Takuya is still interested in developing it. Doug Pouk uses it successfully with FS Architect.Gerrish