noubernou

Actually a LOT is going on, just most of it is in private testing right now. :)

Implemented a number of new features and functionality: https://github.com/NouberNou/carma2#advanced-concepts Pseudo-static Members with :: Operator Using the :: operator you can easily access a objects prototype members/methods, the same as above using the __prototype member. Since all objects that descend from a common prototype share the same instance of that prototype you can use it to define static methods/members that will be shared across all classes. test_base = new carma2_object(); // this will be our prototype. test_base.staticMember = 123; // assign the prototype object a member var test_instance1 = new test_base(); test_instance2 = new test_base(); player sideChat format["test_instance1: %1", test_instance1::staticMember]; // prints 123 test_instance1::staticMember = 321; // assign the static variable on test_instance1 to 321 player sideChat format["test_instance2: %1", test_instance2::staticMember]; // print the static variable on test_instance2, prints 321 Calling Overriden MethodsCalling the original overridden methods is done via accessing the objects prototype object definition, either through the :: operator, or the __prototype member, and then using the magic methods __call(context, arg1, arg2, ...) or __apply(context, arg_array). These methods execute the desired overriden/parent method in a supplied context, commonly passing _thisObj to the method, along with the methods arguments. An example is given below demonstrating the usage of the __call and __apply functions. test_base = new carma2_object(); test_base.testVal = "base instance"; test_base.parentMethod = { diag_log text format["Object %1: %2, %3", _thisObj.__id, _thisObj.testVal, _this]; }; test_instance = new test_base(); test_instance.testVal = "child instance"; test_instance.testMethod = { // call the prototype method, in the context of the prototype, essentially a static method. _thisObj::parentMethod(1); // call the prototype method, but in the context of this instance using __call(context, arg1, arg2, ...) _thisObj::parentMethod.__call(_thisObj, 2); // call the prototype method, but using __apply(context, arg_array) _args = [3]; _thisObj::parentMethod.__apply(_thisObj, _args); }; test_instance.testMethod(); This prints to the RPT: Object 1: base instance, [1] Object 2: child instance, [2] Object 2: child instance, [3] An example of overridden method calling it's parent method is below. test_base = new carma2_object(); test_base.testVal = "base instance"; test_base.testVal = 0; test_base.testMethod = { diag_log text format["parent: %1 testVal: %2", _this[0], _thisObj.testVal]; }; test_instance = new test_base(); test_instance.testVal = 999; test_instance.testMethod = { _thisObj::testMethod(333); // call the parent method as a static method, the context is the __prototype object. _thisObj::testMethod.__call(_thisObj, _this[0]); // call takes the args to the function in-situ after the context object _thisObj::testMethod.__apply(_thisObj, _this); // apply takes the args as an array diag_log text format["child: %1 testVal: %2", _this[0], _thisObj.testVal]; }; test_instance.testMethod(123); Results in: parent: 333 testVal: 0 parent: 123 testVal: 999 parent: 123 testVal: 999 child: 123 testVal: 999

Added some new stuff: https://github.com/NouberNou/carma2#string-member-accesor- String access of object members (basically hash maps), and some niceties for normal sqf function calls.

Updated to add array accessors: https://github.com/NouberNou/carma2#array--accessors Method chaining is also working now.

The only problem with locations is that nearestLocation(s) will run a lot slower. To be honest though I've never really seen anyone use locations for anything, they aren't really used in the engine at all, and in the BI SQF code it is called in only a few places. I feel it's a worthy sacrifice for what is gained. Logics will slow the game down after a couple hundred.

Correct, locations are awesome. In ACRE2s current internal/testing builds I am spawning a pool of 50,000 of them to handle hash maps. There is literally no overhead like you would get with logics or other data containers in the engine. When I found this out soooo many things became possible haha.

If your own FPS is dropping when you transmit make sure you do not have lots of duplicate radios on you all on the same channel... Because you'd then be receiving on all those radios as well.

We are releasing backpack radios, well that is to say we already have. There is an AN/PRC-117F and an AN/PRC-77. The only thing we do not have now is the ability to show the antennas sticking out. We are eschewing the way we did it in ACRE1, which forced us to have backpack models specifically for the radios (which was fine because the backpack actually was the radio) in favor of a more dynamic system in which a radio can be placed in any backpack.

Why yes... Actually there is: http://acre.idi-systems.com/category/dev-blog/ It should happen with the next release! :)

If you are using Arsenal, don't. It breaks the game. If you have a gear script, make sure that it either sleeps between removing and re-adding the gear, or it doesn't remove and then re-add the same type of vest/backpack/uniform.

Known issue and will be fixed soon (fixed in the current repo). Something in the engine now uses idc 106, and so do we (why we use such low IDCs sometimes I am not sure), so it causes a conflict and it closes the dialog.

Sorry for not being around a lot lately in this thread! For some reason after the forums upgrade I found it harder for me to want to come here (don't exactly know why). Anyway, been working on ACRE outside of Arma haha: http://raceriv.com/acre_maps/

This isn't a real 152, it is a fake one for airsoft.

ACRE has to be on and them in TS when they connect to the server, otherwise it will not work. They are in your normal temp files folder in your user profile, i think in an acre folder, I can't remember the exact path. They stay there between games too. I dont clean up ACRE's temp files at the moment. :p

Yup, this should work too on servers that dont allow the files. ACRE2 just needs to read them once, then it caches the wav files in your temp files.

Make sure your server allows b64 files to be read. There is a description in the first post on how to do that.

We didn't port them because there was limited usage of it in ACRE1. Sorry. Maybe in the future.

When he spoke on radio were you able to hear him on direct? Could other people hear him on the radio?

Probably something better handled by ACE or other wounding scripts through our API.

I think ICBMs are a little out of scale for Arma... Even the SS-21 they include is a bit too long range for this game.

You'd just die. So we'd probably need all the CBRN stuff that goes with it... :P The M1135 is the current CBRN vehicle, and I think they still use the M93 Fox as well (which is Fuchs).

And I'll be right there to steal it for the standalone version. :P The A2 version was kinda janky.

The only rounds left for the M109 Soul Assassin and I did are the chemical 155mm rounds and I've been itching to get them in the game. I had a pretty good aerosol simulation working in A2 (using GB/Sarin as the test chemical), but it was implemented in SQF and was running into performance issues. Maybe the game needs CBN weapons and then mod makers will add protection as a response to players dying, just like real life haha. :P

Sounds like a problem with your spectator script as normally this isn't an issue.

Have had my head in signal code the last couple weeks. Been moving it all over to C++ land, including loading and parsing WRP files. Multipath is now mostly implemented and to show some of the features, here are some reception graphs. ACRE2 Signal Fading The two images below show the received signal at the same spot, with the transmitter height changing in increments of 0.1 meters from 1m to 11m. The first image is at 40MHz, the second image is at 70MHz. The antenna is an idealized isotropic antenna with the same gain at any frequency, the signal results here are only affected by terrain, FSPL, and multipath fading effects. Simulated sensitivity for the generic receiver at 12dB SINAD is -116dBm. At 40MHz fading occurs drastically and rapidly from 1 to 4 meters, peaking well above and dropping well below -116dBm. At 70MHz, fading occurs less frequently, though there is a fairly rapid spike around 3m. The signal though never drops below -116dBm.