DnA

Please use http://forums.bistudio.com/showthread.php?p=1777081 for any feedback, bug reports and suggestions related to the Multiplayer Armory beta which is included in this patch :)

LMAO :pet7:

I'm not sure all of the following is present in your version yet, but here is a sample which may help you get started. Again, this is a very limited approach to OO scripting, but it has helped me in many ways already :) Config: class CfgOO { [color="DarkGreen"]//Name used in method prefix[/color] class MyClass { class Attributes { [color="DarkGreen"]//Name used in Logic variable space //Initialized with default value for this type[/color] class myAttribute {type = "SCALAR";}; }; class Methods { [color="DarkGreen"]//Constructor method[/color] class MyClass { [color="DarkGreen"]//Amount of type of provided parameters are validated when invoking methods[/color] parameterTypes[] = {"OBJECT"}; [color="DarkGreen"]//This script file implements the method as a function[/color] script = "some_path\data\scripts\classes\MyClass\MyClass.sqf"; }; class myMethod { parameterTypes[] = {"OBJECT", "SCALAR", "STRING"}; [color="DarkGreen"]//The default return value is based on this[/color] returnType = "SCALAR"; script = "some_path\data\scripts\classes\MyClass\myMethod.sqf"; }; }; }; }; Script: [color="DarkGreen"]//Precompiles all methods into global variables //Naming convention: BIS_OO_<Class>_<method> //Here: BIS_OO_MyClass_MyClass and BIS_OO_MyClass_myMethod[/color] "MyClass" call (compile (preprocessFileLineNumbers "ca\modules_e\oo\data\scripts\functions\addClass.sqf")); [color="DarkGreen"]//Creates a Logic with all attributes initialized //Invokes the constructor[/color] private ["_myClassObject"]; _myClassObject = ["MyClass"] call BIS_OO_createObject; [color="DarkGreen"]//Invoking a method and getting an attribute[/color] private ["_return", "_value"]; _return = [player, 1, "Hello"] call BIS_OO_MyClass_myMethod; _value = _myClassObject getVariable "myAttribute";

This is probably because the AI centres are not set up unless your mission contains units belonging to them. So when your mission does not contain OPFOR units from the start, no OPFOR AI centre is initialized. This is not exclusive to BIS_fnc_spawnGroup, but any dynamically spawned units. To script creation of all important centres add (and set their friendliness according to your needs): private ["_centerW", "_centerE", "_centerG", "_centerC"]; _centerW = createCenter west; _centerE = createCenter east; _centerG = createCenter resistance; _centerC = createCenter civilian; west setFriend [east, 0]; east setFriend [west, 0]; east setFriend [resistance, 0]; resistance setFriend [east, 0]; The reason things work with ACM is because ACM includes this code.

I'm sorry to say that currently there is no easy way to make the SOM use BAF content, unless the module is changed itself. It is prepared to check whether A2, OA or both are available, but not yet for BAF (or any other content). If there is time I will look at doing this for a patch.

Nothing is too wild, but it's not what this module is about ;) Object Oriented scripting yeah ... it mostly allows for neat data and responsibility organisation. Say your system simulates a car, you can identify Car, Wheel, Engine, and many more classes. Each class holds the data specific to that component (e.g. pressure in Wheel and horsepower in Engine) and it performs the operations specific to that component (e.g. start() in Engine). Now you will need four wheels for most cars, so you instantiate four objects of the Wheel class. Automatically all these objects contain the pressure attribute. This means you do not have to, say, use four different global variables ... and when you add a new bit of data to your Wheel later, all instantiated objects receive this data! That is just a very basic overview, but perhaps you can see some of the benefits when creating complex scripted systems :)

This is a module which provides a scripted framework enabling a limited Object Oriented design for any system :) I developed it for an as of yet unreleased project. In complex systems, an OO architecture brings many benefits. This framework definitely does not support all features of typical OO approaches, but it does do: classes, objects (instances), attributes, methods, message passing, inheritance, abstraction, encapsulation ;) Basically you define an architecture in a special CfgOO class and the system then automatically creates the classes and compiles the methods (in functions). You can then instantiate objects of a class, which spawns Logic objects with all attributes initiated as variables. Invoking the methods automatically does parameter validation and generates a debug trace. Since this is a scripted solution and not (yet) part of our engine, it does create some overhead. However, I found the advantages to be huge while implementing and debugging my system. When I have some more time I will try to document the OO module as it is present in OA now :)

Jerry, you made me a proud Dutch BISer ;)

You can do this by checking the SOM's history, stored in its main variable scope: private ["_mainScope", "_history"]; _mainScope = player getVariable "mainScope"; _history = _mainScope getVariable "history"; //[# completed, # failed]

Thanks for posting the link nettrucker. The Armory should work with user-made maps straight away, but there are several levels of support. Without additional work the most basic challenges and functionality should work (if it doesn't, I'd like to trace why not). With additional configuration it is possible to make the more complicated challenges and features work as well :)

Maybe the documentation will help you a bit: http://community.bistudio.com/wiki/Armory_configuration :)

The crashed UH-1Y was left enabled in the Armory, because it is classified a static weapon (it has a functional minigun) :) I did find the bug and am hoping to resolve it in any new patch. Stay tuned :)

Welkom terug Jerry :) Glad to hear you've fully recovered. Looking forward to your community entertainment :D

Hiya, I can help you with the first one :) 1) Check out http://community.bistudio.com/wiki/Armory_configuration#CfgWeapons_.2F_CfgVehicles It's the SomeVehicle.Armory.author config parameter (String)

Currently that is not possible (not counting stealing items from enemies during challenges).

Terrible news. My condolences to his family and friends :(

T.R.A.P. should require you to find and reach the crash site. Then, if the aircraft is still intact, you need to destroy it. Finding explosives or launchers can be tricky, but there's usually a bunch of enemies you come across. Try looting them for RPG's (no pun intended ;)). Each target in Destroy has a specific object or vehicle which is the main target. For the Anti-Air facility it's the Tunguska or Avenger, for the radar site it's the radar, etc. Again, find weapons in crates or on enemies, or steal vehicles. In Escort you should indeed follow the friendly squad and protect them from enemy patrols. Why they are running that fast I don't know, but perhaps that's due to changes in AI in one of the patches? They should go to combat mode once they spot enemies.

You can try looking at some of the Armory config parameters in CfgWorlds :) It sounds to me like your centerPosition might be causing this? http://community.bistudio.com/wiki/Armory_configuration

Now that's a good repro :) However, when I try this item myself, it works just like any other static vehicle with a gun. Which version are you playing? Any patches applied? Thanks! Oh and glad to hear you like the game :D

I think the confusion is that Crashed UH-1Y is actually a static vehicle, not a scenario (just like all elements of the list are either characters, vehicles or weapons). This particular vehicle should definately not be in the list, so I'll look at that. Thanks for pointing it out. I hope the rest of the items works better for you :)

Which scenario is that exactly? I've created all of the Armory challenges and don't remember adding this one :) Do you mean the TRAP SecOp perhaps? Are you running any community content such as worlds?

Dear community, As you are probably the most involved players of ArmA 2, I would like to ask you for any feedback you might have on the Armory mode. Your thoughts may prove valuable while improving this mode for future products and is very much welcome. Feel free to criticize it, but please try to make your points by providing reasoning as well. Thanks a lot for your time! (For modders: I've finally posted documentation on configuring content for the Armory - http://community.bistudio.com/wiki/Armory_configuration)

Thank you all for the honest extensive feedback! I'll definately be checking this thread for a while, so keep it coming :) As some of you have already commented: the Armory was never meant for everyone. I personally think it's a nice break from the main game for those who like and / or need it. I've read comments from people new to BIS games (outside of these forums), who were not yet playing around with the editor or did not want to at all. For them the Armory provides them the opportunity to quickly check out (community) content. Asking for our developers to ignore one aspect of the game and try to improve completely different aspects, is not entirely realistic. Developers each have their roles and specialties and most designers cannot simply become an AI programmer overnight ;)

Yes, you can either use the mission editor to create simple scenarios with those vehicles, weapons and characters, or you can try them inside the Armory itself. And of course there are / will be plenty of nice community scenarios to enjoy :)

You can no longer create Logic objects through createVehicle and should use createUnit. You can compare the case to trying to create a soldier using createVehicle. Your script could not continue because _log is a null-object. Try: _log = _troop createUnit ["Logic", [0, 0, 0], [], 0, "NONE"]; Note 1: avoid position [0, 0, 0] where you can, it's dangerous :) Note 2: create a dedicated group for the Logic on side sideLogic. This will be the safest and in the future may become required for Logic objects.