Sign in to follow this  
Guest Hugo

looking for a landclass ID

Recommended Posts

Hi all. I'm working on a scenery and have the need to identify the landclass bmp file that covers the area I'm working this scenery in. I used R. Ludowise TCalc2004 v2.0 for this purpose and got the info showned in the attached image.Making a search in FS9 folder, using 001332212221101Su.bmp for keyword, I could not come with any file having this name. I made a search using only 1101Su.bmp as kw. This yielded the 7 files showned in the background of the same attached image, all linked to city sceneries.The scenery I'm working on is located in an area covered by a regional landclass (Quebec LC, that actualy covers about 1/3 of the whole province, based on rearranged FS original lcs, I presume!!). How can I determine the exact lanclass GRAPHIC file used to cover this SPECIFIC AREA and its folder location?Thanks for any help.Hugo

Share this post


Link to post
Share on other sites
Help AVSIM continue to serve you!
Please donate today!

Hello Hugo,There are 2 different things here. The file name - 001332212221101Su.bmp - is not land class, but rather a custom (photo-real) ground texture.Land class is made of generic textures that do not precisely represent the ground at any particular place, whereas custom textures are real pictures of the ground.To get the land class value for your scenery, please use Microsoft's TMFViewer, available in the Terrain S.D.K.Then, just open the relevant land class file, place the pointer over the correct place, and read the land class value on the status bar:http://forums.avsim.net/user_files/124285.jpgFor more information on this, please see "Simple Instructions for Modifying Land Class" - it can be found in the Avsim library.Best regards.Luis

Share this post


Link to post
Share on other sites

Hi Luis. Thanks for the fast and informative reply. Sorry if I'm myself somewhat long to come backbut I've been jugling with them since I got them and they are pretty well what I was looking for. I can't tell for shure if,using them, I will be to acheive what I'm after but shurely they put me on the right track :-)>There are 2 different things here. The file name - 001332212221101Su.bmp - is not land class,>but rather a custom (photo-real) ground texture.Funny, cause I don't have any photoreal textures neither in this area nor anywhere else as on the earth far as I know. :-eek >Land class is made of generic textures that do not precisely>represent the ground at any particular place, whereas custom>textures are real pictures of the ground.Well I did make few land class installations with LC Assistant and EZ-Landclass so I have a good idea of the field.>To get the land class value for your scenery, please use>Microsoft's TMFViewer, available in the Terrain S.D.K.Indeed that's a very good tool I was not aware of, that is until now ;-) With the help of your 'Simple Instructions for Modifying Land Class' it turn out to be very helpfull in my quest.>>Then, just open the relevant land class file, place the>pointer over the correct place, and read the land class value>on the status bar:>I did just that and found the value to be 21 when looking into worldlc.bgl, the world original FS land class. But as this area is covered by Quebec LC. So peeking into it, the area lc value is now set to 61.With this and some infos I red into the sdk docs I'm pretty well on my way thought I still have to experiment to see if the end results will be as expected.Again, thanks a lot Luis, for your precious help.Hugo

Share this post


Link to post
Share on other sites

>> Funny, cause I don't have any photoreal textures neither in this area nor anywhere else as on the earth far as I know. The texture filename is generated purely from the Lat/Long coordinates. It may or may not exist.George

Share this post


Link to post
Share on other sites

Salut Hugo,I am glad that this could be of help to you.As for TCalc, it is a tool for designers, and gives a lot of very useful information. For example, even if there is no custom texture installed, TCalc will indicate the file name for this so that a designer will not have to calculate it. Many thanks to Dick Ludowise for making this tool so comprehensive.Best regards.Luis

Share this post


Link to post
Share on other sites

Hi! Me again ;-). Well the previous solution I sought to for my need, playing with LC, was not the right one though the informations I got were realy worthy but for other needs that are not my present one. I'm looking for a way to 'skin cover' the surface of a small area with seasonal grass textures.The place is a small park (more so a rest area) about 140 meters on the side which is totaly included in a lod 13 area.As shown in the attached image, there are 2 sections. The one to the north is almost flat and applyin polys there gives an acceptable result but the southern part is a lot more bumpy and has to remain this way. A 4 meter drop for an about 12 m width. It is very hard to get the polys to adjust to the ground surface there and dosen't look nice.Would there be a tool, I'm thinking about something like SBuilder or Ground2k, that would permit to acheive that, eg redoing the whole area, the north and south parts. Just applying the grass surfaces. I've red a bit about VTP poly, photo textures, but I am still not at ease with this stuff still. Yet I would like to complete the scenery for early september to share it with an online flying group for the beginning of the new flying season.If it can be done, then SBuider should be the tool as far as I can appreciate. Could someone hints me toward the knowledge elements I should focus on with this tool in order not to disperse myself taking into account the time constrain I have to live with.I have made myself nice looking seasonal grass textures but those are dxt 1024x1024 (naturaly the grass is kinda white during winter time around here ;-) ). Donno if those would be handy for this approach though.Again thanks for any help.HugoHum! Am I pointing someone in particular seeking this help? :-)Salut Luis

Share this post


Link to post
Share on other sites

Thanks a lot Luis. "You need to draw a VTP polygon and then either assign a grass land class value to it, or assign your grass textures, including all seasonal variants. It is very easy to do with either program." That's what I wanted to hear (or to read for the matter!) ;-)I guess I'll opt for SBuilder and focus on VTP polys at this time. When I'm over with this project I will look at it on a broader level. You say I could either use grass LC or self define textures. That would be cool :-) Merci et A+ comme disent les fran

Share this post


Link to post
Share on other sites

Well, I finaly got what I was looking for. Well almost!. Compare image #1 (top left) here with the one done with polys attached to a previous message. It's a little more fuzzy, as it blends with the surronding but thats ok. I had to redimension texture files to 512x512 dxt1 as 1024x1024 would crash FS when going from summer to other seasons!! I used Ground2k4 to acheived it instead of Sbuilder I couldn't get to work properly, thought I'm shure it's a very good tool as well.There are 2 questions I'm left with though.1- When I choose Polygons/Line in G2K4 and choose Poly without shore, I do not have access to VTP1 Polys function. So I went for VTP2 Polys to produce this part of the scenery. See attached image#2. I'm not complaining because it works ok ;-) But I wonder if I'm the only one that have this restriction? Only VTP2 polys are usable with the latest G2K4 version. I have V5.4 dated 12/21/20042- My second question is about seasonal change synchronism between FS world and seasonal textures. For example image #1 (center) shows how the terrain looks like on may 5th. Still very much under snow while the surronding is almost dryed out! For the area, FS goes from winter aspect to spring's on april 18. But it's not until may 19 that the terrain changes its face!! A similar discrepancy exist going from fall to winter. Beginning and end of summer are in total synchronism though, on june 19 and sept 20. Note: G. Gray's trees follows the same schedule as this terrain but for trees this quite correct for this area.Now, I remember having red an exchange on this matter, modification of seasonal texture changing date, on this forum. I made a search but could not find the thread back. Anyone has a clue on this?BTW seasonal textures applied to 'regular' polys, the ones made with EOD or FSDS2, don't have their seasonal changes until much later in autumn. Actualy on dec 22 as showned in image #1, bottom L/R. FS winter date for the area is november 21!! Hum! All textures are not created equal ;-) I just wonder about Sbuilder's ones. I shall investigate! (if I can find how to put it to work... someday :-) )So, if someone could indicate how one can modify seasonal texture change date on those applied through Ground2k and, if possible, on those made with 'regular' polys, it would be very much appreciated (at least by... me) :-) :-)Hugo

Share this post


Link to post
Share on other sites

Salut Hugo,Glad that you could get it to work. It looks very good so far.VTP1 only worked with FS 2002. Christian Fumey left that possibility in Ground2K4 in case the FS Team ever decides to make it operable again, but you cannot access VTP1 for now. You were right to use VTP2, and it is easier anyway.As for modifying season dates for your polygon, you might get some clues at Arno's site, as I believe he has indicated the method:http://www.scenerydesign.org/forum/You will have to register and log-in in order to read the threads.Beat regards.Luis

Share this post


Link to post
Share on other sites

Hi Hugo.VTP1 was created for CFS2, and allowed in FS2002 for compatibility ( LWMPoly1 is also allowed in FS2002 ). Christian bought a copy of CFS2 because I nagged him to add the VTP1 and LWMPoly1 option to Ground2K. This probably explains why there has been no further development for Ground2K4... he's too busy shooting down planes in CFS2. ;)Dick

Share this post


Link to post
Share on other sites

Thanks Luis and Dick for the confirmation about the unavailability of VTP1 in G2K4. I feel a lot less lonely now :-)Luis, I went to the link U suggest. There were some discussions on seasonal textures and seasonal date changes there but they were related to gmax coding using makemdl and the bglcomp compiler I'm not at all familiar with (for the moment! I just retired and will have time this fall and winter to give it a closer look along with SBuilder and G2K4). I could not find back the thread I have refered to in my previous message. But I found the following one: http://forums.avsim.net/dcboard.php?az=sho...ing_type=searchwhere, in the next to last message, Arno gives a lot of infos on various variables used by scasm to gather FS time and seasonal states. He also propose coding to retreive from an act on FS behavior, using the IfVarRange conditional command. This combined with Scasm documentation on the usage of this command brought me to find myself a solution for synchronising seasonal textures changes with FS's ones for what I refer as 'regular polys' in my previous message, that is, those textures applied to object surfaces in programs like EOD and FSDS2. It can be used with both tools with little coding differences depending which one uses. The coding change is made in the initial api files and reprocess through airport, FSSC or whatever program that accepts api files. But I'm not totaly satisfied with my solution. It forces me to find, by trial and error, the dates (the day of the year) seasons change of each an any site I'd be working on and apply these values to IfVarRange command. It is un-universal, tedious and un-elegant! Broadly speaking, FS seasonal changes occurs at those dates we all know; 21 march, june, september and december (or about). But the actual seasonal change at a given lattitude (and altitude too, I think) may be delayed or advanced on FS 'generic' seasonal dates.For example in the area I'm presently concerned, between Montreal and Quebec on St-Laurence north shore, the change from winter to spring texture occurs on april 14 (about 3 weeks after the global FS) and the passage from fall to winter happens on november 21, a month earlier than FS's. So peaking FS var 6F8 for seasonal change is not appropriate point of decision.Hence, there ought to be a variable address or an other mean, FS uses to determine what seasonal texture is applied for a specific area at any given time. Would you or someone that reads this thread know that address (or the mean used by FS) so one (including me!) could refer to it to synchronise the changes?For ground polys produced with Gound2k I face the same dilemna. I haven't look to it a great deal at this time. Does it use scasm as compiler? I would think so. I used SCDis2.3 to dissamble the bgl I made. It does it for a litte part but gives this message along the way; -- ;;; sorry, scdis can't decode section 8 --Anyone is aware of any dissasembler that could do the job?As for the above, there will shurely be a need for some code tweekings!!Hugo

Share this post


Link to post
Share on other sites

Hi Hugo.There isn't any variable to tap into that I'm aware of.The seasons.bgl contains a map of the seasonal limits. It's a great deal like worldlc.bgl... the world's landclass file. You can view it in TMFViewer. TMFViewer has a menu item to allow you to view each month, and you can read the latitude/longitude, as well as the seasonal value, at the bottom of TMFViewer.Dick

Share this post


Link to post
Share on other sites

Salut Hugo,I feared that you would not be able to find a solution to this. I have never tried modifying the seasonal changes for ground polygons (seasons? what seasons? It is always hot here!). If anyone could tell you a way to do this, it would be Dick, and you see that he indicates it cannot be done.You could try modifying the seasons assignments (seasons.bgl) in your area, although I am not sure if this will solve your problem. Christian Stock wrote up the procedure for this in his Terrain Model File Manual, that you can find in the Avsim library.I have attempted to modify the seasons in my region numerous times with this method, but have never had any success. So, if someone has been able to do it, perhaps they could indicate the procedure and if there is any change from what Christian advises.Best regards.Luis

Share this post


Link to post
Share on other sites

>For ground polys produced with Gound2k I face the same>dilemna. I haven't look to it a great deal at this time. Does>it use scasm as compiler? I would think so. I used SCDis2.3 to>dissamble the bgl I made. It does it for a litte part but>gives this message along the way; -- ;;; sorry, scdis can't>decode section 8 -->>Anyone is aware of any dissasembler that could do the job?>Hello Hugo,to get the soucecode for the bgl's produced by Ground2K you need no disassembler: The bglc sources (no scasm) are stored in the Ground2k program folder (named something like "$....asm").Otherwise you can disassemble VTP-bgl's with LWMViewer from Jim Keir.Regards, Edgar

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this