Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Levi]

I've noticed there's a "parameters" property/field within the .objdef files. The Tatra is using it to determine the truck's version(with and without bed). I know it's a parameter that can be accessed from JavaScript, and can be used to hide certain parts, for example.

Now, the problem is that I can't make use of it with aircraft. Is it something that only works within the init_chassis event, and therefore only with vehicles?

It would be really useful to have access to that property, so I can properly make different versions of the same plane.

[PytonPago]

What should be the differences ? If a concrete version of the aircraft by adding few modded meshes, then simple hiding at the scripts start should do, for each variants defined by .objdef file ...

[Levi]

What should be the differences ? If a concrete version of the aircraft by adding few modded meshes, then simple hiding at the scripts start should do, for each variants defined by .objdef file ...

Well, the difference would be that I won't have to duplicate the .js file for each variant. That's what you did with your Ural, if i'm not wrong. Instead, you could simply make use of "parameters" property without having to duplicate anything.

If it's not possible to access to "parameters" field using aircraft physics, then I have no choice but to duplicate the .js file...

[cameni]

Aircraft currently doesn't pass the parameters to its initialize event, but I will add it.

[Levi]

Aircraft currently doesn't pass the parameters to its initialize event, but I will add it.

That's great, thank you very much Brano!

[PytonPago]

Well, the difference would be that I won't have to duplicate the .js file for each variant. That's what you did with your Ural, if i'm not wrong.

... i use that for another reason, i want all the changes to the engine script properties (whyle im working on them) being usable on all variants, whyle im tampering whyte it, so i ID-d all the parts and made a simple IF scripting for each version bunch bound to a parameter to change them (and also to keep in check, what parts were imported properly n seek of inverted normals (holes in model)) - when its done il make the other variants just copies of it whyte its specific scripts aditions. So its more an convenience whyle im adding new modeled modules and their parts into it. Doe, its true, it may come in handy for some of them (like bumper types), but still, all specific ones will have separate scripts for one simple reason - i cant put the script for using the Air-pressure vehicle and the BM-21 launcher in one single file. It would not only result in 150 000 line .js script, but also a messy work when someone ewer want to make changes in them - simply, potential modders would kill me in sleep. (an you would be surprised how often i get lost in the actual)  ... so yes, if its just cosmetic, its nicely useful (mind that textures are handled nicely trough the material files and im sure some way will come to change them on the fly on a single "object" too in time - simply for the usability of that approach). But if there are some simulation or more broad scripting differences between the versions, you better make it in separate ones ... doe, its a really nice thing for external payloads on fighter planes or special equipment on civil ones.

[Levi]

... i use that for another reason, i want all the changes to the engine script properties (whyle im working on them) being usable on all variants, whyle im tampering with it, so i ID-d all the parts and made a simple IF scripting for each version bunch bound to a parameter to change them (and also to keep in check, what parts were imported properly n seek of inverted normals (holes in model)) - when its done il make the other variants just copies of it with its specific scripts aditions. So its more an convenience whyle im adding new modeled modules and their parts into it. Doe, its true, it may come in handy for some of them (like bumper types), but still, all specific ones will have separate scripts for one simple reason - i cant put the script for using the Air-pressure vehicle and the BM-21 launcher in one single file. It would not only result in 150 000 line .js script, but also a messy work when someone ewer want to make changes in them - simply, potential modders would kill me in sleep. (an you would be surprised how often i get lost in the actual)  ... so yes, if its just cosmetic, its nicely useful (mind that textures are handled nicely trough the material files and im sure some way will come to change them on the fly on a single "object" too in time - simply for the usability of that approach). But if there are some simulation or more broad scripting differences between the versions, you better make it in separate ones ... doe, its a really nice thing for external payloads on fighter planes or special equipment on civil ones.

That makes sense now! Though, in my case it's just for hiding meshes, nothing more.

For endless scripts, we should be able to split the script in multiple files, just like JSBSim does. That way we could properly organize our scripts, without getting lost between thousands and thousands of code lines...

[PytonPago]

Tha, im bad at da scripting as it is, no need to rise the plank so soon.