V1.75 addon handling

It appears there are some problems with resistance addons handling. First there is a more minor thing I have posted earlier to some other thread but dunno if bis people saw it... Whenever addons that have stuff based on o.pbo's config are put into res/addons the addon handling gets screwed.

For example with my smith & wesson revolvers addon, it has its unit based on the resistance civilians like this:

class Civilian: Man {};

class Civilian6: Civilian {}

class KEGsw44mCivilian6: Civilian6

The actual addon where "civilian6" has all its stuff is inside o.pbo, but after putting this addon in that dir ofp thinks this class came from this addon. The most weird part is, that whenever a mission that uses "Civilian6" gets loaded it wont load and will display a "missing addon: kegsw66" message even when both the o.pbo and kegsw66.pbo are there.

Another issue is what we just faced in our dedicated server: In a mission there are weapons added into weapon crates by an init script (KEGrpg7Launcher, comes from KEGrpg7 addon) and the editor wont add this addon to the addons list, unless you go into preview mode, and actually pick up the weapon, and then save the mission.

Again, most weird part is, that if the rpg7 entry is missing from mission.sqm, but the addon is installed on the server and client where this mission is played an attempt to pick up the weapon will display a "missing addon: rpg7" dialog in the server and the clients, which also crashes the server.

Comments from Suma or someone else from BIS would be greatly appreciated

I think Suma posted that you should always preview then save the mission to have addons that are in crates or used in scripts in order to get them listed in the sqm file.

This way on the preview it reviews the scripts and adds what is required in the addons list in the sqm file.

Hoz

</span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Quote (hoz @ Aug. 12 2002,01:45)</td></tr><tr><td id="QUOTE">I think Suma posted that you should always preview then save the mission to have addons that are in crates or used in scripts in order to get them listed in the sqm file.<span id='postcolor'>

Yes, thats what my message concerns as it doesnt detect everything before you go pick it all up, plus if you dont do that it complains about missing addons when trying to play it, which is rather unlogical if the addons are installed.

i once sent PM to him anyways, asking to lock a highly flammable topic

back on to the post topic, here's what i'm guessing(my PC experience is limited so give me a break)

AFAIK, when mission editor saves user-made missions, it saves every info in text format. like the Init field commands are all converted into text characters in mission.sqm.

this would seem like that mission editor literally grabs what is on the editor, see what stuffs are there, and then use some sort of enumeration method to convert it to whatever we see in SQM file. so no checking, just convert it, and save.

so in your case, when you put all those init stuff,(and possibly new addon and associated human characters) mission editor will go through enumeration process(which might include infos of addon's config cpp info that was loaded at OFP startup) and just convert it to missions.sqm

but when you hit preview button, it seems like the engine will actually kick in and try to execute it. with this process, the game engine will be notified to add another line to mission.sqm, the new addons array thingy.

when OFPR engine is launched for playing SP and MP with such mission, the engine will give out error. up until 1.46, this error immediately cause OFP to crash. i'm guessing that if an error/exception is thrown, the code might just do "exit(1)" or something like that. but to amend that feature, BIS could have added a few more line that changed how exceptions were handled. my guess is that the exception is still thrown, but the exception handling process/function will check if there is that addon array thingy present, and utilize it. but that addon recognition process will look at that specific array only. and if that is not present, it'll call for an error(another one).

so if the addon info is present in that array, game engine will just go as planned, while if not, it gives out error mesage instead of closing itself.

another guess is that maybe OFPR engine looks for o.pbo, and not go through the whole res/addons.

so these are my guesses.(useless i guesses )

I "further investigated" the missing addon entry issue, and it seems that if making a script that adds weapons execute in an init line of some unit will cause this problem. For example, doing

"this exec "addWestWeapons.sqs"" for ammo crates, where addWestWeapons adds some addon weapons causes this problem, you have to go pick the weapons up from the crate in preview. So it after all isnt that bad issue, but something worth fixing if it isnt too complex... (maybe every addWeaponCargo command execution could get monitored for new addon entries?)

Also, for the addon class issue, would it be possible to make the automatic system work so, that entries in CfgPatches class would overwrite all the automatically detected ones, and an automatically detected one would never overwrite a CfgPatches added class? This way it would all work properly, as, for example with my addon, the Civilian6 class would get first assigned to KEGsw66 addon, but when o.pbo gets loaded the KEGsw66 entry would get overwritten by the o.pbo, which has the class in its CfgPatches so its certainly the original source of that class.

</span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Quote (Kegetys @ Aug. 12 2002,10:23)</td></tr><tr><td id="QUOTE">I "further investigated" the missing addon entry issue, and it seems that if making a script that adds weapons execute in an init line of some unit will cause this problem. For example, doing

"this exec "addWestWeapons.sqs"" for ammo crates, where addWestWeapons adds some addon weapons causes this problem, you have to go pick the weapons up from the crate in preview. So it after all isnt that bad issue, but something worth fixing if it isnt too complex... (maybe every addWeaponCargo command execution could get monitored for new addon entries?)<span id='postcolor'>

You know that's what Suma told you right?

I don't want to sound like a BIS lawyer but, from my experience in Development (not too much), what seems like it really should work one way for a user and seems pretty simple and logical to a person may be incredibly difficult and time consuming to implement. This is no joke...

As long as you can get by don't get too upset Keygets.

</span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Quote (bn880 @ Aug. 12 2002,16:35)</td></tr><tr><td id="QUOTE">Don't get too upset Keygets.  <span id='postcolor'>

This thread is old and dusty and smells now