Jump to content
Sign in to follow this  
dr. hladik

New mergeConfigFile scripting command

Recommended Posts

I need that command! Please let it stay!!

Share this post


Link to post
Share on other sites

Wait wait wait... do i understand it correctly, that with that new command, we can override configs "on the fly" or "ingame at any point" ???

Something that has been asked and dreamed of by the Modders since ages???

Jesus Christ, if so that is fricking awesome!!!!

EDIT: One of his dreams for sure: http://forums.bistudio.com/showpost.php?p=1244462&postcount=190

EDIT2: Why isn't that beta in the Six-Updater Network already?

Edited by mr.g-c

Share this post


Link to post
Share on other sites
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?

Extremely restrictive?

As opposed to not restricted at all?

I don't understand, anyway, I think it would be better on the server side too.

Share this post


Link to post
Share on other sites

Well, let it stay and lets get acquainted first. I just merged in a cfgAmmo that defines some new artillery shells, i.e to get increased illumination and burn times, and it just worked. With stuff being defined and expanded in config like this, there is a severe reduction in mission trickery you have to do to achieve the same things.

Maybe mergeConfigFile shouldn't be allowed to modify anything existing, only create derivatives? Doesn't handle all concerns though. And original configs should be re-read on loading a new mission or restarting current mission.

Share this post


Link to post
Share on other sites
You can not power-up existing vehicle. MergeConfigFile is ment to be editing tool, not "pimp your ride" tool.

They should make one that we can change the config on the fly then... it would make for so many possibilities!

Share this post


Link to post
Share on other sites

I wonder when BIS will enter with a new "Solid Plan" ref this config merge issue. :)

Share this post


Link to post
Share on other sites

I just hope that down the line we will be able to reload or remerge that config to allow on the fly tweaking (per mission save anyways, like description.ext). Currently I'm forced to rename class each time, test new class, rename class, test new class - which gets a bit tedious in the long run.

Maybe there exist a command or function that does this?

Share this post


Link to post
Share on other sites
Maybe mergeConfigFile shouldn't be allowed to modify anything existing, only create derivatives? Doesn't handle all concerns though. And original configs should be re-read on loading a new mission or restarting current mission.

Yeah. A new class that inherits from the original one that get used only in that mission.

Share this post


Link to post
Share on other sites
They should make one that we can change the config on the fly then... it would make for so many possibilities!

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.

Share this post


Link to post
Share on other sites
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.

I think that for MP it would be enough if there was a command that could only add - not modify existing - classes. Either way the usefulness of such a command is amazing and I will create structural damage to the nearest wall if it's cut out in future patches.

Edited by Celery

Share this post


Link to post
Share on other sites
I think that for MP it would be enough if there was a command that could only add - not modify existing - classes. Either way the usefulness of such a command is amazing and I will create structural damage to the nearest wall if it's cut out in future patches.

Exactly, its just about changing some classes.

You could script with that for instance a lot of realistic weapon/warhead behavior on the fly and such things.

I don't think anyone ever demanded whole "addon loading" on the fly.

Reference Suggestion: http://forums.bistudio.com/showpost.php?p=1244462&postcount=190

Share this post


Link to post
Share on other sites
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.

This what makes this a great company. They come right and tell you. Good or bad.

EA/DICE/Activision/etc... would tell you nothing and give you the shaft.

Keep up the excellent work BIS. :D

Share this post


Link to post
Share on other sites
I think that for MP it would be enough if there was a command that could only add - not modify existing - classes.

Even adding new things is hard if it should be implemented completely (e.g. including adding new animations).

Moreover, the problem is you need to be able at least to cleanup after the mission, which means you need to be able to unload the things which were created dynamically. This also is quite difficult.

You are free to use or abuse the mergeConfig to do whatever you wish. That said, be aware in future versions mergeConfig will be considered to be content modification and version where mergeConfig is done will not pass equalMod check.

Share this post


Link to post
Share on other sites
Even adding new things is hard if it should be implemented completely (e.g. including adding new animations).

Well, wouldn't you need to load new data for new animations? I guess I figured you can only make changes that don't require loading of new assets (.rtm, .p3d, .paa/.pac, etc...), or is that entirely feasible? I understand also that config definitions can also be interdependent. This especially is the case with class inheretance. If I merge a change to class Air for example, how does this effect all of the subclasses of Air? Or I guess the game maintains the class hierarchy when it loads the config files into memory (since we can read them this way with scripting commands).

Not that I know at all how the system works, but would it not be possible to load config merges into a new "layer" in memory that doesn't overwrite the data loaded at the start of the game, but simply overrides it when that data is referenced? Of course I'm probably totally overlooking something, but if that were possible I guess you could just wipe that space prior to each mission, allowing the original data to be referenced. Again, no clue if this is actually how it works, but perhaps just an abstract concept that may get you thinking about some solutions. Of course this would make the use of the command more costly and probably make the game eat up even more memory...

Share this post


Link to post
Share on other sites
Even adding new things is hard if it should be implemented completely (e.g. including adding new animations).

Moreover, the problem is you need to be able at least to cleanup after the mission, which means you need to be able to unload the things which were created dynamically. This also is quite difficult.

You are free to use or abuse the mergeConfig to do whatever you wish. That said, be aware in future versions mergeConfig will be considered to be content modification and version where mergeConfig is done will not pass equalMod check.

How about an array where you add config classes every time a new one is created? That way you can more easily clear those classes or check if a class that is being modified already exists to prevent its modification.

Share this post


Link to post
Share on other sites
you can only make changes that don't require loading of new assets (.rtm, .p3d, .paa/.pac, etc...), or is that entirely feasible?

This should be feasilble, I cannot see anything preventing this. Generally, it is a lot easier to add a new stuff, than to unload the stuff which is already there. The major difference is when changing or removing the stuff, you need to handle all places where anything could be still referencing it.

load config merges into a new "layer" in memory that doesn't overwrite the data loaded at the start of the game, but simply overrides it when that data is referenced?

Yes, this would be possible, but it is quite a significant change, which would make config entry searching a lot more complicated compared to what we have now.

I am sorry, but we are not going to implement this for ArmA 2 platform, the workload and risks are too high.

Edited by Suma

Share this post


Link to post
Share on other sites
This should be feasilble, I cannot see anything preventing this. Generally, it is a lot easier to add a new stuff, than to unload the stuff which is already there. The major difference is when changing or removing the stuff, you need to handle all places where anything could be still referencing it.

I take it is possible and feasible for you to have loading of new things possible, including full addon, nearly "on the fly"

For the unloading part, couldn't a full "reload" of base config (as stated in the -mod parameters at game start) be possible? Drop all current config and reload from scratch. That would basically nearly be a game restart, but without the "back to desktop and double-click the ArmA2 icon again"

Share this post


Link to post
Share on other sites
be aware in future versions mergeConfig will be considered to be content modification and version where mergeConfig is done will not pass equalMod check

In the meantime, could you please show a dialog asking the user to restart the game? Like the one like you show after having changed UI size in Video Options, or changed the active Expansions.

This dialog should be triggered after a mission has finished, and game config has been altered.

The reason I'm asking this is that, later, reproducing an issue will be impossible if someone played previously a custom mission, that in turn has changed the known state at begin of the game.

Share this post


Link to post
Share on other sites

Just to clarify motivation for adding mergeConfig functionality to the engine:

it was supposed to be very useful for faster development, e.g. no longer necessary to restart game in order to change weapon parameter.

Requiring developer to restart game seems not be very suitable for this purpose.

My current internal suggestion is to rename the command to diag_mergeConfig to reflect its real purpose better.

In the meantime, could you please show a dialog asking the user to restart the game? Like the one like you show after having changed UI size in Video Options, or changed the active Expansions.

This dialog should be triggered after a mission has finished, and game config has been altered.

The reason I'm asking this is that, later, reproducing an issue will be impossible if someone played previously a custom mission, that in turn has changed the known state at begin of the game.

Share this post


Link to post
Share on other sites

I still think that even a command that can only add a new class (save for defining inheritances from existing ones) would be extremely useful. Just last night I got mine and Zipper's horror missions to use all civilian classes instead of the 6 armed civilian types thanks to adding classes that used all the civilian models but had combatant AI instead of the civ one that resulted in poor scripted behavior. And in another mission I got a car's driving characteristics just right for an entertaining chase scene, with good steering and mobility in cross country.

Share this post


Link to post
Share on other sites
it was supposed to be very useful for faster development, e.g. no longer necessary to restart game in order to change weapon parameter.

Indeed, I've just started using it for this and... wow. REALLY great! :)

Share this post


Link to post
Share on other sites
Just to clarify motivation for adding mergeConfig functionality to the engine:

it was supposed to be very useful for faster development, e.g. no longer necessary to restart game in order to change weapon parameter.

Requiring developer to restart game seems not be very suitable for this purpose.

My current internal suggestion is to rename the command to diag_mergeConfig to reflect its real purpose better.

And you get beat by your player's using one of your tool in unintended way :) Like it has often been the case in the past, don't you think? Always with positive results

Seriously, this command is vastly more than just "easier addon making". This is god given for addon-less server usage. Please, don't drop its development that fast.

Share this post


Link to post
Share on other sites

Got a bug that is most likely being caused by the new command.

When I use planes in a mission where the config merge is used (no air classes modified), the RPT file gets spammed with:

class HitPoints::HitEngine not found in An2_TK_EP1

class HitPoints::HitEngine not found in An2_TK_EP1

class HitPoints::HitEngine not found in An2_TK_EP1

class HitPoints::HitEngine not found in An2_TK_EP1

class HitPoints::HitEngine not found in An2_TK_EP1

It possibly causes some CPU lag, at least I did notice some jerking every 0.5-1 seconds.

Edited by Celery

Share this post


Link to post
Share on other sites

http://dev-heaven.net/issues/14163

So, could possibly ruin a lot of things.

Maybe the (diag_) command should automatically write a report in .rpt? Stating what was done, and how it is not a good command to use for missions. I realize it is up to us mission makers to make good judgment calls. But once the (destructive) power of it gets known maybe server admins won't allow missions that use it in a bad way (not intentionally), based on what's in the rpt.

If the effect stays over missions, mission#1 that does things with the configs may unintentionally break mission#2.

Share this post


Link to post
Share on other sites

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.

PS:

I don't like to put any info via default to the rpt.

If would prefer a selection list for the rpt to customize that only errors would be shown, many "information hints" imo only blew the rpt up. :raisebrow:

Edited by Lester

Share this post


Link to post
Share on other sites

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
Sign in to follow this  

×