looking for a landclass ID

[Guest Hugo]

Hi Guys. Sorry for the late reply. Wasen't realy feeling too great yesterday. Things are picking up now.Dick, Thanks for this info about seasons.bgl. New to me as was worldlc.bgl Luis suggested. If, as it appears, FS gathers its seasonal infos through this file. I assume (presume?) it fetches those for the area it is presently in, to some address that could be peeked in.Eventhough I'm convince of that, doesn't mean it is a fact! Yes, I can be kinda stubborn at times ;-)In any case, I do have an alternative way up my sleeve, though, brutal as it may be, can do the job. I will expose it in a separate message. Thanks for bringing up the matter though. Most probably your xth time in this forum ;-)Luis,"I have never tried modifying the seasonal changes for ground polygons (seasons? what seasons? It is always hot here!)." Which indeed, not being realy personaly concerned, renders your help that much appreciated here :-)" You could try modifying the seasons assignments (seasons.bgl) in your area, although I am not sure if this will solve your problem "Actualy, I realy don't want to do this :-)" Christian Stock wrote up the procedure for this in his Terrain Model File Manual "Oups! I overlooked this part when I red your message yesterday. I just downloaded it now and had a qwick peek through. Lots of stuff in there!. Too early for me to comment untill I take time to read it at my own pace, which, at times, may not the fastest around!! Edgar,Your post is as timely as I may had wished in my wildest dreams :-)Indeed, I do have asm files Ground2k program folder. Actualy 2 of those; Ground2K4$_Poly_LWM.asm and Ground2K4$_VTP2.ASM. I already had to look at those and realized they were the equivalent api files for scasm (through Airport). As you suggested, I used LWMViewer and disassembled the bgl file through Export/Source function (hope it's the right way to do it) that yielded a .asm_VTP000.bgs file that is quite similar to Ground2K4$_VTP2.ASMBut (there's always a 'but'), I ain't got the slightest knowledge on how to compile/recompile an asm files with bglc, let alone coding/recoding them.As mentionned earlier, I will post a document for a proposal on how to modify an api files to syncronize one's own seasonal textures with FS's in a scasm compiled environment. I should posted it the latest by noon tomorrow, wednesday 24th.Hopefully, it will be possible to implement the technic into a blgc compiling environment.Thanks to all of you for your concern and participation.Hugo

[Guest Hugo]

Ok Guys. As mentiond in my last post, I will propose here a solution to a glitch that happens when one produces a seasonal texture on scenery objects and/or ground polygones. Namely, a lack of synchronism between the moment of th year a seasonal texure, be it applied to an object surface or to a ground poly, appears in FS and the moment FS's own seasonal textures do.This discrepency is more obvious during the change from fall to winter and from winter to spring and I'm leed to think, more profond the further north of the equator one's scenery is located up to a certain lattitude where winter is present almost year long, in the north hemisphere. I asume, but I have not checked, it the same stands for the southern hemisphere. I leave to each scenery designer the task to determine if it's own scenery area would benifit from the solution I will be bringing here. To precise my thought, I will refer readers to view (or review) an image I posted earlier in this thread; http://forums.avsim.net/user_files/124954.jpg. At the bottom/left of this image, one can see how the grass (textured on the top surface of thin box made with FSDS2 if I recall well) and the trees, produced with EDO in this instance, show when the sim is run on december 21. Fall textures! In the backgound though, one can see FS is showing winter texture and has been since november 21, a 1 month difference in this particular case. To the right, the same view taken december 22. Now everything's finaly in line at last!! Now, this object winter textures will last till march 20 when they will take their spring livery. But FS spring textures won't show until april 18!! In the same image, above/left, you can see a grass ground texture I produce lately using g2k, taken mid july. It shows as it should. But the center part shows how the same texture looks on may 5. It will remain as is until may 19!! But FS's spring texture have been active since april 14 in this area too. On the other end, this winter texture will show on october 19 while it's not until november 21 FS will apply its own!!If one uses G2K to produce his seasonal ground polygons and uses a scams compiled tool to make for its seasonal object textures, he is bound for a shock, at least in this area for shure but, I presume, in many others as well!!At this very moment, the solution I will bring forward, is oriented to those who are still using scasm base tools like EOD and FSDS2, with the hope though, the technic will be adapted to bglc compiler, a language and environement I presenly know noting about, by someone who does. Ground2k is a bglg compiled tool and I would think SBuilder is too. One last thing before I get into the hart of the matter. I'm not by any means a programmer nor am I scasm guru. My programing knowlegde is limited to some MSBasic I stop using 10 years ago with the advent of Win95 and Excel. So the scasm coding I will propose might be perceive as somewhat... well, brutal! If someone can acheive the same in a more efficient/elegant way you are most welcome. Don't worry, I won't take it personal ;-)Here goes...In a first instance, I will use EDO as a working tool because it already has a seasonal texture capacity, but with the aleas mentionned above. Later I will show how to adapt it to FSDS2 which, surprisingly, lacks this feature as well as the rotate to aircraft function, but that's an other matter. I will proceed with a simple example, a vertical season textured wall but the technic is applyable to as many object surfaces of any complexity one may which.Before anything, one should determine for the scenery area he/she is working in, the dates of the seasonal changes as FS applys it for this specific area. It dosen't appear at this moment it is possible to peek an internal address FS would fetch a value (0, 1, 2, 3 or anything else) related to the area.The way I do it is to put myself in top view and and change the flight date to about when you expect the seasonal change occurs. And retry around this date until you see going one day to the next brings an pbvious change to the gound texture. Note de later date of the last 2. Do the same for all seasons.Now we need to translate these dates into day of the year value. For the area I choosed, FS winter starts november 21 (day 325), spring - april 18 (day 108), summer - june 19 (day 170) and fall - september 20 (day 263)These values are only good for the are I'm putting my scenery in and its vicinity. They may differ widely within your own area.For the exercise I will use 4 simple 256x256x256 bmp files colored white(for winter abcd_wi.bmp), yellow (spring - abcd_sp.bmp), green (summer - acbd.bmp) and brown (fall - abcd_fa.bmp). Save them into a proper texture folder. Now its time to make the seasoned textured wall with EDO. Here I will set a 5m x 5m vertical wall facing south and check the approriate season texture In the texture window.I save this object as Seaswall and produce the api file.Now using notepad we will edit the api file.Using Edit/Find function I search for the following text; LoadBitmap( 0 WFS6 This bring us to the section we want to modify that should look like so;LoadBitmap( 0 WFS6 EF 0 0 0 "abcd.bmp" )TexPoly( 0 0 -32767 0 0 34 0 1 34 245 2 238 245 3 238 0 ) ;FrontReturnNow we will delete and replace this whole section by the following;IfVarRange( :COND2 38A 108 169 )LoadBitmap( 0 6 EF 0 0 0 "abcd_sp.bmp" ) TexPoly( 0 0 -32767 0 0 34 0 1 34 245 2 238 245 3 238 0 ) ;FrontReturn:COND2IfVarRange( :COND3 38A 170 262 )LoadBitmap( 0 6 EF 0 0 0 "abcd.bmp" )TexPoly( 0 0 -32767 0 0 34 0 1 34 245 2 238 245 3 238 0 ) ;FrontReturn:COND3IfVarRange( :COND4 38A 263 324 )LoadBitmap( 0 6 EF 0 0 0 "abcd_fa.bmp" )TexPoly( 0 0 -32767 0 0 34 0 1 34 245 2 238 245 3 238 0 ) ;FrontReturn:COND4LoadBitmap( 0 6 EF 0 0 0 "abcd_wi.bmp" )TexPoly( 0 0 -32767 0 0 34 0 1 34 245 2 238 245 3 238 0 ) ;FrontReturnAfter having made the mod, I save the api file back. It's now fit to be insert as 3D object in airportor its equivalent in FSSC or other scenery assembler tools.*** Note: The WFS6 entry originaly present in LoadBitmap line as been replaced by a single 6 entry ***Some explanations on what happens here. I will let Manfred Moldenhauer, author of Scasm do the talking, a moment: from scacmd2.docIfVarRange( :Label ____ Var minval maxval )-The contents of the FS variable Var is tested. Ifthe value is within the range of minval and maxvalthe execution is continued with the next command.Otherwise a jump to :Label is performed.- Var ____ FS variable number in HEX.minval minimal allowed value (decimal/or 0x. hex) maxval maximum allowed value (decimal/or 0x. hex)*Edit; I added the underscore above*Lets apply this to the first occurance of IfVarRange above.38A is the tested Var. It is the memory location that contains the day of the year FS is presently at.So the first line checks if the value at this location is within the range 108 and 169, the spring season in this case.If it is, it executes the the command on the following 2 lines, that is, it applies the spring texture to the wall and returns to the execution of the main program.If it is not then it jumps to the label address supplied ahead, :COND2, in this instance, where it will check again, this time, for summer, if not will check for fall and if it isn't it either will apply the winter texture to the part as all other possibilities have been evaluated and found negative. This way we are now shure the seasonal textures are applied in synchornisation with FS.Now this is a very simple scenery. In a more complex one there might many more texture surfaces that would as many modifications. This thing can be done relativaly fast using the copy/paste function of notepad and just editing the entries that needs it, namely ; the name of the texture files and the name of the labels.For example for the next LoadBitmap( 0 WFS6 entry, I would have copy the whole modification text above and paste it in replacement and edit :COND2, :COND3, :COND4 entries to become :COND21, :COND31, :COND41. For another entry it would be :COND22, :COND32, :COND42 and so on. Fast and dirty ;-)Ok, I'm already late for the deadline I fixed myself last nite. Sorry about that. I will post this for the moment and come back in few hours to follow with the way to do it in FSDS2 as it is slightly different. Those of you that can program in bclg can start the adaptation now ;-)Hugo

[Holger 0]

Hi Hugo,great work - thanks for sharing!I'm not that familiar with SCASM but can contribute a table that might help you and others to determine seasonal changes. I believe Gerrish is the original authors of this table:Season Start End1 15/Jan 15 14/Feb 452 15/Feb 46 17/Mar 763 18/Mar 77 17/Apr 1074 18/Apr 108 18/May 1385 19/May 139 18/Jun 1696 19/Jun 170 19/Jul 2007 20/Jul 201 19/Aug 2318 20/Aug 232 19/Sep 2629 20/Sep 263 20/Oct 29310 21/Oct 294 20/Nov 32411 21/Nov 325 21/Dec 35512 22/Dec 356 14/Jan 14Also, while the seasons in a particular location switch "orderly" from spring to summer to fall, etc., adjacent cells in the seasons.bgl can have rather harsh differences on the same day, such as the hard winter/spring opposition in the Month 3 image in this post of mine: http://forums.simflight.com/viewtopic.php?t=36767 Things get really messy when your scenery happens to lie on the boundary of two seasons.bgl cells that switch seasons in different months. I recently worked on a ski area that had that problem: during parts of the winter a straight line cuts through it with brown textures on one side and white on the other. Sigh! I wonder if your procedure could also be applied to VTP2 polys with custom textures?Cheers, Holger

[Guest Hugo]

To all, I will delay the the infos relative FSDS2 implementation until tomorrow thursday. I still have few thing to check before releasing.Holger, thanks for bringing up this table. This, in conjonction with the exam of seasons.bgl through TMFViewer makes it less of a chore to find seasonal date changes at a specific area, over the trial and error method I proposed above. So a table to keep in a separate drawer. Glad I still got'em right though."adjacent cells in the seasons.bgl can have rather harshdifferences on the same day, such as the hard winter/springopposition in the Month 3 image"I noticed similar patterns too. Image #1 and #2 show an area just south of Chicoutimi, Quebec, for a 5 feb. The covering remains the same all through FS winter time, 21 nov through 18 may, as the table predicts. ;-) But let me tell you, in real life this area is whiter than white at least from the begining of december till the end of april. Yet we have this representation.But for all Quebec I installed QbLC that prevails over UT/AK's that sits over FS's one. :-) So who's to blame? Nevertheless I'd have a dilemna if, as it stands here, I had to set upground poly of any brand at point A showned on the picture. :-) "Sigh! I wonder if your procedure could also be applied to VTP2 polys with custom textures?"Well, that's one of my whish in bringing this up. I hope some bglc programmer will pick the idea here, develop and propose a coding that could be droped in the asm file as the scasm coding I proposed here is droped in the api file and recompile. This way I will be able to adjust my G2K grass texture timing :-)Cherio!Hugo

[Guest Hugo]

Well, today was too nice a day to stay put in front of a monitor. One of the few last of the season. So I took a little time off.Nevertheless, last night and a bit this morning, I made those few checks I needed to complete before releasing. The problematic is not code related but mostly a matter of methodology.FSDS2 users already know that the seasonal texturing has not been implemented to the latest version. Hence, a mean had to be found and has been sometime after its release.It required to insert the now well known (and now infamous ;-) ) coding line; LoadBitmap( 0 WFS6 EF 0 0 0 "ABCD.bmp" ) between the 2 following coding lines related to surface of the concerned part in the generated api file;SetMaterial( 0 0 )DrawTriList( 0that would then look somewhat like this like this;...SetMaterial( 0 0 )LoadBitmap( 0 WFS6 EF 0 0 0 "ABCD.bmp" )DrawTriList( 0etc.Save the file back and recompile.Which is, in broad term, where the modified coding will aslo be placed.It should be inserted in replacement of the LoadBitmap command above....SetMaterial( 0 0 )IfVarRange( :COND2 38A 108 169 )LoadBitmap( 0 6 EF 0 0 0 "ABCDsp.bmp" )Jump( :carryon ):COND2IfVarRange( :COND3 38A 170 262 )LoadBitmap( 0 6 EF 0 0 0 "ABCDsu.bmp" )Jump( :carryon ):COND3IfVarRange( :COND4 38A 263 324 )LoadBitmap( 0 6 EF 0 0 0 "ABCDfa.bmp" )Jump( :carryon ):COND4LoadBitmap( 0 6 EF 0 0 0 "ABCDwi.bmp" ):carryon DrawTriList( 0etc.This set of commands looks very much like the one proposed for EOD but have been adapted to FSDS environment.As for EOD, a similar set of commands should be added to each season textured surface, taking care to provided the proper seasonal range for the scenery area, a different set of label name for each and proper texture file names. That shall complete the coding aspect to assure synchronization of own seasonal textures with FS's, related to EOD and FSDS2 usage.At the beginning of this post I mentionned methodology. The how, why, why not, when, etc. I consider that having brought up the subject, I should also bring some of these considerations along to complete the subject. I will in 3rd and last posting. It should come in the next few days, hopefully in no more than 2 or 3, depending on the quality of the weather ;-)Hugo

[Guest Hugo]

To complete the previous 2 documents, I will bring here few observations and thoughts I made while developping the proposed solutions.BITMAP NAMES.The usual seasonal LoadBitmap( 0 WFS6.... command REQUISES that a set of bitmaps uses the _fa, _wi and _sp extensions to the summer named bmp. But the proposed modifications, that makes use of LoadBitmap( 0 6 ... command, does not.Yet, I see 2 reasons why one should keep using the 'old' extensions scheme. First, this scheme being already familiar, makes them somewhat easier to identify when browsing the Texture folder, mainly a long time after the scenery has been complete and one whishes to bring some update.But when using EDO, there is a practical reason to adhere to that scheme. It permits to easely identify surfaces one has decided to apply seasonal textures to in the api file. The presence of the LoadBitmap( 0 WFS6... in the resulting api file will make it easy, to visualy perceived the mod, but more so when using the Notepad's Find function for editing pupose.Hence, a relativaly complex object could be built wit EDO and yet remains relativaly easy to edit due to the presence of the LoadBitmap( 0 WFS6... command.**Remark** The TexPoly entry showned in the 1st document: - TexPoly( 0 0 -32767 0 0 34 0 1 34 245 2 238 245 3 238 0 ) ;Front - IS NOT a universal code. One should use the one that comes with the related surface as generated in the api.THE FSDS2 CASE:FSDS2, not having seasonal texturing provision EDO has, I'd still suggest to maintain the bitmaps naming scheme for the first reason I brought UP above.On the other hand, finding WHERE to insert the code lines, may not be as obvious as with EDO. The following simple example should show why.Let's suppose one wants to make a double side inclined roof and have it covered with some snow for it's winter appearance. Let also assume he decides to build this roof using an horizontal Tube Part, 1 Section, 3 Points/Section, both ends closed, along the Z axis and apply texture to side and end surfaces. In this instance it chooses to only season texture the side surfaces. Here's how the resulting api file coding would look like.; Part: Tube;Part000000 <-- used ; instead of : here to avoid Smile Transform_Mat( 0.000000 0.000000 0.000000 1.000000 0.000000 0.000000 0.000000 1.000000 0.000000 0.000000 0.000000 1.000000 )SetMaterial( 0 -1 )DrawTriList( 0 0 1 2 0 2 3 )SetMaterial( 0 0 )DrawTriList( 0 4 5 6 4 6 7 8 9 10 8 10 11 )SetMaterial( 0 1 )DrawTriList( 0 12 13 14 15 16 17 ) So, to which SetMaterial/DrawTriList entries shall the coding apply? At this point, your guess is as good as mine.The solution I found to this enigma is to ONLY apply seasonal textures to POLYGON type PARTS, as they only have a single SetMaterial/DrawTriList attached to them.There are 2 possible ways to acheive this in this particular example above.1- Declare the side panels as having no texture and create 2 Polygons (Parts) that will be fit in place.2- Create a totaly new roof out of 5 Polygons (Part). Assemble them over existing roof (as a guide). Delete the tubular roof and assure all surface junctions to be real tight to avoid the ugly sight of unfit junctions in FS.Wathever the chosen method, one would get similar api output as the one that follows; .; Part: Polygon.31;Part000002 <-- used ; instead of : here to avoid Smile Transform_Mat( 0.241404 28.575233 -0.159525 1.000000 0.000000 0.000000 0.000000 1.000000 0.000000 0.000000 0.000000 1.000000 )SetMaterial( 0 -1 )*** insert proper seasonal coding hereDrawTriList( 8 0 1 2 0 2 3 )TransformEndReturn; Part: Polygon.32;Part000003 <-- used ; instead of : here to avoid SmileTransform_Mat( 0.031905 32.481209 44.274605 1.000000 0.000000 0.000000 0.000000 1.000000 0.000000 0.000000 0.000000 1.000000 )SetMaterial( 0 -1 )*** insert proper seasonal coding here too!DrawTriList( 12 0 1 2 )TransformEndReturnetc.As can be seen, it is relativaly easy to identify the Polygons to which the proper coding should be added. No guess also as to where the coding has to be inserted, there's only 1 place per Part to fit it!!Yet FSDS2 requires more work to season a given surface than EDO.SPECIAL CASES:1- ROTATE TO AIRCRAFT.EOD has a provision for this command. It does not affect texturing though. So code editing remains the same.FSDS2 has no provision this entry for either. It can be done through, again, api editing according the code mod proposed in the last message (by gorchi) of the following thread;http://forums.avsim.net/dcboard.php?az=sho...ing_type=searchAs for EOD, this mod does not affect texturing and, again, the code editing remains the same.2- NIGHT TEXTURES.Here EOD and FSDS2 both have this provision. If one wants to implement it to some parts then one should use this command; LoadBitmap( 0 L6 EF 0 0 0 "ABCD.bmp" ). The L entry tells scasm that there is a night texture associated with the regular one. This is one case though, where one may have to depart from the formal bmp naming suggested above. In this instance, 8 bitmaps would be required if one intends to show the enlightment year round. Winter bmps could be given following names; ABCD0.BMP and ABCD0_LM.bmp, ABCD1.bmp and ABCD1_LM.bmp and so on for the other seasons.3- SPECIAL (or conditional) APPREARANCES.Altough the proposal was developped around acheiving synchronisation of own's seasonal textures with FS's throughout the year, the IfVarRange( might be put to other usages. Lets look at it through an example.Suppose one wishes to add to the top of a building (his own house for example) a panel such as this one; http://www.twilightbridge.com/hobbies/fest...as/reindeer.htm that would is to appear only from 10 december to 6 january. Kind of a kitch proposal you will say ;-) But let's just pretend for the sake of illustration. He has pampered the image to its taste into an adequate format to FS and saved it under Santa.bmp. He then save the same image as Santa_LM.bmp and has produced a 3rd one name Offseason.bmp, which is only a transparent image, black, dxt1 with alpha, the same size as the other 2. What would the coding be like in this instance. How about this?With EOD he would produce a proper sized wall choose Santa.bmp for texture. Once the api is produced he would mdify the code so it reads something like this;..IfVarRange( :COND2 38A 7 344 )LoadBitmap( 0 6 EF 0 0 0 "Offseason.bmp" )TexPoly( 0 0 -32767 0 0 34 0 1 34 245 2 238 245 3 238 0 ) ;Front Return:COND2LoadBitmap( 0 L6 EF 0 0 0 "Santa.bmp" )TexPoly( 0 0 -32767 0 0 34 0 1 34 245 2 238 245 3 238 0 ) ;Front Returnetc.The first IfVarRange( checks if the day of the year lies between january 7 and december 9. If so, it puts a transparent texture to the wall and carrys on. If the day of the year is not found to be within that range, it then jumps to :cond2 where it applies Santa's picture to the wall that will also show illuminated at night due to L6 entry. Note: Make shure to have the correct entry in the TexPoly line.With FSDS2 he would setup a proper sized vertical Polygon (Part) The api coding after modification should something look like this;...SetMaterial( 0 0 )IfVarRange( :COND2 38A 7 344 )LoadBitmap( 0 6 EF 0 0 0 "Offseason.bmp" )Jump( :goahead ):COND2LoadBitmap( 0 L6 EF 0 0 0 "Santa.bmp" ):goaheadDrawTriList( 0etc.From what precedes, it would be relatively easy to concieve a coding so the panel above would only be lit from dusk to let say midnight and/or include provisions for it to be lit all night during Chistmass night. Hint: address 389 - hour (GMT) 1...24 : 28C - time of day: 1 day, 2 dusk/dawn, 4 night.This shall completes what I wished to bring on the subject. I hope it will find some usefullness for those of the community that still design with scasm base tool. My next step will be to look for a way to transport this approach to bglc compiling.Hugo