New mergeConfigFile scripting command

[dr. hladik 231]

[73625] New: mergeConfigFile script function

1. start mission with AH-64

2. run mergeConfigFile ["c:\Arma2OA\EDITED_CFG\AIR_e\ah64.cpp"]

3. restart mission

4. your chopper should be using data from given config file

[rundll.exe 12]

[73625] New: mergeConfigFile script function

1. start mission with AH-64

2. run mergeConfigFile ["c:\Arma2OA\EDITED_CFG\AIR_e\ah64.cpp"]

3. restart mission

4. your chopper should be using data from given config file

Does that mean we can now alter vehicle properties in-mission? if true, that would be :butbut::yay:

[dr. hladik 231]

Now we can have in-game power-ups for vehicle....

You can not power-up existing vehicle. MergeConfigFile is ment to be editing tool, not "pimp your ride" tool.

[rundll.exe 12]

Well if you re-spawn that vehicle (createVehicle) wouldnt it have the changed config then?

IF you have to re-start the mission before effect, its pretty useless command, isnt it?

EDIT:

re-reading your post, it's meant for editors, so they can change/test their config witout re-starting the game each time. Is that correct?

Edited September 30, 2010 by rundll.exe

[whisper 0]

As far as I understood here and there (Rommel did some tests yesterday), you can add classes derived from base classes on the fly in the config file, then createVehicle them.

This is just awesome.

[rundll.exe 12]

As far as I understood here and there (Rommel did some tests yesterday), you can add classes derived from base classes on the fly in the config file, then createVehicle them.

This is just awesome.

Im testing it right now, and it seems to work nicely. I DOES support loading config files from the mission directory, if you give the second argument as false:

mergeConfigFile ["config.cpp", false];

after this command you can do a createvehicle, and your new vehicle will be ready

The config change is persistent for your game session tho, so If you close the mission and start a new one, your new vehicle will still be available.

This is potentially a bad thing, since if you overwrite a original vehicle class, you could break other missions using it. :(

[rundll.exe 12]

Now, of course, can we get a 'revert' type command? :D

That would be the simplest solution, but if a lousy mission maker doesnt use the revert command, he can still break other missions...

Actually it would be best if the main BIS config is "merged" each time a mission loads, but then the intention of the command to change configs for editors is broken (you cant createvehicle everything)

hmm enough to think about, and play with.

BTW, after fiddling around with this command, I found myself flying around in a power generator firing hydra's in the desert :p

[-)rStrangelove 0]

Uhm, since the p3d model is in a config too does this mean we can switch models with mergeConfig? Even the player?

Then it's possible to script actions like 'Disguise yourself as enemy officer'. Now that would be awesome for undercover missions. :)

[rübe 127]

[73625] New: mergeConfigFile script function

This is friggin tits!

... but I hope that the config will be reset after the mission in future patches.

Indeed. Please reset/clean the environment (or in this case the config-tree) prior to launching a new mission. Otherwise this will get ugly (as is currently with setVariable for world-objects, see http://dev-heaven.net/issues/13620).

[tj72 0]

Quote:

[73625] New: mergeConfigFile script function

This is friggin tits!

Why? Will this allow us to override the nativefsm for AI by script? Just curious about what this command can do.

[rundll.exe 12]

2 things:

1 - without pics, it didn't happen ;)

2 - when will that mod be released? :D

1:

2:only 3 lines of code, and 2 lines of config (without the inheritance)

init.sqf

private ["_heli"];
mergeConfigFile ["config.cpp", false];
sleep 1;
_heli = "AH64D_ger" createVehicle (position player);
sleep 1;
player moveInDriver _heli;

config.cpp

class CfgVehicles {
class Air;	// External class reference	
class Helicopter : Air {};	
   class AH64_base_EP1 : Helicopter {};
   class AH64D : AH64_base_EP1 {};

class AH64D_ger : AH64D {
	displayName = "Flying power generator";
        model = "\ca\misc_e\PowGen_Big_EP1";
}	
};

place them in a mission folder, and off you go!

[TRexian 0]

LMAO

Serves me right for being a smartass. :D

Oh, and I guess with some decent config-writing, that is, making new classes rather than over-writing classes, the un-merge or revert command may not be totally necessary. Still thinking that it will be a cool thing for mission-makers to be able to add mission-specific config classes. :)

I wanted to do that once... only now I can't remember why!

[Big Dawg KS 6]

I'm concerned. All this on the fly config merging seems pretty dangerous. It's too easy for someone to use this to cause bad things to happen: intentionally or not.

[rundll.exe 12]

I'm concerned. All this on the fly config merging seems pretty dangerous. It's too easy for someone to use this to cause bad things to happen: intentionally or not.

Agreed, it's dangerously powerfull, and game-breaking in many cases if a mission designer is uncarefull.

[rübe 127]

so what? Dividing by zero is even more dangerous, yet nobody prevents you from doing it either. :D

[CarlGustaffa 4]

What stops a smucker from creating his own classes on the fly? I haven't played with this command yet. Although I share the concerns, I'm at the same time ecstatic about the possibilities it offers. Not something I'm going to make my mission dependent on at this time though.

Edited October 1, 2010 by CarlGustaffa

[Zipper5 74]

It would have been less likely a hacker would come into knowledge of this had you not brought it up on the official forums. Just sayin'. ;)

Most of them have gone on to the next shiny toy.

[TRexian 0]

Actually, I think BD has a pretty good point. I'd almost say they should attach an EH or something to it, so it can be captured somehow. Or, probably even better, a command to disable it altogether.

[CarlGustaffa 4]

K, point taken. Renamed the bastard so he won't find anything in searches. But chances are they already reading the forums, so...

Yes I agree. Global command in mission to disable/enable it, EH to track it, and maybe Event Scripts as well (who just tried to perform a merge on the client?). Notify the server at least. Just thinking wild here.

Edited October 1, 2010 by CarlGustaffa

[dr. hladik 231]

I'm concerned. All this on the fly config merging seems pretty dangerous. It's too easy for someone to use this to cause bad things to happen: intentionally or not.

Yes, you are right. It seems i'll have to disable this command for MP missions and make sure that nobody will join with edited data. Purpose of this command was just to simplify creating of new vehicles.

[celery 8]

It seems i'll have to disable this command for MP missions

Please don't. The command can give absolutely stunning new possibilities expressly in multiplayer, because small config changes wouldn't require addons which at the moment are a very big obstacle in online play. For example, it can enable faster cars, more accurate handguns, TI equipment for vehicles that don't have it, and so on. It's just that it needs to be reset either before or after a mission.

[f2k sel 164]

Has anyone done a how to use the new mergeConfigFile?

I tried using the example from rundll.exe but nothing happens I assume I don't have that helicopter and trying to find what name goes where is very confusing when trying to use a different chopper.

[kylania 568]

Please don't.

The problem is players using this in a clientside mod. Sure you can turn on verifySignatures, but that's extremely restrictive.

Maybe make it server only in multiplayer, if that's even possible?

[Big Dawg KS 6]

Yes, you are right. It seems i'll have to disable this command for MP missions and make sure that nobody will join with edited data. Purpose of this command was just to simplify creating of new vehicles.

Well I wasn't exclusively talking about MP. Excessive use of this command can cause all sorts of unpredictable outcomes. For example, a user is running some mod X that makes some config changes (whether using regular/binaraized config from an addon, or using the new command). He tries to play mission Y, that is using the new command to merge a config that assumes native ArmA 2 data. Configs X and Y both modify some of the same data. When the user loads mission Y, he has now potentially broken mod X, or mod X has broken mission Y.

Ok, so that can already happen with mods and missions, but I forsee that just about every mission maker now is going to want to use this new functionality, and config changes are not always obvious to the user. Also, what happens if several configs get merged on top of eachother; now nobody can know what to expect. I guess what I'm trying to say is that mission makers need to be cautious about using this. I'd be a shame if the devs had to make it really restrictive to prevent irresponsible use.

As for the devs: maybe you should add another command that disallows merged configs to override certain things, and/or a way to protect specific configs.

[rundll.exe 12]

Yes, you are right. It seems i'll have to disable this command for MP missions and make sure that nobody will join with edited data. Purpose of this command was just to simplify creating of new vehicles.

Im with Celery on this one: please dont. This command has so much potential for the MP community by improving gameplay without mods. Its something many of us have dreamed of, and it just became possible.

I think the solution is much simpler: reset the config to the original (incl loaded mods ofc) on every mission load. (or better: at mission unload)

If the intention is to simplify vehicle editing, the editor can use createvehicle after the merge command to test his vehicle.