Detect ECP

[Blanco]

In my mission there are lots of effectscripts, but a low-end user can disable them all at the start of the mission.

I want all effects disabled when the user 's running ecp mod.

How can I do that?

[Nemesis6]

ECP must have some global variables. Try checking if some of them are true, like this -
? ECP_effectvariable:Dowhatever.

Or just do it in a trigger, where you only have to type the global variable name in the condition box, and do whatever you wish with the activation box.a

I don't know the ECP variables, but you get the idea.

[macguba]

I used a little script called from init.sqs.    If you dig through the ECP folder you will quickly find the master script, which controls all the main ECP global variables.     Your script just sets them to false.

The player can turn most of them back on again, so you might want to loop the script, maybe with hints so the player doesn't get confused.

Code: [Select]

; this script controls ECP (Enhanced configuration project) variables

; turn off explosions at the start
; this reduces lag and avoids mysterious bangs in the distance
; or even more mysterious bangs nearby
; depending on where you start


ECP_expeff_enable = false


; turn off other effects
; these have an effect on the mission so don't turn them back on again
; although it shouldn't cause mission-terminating problems if you do

ECP_h_smk_enable = false

ECP_h_rfail_enable = false

ECP_random_weather_enable = false

ECP_halo_enable = false

ECP_AI_join_enable = false



; these are just turned off to help with lag
; turn them back on again if you like

ECP_jam_enable = false

ECP_lh_enable = false

ECP_pln_smk_enable = false

ECP_alt_enable = false

ECP_keg_snow_enable = false


~1




; turn down some effects to help prevent lag
; by all means turn these up if you kit can take it

ECP_flies_max = 6

ECP_lod_dis = 150



~30


; turn explosions back on again
ECP_expeff_enable = true



exit


[Killswitch]

In my mission there are lots of effectscripts, but a low-end user can disable them all at the start of the mission.

I want all effects disabled when the user 's running ecp mod.

How can I do that?

Check for the existence of and/or value of ECP_initialised and activate/deactivte your mission-specific effects script based on that. An example:

Code: [Select]

; My nifty effects script
? ECP_initialised: exit
...
...
; effects follow, will only be run if player isn't running ECP
...
...

[Komuna]

VERY IMPORTANT!

Don't use those variables! The new ECP architecture has only a few global variables - about 6 - therefore, it's quite probable that your scripts/missions won't be ECPv1.075 compliant.

I would recomend you to use the variable ECP_path, which is the variable that ECP uses to verify is the value database is launched, upon declaring this variable on EH init.

Note: With this variable, you can detect ECP on mission init.
Note2: In order to verify this variable, use the condition "(format["%1",ECP_path]) == _null", where "_null" is that strange value "scalar bool array 0xfddddd-or-something-like-that".

[Killswitch]

Dang. I knew that would come back and bite me in the posterior.  ;D

Thanks for informing us of the new system!

[THobson]

I do not have ECP.  How can I ensure that my missions does not get screwed up when a player with ECP plays it?  

I liked macguba's solution of turning off various variables.  I don't know what they do but some I can guess.  

ECP_random_weather_enable  

for example.  In my current mission I have complete control of overcast, rain and fog and I certainly don't want any other code interferring with mine.

Until I know more, what I need is an ECP_OFF switch.  Is there one?  Is this heresy?

[MachoMan]

Until I know more, what I need is an ECP_OFF switch.  Is there one?  Is this heresy?

Indeed it is!
It can't be done clean but there are some very dirty ways

You could for example change the ECP_path variable, that will make ECP go down!!!  ;D
I haven't tried it, but i fear u might kill ofp too  ;D
You'll at least see massive errors!

-- EDIT:

DOPE komuna already said that, I should read before posting

[Zayfod]

I do not have ECP.  How can I ensure that my missions does not get screwed up when a player with ECP plays it?  

I liked macguba's solution of turning off various variables.  I don't know what they do but some I can guess.   for example.  In my current mission I have complete control of overcast, rain and fog and I certainly don't want any other code interferring with mine.

Until I know more, what I need is an ECP_OFF switch.  Is there one?  Is this heresy?

Once ECP 1.075 is published you will see all those settings that you may turn off for your map if you dont want them in game. Simply choose the ones that you want switched off and make it so (in a script or trigger) when your map starts.   I can't reveal what they are atm but the ECP_settings.sqs is very intuitive, I'm sure you will have no problems.

Zay

[THobson]

Fine.  Thanks.  

It would be helpful if the variables are published in a way that will not require everyone to download it, and then understand it in order to turn it off.

Also it seems that the ECP is being developed in a way that is not backwards compatible (macguba's solution for an earlier version of ECB would apparently be non-compliant with the up-coming version).  So even if I make my current mission compliant with this coming version of ECP there is no guarantee that it will be compliant with later versions).

I don't want to seem rude, but this feels like vandalism.

[RED]

Then just tell people not to use the ECP If you really don't want your mission to be effected by the ECP tell people not to use it, it will be their own fault if the mission gets screwed up because of it.

Regarding the new format of variables, it is not vandalism, it is the most constructive change to the ECP for a long time - It will have heaps of positive effects.

RED

[THobson]

I am sure it is wonderful, and I am sure I will really appreciate it when I get to it.  

I was reacting to the lack of backward compatibility.  If a mission builder deals with ECP in their mission (as macguba has done in his) I do feel they have a right to expect that future versions of ECP will not screw them up.

I think if I were him I would be quite irritated by the comment above that what he has done could make his mission non-compliant with the next version of ECP.

[RED]

I understand what you are saying, but as the ECP is still in the beta stage, things will always be changing and thus backwards compatiblity will not always be possible. Im sure people wouldn't mind changing a few lines of script in their missions inorder for them to work better would they?

RED

[macguba]

Actually I am bloody furious.    ECP, for all its great strengths, is capable of totally screwing up my mission.   (Weather routines and explosions in particular.)   I have spent a great deal of time digging into ECP to see how it works, fixing the variables, testing and so on, and now you tell me I have to do it all again!

THIS IS A DISGRACE.    

If you want to create a new, better ECP using a different architecture that's great, I'm all in favour.     But it is YOUR job to include in that architecture the appropriate routines to keep old missions working.     All I've done is set variables LIKE YOU TOLD ME TO DO so fixing the architecture shouldn't be too difficult.

So yes, I mind a great deal about changing a few lines of script:-

a) on principle

b) its not just changing a few lines ... I have to understand the new ECP (which you already understand), revise my understanding of the old ECP (which you can probably remember), figure out how they relate to each other (which you already know) and then invent a new fix, test it, then release a whole new version of my mission.      It's a big mission and obviously for a release version everthing has to be tested (in case the change have introduced a bug) which takes a long time.    Its hard to predict but I would guess I'm looking at 25-50 hours of work.


Backwards compatability is an axiom of good software design.


ECP is great, I don't want to tell people not to use it.   I like using it myself on this mission.   It has lots of wonderful effects which really improve the atmosphere, which is an important element of the mission.    That is why I went to so much trouble to make it work with ECP.    You guys have done such a fantastic job in creating it it would be a dreadful, dreadful shame to piss it away like this.

[RED]

Ok, I agree with you on all your points apart from 'b', it would only take a matter of minutes to change. For example if you wanted to turn the weather off you would change:

ECP_random_weather_enable =false

Code: [Select]

; ECP_random_weather_enable:
   ; true / false, default is true
   ; defined by server in MP
ECP_public set [19, false]

No testing should be requires as it will operate exactly the same as the old version, only the way the scripts are executed are changed.

Having said that, 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.

RED

[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: