Hi Luis,
Is there a way to modify rivers or streams that show above terrain, using SBuilder present version?
If not, how much time does it take to such a new SBuilder version comes up?
Could you show an easy solution to modify FS X river's poligon?
Thanks,
José
J.F.Lôbo
SBuilder for FS X ?
Hi José,
I am not working with the present version. The only thing I did was an elementar correction to allow FSUIPC 4.0 to work with SBuilder.
I am almost reaching the point to generate BGL files using FSX approaches. I have resisted to experiment with the new tools because I wanted to review everything in SBuilder step by step. But I am reading very carefully the discussions on other forums. I think that I know what to introduce in SBuilder. Wait 1 or 2 more weeks. But do not expect the same flexibility as before. Now the MS tools are very powerful and SB will be a kind of graphical user interface. The BGL internal format is not know (yet) and, for exemple, you will be not able to import a BGL, edit it graphically and compile again.
Luis
I am not working with the present version. The only thing I did was an elementar correction to allow FSUIPC 4.0 to work with SBuilder.
I am almost reaching the point to generate BGL files using FSX approaches. I have resisted to experiment with the new tools because I wanted to review everything in SBuilder step by step. But I am reading very carefully the discussions on other forums. I think that I know what to introduce in SBuilder. Wait 1 or 2 more weeks. But do not expect the same flexibility as before. Now the MS tools are very powerful and SB will be a kind of graphical user interface. The BGL internal format is not know (yet) and, for exemple, you will be not able to import a BGL, edit it graphically and compile again.
Luis
Hi,
This is a post I have just posted in www.fsdeveloper.com.
Hi,
I would be grateful if anyone with experience in using shp2vec and with a exposure to the (old) SBuilder interface could confirm what follows. Take this as an effort of me to make a plan before starting to write code.
Sbuilder interface is similar to what it was. We can make lines and polys by hand or we can import GIS data (SHP is a new supported format). We can place the right mouse over a line and get to properties page of that line. Then we can set the properties of the line to be, for example, "stream A", "road A", "road B" or else. Basically when the user picks one of these types, a GUID is chosen. For example, what I referred to as road B could be 698E20FC-1C69-4876-AF34-A6E9F531CCA5. I have not yet polish the interface but I will probably show the name "Asphalt 2 Lanes Divided Median" and, on the side, a texture (hiway_2_lane_asphalt_su.bmp on the case). Sbuilder will not read the Terrain.CFG but, as before, it will read a simple TXT file similar to LINES.TXT with the same information. Now I will describe the internal structure of a Line as you can see it when you export a project to a SBX file. An example is:
[Line.2]
Name=3_Points_Line
Selected=True
Type=RDX
Color=-16776961
Guid=698E20FC-1C69-4876-AF34-A6E9F531CCA5//0//0//
NoOfPoints=3
Lat1= 40.3364562988281
Lon1=-9.90804327748329
Alt1= 35
Lat2= 40.3501892089843
Lon2=-9.59961751750456
Alt2= 35
Lat3= 40.2540588378906
Lon3=-9.35215964031233
Alt3= 35
Let me comment.
[Line.2] means that it is the second line in the project. The UIID to pass on SHP2VEC will be 2.
Name=3_Points_Line. This is a label. When importing a SHAPE file SBuilder will show a small dialog which will allow to define that name is read from one of the existing fields in the shape database file. Otherwise SBuilder will create a name as "3_Points_Line".
Selected=True, This very internal to SBuilder. Shall I export it? It simply means the selected (or not selected) state of a line at the time of exporting.
Type=RDX This is the type of a line. It could be an empty string in which case the type of the line is shown as to "None". RDX means Roads. The other FSX types for lines will be FWX RRX HLX STX UTX. I kept the name Type as I do not know if I will porte to the new SBuilder some support for FS9. If that will be the case Type could be, for example ,Type=VTP//7//1033//
Color=-16776961 is the ARGB value of the color used by SBuilder to show the line in the SBuilder display
Guid=698E20FC-1C69-4876-AF34-A6E9F531CCA5//0//0// This is the texture GUID plus a 0 (zero) plus another 0 (zero) separated by "//". The //0//0// string at the end will never be used except in the case of Freeways in wich case they mean the Number of Lanes and the Traffic Direction. For Polygons I plan to use the same arrangment with the 2 extra parameters menaing SlopeX and SlopeY as required on, for example, water polygons.
NoOfPoints=3
Lat1= 40.3364562988281
Lon1=-9.90804327748329
Alt1= 35
These are self explanatory. Note that Z (altitude) will allways be present. I am giving up to store another point parameter (the M value that I refer to in my previous post).
I never generated a BGL with the SHP2VEC tool
Here is what I am thinking of. I will be greateful if someone has a nicer solution or detects any error in my thinking.
I will have a subfolder under SBuilder called SHAPE and another sub/subfolder called WORK. If SBuilder is in C:\ I am referring to:
C:\SBUILDER\SHAPE
C:\SBUILDER\SHAPE\WORK
Inside C:\SBUILDER\SHAPE I will place:
shp2vec.ex
RDX.xml
FWX.xml
RRX.xml
HLX.xml
STX.xml
UTX.xml
These XML files will be copies of the ones given in the SDK examples. For example RDX.xml will be equal to RDS7824.xml
Say that the SBuilder's project has the name my_Project and that the only Line selected is line.2 above. When the user press Compile the following actions will take place:
a) all files inside C:\SBUILDER\SHAPE\WORK are deleted
b) RDX.xml is copied (and renamed) to C:\SBUILDER\SHAPE\WORK with the name RDX_my_Project.xml
c) Sbuilder exports into C:\SBUILDER\SHAPE\WORK the files
RDX_my_Project.dbf
RDX_my_Project.shp
RDX_my_Project.shx
d) Sbuilder will issue the command:
c:\sbuilder\shape\shp2vec.exe .\work my_Project -ADDTOCELLS
e) The file cvxmy_Project.BGL is copied into the SCENERY Target folder
I am sorry about this long post. If someone reads it and detects a wrong idea please advise. After all I never tried shp2vec!
Luis
This is a post I have just posted in www.fsdeveloper.com.
Hi,
I would be grateful if anyone with experience in using shp2vec and with a exposure to the (old) SBuilder interface could confirm what follows. Take this as an effort of me to make a plan before starting to write code.
Sbuilder interface is similar to what it was. We can make lines and polys by hand or we can import GIS data (SHP is a new supported format). We can place the right mouse over a line and get to properties page of that line. Then we can set the properties of the line to be, for example, "stream A", "road A", "road B" or else. Basically when the user picks one of these types, a GUID is chosen. For example, what I referred to as road B could be 698E20FC-1C69-4876-AF34-A6E9F531CCA5. I have not yet polish the interface but I will probably show the name "Asphalt 2 Lanes Divided Median" and, on the side, a texture (hiway_2_lane_asphalt_su.bmp on the case). Sbuilder will not read the Terrain.CFG but, as before, it will read a simple TXT file similar to LINES.TXT with the same information. Now I will describe the internal structure of a Line as you can see it when you export a project to a SBX file. An example is:
[Line.2]
Name=3_Points_Line
Selected=True
Type=RDX
Color=-16776961
Guid=698E20FC-1C69-4876-AF34-A6E9F531CCA5//0//0//
NoOfPoints=3
Lat1= 40.3364562988281
Lon1=-9.90804327748329
Alt1= 35
Lat2= 40.3501892089843
Lon2=-9.59961751750456
Alt2= 35
Lat3= 40.2540588378906
Lon3=-9.35215964031233
Alt3= 35
Let me comment.
[Line.2] means that it is the second line in the project. The UIID to pass on SHP2VEC will be 2.
Name=3_Points_Line. This is a label. When importing a SHAPE file SBuilder will show a small dialog which will allow to define that name is read from one of the existing fields in the shape database file. Otherwise SBuilder will create a name as "3_Points_Line".
Selected=True, This very internal to SBuilder. Shall I export it? It simply means the selected (or not selected) state of a line at the time of exporting.
Type=RDX This is the type of a line. It could be an empty string in which case the type of the line is shown as to "None". RDX means Roads. The other FSX types for lines will be FWX RRX HLX STX UTX. I kept the name Type as I do not know if I will porte to the new SBuilder some support for FS9. If that will be the case Type could be, for example ,Type=VTP//7//1033//
Color=-16776961 is the ARGB value of the color used by SBuilder to show the line in the SBuilder display
Guid=698E20FC-1C69-4876-AF34-A6E9F531CCA5//0//0// This is the texture GUID plus a 0 (zero) plus another 0 (zero) separated by "//". The //0//0// string at the end will never be used except in the case of Freeways in wich case they mean the Number of Lanes and the Traffic Direction. For Polygons I plan to use the same arrangment with the 2 extra parameters menaing SlopeX and SlopeY as required on, for example, water polygons.
NoOfPoints=3
Lat1= 40.3364562988281
Lon1=-9.90804327748329
Alt1= 35
These are self explanatory. Note that Z (altitude) will allways be present. I am giving up to store another point parameter (the M value that I refer to in my previous post).
I never generated a BGL with the SHP2VEC tool
Here is what I am thinking of. I will be greateful if someone has a nicer solution or detects any error in my thinking.I will have a subfolder under SBuilder called SHAPE and another sub/subfolder called WORK. If SBuilder is in C:\ I am referring to:
C:\SBUILDER\SHAPE
C:\SBUILDER\SHAPE\WORK
Inside C:\SBUILDER\SHAPE I will place:
shp2vec.ex
RDX.xml
FWX.xml
RRX.xml
HLX.xml
STX.xml
UTX.xml
These XML files will be copies of the ones given in the SDK examples. For example RDX.xml will be equal to RDS7824.xml
Say that the SBuilder's project has the name my_Project and that the only Line selected is line.2 above. When the user press Compile the following actions will take place:
a) all files inside C:\SBUILDER\SHAPE\WORK are deleted
b) RDX.xml is copied (and renamed) to C:\SBUILDER\SHAPE\WORK with the name RDX_my_Project.xml
c) Sbuilder exports into C:\SBUILDER\SHAPE\WORK the files
RDX_my_Project.dbf
RDX_my_Project.shp
RDX_my_Project.shx
d) Sbuilder will issue the command:
c:\sbuilder\shape\shp2vec.exe .\work my_Project -ADDTOCELLS
e) The file cvxmy_Project.BGL is copied into the SCENERY Target folder
I am sorry about this long post. If someone reads it and detects a wrong idea please advise. After all I never tried shp2vec!
Luis
-
rhumbaflappy
- Posts: 420
- Joined: Sat Oct 16, 2004 10:11 pm
Hi Luis.
Your process looks good to me. I can add some info.
No one has been able to give me an answer concerning priority of polys or lines within the BGL. The <b>Types are basically layers </b>that do control priority... for example a FLX can actually be a "park" polygon, but the priority is FLX. But within the same Type, and within the same BGL, the priority of overlapping polys and lines has been described as random. That doesn't seem close to being right, so we may discover something once SBuilderX gets into general use. Only shp2vec is concerned with Type and UUIDs. The sim doesn't use them. I had hoped UUIDs would control priority, but they do not, as I am told.
For the most part, the XML file associated with the Type can be unchanged, except for it's name.
Dick
Your process looks good to me. I can add some info.
No one has been able to give me an answer concerning priority of polys or lines within the BGL. The <b>Types are basically layers </b>that do control priority... for example a FLX can actually be a "park" polygon, but the priority is FLX. But within the same Type, and within the same BGL, the priority of overlapping polys and lines has been described as random. That doesn't seem close to being right, so we may discover something once SBuilderX gets into general use. Only shp2vec is concerned with Type and UUIDs. The sim doesn't use them. I had hoped UUIDs would control priority, but they do not, as I am told.
For the most part, the XML file associated with the Type can be unchanged, except for it's name.
Dick
Hi, Luis
For South America FS X mesh is very poor, perhaps based on Gtopo30 (about 900 m resolution). Using a little better mesh, 76 m resolution, many lakes appear upper or below the terrain level.
I compiled flat polys with SBuilder, appending HPxxxxxx.bgl file from FS 9, just to create the poly covering the lake durface, and the FS X read the compiled bgl and adjusted the water level to the apropriated high (entered in flat poly)
Does this mean that flat polys have the same structure, in both FS 9 and FS X?
Thanks for your attention,
Regards,
José
J.F.Lôbo
For South America FS X mesh is very poor, perhaps based on Gtopo30 (about 900 m resolution). Using a little better mesh, 76 m resolution, many lakes appear upper or below the terrain level.
I compiled flat polys with SBuilder, appending HPxxxxxx.bgl file from FS 9, just to create the poly covering the lake durface, and the FS X read the compiled bgl and adjusted the water level to the apropriated high (entered in flat poly)
Does this mean that flat polys have the same structure, in both FS 9 and FS X?
Thanks for your attention,
Regards,
José
J.F.Lôbo
Hi Jose,
FSX is supposed to support VTP/LWM type scenery. But I never checked this. In FSX you do flattens and water polygons in a different manner. SBuilder X will try to make flattens, and the rest, using the FSX way. But the old VTP/LWM had more flexibility. And problems. As an example of flexibilty you could make lines of adjustable width as in, for exeample, here:
http://www.ptsim.com/images/figueira.jpg
which you can not in FSX. You can not vary the width of the beach shoreline in FSX as in the above picture. It also had troubles as the flatens that could not be excluded. So, may be there will be a place to use the old techniques in some ocasions. That is why I am not sure if I will look again to SB2.05.
Regards, Luis
FSX is supposed to support VTP/LWM type scenery. But I never checked this. In FSX you do flattens and water polygons in a different manner. SBuilder X will try to make flattens, and the rest, using the FSX way. But the old VTP/LWM had more flexibility. And problems. As an example of flexibilty you could make lines of adjustable width as in, for exeample, here:
http://www.ptsim.com/images/figueira.jpg
which you can not in FSX. You can not vary the width of the beach shoreline in FSX as in the above picture. It also had troubles as the flatens that could not be excluded. So, may be there will be a place to use the old techniques in some ocasions. That is why I am not sure if I will look again to SB2.05.
Regards, Luis
Hi Dick,
Thank you for the input. By your words it seems that I understood the SDK just by reading and now I will try to implement what I described. I will be glad to send you a copy of the new version of SBuilder once it makes a BGL even if the inteface is not complete polished.
Before we could define width, priority, custom named texture,..., without changing the Terrain.CFG. Now it seems impossible. I was surprised to ear responses from the designers suggesting (if I understood it right) we could alter (add our entries) to the Terrain.CFG.
Your proposal for a minimal change of the Terrain.CFG (to include 252 254 and 255 classes) is solid in the community? I have a commercial product and I need to porte it to FSX. I am in doubt about (i) making a major redesign using FSX techniques or (ii) making a minor redesign plus suggesting to the useres the adoption of your Terrain.CFG.
Kind Regards, Luis
Thank you for the input. By your words it seems that I understood the SDK just by reading and now I will try to implement what I described. I will be glad to send you a copy of the new version of SBuilder once it makes a BGL even if the inteface is not complete polished.
Before we could define width, priority, custom named texture,..., without changing the Terrain.CFG. Now it seems impossible. I was surprised to ear responses from the designers suggesting (if I understood it right) we could alter (add our entries) to the Terrain.CFG.
Your proposal for a minimal change of the Terrain.CFG (to include 252 254 and 255 classes) is solid in the community? I have a commercial product and I need to porte it to FSX. I am in doubt about (i) making a major redesign using FSX techniques or (ii) making a minor redesign plus suggesting to the useres the adoption of your Terrain.CFG.
Kind Regards, Luis
-
rhumbaflappy
- Posts: 420
- Joined: Sat Oct 16, 2004 10:11 pm
Hi Luis.
I've been working with Luis Féliz-Tirado on a replacement terrain.cfg.
The big changes we are suggesting are mostly to eliminate the rocky slopes in water, eliminate the flattening for FS9 legacy airfields, and add the ability to have the FS9 CUSTOM VTP polys ( by adding landclass number 252, 253, and 254 ).
Not a lot of change really, but it will improve the sim. We would really like developers to include the package with their sceneries, as it does no harm, and adds some value for end-users. We'll also post it at several places in the next day or two.
Luis and I are going to try to act as a clearing-house for changes to the terrain.cfg... I don't know how that will work. We really wished the Aces team would have made these changes, but they declined.
There hasn't been a lot of discussion over this, as mostly beta-testers have been informed, and few of them showed interest. Once they are posted, and users see it fixes the rocks in London's Thames and fixes Niagara falls, I think it will get accepted.
Dick
I've been working with Luis Féliz-Tirado on a replacement terrain.cfg.
The big changes we are suggesting are mostly to eliminate the rocky slopes in water, eliminate the flattening for FS9 legacy airfields, and add the ability to have the FS9 CUSTOM VTP polys ( by adding landclass number 252, 253, and 254 ).
Not a lot of change really, but it will improve the sim. We would really like developers to include the package with their sceneries, as it does no harm, and adds some value for end-users. We'll also post it at several places in the next day or two.
Luis and I are going to try to act as a clearing-house for changes to the terrain.cfg... I don't know how that will work. We really wished the Aces team would have made these changes, but they declined.
There hasn't been a lot of discussion over this, as mostly beta-testers have been informed, and few of them showed interest. Once they are posted, and users see it fixes the rocks in London's Thames and fixes Niagara falls, I think it will get accepted.
Dick
-
luisfeliztirado
- Posts: 436
- Joined: Sun May 15, 2005 9:15 am
- Location: Santo Domingo
Hi guys,
I have just placed the revised terrain.cfg in the Avsim library, and it should show up tomorrow.
You may want to take a look at it, Luis, and it can also be found in the beta newsgroup in Dick's post, "Important addition needed to the default terrain.cfg".
The modifications are not particularly radical, and are mostly corrections to some minor inconsistencies,
For most people, the major difference will concern the display of water, and this definitely needed to be changed, as can be seen in these before and after pictures of London:
Otherwise, there are some modifications that will allow you to use FS 9 features in FS X vector files, Luis, so you may find them beneficial.
In truth, the changes that Dick and I have made are of prime interest to scenery designers.
Best regards.
Luis
I have just placed the revised terrain.cfg in the Avsim library, and it should show up tomorrow.
You may want to take a look at it, Luis, and it can also be found in the beta newsgroup in Dick's post, "Important addition needed to the default terrain.cfg".
The modifications are not particularly radical, and are mostly corrections to some minor inconsistencies,
For most people, the major difference will concern the display of water, and this definitely needed to be changed, as can be seen in these before and after pictures of London:
Otherwise, there are some modifications that will allow you to use FS 9 features in FS X vector files, Luis, so you may find them beneficial.
In truth, the changes that Dick and I have made are of prime interest to scenery designers.
Best regards.
Luis
-
rhumbaflappy
- Posts: 420
- Joined: Sat Oct 16, 2004 10:11 pm
Hello Luis and Dick,
I have just read your file. Could you clarify the following?
- I think that you added GUIDs for the legacy entries in order that we could use shp2vec to generate vector scenery in addition to allow FSX to display vector scenery made for FS9. The XML files required by shp2vec use GUIDs to identify the type of "sister" shapefiles that need to be processed. In the case of Lines I think that there are 6 types of lines ...
- ... taking your entries 387 and 388 for example, should I use a XML equal to HLX****.XML for the former and one identical to UTX****.XML for the latter?
- Finally, yesterday I was working on the graphical interface for setting the properties of Lines in SBuilder. This is really what I need to start using SBuilder to produce BGLs as it already can export shapefiles. So I created a LINES.TXT file whose first 3 lines look like these:
// Stream Lines
[Texture.0]
Name=Stream_Lines_Perennial
Color=FF01A2FF
Guid={2D3FC985-A72B-473D-B23B-D78E72E63B53}
Textures=RiverSU.bmp
Type=STX
// FSX shorelines
[Texture.110]
Name=Shorelines_Default
Color=FFC0C000
Guid={6BE0F0F1-C807-4C6F-81CB-B5D565C69375}
Textures=l_tanrock_ns.bmp
Type=HLX
[Texture.111]
Name=Shorelines_Generic_Bay_Harbor
Color=FFC0C000
Guid={D2E16D2B-692A-4BFC-8383-B1A1A815A3E8}
Textures=l_tanrock_ns.bmp
Type=HLX
...
As you noticed I removed the legacy entries. Do you think I should keep the legacy entries? After all, the user of SBuilder can just create his own LINES.TXT.
A final question from a lazy person. I remember to read some discussions about the format of the GUIDs. Shall I export them to the shapefiles as in {D2E16D2B-692A-4BFC-8383-B1A1A815A3E8} ? I mean with the starting and ending brackets? Well this is a stupid question. The shapefiles in the examples are self explanatory!
Kind Regards, Luis
I have just read your file. Could you clarify the following?
- I think that you added GUIDs for the legacy entries in order that we could use shp2vec to generate vector scenery in addition to allow FSX to display vector scenery made for FS9. The XML files required by shp2vec use GUIDs to identify the type of "sister" shapefiles that need to be processed. In the case of Lines I think that there are 6 types of lines ...
- ... taking your entries 387 and 388 for example, should I use a XML equal to HLX****.XML for the former and one identical to UTX****.XML for the latter?
- Finally, yesterday I was working on the graphical interface for setting the properties of Lines in SBuilder. This is really what I need to start using SBuilder to produce BGLs as it already can export shapefiles. So I created a LINES.TXT file whose first 3 lines look like these:
// Stream Lines
[Texture.0]
Name=Stream_Lines_Perennial
Color=FF01A2FF
Guid={2D3FC985-A72B-473D-B23B-D78E72E63B53}
Textures=RiverSU.bmp
Type=STX
// FSX shorelines
[Texture.110]
Name=Shorelines_Default
Color=FFC0C000
Guid={6BE0F0F1-C807-4C6F-81CB-B5D565C69375}
Textures=l_tanrock_ns.bmp
Type=HLX
[Texture.111]
Name=Shorelines_Generic_Bay_Harbor
Color=FFC0C000
Guid={D2E16D2B-692A-4BFC-8383-B1A1A815A3E8}
Textures=l_tanrock_ns.bmp
Type=HLX
...
As you noticed I removed the legacy entries. Do you think I should keep the legacy entries? After all, the user of SBuilder can just create his own LINES.TXT.
A final question from a lazy person. I remember to read some discussions about the format of the GUIDs. Shall I export them to the shapefiles as in {D2E16D2B-692A-4BFC-8383-B1A1A815A3E8} ? I mean with the starting and ending brackets? Well this is a stupid question. The shapefiles in the examples are self explanatory!
Kind Regards, Luis
-
rhumbaflappy
- Posts: 420
- Joined: Sat Oct 16, 2004 10:11 pm
Hi Luis.
<blockquote id="quote"><font size="1" face="Verdana, Arial, Helvetica" id="quote">quote:<hr height="1" noshade id="quote">
- I think that you added GUIDs for the legacy entries in order that we could use shp2vec to generate vector scenery in addition to allow FSX to display vector scenery made for FS9. The XML files required by shp2vec use GUIDs to identify the type of "sister" shapefiles that need to be processed. In the case of Lines I think that there are 6 types of lines ...
<hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">
Luis added the GUIDs to the legacy terrain.cfg defaults because they had no GUIDs. In effect, they could not be used. Note: The legacy VTP was working without this addition. What the GUIDs do is allow new FSX vector polys to use the old shoreline types.
<blockquote id="quote"><font size="1" face="Verdana, Arial, Helvetica" id="quote">quote:<hr height="1" noshade id="quote">
- ... taking your entries 387 and 388 for example, should I use a XML equal to HLX****.XML for the former and one identical to UTX****.XML for the latter?
<hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">
387 is a shoreline type that is just a wave... no beach at all ( HLX type ).
388 is a utility line that does not modify the ground... so it is just the towers ( UTX type ).
<blockquote id="quote"><font size="1" face="Verdana, Arial, Helvetica" id="quote">quote:<hr height="1" noshade id="quote">
As you noticed I removed the legacy entries. Do you think I should keep the legacy entries? After all, the user of SBuilder can just create his own LINES.TXT.
<hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">
I think you can leave them out, as long as the enduser knows he can add them to his own LINES.TXT.
If SBuilder is flexible enough to use the altered terrain.cfg, that's great. The only danger is that someone would release scenery using the altered terrain.cfg, and then not include it with insructions how to add it to the sim. Then we'll have posters claiming SBuilder doesn't work right, when we know it is the new terrain.cfg that wasn't added.
Here's an example:
<i>The new terrain.cfg gets rid of unwanted rocky outcroppings in the water polys ( a bug in the sim... look at Niagara Falls with the default terrain.cfg!!! ). The SBuilder-created scenery uses this new added feature. The enduser doesn't install the new terrain.cfg, and then he complains the scenery is bad and SBuilder is at fault.</i>
Luis and I were a bit hesitant to suggest the new terrain.cfg, but the Aces members were not convinced our changes were needed, and the final FSX release was produced in quite a hurry, leaving no time for us to convince the team to include the changes. I do not know if future updates of the terrain.dll or the terrain.cfg will address the changes we made.
What I suggest is that you include the new terrain.cfg zip file with SBuilder, so designers know it is available, and can distribute it with their scenery if it is used, so we can all avoid confusion in the future.
Another note:
The shapefile types ( EXX, FLX, FWX, HGX, HLX, HPX, PKX, RDX, RRX, STX, UTX ) are, I believe, a type of priority system for shp2vec. The associated XML file actually controls what is displayed... so for example, a waterpoly can be type UTX, if the XML file is adjusted for it. I only tell you this so you understand the XML file is what's most important. The XML files from the SDK examples would never need to be altered, if you stick to the correct Types.
Dick
<blockquote id="quote"><font size="1" face="Verdana, Arial, Helvetica" id="quote">quote:<hr height="1" noshade id="quote">
- I think that you added GUIDs for the legacy entries in order that we could use shp2vec to generate vector scenery in addition to allow FSX to display vector scenery made for FS9. The XML files required by shp2vec use GUIDs to identify the type of "sister" shapefiles that need to be processed. In the case of Lines I think that there are 6 types of lines ...
<hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">
Luis added the GUIDs to the legacy terrain.cfg defaults because they had no GUIDs. In effect, they could not be used. Note: The legacy VTP was working without this addition. What the GUIDs do is allow new FSX vector polys to use the old shoreline types.
<blockquote id="quote"><font size="1" face="Verdana, Arial, Helvetica" id="quote">quote:<hr height="1" noshade id="quote">
- ... taking your entries 387 and 388 for example, should I use a XML equal to HLX****.XML for the former and one identical to UTX****.XML for the latter?
<hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">
387 is a shoreline type that is just a wave... no beach at all ( HLX type ).
388 is a utility line that does not modify the ground... so it is just the towers ( UTX type ).
<blockquote id="quote"><font size="1" face="Verdana, Arial, Helvetica" id="quote">quote:<hr height="1" noshade id="quote">
As you noticed I removed the legacy entries. Do you think I should keep the legacy entries? After all, the user of SBuilder can just create his own LINES.TXT.
<hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">
I think you can leave them out, as long as the enduser knows he can add them to his own LINES.TXT.
If SBuilder is flexible enough to use the altered terrain.cfg, that's great. The only danger is that someone would release scenery using the altered terrain.cfg, and then not include it with insructions how to add it to the sim. Then we'll have posters claiming SBuilder doesn't work right, when we know it is the new terrain.cfg that wasn't added.
Here's an example:
<i>The new terrain.cfg gets rid of unwanted rocky outcroppings in the water polys ( a bug in the sim... look at Niagara Falls with the default terrain.cfg!!! ). The SBuilder-created scenery uses this new added feature. The enduser doesn't install the new terrain.cfg, and then he complains the scenery is bad and SBuilder is at fault.</i>
Luis and I were a bit hesitant to suggest the new terrain.cfg, but the Aces members were not convinced our changes were needed, and the final FSX release was produced in quite a hurry, leaving no time for us to convince the team to include the changes. I do not know if future updates of the terrain.dll or the terrain.cfg will address the changes we made.
What I suggest is that you include the new terrain.cfg zip file with SBuilder, so designers know it is available, and can distribute it with their scenery if it is used, so we can all avoid confusion in the future.
Another note:
The shapefile types ( EXX, FLX, FWX, HGX, HLX, HPX, PKX, RDX, RRX, STX, UTX ) are, I believe, a type of priority system for shp2vec. The associated XML file actually controls what is displayed... so for example, a waterpoly can be type UTX, if the XML file is adjusted for it. I only tell you this so you understand the XML file is what's most important. The XML files from the SDK examples would never need to be altered, if you stick to the correct Types.
Dick
-
luisfeliztirado
- Posts: 436
- Joined: Sun May 15, 2005 9:15 am
- Location: Santo Domingo
Hello Luis,
I certainly understand your reluctance to adapt your program to this modified file. Obviously, if you don't feel comfortable with the idea, then you shouldn't do it. That is the best thing. Perhaps with time, you will come to find the idea more acceptable.
On the other hand, your market is not the end-user of scenery, but scenery designers, who will probably see advantages in this modified file.
After all, it is nothing more than additions that allow using features that would otherwise only exist in FS 9 scenery (and only available in previous versions of SBuilder.)
It is really up to you to decide if you feel it is interesting to your customers or not. As a compromise, you might decide to create a Lines.txt based only on the default terrain.cfg, but also include a version based on the modified file and allow your customers to choose which they want. Or not, it is up to you.
Perhaps in a few days, you will be able to see if this file has gained wide acceptance in the community. I have placed it in the Avsim library, and I believe that Dick will place it in other sites. So, this might help you to decide.
But, I understand your problem.
As far as the Niagara display problem is concerned, Adam is some kind of perfectionist. This is how it looked before:
He must have seen this picture because it seems that he spent another sleepless night and fixed it. This is how it looks now:
And how it looks with our modified terrain.cfg:
Fortunately, there are a lot of places in the world that Adam did not get around to fix, so our file is still pretty useful.
Best regards.
Luis
I certainly understand your reluctance to adapt your program to this modified file. Obviously, if you don't feel comfortable with the idea, then you shouldn't do it. That is the best thing. Perhaps with time, you will come to find the idea more acceptable.
On the other hand, your market is not the end-user of scenery, but scenery designers, who will probably see advantages in this modified file.
After all, it is nothing more than additions that allow using features that would otherwise only exist in FS 9 scenery (and only available in previous versions of SBuilder.)
It is really up to you to decide if you feel it is interesting to your customers or not. As a compromise, you might decide to create a Lines.txt based only on the default terrain.cfg, but also include a version based on the modified file and allow your customers to choose which they want. Or not, it is up to you.
Perhaps in a few days, you will be able to see if this file has gained wide acceptance in the community. I have placed it in the Avsim library, and I believe that Dick will place it in other sites. So, this might help you to decide.
But, I understand your problem.
As far as the Niagara display problem is concerned, Adam is some kind of perfectionist. This is how it looked before:
He must have seen this picture because it seems that he spent another sleepless night and fixed it. This is how it looks now:
And how it looks with our modified terrain.cfg:
Fortunately, there are a lot of places in the world that Adam did not get around to fix, so our file is still pretty useful.
Best regards.
Luis