New mergeConfigFile scripting command

[CarlGustaffa 4]

Well it was only an idea. As far as I see it you're already getting these "hints" as "updating class..." when starting with an addon. And this command isn't something you constantly do. I'm assuming only once per mission start, where you might include several config changes/addions, before merging. Most certainly it won't "blow it up" :)

When did your config work alone reach hundreds of MB? It doesn't replace complex addons, but it allows small stuff that you might want to do while staying addon free. Like creating (proper) artillery flares for a mission that can be delievered at correct altitude, burn for correct time, and have an output that actually makes them usable.

Edited October 6, 2010 by CarlGustaffa

[whisper 0]

This command is definatly a wonderful development tool,

but to prevent other problems or dirty things like adding hundreds of MB to mission files instead of an addon,

i think at the best that this command should work only from preview mode of the editor.

This command doesn't do anything more than add configuration parameters and classes. There won't be anything near 100's of Mb of missions because of it

A bit shortsighted to stop this kind of helpfull develeopment just for fear if big missions download, tbh...

Edited October 6, 2010 by whisper

[Gnome_AS 10]

This a very powerful and helpful tool for mod developers. And as stated by BIS, that is the intended purpose. I personally very much appreciate BIS dropping this in, and would hate to see the intended benefit be taken away.

On the flip side, in it's current state, it can cause some issues when/if utilized for purposes unintended. While I personally don't think it's anything to fear, I understand the concerns here.

At the end of the day though, for me, the benefit far outweighs any fears I have in maintaining our dedicateds and the missions we put on them. I'd rather see this:

Quoting Dr. Hladik:

It seems i'll have to disable this command for MP missions and make sure that nobody will join with edited data.

Rather than seeing the command removed, if something is to be done. I also share the thoughts on the mission maker side though, where this again can also be an awesome tool. Granted it comes with inherent/known issues. It's a responsible usage thing in my mind.

Anyway, much appreciated BIS! :cool:

2 cents from the guy in the backyard,

Gnome

[Lester 0]

This command doesn't do anything more than add configuration parameters and classes. There won't be anything near 100's of Mb of missions because of it

A bit shortsighted to stop this kind of helpfull develeopment just for fear if big missions download, tbh...

You can bet that it isn't possible to put paa and p3d files in the mission folder and set this "addon" via mergeconfig ?

I never said stop this very helpful development tool ... try to re-read my post. ;)

[whisper 0]

I can bet cause I tested ;) You can't reference files in the mission's directory from a config file inserted through mergeConfig, you can only reference files in the game's virtual filesystem, which doesn't include the mission folder, only data and addons files present at game start

[Master85 1]

I can bet cause I tested ;) You can't reference files in the mission's directory from a config file inserted through mergeConfig, you can only reference files in the game's virtual filesystem, which doesn't include the mission folder, only data and addons files present at game start

you'll lose your bet :p - you can reference files in the mission's pbo (during the mission)

Edited October 7, 2010 by Master85

[TRexian 0]

Ah! But, that's somewhat better from an anti-cheat perspective. :) Someone cannot reference a new object that is external to the mission, or the loaded-at-startup mods? Servers can lock down the allowed mods to make it more difficult for someone to do something REALLY wacky?

[whisper 0]

you'll lose your bet :p - you can reference files in the mission's pbo (during the mission)

Example of config file for this one, plz. Like pointing to a .p3d located inside mission folder. Tried hard without success, and several @DH told me to abandon all hope :)

Edited October 7, 2010 by whisper

[rundll.exe 12]

you'll lose your bet :p - you can reference files in the mission's pbo (during the mission)

I'd like to know how also ;)

[Master85 1]

for a SP mission on Desert:

model="\missions\__cur_sp.desert_e\modelname.p3d";

for a MP mission on Desert:

model="\mpmissions\__cur_mp.desert_e\modelname.p3d";

:cool:

[soul_assassin 1723]

We know we should, but unfortunatelly we are probably not able to do it. The basic underlying technology which we are currently missing for this is loading (and unloading) addons on the fly. This is very difficult and it is unlikely it will be ever done for Arma 2.

That makes me cry at night :(

Anyway, thnx for this.

[PuFu 4591]

That makes me cry at night :(

Anyway, thnx for this.

You are a softie alex...

[snkman 351]

May could we get the ability to use a custom directory too instead of the user/mission directory only?

[whisper 0]

for a SP mission on Desert:

model="\missions\__cur_sp.desert_e\modelname.p3d";

for a MP mission on Desert:

model="\mpmissions\__cur_mp.desert_e\modelname.p3d";

:cool:

FFS I tried that, but couldn't get it to work :( Gonna check what was wrong this evening

[Crowe 0]

What happens if you create a global custom vehicle via createvehicle, and another player joins via JIP ?

Can you use this via __EXEC(mergeconfigfile ... ) in description.ext?

[Master85 1]

What happens if you create a global custom vehicle via createvehicle, and another player joins via JIP ?

Can you use this via __EXEC(mergeconfigfile ... ) in description.ext?

can only say: idea of the day!!!

tried it and it works.

[Crowe 0]

Master85 be careful you are about to crash every dedicated server which you put your missions on!

[Master85 1]

Master85 be careful you are about to crash every dedicated server which you put your missions on!

tried it with the latest beta server and it worked flawlessly

Edit:sure, that doesn't mean that there aren't / won't be any problems - but anyone has to try it

Edited October 9, 2010 by Master85

[Baron von Beer 0]

Guessing it can't be made to run at mission start, IE not the 2nd run of the mission? At least for me, one nice thing would be to disable the medical ability of vehicles for some missions without requiring an add on.

While I prefer having the physical ambulance HMMWV/M113, I still prefer the medics inside be the Saint of Second Chances. :)

Do understand this is mostly for addon making though, not having to exit & restart to test every little tweak.

Edited October 10, 2010 by Baron von Beer

[CarlGustaffa 4]

I would be very careful trying to use this command in a mission. Has an ugly tendency to break the mission. At least it broke my Domino (Domination edit), in the sense that not a lot of things was working anymore.

[maruk 80]

Quick heads up:

Currently, we think best way ahead with merge config is to implement it in a way that its use will report like if a new modification was installed with each use of the command.

This way, command will be available for free use without risking mp abuse of the command.

There is no specific ETA for it but we consider it high priority and we plan to release it no later than in next final patch release.

[rundll.exe 12]

Quick heads up:

Currently, we think best way ahead with merge config is to implement it in a way that its use will report like if a new modification was installed with each use of the command.

This way, command will be available for free use without risking mp abuse of the command.

There is no specific ETA for it but we consider it high priority and we plan to release it no later than in next final patch release.

That sounds like a good solution, but what does this mean for the MP-usefulness of this command? I assume you can't join a server that has issued mergeConfig in a already running mission, since it has different data at that moment?

And what about a client that issues mergeConfig while in a MP game? (trough a locality check in the mission for example). Will he get a "modified data" message at that moment?

[whisper 0]

That would mean yellow flagged server and client dropped due to modified config, I guess.

Seeing the command has heavy impact on several scripting aspect (borking units count and things like that), it looks wiser to drop its usage for pure MP, unfortunately.

Which means BI should keep working HARD on implementing some in-game addon management solution

[Wolfrug 0]

So this would basically create a situation where SP missions can be as crazy as they want without needing an addon-based solution, whereas MP missions will still be lugging around those heavy old .pbos. Isn't this a little back-asswards? Seriously, I thought minimizing addon dependencies for MP was THE holy grail for all multiplayer gaming in the OFP/Arma series!

That said, I'm very excited over this new command. I just tried it, and it's quite awesome; it essentially makes the addon version of my RUG HD addon completely redundant, since now ANYONE can change dispersion values (for instance) on the fly! Of course, you still need to be able to write a config, but hey...

I do think that there needs to be a _strong_ drive towards using tags what with this new command, though. NO "script addons" should ever be accepted without them being properly tagged. I don't want to be in a situation where some n00b overrides half the default configs with his own bullshit, only to find this has bled into every other mission I play that day, forcing me to restart the game just to get rid of the extraneous config crap.

Sadly, considering not even real addon makers making real addons are capable of tagging (not to mention the failure of scripters in this regard), I'm somehow nervous about how this thing is going to look like when it's out there for real.

Is it possible, BIS, to make it mission-specific? E.g., if I run it in mission.x, the changes it makes will not transfer beyond the mission where the mergeconfig command was run? That could solve a lot of problems, potentially. Even better: why exactly is this being run as a script command, instead of as a part of the description.ext? A simple #include "Addon/config.cpp" in the description.ext would be much, much, much simpler! It wouldn't change anything for the addon editor: you'd still just save the config.cpp with the changes and then save the mission and then try it. The difference is that it'd run as the mission starts by default. Also, that would add all the new classes etc to their appropriate slots in the editor from the beginning, and hopefully also keep them there between saves/loads (now, as I see it, if you add e.g. a custom logic module you've made with mergeconfig, it will just disappear after restarting the game and loading the mission again). By instead allowing this to be inserted directly into the description.ext, you'd basically give us what we've been clamoring for since the beginning: mission-based addons :)

Pretty awesome stuff, nonetheless!

Regards,

Wolfrug

[maruk 80]

I believe this was explained in good detail before but I will try to summarize it again:

it touches the very low level parts of the engine and allowing this command to be mission specific would require major overhaul of many parts of it that would take many months of work with extremely high risk of braking many aspects. So certainly not possible for any patch.

The way we want to design it in the end is that in sp it will be possible to use it as well as in mp on any server that is not worried about cheating.

So this would basically create a situation where SP missions can be as crazy as they want without needing an addon-based solution, whereas MP missions will still be lugging around those heavy old .pbos. Isn't this a little back-asswards? Seriously, I thought minimizing addon dependencies for MP was THE holy grail for all multiplayer gaming in the OFP/Arma series!

That said, I'm very excited over this new command. I just tried it, and it's quite awesome; it essentially makes the addon version of my RUG HD addon completely redundant, since now ANYONE can change dispersion values (for instance) on the fly! Of course, you still need to be able to write a config, but hey...

I do think that there needs to be a _strong_ drive towards using tags what with this new command, though. NO "script addons" should ever be accepted without them being properly tagged. I don't want to be in a situation where some n00b overrides half the default configs with his own bullshit, only to find this has bled into every other mission I play that day, forcing me to restart the game just to get rid of the extraneous config crap.

Sadly, considering not even real addon makers making real addons are capable of tagging (not to mention the failure of scripters in this regard), I'm somehow nervous about how this thing is going to look like when it's out there for real.

Is it possible, BIS, to make it mission-specific? E.g., if I run it in mission.x, the changes it makes will not transfer beyond the mission where the mergeconfig command was run? That could solve a lot of problems, potentially. Even better: why exactly is this being run as a script command, instead of as a part of the description.ext? A simple #include "Addon/config.cpp" in the description.ext would be much, much, much simpler! It wouldn't change anything for the addon editor: you'd still just save the config.cpp with the changes and then save the mission and then try it. The difference is that it'd run as the mission starts by default. Also, that would add all the new classes etc to their appropriate slots in the editor from the beginning, and hopefully also keep them there between saves/loads (now, as I see it, if you add e.g. a custom logic module you've made with mergeconfig, it will just disappear after restarting the game and loading the mission again). By instead allowing this to be inserted directly into the description.ext, you'd basically give us what we've been clamoring for since the beginning: mission-based addons :)

Pretty awesome stuff, nonetheless!

Regards,

Wolfrug