• Which the release of FS2020 we see an explosition of activity on the forun and of course we are very happy to see this. But having all questions about FS2020 in one forum becomes a bit messy. So therefore we would like to ask you all to use the following guidelines when posting your questions:

    • Tag FS2020 specific questions with the MSFS2020 tag.
    • Questions about making 3D assets can be posted in the 3D asset design forum. Either post them in the subforum of the modelling tool you use or in the general forum if they are general.
    • Questions about aircraft design can be posted in the Aircraft design forum
    • Questions about airport design can be posted in the FS2020 airport design forum. Once airport development tools have been updated for FS2020 you can post tool speciifc questions in the subforums of those tools as well of course.
    • Questions about terrain design can be posted in the FS2020 terrain design forum.
    • Questions about SimConnect can be posted in the SimConnect forum.

    Any other question that is not specific to an aspect of development or tool can be posted in the General chat forum.

    By following these guidelines we make sure that the forums remain easy to read for everybody and also that the right people can find your post to answer it.

SceneryDesign.org team looking for reinforcement

arno

Administrator
Staff member
FSDevConf team
Resource contributor
Messages
34,340
Country
netherlands
Until now SceneryDesign.org has been mainly a one-man show (or two-man show if you include all the discusions I have had with Nick about the tools). But now I think it is time to let the team grow a bit.

Lately I have been rather busy with coding new ideas (and I enjoy that a lot of course), but as my time is limited releases of bugfixes have been delayed a bit. For example new version of Library Creator XML and ObPlacer XML are waiting for release, but I first need to find the time to finish the documentation and installers. The same is true for the docking system pack.

So therefore I am looking for some extra power in the SceneryDesign.org team. For example someone who would enjoy it to help with the documentation or the release management. Or maybe with the actual coding of the tools.

But if you think you can help with other things, I am always willing to listen of course :). So if you are interested or if you have other good ideas, please contact me.
 
Don't know what you're coding in, but I'm able to write in C, C#, Java, and any other language you give me a week to figure out! I can also help with documentation if needed.
 
We are coding in everything :) I stand behind with a Whip for motivation :ziplip:

One key area we need people is the documentation, it has become too much to handle. I have an idea.......

Could someone design a web based application that would allow many people to work on documentation?
 
Arno, im about to go on vacation for a month after a 4 month break from FS Scenery design but would be more than willing to offer my help creating basic tutorials if required.

Jeff
 
Hi Matt,

mattperry78 said:
Don't know what you're coding in, but I'm able to write in C, C#, Java, and any other language you give me a week to figure out! I can also help with documentation if needed.

Indeed forgot to mention that. At the moment most tools are made with VB6 and C/C++ for the FS modules.

But I would also like to mention that this should mainly be fun, as it is a hobby for us all. So I do not plan to force anyone to learn a new language just to help me. You should help with what you find fun to do (and can do).

Some help with coding the FS modules in C/C++ could indeed be useful. For the rest it is mainly the documentation as Nick already mentioned. It is usually rather easy for me to fix a bug or add a new feature in an evening. But then it in general takes me another evening to update the docs, installers, etc. Sometimes I just don't have to time to do that for all the tools at the same time.
 
nickw said:
Could someone design a web based application that would allow many people to work on documentation?

Maybe we could use a Wiki system for that. I could install something like that of course. But there are a few reasons I am not sure if a Wiki is really what we want:

  • Not all the users have internet access all the time, so we would need an offline version in some way
  • I would also like to include some docs with the download, not only online
  • It might become a bit confusing as well if we have a forum, a bugtracker and a wiki

But I think switching to HTML documentation or so might be a good idea. Then we can have an online version and include the latest version of these HTML pages with the releases.
 
JeffS said:
Arno, im about to go on vacation for a month after a 4 month break from FS Scenery design but would be more than willing to offer my help creating basic tutorials if required.

Thanks Jeff. I would say first enjoy your vacation and I would certainly be happy to see some tutorials based on user experiences.
 
hey arno,
im not really proficient in a computer language, perhaps that will come at a later stage of my life :p ... But id be interested in helping with the documentation, installers, whatever odd job youve got :scratchch ! i just need a head up bout what needs to be done and so on. But im available if ya need me!

ciao! :cool:
 
Shagster22 said:
But id be interested in helping with the documentation, installers, whatever odd job youve got :scratchch ! i just need a head up bout what needs to be done and so on. But im available if ya need me!

Great, I'll contact you. I first need to figure out in what form the docs will be put. HTML, PDF, etc. Maybe someone has good suggestions for that as well?
 
Actually it does look to be freeware! What a cool find Frank! It's just the "related products" that you are encouraged to purchase before making your free download.

As far as documentation format goes, I'm a big fan of PDF. Everyone should have the capability to view it as it is encouraged that you install it when installing FS9. However, only a few of us have the full Acrobat software in order to help you create the documentation.

HTML can be a good choice if done with good taste and organization. Some people try to get too fancy with HTML documentation and it tends to look bad.

Speaking about code, I am quite familiar with C/C++. VB6 is not something that I know, however I would like to pick up some experience in it. I don't think you necessarily want a newbie to VB writing your code! :D

Anything you need Arno, just send me a message or email!
 
Hi Frank,

helmi said:
for building an online-documentation it would probably useful to use a script like this:

http://www.octeth.com/products/docauthor/

this is not freeware, but i couldn't find anything else until now - maybe there is also something like this as a freeware.

Thanks for this suggestion. It certainly looks interesting (and free as well :)). I will certainly consider this.
 
Hi Matt,

mattperry78 said:
As far as documentation format goes, I'm a big fan of PDF. Everyone should have the capability to view it as it is encouraged that you install it when installing FS9. However, only a few of us have the full Acrobat software in order to help you create the documentation.

For all the manuals I made until now I used LaTeX. This is a totally free as well and allows you to create nice PDF files. But the LaTeX syntax might not be that easy to use for everybody, that is also way I am now considering different ways to create the manuals. We need something that different people can easily work together on I think.

mattperry78 said:
HTML can be a good choice if done with good taste and organization. Some people try to get too fancy with HTML documentation and it tends to look bad.

When using HTML I would prefer to keep it as simple as possible. So just using the standard HTML commands and no special colors, fonts, animations, etc. It should be about what has been written down, not about how it looks.
 
I have done a little test with a wiki system (DocuWiki in this case). I must say I like the looks of it and it would also allow mulitple people to work on the manuals etc. Here is a test I made with the Library Creator XML manual:

http://www.scenerydesign.org/wiki/doku.php?id=manuals:library_creator_xml

How do you, as users, think this looks? Would that be useful as a manual? With the downloads we could then of course put a static HTML version of this page.

Don't look at the color schema etc at the moment, I still need to tweak that. But for a first test that is not the most important of course :).
 
English language proofing

Hi Arno.

If you need any English language proofing, give me a yell. Your documentation'is pretty good, but I'd be happy to look over anything in the future. I do this editorial stuff quite a bit at uni.

Cheers,
Matthew.
 
arno said:
I have done a little test with a wiki system (DocuWiki in this case). I must say I like the looks of it and it would also allow mulitple people to work on the manuals etc. Here is a test I made with the Library Creator XML manual:

http://www.scenerydesign.org/wiki/doku.php?id=manuals:library_creator_xml

How do you, as users, think this looks? Would that be useful as a manual? With the downloads we could then of course put a static HTML version of this page.

Don't look at the color schema etc at the moment, I still need to tweak that. But for a first test that is not the most important of course :).


It gets my vote Arno.
 
I have some code C# that will load a MDL or BGL file (a file directly exported from GMax, it probably does not really like manual tweaks). Let me know if you think you can use it - only condition is that I want access to any changes or additions made to the code.

It decompile the file and loads it into an object model (hence separating it completely from the source format allowing additional formats to be supported). Currently only polygons and lights are supported - next step is animations and effects. The object model does handle LoD.

The system consist of a number of transforms (well, two at present, but it will be expanded as time allows). A transform will take a 3D model as input and change it. It is itself considered a 3D model, and can hence be used as input for another transform.

I write though a scenery object (to allow the models to be combined in fewer BGL files) but it would be easy to reexport to MDL format. While I attempted to export in both FS2002 and now FS2004 format something is wrong in the FS2002 format resulting in FS crashes (FS2004 handles the FS2002 export fine). I do not know how serious this problem is - I have never bothered to debug it as I consider FS2002 dead.

The two transforms I currently have are:

AutoLoD - creates LoDs. Not as good as manually constructed LoDs obviously, but better than nothing.

Texture - Change the name of a texture (with support for seasonal textures), add/remove light map (TODO: Support randomness in the texture name to allow quickly generate a bunch of cars, boats, etc with different texture).

Other transforms I have planned are:

Grouping - simply groups certain part of the model based on texture or material - it willl be used to allow other transforms to modify only a part of the model (for example tilt the boat based on the wind, leave the wake flat)

Animate flag - Cycle though bitmaps (ideal if I could find an algorithm to generate more or less real looking bitmaps from a flat image of the flag, but this is tricky). Could select texture based on wind strength.

Rotate based on variable. Could be used to rotate to the wind, but also to tilt a sail boat based on wind strength (after turning it so the sails are positioned correctly with regards to the wind obviously). It should support grouping so only the boat is tilted, the wake remains flat. Could also be used to rotate the wings of a windmill etc without animating it in GMax (you can do both obviously). It could also support a "sinus pattern" movement (boarts in waves for example), but this might be another transform.

Conditions - A generic system to define conditions (time, weather, etc) that can be used to determine if an object (or part of it) is displayed. For example a windmill could have a transform copying the rotating roter in three variants - one standing still, one moving slow, and one moving fast. It would then use a condition on the wind strengh to display only one. A flag could be shown only in day time, and maybe only on "flag days".
 
Hi Lars,

Thanks a lot for the offer. As you have probably read above I do most coding still in VB6, so I don't think that your C# code will help me much while coding on my tools (trying to convert between different languages probably costs more time than writing it again).

As you might have seen I am working on a new MDL Tweaker version already and I have already finished some code that can read a MDL file directly and then tweak it.

But if you want to release your tool on this site as well (as part of the SceneryDesign.org team) that is fine with me of course. We could also discuss things we come across while coding MDL/BGL file readers and learn from each others errors.
 
Last edited:
If you change the MDL format directly you are right - you can't use the code for much. I had code manipulating BGL files, but did not reuse any of it with my new object model.

There will probably be some similarities between the modifications you do and my writer, but my writer is still rather rudementary (as it did not exist a week ago). :)

I do not have plans to do a real release in the near future, as I do not have time to support it. It would also need some GUI or command line arguments. The current GUI is tied into our server/client application, but as the code has 100% separation between GUI and business logic its no big deal - so if anyone is interested and know how to program a .NET language drop me a mail and we can work something out.

So far I have only worked with the (more or less) documented parts of the MDL format. The next step is decoding the animations (still trying to figure out exactly what the three int parameters to BGL_SCENEGRAPH_ENTRY are and why BGL_TRANSFORM_INDIRECT takes two parameters). After that it is on to the ATTO RIFF chunk... I just hope I'll make it before the next version of FS. :)
 
Back
Top