@G. Barron:
Sure, that would be a nice feature, for small addons and maybe for some custom configs so you could have some customised units for one mission etc...
Best thing would be that both would be supported... So you could either include the addons in the mission or as a separate addon...
For bigger and more popular AddOns the AddOns/mod folder would still be the best solution...
@Uldics...
I think the problem is that OFP does not read the mission .pbo when it loads up the game, which it does with the .pbos in the AddOn folder (like Planck said)...
As the config is not read (from the mission .pbo or folder) there is no units to place in the editor
The mission .pbo is read only when the mission is loaded up from the SP/MP menu...
You can see this at the most simpliest way, load up a SP mission and then try to delete the mission pbo; you will get 'access denied' error..
Then load another SP mission and then try to delete the previous mission pbo again, and now it gets deleted...
With pbos in the AddOns folder you will always get 'access denied' error when OFP is running and you try to delete/modify them...
What could be tried to do is to include the AddOn's config in the mission.sqm, but I very much doubt that it would work either..
In the past I (and others) have tried to use the description.ext to config an addon but it has not worked..
I guess OFP uses different kind of 'parsers' (or whatever they are called) for each 'code' type they use in OFP since if you try to config an addon in the description.ext which is very similar with config.cpp in format you will only get errors...
If you
preprocess/loadFile and
call a .sq
s you will get errors because the .sqs is in the wrong format as the
preprocess/loadFile and
call functions require the ; semicolon in every end of line, which IMO clearly shows that the scripts is run through a different kind of process with those functions..
So, when you get only errors with the description.ext when trying to config an AddOn in it it again IMO shows that the .ext is passed through a different process that the .cpp, the .ext process does not understand the .cpp values and vice versa...
Which IMO leads to the conclusion that mission.sqm is again passed through a different process than the rest so having the AddOn config in it
should just cause trouble..
Anyway, IF the config in mission.sqm works, then you could have an addon in the mission because then the addon would 'loaded' when the mission.sqm is accessed by the game.. In theory..
Of course you would need to have the mission not pboed in the mission folder like Uldics suggested...