[Mobius]

Whenever I'm interested on a Scripting feature I read of many restrictions to its use and fear problems of compatability. Is it possible to spread the use of Scripting?

Is there a way to make all FS Open builds compatible to most scripting features? What if I want to release a campaign that makes use of Scripting? Is the campaign going to be playable for many years?

Thanks in advance.

[Nuke]

the reason scripting is being slow at catching on is that everyone using scripting is involved in a long term mod project. some of the bigger mods want to keep their features under wraps. so while of script is being developed, most of it is done out of public view.

scripting, while stable for the most part, is still somewhat experimental. some mods are reluctant to use it because the requirement to use head builds. long term mods can get away with it cause theres a good chance the current line of features will be in the stable branch before their projected release dates.

the scripting system is also a huge can of worms as far as a feature goes. since its such a big feature its gonna take time to get it all together. plenty of time to learn lua btw . its not a hard language to use.

[Mobius]

I already have something to use in a campaign(more stuff will follow ). You're saying that I need head builds, right? Are they always compatible with Media VPs and other MODs?

Are there any problems connected to the use of head builds?

[Nuke]

other than potential for pilot file corruption, no.

i typically develop scripts with vanilla data only, no mods no media vps. this causes fewer problems, especially when using cutting edge builds. i include mod data only for the purposes of testing a script. for example if im modding a gatling turret, it would require one as part of a mod because freespace doesnt have any. this does not mean that the script in its final form must run without mods. it just saves of headaches. mod data too can be full of bugs, and i perfer to eliminate those bugs from the pool of things tat can go wrong.

as for perfered builds, theres a thread here for that.

[Mobius]

other than potential for pilot file corruption, no.

i typically develop scripts with vanilla data only, no mods no media vps. this causes fewer problems, especially when using cutting edge builds. i include mod data only for the purposes of testing a script. for example if im modding a gatling turret, it would require one as part of a mod because freespace doesnt have any. this does not mean that the script in its final form must run without mods. it just saves of headaches. mod data too can be full of bugs, and i perfer to eliminate those bugs from the pool of things tat can go wrong.

How do I fully integrate scripts in a MOD?

[Nuke]

theres a whole bunch of things you can do. custom tables, for example. fred integration, or you can make your script entirely mod-independant. mod data is really just extra game data, so if the script works in fs2 vanilla, it should work just as well in a mod.

[WMCoolmon]

Right now there are two big sets of scripting, the HEAD branch and the stable branch. The stable branch is basically completely different from the HEAD branch. The HEAD branch is much better, and has all of the scripting improvements that've been done in the last year or two. It's been a long time.

I thought the pilot file corruption bug was fixed but I don't know. That's an ask-taylor thing.

Basically, the stable branch scripting is not forwards compatible, and the HEAD branch is not used for official releases (nor is it necessarily stable). I don't really like cutting off potential mod opportunities like that, but it's already going to be one hell of a job ever getting the stable branch stuff working with the updated scripting system stuff. Changes to the stable branch are supposed to be committed to HEAD as well, but that's not the reality of things at all, so there's an unknown number of scripting functions that may have to be updated to work with code that was never committed to the unstable branch.

What it means is that whenever scripting does become a part of an official release, scripts will have to be updated by changing things like

Code: [Select]

mn.getShipByName("Alpha 1") to

Code: [Select]

mn.Ships['Alpha 1']

[Aardwolf]

I realize it's been more than a month, but...

Would it not be possible to have a simple launcher checkbox or mod.ini entry or something indicating which scripting system a mod uses?

[WMCoolmon]

Well, it's a choice between the old, less stable, and unsupported system and the newer, more reliable, more informative, supported system with mos of the old features and then some - but with slightly different ways of accessing them.

Yeah, of course it would be possible, but at this point I would rather disable the "stable" scripting system entirely for the next release, and then do a microrelease whenever the new scripting system has been moved over to the stable branch. I don't consider it reasonable; I feel like the old scripting system was a rough draft, that it was possibly even a mistake to let it stay on in the stable branch as long as it has because I've never had any intention of supporting since I revised the code based on what I'd learned with the initial implementation.

[Aardwolf]

Ok, I guess I was under the impression that there were released mods out there that made extensive use of the old scripting system and would need to overhaul stuff.

[WMCoolmon]

If there are, I would love to know so that we can work something out.

But what I've heard so far is that mods are waiting for the system in the unstable branch (the more stable system in the unstable branch ) to come out w/ 3.7 before they begin serious coding.