A high-priority request for SYs and other developers

[Caydr]

Hi, I need some attention from Spring developers. I was under the impression for the last month or so that Zaphod would be able to add the functionality I'm about to ask for in the near future, but he's just informed me that he may not complete the radical scripting redesign he had planned.

Basically, using his script system, you could get a unit to have just about any properties you want and, pretty much, do anything you want if you're willing to spend enough time on it.

This is not what I'm asking for.

Of Zaphod's new script system, the one feature that I as a mod developer was really strongly interested in was the ability to create units which do not land and do not execute any kind of mid-air maneuvering, except perhaps a bit of banking when told to turn. Essentially, what I need is a "isspaceship" tag. This would cause the unit it is applied to, to not land, attempt to land, or try to do any kind of mid-air maneuvers. Once it is completed, it simply takes off (or goes to its default cruisealt) and is in the air permanently.

I was depending on this for G/E/M. Basically, without this one tag the mod is impossible to do in any kind of convincing fashion. This tag would have far-reaching consequences, including the fact that every mod that wants to feature spaceship-type units, like a Star Wars mod or Final Frontier, would be able to do so without them behaving like airplanes.

So, what the tag needs to do is:
disable maneuvering
prevent a unit from attempting to land
prevent a unit from flying around as if confused when it's impossible to land

Again I'll admit I have very little programming knowledge at all, but from what I do know, disabling existing functions is a much simpler process than creating new ones.

If this could go in either the next, or one of the next Spring releases, I (and many others) would greatly appreciate it. I can't emphasize enough - this is a badly needed tag which would have dozens of implementations. It's like how high trajectory has opened up so many new possibilities, similarly this could open up many others.

The Spring community already asks so much of you, but I think you'll agree that requests should be done on a basis of how much better or adaptable it could make the engine.

Please take this into serious consideration. Thanks for your time.

[FLOZi]

I expect the behaviour can be improved considerably with the Spring aircraft tags

[Neuralize]

Currently parts of engine is being totally rewritten, if it's any indication by the test build that Zaphod handed out, it's going to be a awhile before they even get back to where they were with the last release. :/

[Zoombie]

So the next release will have massive performance/visual improvments as the code is hammered out and repaired by the brilliant SY?

COOL!

[FizWizz]

Currently parts of engine is being totally rewritten, if it's any indication by the test build that Zaphod handed out, it's going to be a awhile before they even get back to where they were with the last release. :/

So the next release will have massive performance/visual improvments as the code is hammered out and repaired by the brilliant SY?

COOL!

Reading Comprehension is your friend, learn it.

Neuralize said is that The engine will have some significant overhauls done to it.
He then said "if it's any indication by the test build that Zaphod handed out, it's going to be a awhile before they even get back to where they were with the last release. :/". He is inferring that Zaphod's test build is bugged or unstable, and that it will be a while before it gets fixed up to as stable a condition as the last release", v0.67b3, which itself is stable.
He also did not say a single thing about visual or performance improvements, by the way.

[jcnossen]

Currently parts of engine is being totally rewritten

Most parts aren't really rewritten, just changed a lot to use different API's/libraries. All the code that previously used windows functions (sound, window creation, opengl initialization, file tree handling, fonts) has been replaced by code that uses portable libraries.

So the next release will have massive performance/visual improvments as the code is hammered out and repaired by the brilliant SY?

No, it will not have that, the aim is simply to let it do the same as the current version, only using portable code. It will run just as fast and have the same visuals. Porting is an important step that almost any opensource program goes through... however it will likely not be possible to play with people on a different OS. That is yet another step that needs to be taken sometime.

[edit] FizWizz beat me

[Caydr]

Any response from SYs or other devs about my request? Even if it was just, "it'll be done in the next 3-6 months" or something, that'd be fantastic. (as long as you don't forget)

[clericvash]

I take it this is the step needed to allow it to be ported to other OS's fully?