Detect ECP

[THobson]

Im sure people wouldn't mind changing a few lines of script in their missions inorder for them to work better would they?

It all depends on how you define 'better'.  Once a mission has been reviewed it seems to be locked.  It cannot be updated.  So simply changing a few lines of code is not an option.

Backward compatability is an absolute must for any good software

So should publishing a list of variables.

The names of the variables seem to have become rather cryptic in the new version.

[macguba]

I have just started work on a script that will solve your problem. It will just check for the old variables then 'translate' them to the new format. Not perfect but it should work.

Without knowing the technicalities I suspect that would be fine.   :thumbsup:    Thanks for the quick response and the understanding of the problem.    

And I understand your point about it only taking a matter of minutes to change.  In principle, you are of course correct.   In practice its a lot harder.    Don't forget we don't know anything about the new ECP and how it works, so we would have had to figure that out before even starting.   Also, I'm not going to publish a mission unless I'm convinced it works ok, so testing is essential.   It's not so much checking what you have changed, its checking that something has not gone wrong accidentally.

[KTottE]

Backwards compatibility only works so far, the new ECP architecture is very different from the old, and it's very much improved.

To retain backwards compatibility in this case would be to stick to the old architecture, and that's not an option.

Would you people be more comfortable if the next version of ECP was renamed to ECP 2, make you feel like it's a new thing (which it is, basically)?

[THobson]

My view - if it is that different it would help to give it a different name.

So I take it that the variables in the current version don't all have direct equivalents in the new one.  If they did you would only need a mapping table to provide backwards compatability.

[macguba]

"ECP2" implies backwards compatability.

All we are talking about is a bunch of variables which turn various effects off, on, or set them at some level.    All you need is a script which detects the value of these old variables and sets the new variables (or whatever) to the appropriate value.  

Writing that script is very easy for the ECP team and very hard for users.  Plus every user with an old mission has to do it, rather that it being done only once.   Plus the ECP team will do it better.

I can appreciate that there will not always be a perfect match and that some fudging might be required, but again, the ECP team is best placed to figure out the best fudges.

[Komuna]

AhAhAh! Hey, guys, this topic is rather a Software Principles discussion than editing discussion.

Indeed, all users have right to pronounce themselves towards the changes that have been done and the problems that might be acquired from those modifications. And we ARE aware of that. v1.075 is still two or three months away from release and we still have to deal with MP and compatibility issues.
From now on, I recomend every mission maker to check for ECP by verifying the variable ECP_path. I asure you that this variable is so special that it won't be changed in further versions.

Regarding old mission compliance, well, sure we can have a script to detect ingame settings modifications:

Check the nullity of each old ECP var: {if ([ x ] call (ECP_Resources select 0)) then {<CODE>}} forEach [ list of the "names" of the old variables ]

However, some missions check for ECP before changing the settings - in this case, there's nothing we can do except declaring each of the old variables: so, what's the choice? FX overriden or CTD on load?

Indeed, it's a pity, but these changes were made to prevent one of the most serious bugs and, thus, may not be compatible with old mission settings.

Note: for those missions that use the bools "ECP_initialised" and similar, we can easily make a script to declare temporarily those vars and then destroy them. Otherwise,  :-\

[Killswitch]

Might as well ask... what will happen to the following variables that in ECP up to and including 1.072 refers to the ECP event handlers?

• ECP_EH_handler_init
• ECH_EH_handler_fired
• ECP_EH_handler_hit
• ECP_EH_handler_killed

I don't think I can emphazise enough how much I'd "like" to see these still work with future ECP versions. Reason: there are a few addons out there that are ECP compatible and use these names in order to be that.

Furthermore, the "semantics" for an ECP-compatible init EH definition requires the following

Code: [Select]

(format[{%1},count ECP_addUnitsArray] == {scalar}) then {ECP_addUnitsArray = []}; ECP_addUnitsArray = ECP_addUnitsArray + [_this select 0]; _this call ECP_EH_handler_initand I hope that care is taken to have that work as expected in the future. As mentioned, it's just good software engineering to do so
 ;D

[THobson]

A suggestion:

Current ECP uses a set of variable that the mission builder can initialise (see macguba's script)

I presume
- the new version will also have variables that the mission builder can initialise.

- that initialising the current ECP variables will do no damage either if ECP is not running, or if the new version of ECP is running.

- that initialising the variables for the new version of ECP will do no damage if ECP is not running or if only the old version is running.


If all that is correct then could you please just publish a list of the variables for both versions of ECP so the mission builder can initialise them as required.   That won't help the exisitng missions though.

In the meantime:

I recomend every mission maker to check for ECP by verifying the variable ECP_path

Having checked for ECP is there are global OFF switch?  Will it apply to both versions?

[Komuna]

Could we have a list of ECP-dependent addons and missions?
If we make scripts to solve all of these problems, the CTD issue will be back, as long as the tremendous lag that a few PC's might experiment due to the new effects scripting.

 :-\ (Oh, boy...)

#Edit (Just noticed Hobson's post)

Having checked for ECP is there are global OFF switch?  Will it apply to both versions?

Excuse me, but I didn't quite understand what you meant with the first sentence.
Still, I may say that ECP_path is a variable present in both versions and, thus, checking if that variable is null is checking if ECP is loaded.

Note: The old version of ECP declares ECP_path about 0.7 seconds after mission initialisation. The new version declares ECP_path on init - I assume that it might be loaded by briefing time.

Regarding the global variables for ECP settings: well, the new version as no global variables, except a few that work as a list of values for resources and settings. So... We need to find a solution.

[THobson]

Having checked for ECP is there are global OFF switch?  Will it apply to both versions?

Excuse me, but I didn't quite understand what you meant with the first sentence.

What I meant was - can a mission builder detect the presence of ECP and turn it off should they chose to do so?  

ECP has been recommended to me on several occasions.  I have not yet had chance to investigate it yet (frankly I was a bit put off by all the exceptions and incompatabilities listed) but I see variables that refer to random weather and such like and have a concern that weather and other effects built into missions by the mission builder might get screwed up by ECP.

I don't think you need a list of ECP dependant missions and add-ons.  

[RED]

Might as well ask... what will happen to the following variables that in ECP up to and including 1.072 refers to the ECP event handlers?

• ECP_EH_handler_init
• ECH_EH_handler_fired
• ECP_EH_handler_hit
• ECP_EH_handler_killed

I don't think I can emphazise enough how much I'd "like" to see these still work with future ECP versions. Reason: there are a few addons out there that are ECP compatible and use these names in order to be that.

Furthermore, the "semantics" for an ECP-compatible init EH definition requires the following

Code: [Select]

(format[{%1},count ECP_addUnitsArray] == {scalar}) then {ECP_addUnitsArray = []}; ECP_addUnitsArray = ECP_addUnitsArray + [_this select 0]; _this call ECP_EH_handler_initand I hope that care is taken to have that work as expected in the future. As mentioned, it's just good software engineering to do so
 ;D

Hi Killswitch, those variables will indeed be kept intact so addons will not need any modification to work with the new ECP version.

@All: We have come to a decision on how we will handle the old variables with the new ECP structure to ensure that missions and all ECP compatible addons will remain uneffected. Sit tight until the release  ;D

RED

[THobson]

Wonderful.  Thank you

[macguba]

:thumbsup: