Can SCASM Library Objects be Called from FS9/FSX XML?

[gadgets]

(Doesn't seem to work for me.) If so what do I need do to make it happen, please.

Don

 

[NoNewMessages]

Working from a foggy memory, but everything I can recall is that library objects must be MDL based or FS9 or later.

A search at the F1 Instant Scenery sub-forum *should* offer up confirming comments.

 

[GaryGB]

Hi Don:

As you may know, the legacy SCASM / FSReGen 3D model and "library" macro format and related coding is distinct from that of the BGLComp XML format used for FS9 / FSX libraries and related coding ...as alluded to in these threads:

http://forum.avsim.net/topic/77904-adding-new-objects-into-library/

http://forum.avsim.net/topic/78820-adding-objects-to-the-library-list-for-use-with-xml/

http://www.flightsim.com/vbfs/showthread.php?141043-Hangars-and-List-of-Library-objects

http://www.fsdeveloper.com/forum/threads/preparing-airport-for-the-future.2244/#post-13614



If for no other reason than curiosity and a brief walk down memory lane, you might find this mini-tutorial and those linked at the bottom of its web page (including how to place newer BGLComp XML-based MDL library objects via SCASM ) somewhat interesting:

http://www.flightsimworld.com/kb/idx.php/0/032/article/Creating-a-Library-of-API-Objects.html


Generally speaking, it seems that the legacy SCASM / FSReGen objects must be converted into MDLs first before they can be compiled into / called from BGLComp XML FS9 / FSX format libraries.


It has been my observation ModelConverterX (purposely ? ) persists over the years in refusing to properly deal with import and conversion of legacy objects utilizing certain BGL OpCodes and/or certain FS internal variables for conditional display.

AFAIK, one may be more successful with conversion / utilization of such legacy objects via:

1.) De-compilation of BGLs, APIs, or SCMs to intermediate *.SCA SCASM source code

2.) Disabling of all or most traceable conditional display subsections in the (tens of thousands of lines of...) SCASM code

3.) Creation of legacy format compiled *.API macros with 'dummy' headers and RefPoints as to geographic coordinates

4.) SCASM *.API's can then be converted via ex: MCX to BGLComp compatible MDLs / XML library structures (with updated format GUIDs as needed) prior to placement.



However, there "may" be a way to do what you are referring to, depending on what legacy objects are to be placed via (what the author describes as...) "XML" code:

http://www.flightsimworld.com/kb/idx.php/13/024/article/Placing-3rd-party-Macros-with-XML.html

[EDITED]

BTW: Given some of the issues we are currently working through with undesired run time offset of displayed Effects (attached to MDLs or otherwise placed directly) relative to legacy FS 3D world model versus FSX P3D "curved earth" FS 3D world model and/or P3D Tesselation, batched texture draw calls etc., I found this 'brute force method' implementation of "<BiasXYZ" used for achieving specified placement of Effect lights interesting (...for at least a "temporary" workaround ? ):

http://www.fsdeveloper.com/forum/threads/blinking-lights-timers.762/

[END_EDIT]


Hope this helps !

GaryGB

 

[gadgets]

Thanks, guys. I appreciate the differing file formats. I trying to see if I can offer SCASM lights as an alternative in AFLT. (Apparently, SCASM lights - at least in some configurations - still work with P3Dv2 whereas I've confirmed that BGL_LIGHTs and effects controlled by BGL coding don't.)

It's basically just the LIGHT command that I'm interested in. The models themselves (to which the light is attached) display just fine.

Hopefully, MCX won't simply convert SCASM lights to BGL_LIGHTs, because I already know they won't work.

Don

 

[scruffyduck]

I am not aware of any way to use model formats other than mdl directly with BglComp. I think they need converting first.

 

[GHD]

They work fine but there may be problems with textures.

 

[GaryGB]

Thanks, guys. I appreciate the differing file formats. I trying to see if I can offer SCASM lights as an alternative in AFLT. (Apparently, SCASM lights - at least in some configurations - still work with P3Dv2 whereas I've confirmed that BGL_LIGHTs and effects controlled by BGL coding don't.)

It's basically just the LIGHT command that I'm interested in. The models themselves (to which the light is attached) display just fine.

Hopefully, MCX won't simply convert SCASM lights to BGL_LIGHTs, because I already know they won't work.

Don

Hi Don:

I never quite understood whether the "Light Point" objects Richard Ludowise (aka "rhumbaflappy") created using *.ASM code were calling BGL_Lights or not, and whether another set of such objects could be created in differing sizes, but perhaps this might be another pertinent stroll down memory lane:

http://forum.avsim.net/topic/296289-looking-for-some-light-balls/

http://forum.avsim.net/topic/296289-looking-for-some-light-balls/page-2


"The light "objects" are the same as the SCASM code you are thin(kin)g of... just coded in BGLC. Can be made as FS9 library objects and called by xml placement."

http://www.fsdeveloper.com/forum/threads/street-lights-like-ultimate-terrain.6674/


PS: Some ideas and caveats on this topic by Jim Robinson:

http://www.fsdeveloper.com/forum/threads/simple-red-light.427411/


Hope this helps a bit more !

GaryGB

 

[gadgets]

Thanks Gary, et al. I've tried converting the SCASM file with MCX. It does convert. However, following conversion we have an empty (FS9 or FSX - user's choice) object with a single attached effect. MCX even creates a correctly-colored .fx file for you (a modified obs_light2.fx). Unfortunately, since the effect has to be conditioned by BGL code (and therefore won't work with P3D) in order to fulfil its purpose as other than an omni-directional light source , I guess my AFLT users will have to be happy with FS9 and FSX compatibility for the time being - until LM announces replacement technology.

I have a feeling, given LM's apparent disregard for legacy technologies, FSX and its other derivatives still have a long life ahead.

Don

 

[gadgets]

As many of you know, I'm not one to give up easily. If you can't "get Mohammad to the mountain", try "bringing the mountain to Mohammad".

P3Dv2 will display SCASM lights and, presumably many other SCASM objects IF the placement code is also SCASM and the altitude is specified absolutely.

I suspect this shouldn't be too surprising because CVX files are, essentially, SCASM code with altitude specified absolutely. Using AGL elevation almost works. You can see the lights while the sim is loading but, at the very last moment, they disappear, suggesting an intentional override.

Whether or not I can control those lights using SEPARATION_PLANEs remains to be seen, but I thought my finding was newsworthy in itself.

Don

 

[GaryGB]

Hi Don:

Would I be correct that when you use the terms "altitude specified absolutely" you are referring to elevation / altitude relative to Mean Sea Level (aka "MSL") being used in the SCASM code (and NOT altitude Above Ground Level (aka "AGL") ?


Also, since others here have previously discovered some quirky behavior when using integer (rather than floating point) and certain numeric value ranges in SCASM source code with degrees of "RWY Heading", might "Altitude" be yet another parameter where a floating point value (to a specified number of decimal places) needs to be utilized ...in one's parameter value units ?

http://www.fsdeveloper.com/forum/threads/scasm-lights-kill-my-fps.21793/

http://www.scasm.de/doc/sca_s16.htm#mb

http://www.flightsim.com/vbfs/archive/index.php/t-140624.html


Thanks in advance for your clarification, and for the update on this interesting endeavor !

GaryGB

 

[gadgets]

Would I be correct that when you use the terms "altitude specified absolutely" you are referring to elevation / altitude relative to Mean Sea Level (aka "MSL")

yes

Also, since others here have previously discovered some quirky behavior when using integer (rather than floating point) and certain numeric value ranges in SCASM source code with degrees of "RWY Heading", might "Altitude" be yet another parameter where a floating point value (to a specified decimal places) needs to be utilized ...in one's parameter value units ?

Perhaps. But, at this point, I suspect not. In fact, the AGL/MSL discussion now seems to be a "red herring". The problem I discovered only a couple moments ago is that visibility of SCASM Lights is severely limited in elevation. The light is visible only so long as the view point is < 10-15 degees above. Above that, the lights seem to disappear into the ground/runway. (What started as a circular light dot develops a flat bottom that progresses upwards until the entire dot disappears - as if being lowered into a plane.) There seems to be no limit below. Lights placed AGL are in fact visible. But to see them you've got to be very low. Only P3Dv2 exhibits this behavior. FS9/X seem OK.

So, I'll return to the issue tomorrow. In the meantime, if someone can comment on the visibility issue, that would be helpful.

Don

 

[GaryGB]

Hi Don:

Possibly you've seen these links from a Google search ?

https://www.google.com/search?q=SCASM BGL_LIGHT altitude visibility site:www.fsdeveloper.com&biw=1138&bih=570&sa=X&ei=6fkrVObdKYOTyQTbxIIo&ved=0CCoQrQIwAA


I was particulary intrigued by Thorsten Reicherts findings implicating DX-10 mode:

http://www.fsdeveloper.com/forum/threads/ref-points-visibility-and-tweaking.18436/



One might wonder if this has already been "fixed" by means of a custom "lights" Shader tweak via DX10 Scenery Fixer by Steve Parsons (aka "SteveFX"), or if another modified Shader may be needed as a temporary workaround until LM further modifies its code base for such "light" display issues.


Steve apparently has recently (Sept. 2014) resumed development and support for his brilliant DX10SceneryFixer:

http://forum.avsim.net/forum/644-the-official-dx10-scenery-fixer-support-forum/

http://www.flightsimstore.com/product_info.php?products_id=2630


Steve's freeware "DX10 Shader Fixes" which preceded the current payware version (which offers more features):

http://library.avsim.net/esearch.php?CatID=fsxmisc&DLID=185080


"Steve's FSX Anaysis" Blog:

http://stevesfsxanalysis.wordpress.com/

Some posts regarding fixes for "light" display issues:

http://stevesfsxanalysis.wordpress.com/category/nav-lights/

http://stevesfsxanalysis.wordpress.com/category/uncategorized/

http://stevesfsxanalysis.wordpress.com/2014/06/

[EDITED]


BTW: As you may know, Lockheed-Martin posted some interesting info on the more recent DirectX-10 implementation (originally it was DX-11 only) for Prepar3d version 2 et seq. (aka "P3D v2.x"), and has described some DirectX version-specific functionality issues here:

http://www.prepar3d.com/SDKv2/LearningCenter/getting_help/getting_help.html


MSFS users, and especially P3D users running on Windows 7 may wish to ensure that they have less problematic DirectX 10 and 11 driver updates installed and optimally configured:

http://www.fsdeveloper.com/forum/threads/win-7-directx-updates-and-fixes.427758/

[END_EDIT]



And of course one might also wonder whether there might be yet another obscure, poorly documented (or un-documented) consideration to be addressed in one's SCASM source code that works around such display issues which can be reliably used in FS development via tools such as you are so graciously providing to the FS development community.

Thanks again for your ongoing efforts; hope some of this info might prove helpful !

GaryGB

 

[gadgets]

Thanks for all the extra suggested reading, Gary. I had seen most of it. At this point I have looked at every item that pops up on a Google search of "SCASM light" and SCASM P3D". I've thoroughly searched the fsDeveloper and P3D forums as well as those at Avsim and Flightsim. Not very much that has been helpful. It seems I am pioneering this issue.

I have confirmed that I can place a SCASM light in P3Dv2 using SCASM positioning (but only with SCASM positioning). However, the light dot is only visible at shallow angles from above. At about 10 degree above, a horizontal cut-off line develops at the bottom of the light dot and progresses upwards as the vertical angle increases. By about 15 degrees, the light is completely gone. It's as if the light is disappearing into an invisible box. There does not seem to be any issue from below nor from the side. Other than from above, the light remains visible irrespective of the direction from which it is viewed.

I have adjusted every P3D scenery/display slider/checkbox I can find. Nothing seems to make any difference.

Unless someone can point me in the right direction, it looks like I've reached the end of my exploration to bring SCASM lights (which seem to have a much greater range than either BGL_LIGHTs or effects) to AFLT. They would have been perfect for PAPI/VASIs.

Don

 

[GaryGB]

Hi Don:

I am wondering if you've seen this post:


http://www.fsdreamteam.com/forum/index.php?topic=10244.0



"virtuali
Administrator
Hero Member

Posts: 16801


LSGG Runway Lights in P3D 2.2

« Reply #1 on: May 05, 2014, 04:30:57 PM »
Quote from: Flightpumpkin on May 05, 2014, 04:20:51 PM

Where do they come from?

In the LSGG_Papi_SC.BGL file. It's a SCASM file, so you can't edit it with an AFCAD editor. The (P3D) 2.2 version supports this kind of lights correctly, so there's no need to edit anything."


NOTE: Product Page: http://www.fsdreamteam.com/products_geneva.html


Perhaps Umberto Colapicchioni (aka "virtuali") might share some insights here at FSDeveloper on how to make such lights work in P3D v2.x ?



FYI: This scenario is rather intriguing, and you may indeed be among (very ?) few 'pioneer' developers for P3D.

Although I had initially planned to begin development of another version of my projects for Prepar3D this year, I have been waiting for the LM P3D 2.x code base to stabilize, and for resolution of various as yet un-fixed and/or missing features (already otherwise working in FS2Kx and FSX) ...to become fully and properly implemented into P3D.

In "light" of this thread and substantial other end user feedback over this last year making it evident that P3D may still not yet be "ready for prime time", I have further postponed my plans for P3D development, and would thus not be available to personally test anything on P3D until I acquire a more well-developed and full-featured Prepar3D ...which can genuinely function as something more than a IMHO "Release Candidate paid for by the end user".

I hope we might see more FS Developer community participation in this and other threads as the Winter months approach; to me it seems we are still in the tail end of the 'Summer doldrums' (even though MSFS colored trees tell us we have now transitioned into "Fall").

I'll keep a eye open for additional ideas on this scenario of using SCASM lights in P3D 2.x, and will post more here when I find anything reasonably pertinent which might provide some new insights and solutions, as I too would plan to use as much "legacy" code as possible when I finally do port my projects for additional use within P3D.


And of course, I'll be closely watching the end user feedback on P3D v2.4 to see if the latest version may be less demanding on my limited available time and patience, considering my existing real world commitments and workload with ongoing development of new content for FS2Kx and FSX.

GaryGB

 

[GaryGB]

Hi Don:

I was looking this info over again today to refresh my memory on what it was dealing with in regards to RWY Heading parameter values in SCASM source code having an impact on FSX SP2 performance.

This is just a "shot in the dark" (pun intended ), but I noted that an associated FS run time display anomaly accompanying the FPS hit was reported to be SCASM "lights".

So I thought it might merit mentioning this linked thread again as a possible avenue to be explored in your ongoing efforts to fully utilize SCASM lights in MSFS SP2 and P3D 2.x in ex: AFLT.


http://www.fsdeveloper.com/forum/threads/scasm-lights-kill-my-fps.21793/

I found it intriguing that Jim Vile mentioned he was able to change the run time anomalies seen when displaying such SCASM-coded BGLs (with "incorrect" Headings in the SCASM source code) when he stated:

"you have to turn off Aircraft cast shadows in the (FSX SP2) Display Options (DX9)"

...and:

"The FS2004 AI Planes ported over to FSX become invisible and the only thing that shows are the aircraft lights."


When the OP of that same thread above wrote the wiki on that topic here at FSDeveloper, he stated:

http://www.fsdeveloper.com/wiki/index.php?title=SCASM_Runway_Overlays

"SCASM created runways have the problem that FSX/P3D AI traffic (with FS2004 native models) disappear when the "Ground cast scenery shadows" is activated in the preferences. No workaround exists at the moment.

AI Traffic with FSX native model does not suffer of this problem."


IIUC, SCASM lights associated with a SCASM RWY display as "too big" ...and legacy AI aircraft 'disappears'.


FYI: This anomaly can also be seen in FS9 with Multi-player aircraft (essentially another instance of AI aircraft) on certain legacy coded FS2002 or FS004 sceneries (ex: on the RWY in LAGO's Georender "Darrington" when "Ground Shadows" are left globally enabled in the FS9 GUI (despite the author's caveat in "The Manual" ...to disable them. ).


One might wonder whether this anomaly can also be eliminated in one's source code by utilizing a "Suppress Shadow" technique in legacy aircraft MDLs being used (obviously impractical to do), or alternatively via use of obscure SCASM / ASM "tweaks" in scenery coding ...as you discussed here:

http://www.fsdeveloper.com/forum/threads/invalid-texture-size-missing-aircraft-shadow.23147/

http://www.fsdeveloper.com/forum/th...autogen-suppression-shadow-flickering.428636/


...and as (others) discussed in this thread:

http://www.fsdeveloper.com/forum/threads/flatten-problems.15791/



In the case of P3Dv2.x, this thread discussing aircraft shadow display anomalies raised some questions about cause / effect / how to prevent such aircraft shadow display anomalies ...with Ground Polygons:

http://www.prepar3d.com/forum-5/topic/aircraft-cast-shadows-on-ground/


Since IIRC, P3D's Tesselation reportedly "breaks" DrawCall Batching, and also causes Effect display positioning (offset) anomalies, one might wonder if here are other associated code 'work-arounds' that work in FSX SP2 which might be further tried for P3D ...to achieve consistent display without performance penalties or other "gotchas" when using SCASM-coded Ground Polygons, RWYs, and lights ?


Some other hits on the subject of aircraft shadows:

https://www.google.com/#q=Aircraft cast shadows

[EDITED]

PS: I'll have to refresh my memory on how you and Arno are coding G-Polys via your respective methods, but perhaps the info in this thread might merit further consideration with regards to how one "textures" SCASM objects:

http://www.fsdeveloper.com/forum/threads/flatten-problems.15791/

"For some reason 'TexPoly' on TexPoly works fine but VertexList on TexPoly causes flickers."

NOTE: IIUC, the above posted description of "flickers" infers that the cited SCASM "TexPoly" method may have used "Points" (deprecated for FS200x versions) to define vertices when creating Ground Polygons.

A FSDeveloper wiki shows a SCASM code tweak for flickering Ground Polygons created using "points":

http://www.fsdeveloper.com/wiki/index.php?title=Flickering_ground_polygons_fix_(SCASM_tweak)


The SCASM online docs state that VertexList replaces the "Point" command for FS200x:

http://www.scasm.de/doc/sca_cmd5.htm#vtls

"VertexList( 0 <vertex_0> ... <vertex_n> )

This command replaces the old Point command. All values are floating points."

Of additional note is that objects defined using VertexList can be "Scaled" via an additional Transform_Mat() command, and have a "Normal vector" which can be used for color shading.

An alternate input format to define the 'Normal Vector' requires a <elevation angle> and <heading angle>; I presume that the latter "<heading angle>" should properly be entered as a Floating Point (aka "non-integer") parameter 'value' ...subject to the same considerations of Degree range formatting as already discussed above for RWY heading to minimize risk for FS run time dispaly anomalies and/or performance issues:

http://www.fsdeveloper.com/forum/threads/scasm-lights-kill-my-fps.21793/


Points:
http://www.scasm.de/doc/sca_cmd3.htm

TexPoly:

http://www.scasm.de/doc/sca_tply.htm


NOTE: Interestingly, with TexPoly, both Brightness and Color shading can also be done via (accompanying) TexPolyShading:

"This instruction sets the shading intensity of building bitmaps (side#.R8) in conjunction with textured polygons ( TexPoly( ) ).

This shading requires a special prepared bitmap file with 8 areas one for each of the 8 intensity steps).
and a special prepared bitmap file with 8 areas (one for each of the 8 intensity steps)."

http://www.scasm.de/doc/sca_tply.htm#tpsh


BTW: FSX still supports *.R8 texture files, and has 138 such default FS files:

* 8 of which are named in a "side#.r8" series

...and as you may already know:

* 10 of which are named in a "runway0#.r8" series


http://www.fsdeveloper.com/forum/threads/texture-formats-and-conversion.425132/

http://www.fsdeveloper.com/forum/threads/afcad-texture-layers.7932/

http://www.fsdeveloper.com/forum/threads/harden-a-runway.428345/

http://forum.avsim.net/topic/279498-afcad-texture-mapping/

[END_EDIT]


FYI: IIRC, Richard Goldstein (author of the "Georenders" and many other excellent legacy-coded sceneries) once stated that when SCASM "TexPoly" methods were used, there was virtually "no limit" as to the resolution of textures which could be displayed in FS at run time (despite limits otherwise imposed on (FS2Kx) texture display resolution via 'default' FS SDK methods using ex: Resample).


Hope this info might help a bit more with successfully implementing SCASM coded lights.


PPS: All the above pertains to MSFS DirectX-9, and P3D DirectX-11 (or the new DirectX-10 mode option).

One might wonder if "Shader mods" might be applicable for fixing such anomalies with DirectX-9 in a manner comparable to what apparently is being achieved to fix anomalies with DirectX-10 ?

http://forum.avsim.net/topic/468031-ground-scenery-shadows-vs-building-flicker/

GaryGB

 

[gadgets]

Thanks for the info, Gary. But, I'm not using SCASM lights for AFLT is P3d. I'm using the stock models as SimObjects with attached effects.

I've finished the development during my absence over the past 5 weeks. Just got back, so still don't know about the FPS impact. But, I suspect it won't matter. I have been unsuccessful in creating AFLT lights for P3Dv2 using any other technology. So if somebody wants 3D-model lights in P3D, I see no alternative at the moment.

Don