Vector autogen bridges in Ground2K scenery for FS2004

[Guest]

Has anyone found out how to make the autogen bridges appear correctly when making new scenery in FS2004? I have been trying to use Ground2K to make scenery, have the ownlines.txt provided by Dick in another thread here installed. The bridges appear, but at least two things go wrong...1. The bridges remain too short (might have something to do with LOD area boundaries?)2. For some of the vector autogen bridge types a small piece of bridge appear at some distance from the intended bridge and at 90 degrees angle to the actual bridge. I have tried to make the bridges just as a straight line (same settings in G2K as for roads, expect for the line type number) with a starting point and an end point and also to make the line end with two adjoining points (this cause the bridge to look very complicated, though :) )BamceEFHN

[rhumbaflappy 113]

Hi Bamce.I don't think anyone has done it yet.We need a new macro. In order to get that, we'll either have to wait for the SDK ( and hope it's in there ), or experimentr with a hex editor on a file that has only one or two bridges... and substitute values until we understand the structure ( just like Christian stock and I did for the original LWM code ).Another possibility is to place them as objects. They actually are library objects, with GUIDs described in the terrain.cfg file.Dick

[Guest]

I successfully created one by hand, but it took a lot of trial and error.I used my Coast-Line-Maker to lay down a two-point segment, then hand edited the ASM code to change the layer number and texture to that for the appropriate bridge.However, I initially noticed the "spare" bit of bridge some distance away that you mentioned, plus some extra ramps at the ends. The bridge was not only shorter than the segment, its endpoints were quite far from where they should have been.A two-point segment becomes a 5-point segment in the ASM file, and I hand-edited this to a 3-point segment (1st dummy point, 1st real point, 2nd real point) and this got the bridge to look OK, and eliminated the spurious bits.With further laborious trial-and-error, I eventually got the endpoints to where they should be, but it was quite a long way from the expected VTP co-ordinates.Never thought it would be easy ...Cheers,Iain.

[Guest JR Morgan]

Gentlemen: I know it's in all our best intrests to develop routines in programs like Coastline maker and Ground2K type programs to do vector bridges and/or other objects. Meanwhile, for us lazier 'SCASMese' types, here are 2 bridges made with simple SCASM api macros (inspired by Dick Ludowise), using AFW 2.95 build 166 as a GUI, allowing quick/easy placement of AGN bridge segments (or any AGN objects with known LibObj code Id's wherever needed:The api macro:;SCASM api Macro to place FS9 Autogen objects using AFW GUI 3D object placement routine.;The 4 (%6-%9) hex 'words' comprise the LibObj ID string. Macro by J.R. Morgan Jr; ;Copyright SCASM by Manfred Moldenhauer;Macro inspired by code examples by Dick Ludowise Area( A %1 %2 %3 )PerspectiveCall( :_object )ShadowCall( :_object )Jump( : ):_objectMif( %11 )RefPoint( Abs :_Fail %4 %1 %2 E= %11 V1= 6000 V2= 100 )MelseRefPoint( Rel :_Fail %4 %1 %2 E= %11 V1= 6000 V2= 100 )MifendRotatedCall( :RO 0 0 %5 ):ROCallLibObj( 0 %6 %7 %8 %9 );CallLibObj( 0 51AA12D6 49E6AE0F BC6D16A9 02F41CD8 ); i.e. Typical resulting format of Call:_FailReturnEndAJ.R

[Guest GerrishGray]

Actually, placing the bridges with a SCASM macro as JR suggests is probably a much easier and more reliable approach than doing it via VTP lines. MS developed the VTP method to suit their automatic generation of the default scenery, but it caused them quite a bit of difficulty with bridges that did not appear correctly, just like the problems reported earlier in this thread. In fact there are still a few 'broken' bridges around the default scenery if one searches carefully. Placing the library objects 'direct' is likely to be far less error prone for the individual scenery designer.If you don't mind me saying so, the proposed macro code could do with a couple of tweaks though ... it should actually look like this for maximum efficiency:-Area( 4 %1 %2 %3 )PerspectiveCall( :object )ShadowCall( :object )Jump( : ):objectMif( %11 )RefPoint( Abs :Fail %4 %1 %2 E= %11 V1= 8000 V2= 100 )MelseRefPoint( Rel :Fail %4 %1 %2 V1= 8000 V2= 100 )MifendRotatedCall( :RO 0 0 %5 ):FailReturn:ROCallLibObj( 0 %6 %7 %8 %9 )ReturnEndAAlthough the macro allows for automatic elevation placement in the usual way, it will probably prove better, in the case of bridge segments, to specify the required absolute elevation AMSL in order to make sure that all segments of the bridge are correctly placed at the same level.CheersGerrish

[Guest]

Hi Gerrish I noticed that your "V1" value is 8000 meters do you findthat's a good value for things like bridges? Dan

[Guest GerrishGray]

Hi DanYes, I would always use at least 8000 or maybe a little more. Features like bridges should be visible from at least 8km away - and should normally be displayed successfully at that range by FS with reasonable display settings - so it doesn't seem sensible to cut them off as close as 6000m. Actually, if the macro is going to be used with programs such as AFW one can use the parameter %10 in place of the fixed 8000 value and allow the user to set the visibility range they prefer. But I would always recommend at least 8000m for objects as prominent as bridges.CheersGerrish

[Guest]

10-4 in fact I thought that 8km was a little low as well. Dan

[Guest JR Morgan]

Thanks for the tips Gerrish. The thing I usually do is to set V1 * V2 based on testing in the scenery and set the lowest possible values that yield visibility 'typical to the area'. The 2 bridges in the example I posted are not very 'prominent' bridge types, i.e. no high suspension structure, etc. As a matter of fact, I didn't see any such bridges in the FS9 examples with GUID codes published, although I've not tried every example yet.The thing I really wanted to do was to develop a macro using TransformCall so that an entire bridge could be drawn from one Area/RefPt callout instead of having to iterate same for each of a bridge's center spans and end objects. So far, in my testing, that approach is not working -- each lib object is 'paying no attention whatsoever' to X,Z,Y offsets. I know you do this with trees, but I think your trees are your own creation original lib objects. If you come up with a trick to do this with M$ lib objects, I'd sure like to learn that one.Finally (and most demoralizing) is the insatiable desire to create that pylon with the erect middle finger as you mentioned on another post --- But at my age, and with a 'nuked' prostate, I can't seem to get anything erect...J.R

[Guest Ideas]

TMI(Too Much Information)

[arno 1]

I did a little test and I can translate my library object without a problem with a TransformCall. So I guess it should work.

[Guest JR Morgan]

Hi Arno... Yes, I can translate "My" multiple library objects also, but the problem I'm having is with (multiple) FS9 default AGN objects i.e. bridge segments, light poles etc. Are you saying you've tested translating multiple FS9 AGN objects and your SCASM transform call code works to do that - or are you saying you're translating your-own non FS9 AGN objects within one macro?I can put the FS9 AGN lib objects wherever I wish using a seperate macro for each object, but so-far, not successful to place an entire bridge comprised of say 12 seperate segments or an array of light poles, etc, using only one transform call macro. Obviously, MS is doing it with bglc -- I'm looking for a way to scasm'ize it...Thanks J.R

[arno 1]

Hi JR,I tested translating another library object, not a MS autogen object. But if you now the size of the segment you are using it should be a troubled should it?I don't think MS did the bridges with BGLC, as they are generated from VTP lines it is something hardcoded and is not necesairy that they use the TransformCall command.

[Guest JR Morgan]

Hi Arno...Re: "if you now the size of the segment you are using it should be a troubled should it?"**The format of the bridge objects in Terrain.cfg file may be VTP lines (I don't know).The Terrain.cfg default size of these lib objects can be scaled with no problem in a user macro. The bridge objects in Terrain.cfg are merely segments of bridges and bridge ends -- not complete bridges.These segments are easily arranged into a complete bridge by using a macro for each segment (See pictures I posted). However, the thing I'm trying to do is to displace these segments with respect to one macro's RefPoint using transform call. It seems to me it should be possible. BUT; so far I've not been able to do it.Rotated calls of single segments (or objects) work just fine but transform calls to place an entire bridge comprised of many segments or the ofsetting of even one segment from the RefPt isn't working for me yet. ---'There's gotta be a way.J.R

[Guest GerrishGray]

Hi JRPost an example of the code you are using with TransformCall() and I'll see if I can solve the problem for you ... :-)CheersGerrish