"Hard formation" removal - will somebody notice?

[suma 8]

I am contemplating removing the "hard formation" support to clean the formation handling code a bit for further fixes and improvements.

Before I do remove it, I want to verify there is not someone out there using the hard formations, who would badly miss them.

This feature is never used by default, unless a script is specifically reqesting for it. To use "hard formation" one has to call one of the following:

"AwareFormationSoft" enableAIFeature false

"CombatFormationSoft" enableAIFeature false

If you do use this commands, please, post a comment what you use it for.

Edited January 24, 2011 by Suma

[dmarkwick 261]

I don't use this functionality, but one thing I'd be concerned about is it's removal maybe breaking some addon that I do use, I'm thinking about things like the SLX addon suite, which are excellent but don't appear to be maintained anymore. (I use SLX as an example, I don't know if it uses this functionality specifically.) So, as long as it's removal is transparent, I'd be happy to lose it.

However, in the spirit of evolutionary progress, I'd rather the improvements break something I need to lose than not get the general improvements :)

Edited January 24, 2011 by DMarkwick

[suma 8]

I don't use this functionality, but one thing I'd be concerned about is it's removal maybe breaking some addon that I do use, I'm thinking about things like the SLX addon suit

I have created this poll so that if anyone, be it mission designer, addon maker or a mod team is using the functionality, can say it here and we could discuss how to move on. I doubt anyone is using it, as I do not think it brings any significant behavioral improvements, but I want to be sure before removing it.

[.kju 3245]

Some reference data to be able to judge this better:

[60234] New: Scripting function enableAIFeature to disable new AI features when old behavior is required.

BIKI: enableAIFeature

Suma: Changed the way units keep in formation

[Hanzu 10]

In Harvest Red campaign Bitter Chill mission

when NAPA fighters enter FOB Manhattan and you go to talk to them. They automatically line up and stop in some sort of V-formation behind their NAPA squad leader while Cooper and NAPA leader are talking.

I guess here or in any other BIS official missions, it is not done using hard formation command(?) Otherwise it might create some new problems after the change.

Edited January 25, 2011 by Hanzu

[Wolfrug 0]

I'm just curious about why you would want to remove a command once it's been implemented? I had no idea such a thing existed, and I wouldn't be surprised if this was true of the large majority of mission makers/script makers/addon makers here :) Without having tried it, I can't say I'd miss it, but who knows: maybe I would!

So, what's the rationale behind removing it, aside from...I don't know...cleaning up the comref? :-S

Regards,

Wolfrug

[Hanzu 10]

So, what's the rationale behind removing it, aside from...I don't know...cleaning up the comref? :-S

My best guess is that "hard formation" is something that cannot be bypassed and it restricts the ability to tweak AI behaviour even more. So if you want AI to change formation, regroup, take cover and whatever "hard formation" may conflict with those and in some rare cases be one reason why people report AI behaving different than they should by the newest patches.

Suma correct me if my guess is all wrong.

[suma 8]

I'm just curious about why you would want to remove a command once it's been implemented? I had no idea such a thing existed, and I wouldn't be surprised if this was true of the large majority of mission makers/script makers/addon makers here :) Without having tried it, I can't say I'd miss it, but who knows: maybe I would!

The rationale is to simplify code maintenance. Hard formations are not an isolated functionality, and they making harder implementing changes (both fixes and improvements) in other related code, like bounding overwatch routines, as they need to handle both soft a and hard formations correctly.

[maddogx 13]

As DMarkwick suggested, I would recommend making the removal of the feature transparent, if you decide to do so. For me this would mean keeping the scripting command (to avoid syntax errors in legacy code) but removing its functionality and cleaning up your code as intended. Essentially reduce the enableAIFeature command into a stub instead of removing it completely.

[sakura_chan 9]

definitely the most practical solution. I don't think anyone out there has even used this command.

[suma 8]

As DMarkwick suggested, I would recommend making the removal of the feature transparent, if you decide to do so. For me this would mean keeping the scripting command (to avoid syntax errors in legacy code) but removing its functionality and cleaning up your code as intended. Essentially reduce the enableAIFeature command into a stub instead of removing it completely.

This is something I am not sure about. If somebody is out there using the command for something serious, perhaps it is better to notify him. If using will enableAIFeature report an error, perhaps it is better than stopping to work silently?

I am more inclined to cause an error, but I am not sure.

[dmarkwick 261]

This is something I am not sure about. If somebody is out there using the command for something serious, perhaps it is better to notify him. If using will enableAIFeature report an error, perhaps it is better than stopping to work silently?

I am more inclined to cause an error, but I am not sure.

Well, as we're talking in the beta forum, I don't really think it's much of a problem to do it either way, so I would suggest you do it the cleanest way :)

[Fireball 16]

Well, as we're talking in the beta forum, I don't really think it's much of a problem to do it either way, so I would suggest you do it the cleanest way :)

Well all the BETA stuff that get's past the BETA phase will go to the next full patch. Better to remove it altogether and throw the error.

[VictorFarbau 0]

Actually I was using these commands in some complex missions. I hoped to circumvent the sometimes problematic formation behaviour with this.

In my view it would be perfectly ok to silently ignore these commands but log a comment in the RPT file such as "Command XYZ in script file xyz is obsolete as of build 12345. Please remove this from your code."

If the Wiki also gets updated with a related comment sufiicient care has been taken. After all you can also expect hobby scripters to consult error reports and online command references from time to time.

Cheers,

VictorFarbau

[Mr. Charles 22]

I guess it can be replaced with attachto, as i would use this for cutscenes only.

[TommyC81 10]

Remove and improve (more easily)! :-)

[maddogx 13]

This is something I am not sure about. If somebody is out there using the command for something serious, perhaps it is better to notify him.

True, but the question is whether the best way to notify an addon/mission maker of a problem is by making his scripts start throwing errors and thus potentially breaking them entirely. The way I see it, this could cause much bigger problems than just AI formation issues.

If using will enableAIFeature report an error, perhaps it is better than stopping to work silently?

Can you make it report the error without stopping the whole script? That would probably be ok.

I am more inclined to cause an error, but I am not sure.

Neither am I - there are arguments for both sides.

Personally, I'm more in favor of altering functionality instead of making previously valid code throw errors. But that's just me. :)

[suma 8]

In my view it would be perfectly ok to silently ignore these commands but log a comment in the RPT file such as "Command XYZ in script file xyz is obsolete as of build 12345. Please remove this from your code."

If the Wiki also gets updated with a related comment sufiicient care has been taken. After all you can also expect hobby scripters to consult error reports and online command references from time to time.

Great idea.

Consider it done.

[maddogx 13]

Sounds like a good compromise.