VTP code for Bridges :(

[rhumbaflappy 113]

Hi all.The VTP code for bridges is a mystery. You can get bridges to show, but there is little control over type, length, orientation... and even odd bridge segments pop up. I have found length does seem to have a bearing on the type of Autogen used, and they are layer 7.I had hoped this would be simple. It is not. So we wait for the new terrain SDK.Dick

[bob.bernstein 0]

I think it may have something to do with where the road ends show up.B

[rhumbaflappy 113]

Hi Bob.The bridges are VTP lines... but of a new type ( similar to the default FS2002 roads that we never properly cracked ).They are in BGL files that start with "br9", and they will display in TMFviewer. They look to be 2 point lines, but are of a different type then we are using for VTP. They can be exclulded with a VTP exclusion of layer 7 ( same as the new AB...airport skirtings ).They really don't have any connection to the VTP roads.I can almost get them working. :(It's sad, because we could get everything working with about 3 typewritten pages explaining the new changes... but we'll have to wait a year for the SDK to arrive, and then it may not tell us the most current usage. FS2002 roads were never explained in the Terrain SDK... we've just been faking them as shorelines. If we knew the road BGL structure, we could probably guess the format for utility lines and bridges.Hopefully the SDK will be complete this time around.LWM polys have also changed, although our old style still works... and VTP1's have met their demise.All this is fine, but waiting for the SDKs will be torture.Many BGL structures have been changed... runways are noticably different. And all are not decompilable through BGLAnalyze. It's a new format. Although SCASM derived code works ( for the most part ), it will also need a major overhaul.The MS design team has given us a 2 year grace period to get with the new design process. I really hope they give us the level of help they did for FS2002 ( maybe a little quicker? ).Dick

[Guest JR Morgan]

Hi Dick... It's good to see that you're already actively digging-in.Re: Although SCASM derived code works ( for the most part ), it will also need a major overhaul.Have you (or anyone) heard what the SCASM "SetVer(" variable should be for compiling ACOF add-on scenery? One might assume it would be 0x900? But every time I assume, I make an a__ out of me :-).

[rhumbaflappy 113]

Hi JR.Christian Stock has told me the entire BGL structure has been changed for the default FS2004... including the combining of airfield and navaid data, and the loss of the old BGL headers, as well as a new set of instructions ( of which we know nothing ).Our FS2002 sceneries are mostly compatible, so for SCASM, we can keep using 0x800.I'm already reading a few comments about difficulties in getting old runways, ILS, etc.. functional in FS2004. Objects and effects placement should be no problem, but these are changed in default 2004 as well. Thankfully, there is generally backward compatibility.It's going to be a new world, and a new way of doing things. I just hope the SDKs are timely and comprehensive.Dick

[Guest GerrishGray]

Hi guysIt seems that FS2004 is a 'transition version' of the simulator. This impending transition was actually announced in the FS2002 floating point SDK, which seemed to imply that FS2004 would use only the new 'floating point' command set (although that was not what was actually said, if one re-reads the words carefully). In order to maintain previous 'backward compatibility' policies, the transition period has been extended to FS2004. The outcome is that FS2004 actually supports two different formats of BGL file, both using the .BGL extension.[ol][li]There is virtually full compatibility with the traditional format used up to and including FS2002. As a result, scenery can still be created with existing tools and compiled with existing copies of SCASM, BGLC etc. There are one or two exceptions to this, such as AFCAD scenery and some types of VTP. (As regards VTP, it seems that we were exploiting an unintended 'loophole' in VTP in FS2002 which no longer works in FS2004).[/li][li]There is also an entirely new format of BGL whch appears to be related to the RIFF format now used in aircraft models. This new format cannot be created by any existing tools nor decompiled by BGLAnayze, SCDis etc. No details of the new format have yet been published. MS have recompiled much of the default/new scenery into this format, which is why we can't 'read' it with BGLAnalyze etc. Looking at the hex code of these new-format BGLs, it appears that the changes may not be that dramatic - the new code appears to be based on recognisable, known, commands but compiled in a slightly different way, and with a new structure for the BGL header etc. It is fairly certain that this new format uses the 'floating point' command set exclusively, as announced in the FS2002 SDK, but we will presumably have to wait for the FS2004 Scenery SDK(s) before we know the details and get new tools.[/li][/ol]So, for the time being, we can create new scenery for FS2004 using our present tools (and there is no need for a new value for the SCASM SetVer setting etc). In due couse we will doubtless learn more about the new format and tools for creating it ...CheersGerrish

[Guest JR Morgan]

Hi All...I think Gerrish is right because I've tried both manual (scasm 2.88) compile and Apt2.95 build 166 auto-compile (which uses SetVer 0x800, along with setting larger buffers if needed for FP compilation) and they both seem to work OK to install user designed objects in FS9.Although SCASM still "rebels" with an error report for things like setting 'E= nn' (in a RefPt) to a non-integer number, it gladly accepts a calculation within brackets to achieve a floating point user-desired-end-result value if using the bracketed calculation (go figure).So-far (about 4 hours use with installing newly created scenery objects (bldgs, helipads, flashing strings of lights, etc), FS9 is working same as FS8, including usage of exclude bgls created in AFW. 'Haven't tested copying entire FS8 'scenery area' bgls over to FS9 yet.'Noticed a couple of 'oddities' with creation of strings of flashing lights using SCASM DotLine opcode though, i.e. after making a string of Red flashing lights -- depending on your plane's direction while viewing the Red ones, they would appear as white or orange -- almost as if filtered to do that. Viewed farther away, they seem to remain Red. This "psychedelic" effect occurred on an object approx 2 km distant from an orange flashing object within the same LOD area. When viewed from the north (from a different LOD area), the Red was always Red, however as the viewing plane enters the southward LOD and looking over or back at the (supposed-to-be) Flashing Red string, it's color would change to White, then Orange, then Whitish Orange....So far, in FS9, I've not seen any need for a Dummy RotatedCall to preserve AGN --- Haven't had time to test this on ground polygons yet though...And BTW, 'Crash-Detect' no longer has to be turned-on to be able to land Helis on flat roofed AdvBldgs - UNLESS - the bldgs have peculiar logos or fancy architecture (moldings, air vents, etc) installed. In which case, as Dick discovered in FS8, installing a zero-height AdvBldg at ground level and creating an Abs RefPt at roof height cures this 'soft roof' problem and then the 'peculiar' bldg can be landed-on.One very undesirable thing I see in FS9 though is that many, many Instertate Highways are no longer visible in varying mesh elevations. 'Probably a case of M$ getting the product out the door before the VTM code for roads was ready....? This greatly detracts from the VFR experience.And finally, 'sure wish they'd have left a 'Menu-Accessable" path to the Scenery Library... Oh Well -- There's always something.....J.R