loyalguard

As I hinted in a few other threads and continuing a tradition since A1, I am porting and enhancing my ArmA Electrical Grids (AEG) simulation to A3. I have basic functionality working on Stratis thanks to some amazing island analytic techniques pioneered by Wolffy.au. BUT, in the current Alpha (0.56) the ability to switch street lamps on and off is not yet implemented, so there is nothing tangible to release just yet. In the meantime, I have been focusing on making the simulation more efficient and including features not available in previous versions. What features you ask? For each successive ArmA game release, I have tried to enhance the simulation. For A3 the big changes are going to be the addition of renewable power sources (solar, wind, and wave). So far in game in the Alpha we have all seen plenty of solar (photovoltaic) objects: Buildings with Photovoltaic (Solar) Panels on Rooftops: Photovoltaic Transformers: Through screenshots and other hints online and in game (and in the real life islands that have inspired Altis and Stratis), I expect there to be wind and wave power-related objects as well. So, the challenge has been how to realistically add these to the simulation. So far I am quite please with the results. I have been able to "connect" solar panels on building rooftops to nearby photovoltaic transformers (in real life these would actually be a solar inverters/transformers) that in turn provide power (assuming it is not dark or too overcast!) to nearby street lamps and other objects too! What kind of objects? Well... In the previous versions of the simulation (SEG (A1), CEG (A2), and AEG A2/OA) only street lamps were controlled by the grid. Ever since A1 and Sahrani, it has been requested and I have wanted to include lighthouses, airport runways, and other light sources. For A3, I have found a way to turn off lighthouses, runway edge lights, and airport VASI lights by damaging them so they are inoperational. There are some small unintended consequences (breaking glass sound in the lighthouse and puffs of smoke on runways), but none that spoil the overall effect. Here is a quick video of the progress so far showing lighthouses on and off and then runway/VASI lights on and off: (Please excuse poor quality - game and video settings have been optimized for development -- not rendering) http://www.youtube.com/watch?v=PiVulpUw7zg As noted above, if it is dark (sun is not up) or if it is overcast enough to possibly rain, solar panels will not generate power. Even though there is not much of a connected electrical grid represented on Stratis so far, I have included a "virtual grid" that provides backup power to solar inverters/transformers so they still provide power at night or when cloudy. But, if both are down: no power! Since there are also commands to monitor wind strength and wave strength, I will look to incorporate these as well when calculating power output from wind and waves power generators. I will post updates as they occur, in the meantime, please provide feedback on what you want to see in AEG for A3! Update #1 - 5/11/2013 Here is a preview video of the remote logon system to control the grid that is available if enabled by the mission maker. http://www.youtube.com/watch?v=SGohtbmxFI8 Update #2 - 5/13/2013 Preview video of the password logon feature with failed facial recognition sequence. http://www.youtube.com/watch?v=1pZ212PfkAQ Update # 3 - 5/23/2013 Preview video showing new scripted light effects adding red warning lights to airport control towers and communications and transmitter towers. http://www.youtube.com/watch?v=EwOCowXnU3E

AEG - ArmA Electrical Grids Script Pack and Addon for ArmA 2, OA, and CO by Loyalguard Development Status: General Release Current Version: 1.01 Download: MediaFire 9MB Download is 9MB but AEG itself is only 600K. The download is larger because it contains both the script and addon versions, several demo missions, and documentation and images for mission makers. Mirrors: Armaholic ArmedAssault.info Overview: The ArmA Electrical Grids (AEG) project simulates electrical power grids throughout various islands in the ArmAverse. The simulation features power plants with smokestacks that emit smoke when generating electricity. Substations or poles with transformer that emit a humming noise when energized. Street lights are turned off when power is cutoff. Features: -Multiple supported islands: Chernarus, Utes, Takistan, Zargabad, and Qom Province. -Power plants with working smokestacks and power plant noises. -Electrical substations that emit a transformer humming noise when energized. -Area/City/Town/Neighborhood pole mounted transformers that emit a transformer humming noise when energized. -Ability to interrupt power by destroying components or, if enabled by mission makers, by manually tripping circuit breakers via the action menu (if tripped, breakers can again be closed to restore power). Manually switching circuit breakers can cause arc flash explosions if enabled by the mission maker. -Mission makers can enable players to remotely logon to grid control software and substation video feeds via custom dialog. -Grid redundancy - if certain components go offline, power automatically switches to secondary circuits when available. -Built-in task/objective support via global/public variables (with examples). -Fully SP, MP, Team Switch, JIP, and persistent mission compatible. Each mode is optimized for minimal performance impact. JIP is self-contained and does not require onPlayerConnected code. -Backward compatible with CEG (Chernarus Electrical Grid) for functionality purposes on Chernarus and conflict avoidance. -Extensive documentation for mission makers and players. Easy implementation into any mission. -Fully featured demo missions for each island. -Available in script only (no addons required) and addon versions. Addon version automatically adds AEG to any mission on supported islands. Requirements: -ArmA 2 v.1.10 or higher for Chernarus and Utes. ArmA 2 OA (or CO) v.1.59 or higher for Takistan, Zargabad, and Qom Province. -The addon version of AEG requires Community Based Addons (CBA), more specifically, Extended Event Handlers (XEH) to be installed and loaded in order to function. CBA can be found at most ArmA2 content download sites. The script version does not require any addons. -For multiplayer missions, AEG must be running on the server and all clients to function correctly. This is automatic for the script version since it is included in the mission. -See readme.txt in download folder for additional details. Changelog: v.1.01 - 29 Oct 2011 ------------------- ADDED: Support for Qom Province by Tupolov. IMPROVED: Cleaned up initialization code for some scripts. IMPROVED: Fixed typos/formatting in comments in various scripts. IMPROVED: Cleaned up config.cpp for addon version. IMPROVED: Gave units names in all demos. CHANGED: Added instructions in missionmaker.txt to convert demo missions to work exclusively with the addon version. FIXED: Corrected Marker links for documentation in the Zargabad demo briefing. FIXED: Added briefing.html file to Zargabad demo. v.1.00 - 14 Oct 2011 --------------------- -IMPROVED: Cleaned up code in island functions for uniformity. -IMPROVED: Inserted explanatory comments in variable initialization block of all island functions. -IMPROVED: Adjusted smoke particle source in Chernogorsk to better align with smokestack. -IMPROVED: Added a server/client version to check to ensure the server and client are running the same version of the AEG addon. If not, The AEG client version will abort and will display a side chat message to alert the player. -IMPROVED: Standardized Demo mission markers. -ADDED: Additional documentation for mission makers added to each demo mission briefing to include use of circuit breakers via the action menu, the remote control system, and node descriptions and diagrams. -ADDED: Additional an "Intelligence" subfolder to each demo mission with images in .paa format that can be used for AEG related tasks/objectives via briefings and hints. -IMPROVED: Cleaned up readme.txt and missionmaker.txt files and added information on demo briefings and Intelligence folders. -ADDED: Added islandmaker.txt to give guidance to island makers who want to design realistic electrical grids on custom islands and that can be easily supported by AEG. v.0.90 - 10 Sep 2011 -------------------- Initial Beta Release Screenshots: Electrical Distribution Zone Map (Color Coded) Remote System Control Dialog Built-in CCTV System In-Game Documentation Demo Video: sVi3HGKX4rI Developer Notes: The ArmA Electrical Grids (AEG) Project for ArmA 2 & A2OA is the third installment of realistic electrical grid simulations for the ArmA series. In addition to continuing support for Chernarus, AEG also adds support for Takistan, Zargabad, Utes, and custom made islands. The simulation is no longer tied to specific islands and new islands can be added as needed. Beginning with Sahrani Electrical Grids (SEG), followed by Chernarus Electrical Grid (CEG), and now with AEG, the developer’s goal has been to realistically simulate electrical grids for ArmA modeled on existing map objects (no new objects/models). The simulation's core function is to monitor the integrity (damage and connections) of electrical grid components (power plants, substations, and local transformers) and interrupt "power" to affected areas when integrity is lost or diminished. Power interruptions cause street lamps to turn off (other light sources are unaffected). If you have comments, questions, or suggestions please post them! If you are a custom island maker and want to include your island in the AEG simulation (requires no modification of your island), please feel free to contact me.

I have slowly been working on my ArmA Electrical Grids simulation for A3. I have basic functionality ported over from A2 working on Stratis, but since switchLight does not seem to be not working (or just not enabled) yet, there is nothing to release yet. In the meantime, I have been looking to add some functionality to AEG and have been looking at disabling lighthouse lights, runway lights, and possibly other light sources not affected by switchLight. For lighthouses, the best method I have come up with so far is to use setHit to damage the appropriate selections/hitpoints of the lighthouse to turn off the lamp without damaging the lighthouse as a whole. I cannot use setHitPointDamage because there is no class HitPoints in Land_Lighthouse_F, so I am just using setHit on the hitpoint entry ("Main_Light_hitpoint") in class Reflectors. The problem is that... object setHit ["Main_Light_hitpoint", 1]; (where object is a pointer to the actual lighthouse object) ...has no visible effect. So, I added a dammaged event handler to the lighthouse, shot the light, and eventually got a result (via hint) confirming that "main_light_Hitpoint" is the correct selection. Just for kicks, I tried setHit 0 and even though the light did no turn back on (no apparent light emitted from the lamp) there was a single lit area on the ground (not the normal three) that moved as if it was "on" (see screenshots comparing before damage/after damage but also with setHit 0): So, I did some deeper debugging and outputted the the event handler to the .rpt and noticed whenever I damaged the lamp, I got four outputs. So then it clicked, there are four reflectors in class Reflectors (Reflector_1, Reflector_2, Reflector_3, and Cabin_Lumination) that all inherit from the first (Reflector_1) and as such all have "main_light_Hitpoint" as their hitpoint (there is technically a fifth reflector (the door lamp) but it has a different hitpoint and I can setHit 1 and 0 with no problems.) So I assume that when I use setHit, it is only affecting one instance of "main_light_Hitpoint" (as supported by using setHit 0 after manual damage only turning back on part of the lighting) but actual physical damage (bullets and such) all get damaged. Just to be thorough, I also tried the selection name "Main_Lights" and Ilooked through the model config to see if there were other possible selections/points I was missing. So assuming I am correct on the multiple instances, any ideas on how to overcome using this setHit such as cycling through the different reflectors or some other way of getting all of the instances of the hitppoint? Could I be wrong and just approaching this incorrectly? Thanks! Edit: So I have found one alternative to using setHit. I spawn individuals bullets and direct them towards the light to destroy it. This was inspired by code posted in the past by Twirly and Big Dawg KS: private ["_object","_sPos","_tPos","_bullet","_bPos","_heading","_velocity"]; _object = lh; // In this case a named object but can be determined via nearestBuilding or other similar methods. _sPos = _object selectionPosition "light_4_pos"; // The selection position of the center of the main light in model space. _tPos = _object modelToWorld _sPos; // The center of the main light in world space. //Run a loop that creates five .50cal bullets and then direct each one to hit the main light for "_i" from 0 to 4 do { _bullet = "B_127x99_Ball" createVehicle _tPos; _bPos = getPosASL _bullet; _heading = [_bPos,_tPos] call BIS_fnc_vectorFromXToY; _velocity = [_heading, 1000] call BIS_fnc_vectorMultiply; _bullet setVectorDir _heading; _bullet setVelocity _velocity; }; It only takes four bullets but I added the fifth just to be safe. You can hear glass breaking if you are close enough which is a little unrealisitc for power switching off but I can live with that. I the just setDamage the whole lighthouse back to 0 to get the lights to turn back on. If someone still has a solution via setHit I would still welcome it. Thanks!

I know it has been several months since I have provided an update. Rest assured, work continues. I had to take a several month break this summer for personal reasons, but have been working diligently since the 1.0 release to try to provide a realistic yet practical implementation of AEG for A3. I do not need to tell anyone here how massive Altis is in comparison with previous ArmA worlds. Previous versions of AEG only had to work with dozens of objects. The A3 version has hundreds to consider. I am trying to model the grid so it is realistic, easy to interact with, not overly resource intensive on server and client CPUs, and bug free. The macros I have created to automatically plot out electrical grids is helping tremendously, but there is still a lot of tweaking required to make it practical. More updates soon!

Wow! That is beautiful and makes complete sense. Since functions are now always loaded versus having to put down a functions module, this is great implementation method. That's what I get for taking three months off from coding. Thanks to you and Deadfast for highlighting it.

Another great initiative .kju! I have often thought of properly documenting a similar tutorial dealing with script only addons, that is, no replacement or addition of weapons or vehicle classes...purely an addon that launches a script or scripts similar to how Kylania and I describe in this thread: how do you make a script into a mod? I know al lot of the process is already documented in the CBA wiki at DevHeaven, but I think having in the Biki specifically would be helpful as well. If there is concurrence, I will create one following your template for replacement configs.

Just to chime in as well as Mr_Centipede stated, I also recommend that script wins over addon in order to preserve mission maker intentions. This is the way that I have made my electrical grids simulation work in the past. There are some tricks to getting it to work correctly though such as trying to make sure the script version runs first so if a second instance is detected (the addon version) then the second is aborted. Not the only way to do it, but the easiest in my opinion. Let me know if you decide to pursue and I can share some sample code.

Name Tags Script v 0.2 (Beta) by Loyalguard This script is still in beta development so community feedback is highly desired! Overview The Name Tags Script provides an alternative method to recognize and identify a player's teammates from the default "friendly tags" used by ArmA with the goal to make recognizing teammates as realistic and easy as possible. The Name Tags Script works completely independently of the mode of difficulty (cadet or veteran) and related settings so they can be seen even when ArmA tags cannot. Demo Video: <a href="http://www.youtube.com/watch?v=vjyn2Vrqowo" target="_blank"> Name Tags Script v 0.1.5 (Beta) Demo Video</a> (Demo is from a previous beta version but functions the same) Download (340K) MediaFire: Name Tags Script v 0.2.zip Features -Pressing the space bar momentarily displays the name of the teammate you are facing (key is customizable). -Names are only shown for teammates within 25m (value is customizable). -Recognition range is reduced to 5m for teammates facing more than 90 degrees away from you. -Only displays names for units on your side (West, East, Civilian). -100% scripting with no addon dependencies. -Fully single and multiplayer compatible. -Demo mission included. Limitations -Does not work in freelook. You will still only see names of teammates that your body is facing, not your head. -You cannot recognize teammates while they are in a vehicle. -Does not work well while player is in a vehicle as name tags are only displayed at certain angles/directions. -Tags still appear for teammates that would normally be out of your field of vision (behind a wall, vehicle, other opaque object) but within visual range (25m). Mission Maker Instructions 1. Copy the "LYGD_NameTags" sub-folder into your mission folder. 2. Insert the following lines into your init.sqf: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">sleep 1; (findDisplay 46) displaySetEventHandler ["KeyUp", "_nil = _this execVM""LYGD_NameTags\LYGD_NameTags.sqf"""]; 3. Review the LYGD_NameTags.sqf file for mission maker customization options. Player Instructions If a mission maker has included the Name Tags script in his/her mission, while facing a teammate, press the space bar. If the teammate is within visual range and does not have too much of their back to you a name tag for that unit will appear on the screen momentarily. To view it again or view another teammates name adjust your mouse as appropriate and press the space bar again. Developmental Change Log v 0.2 -Added mission maker option to display an "Unknown" tag for friendly units that are in range but facing away from the player. -Made adjustments to avoid possible unwanted infinite loops. v 0.1.5 -Initial Open Beta Release. Script Applications With ArmA's default friendly tags enabled you can "recognize" players well beyond visual recognition range. With them disabled you cannot recognize fellow players right in front of your face whereas in real life you most likely would be able to (facial features, gait, clothing, etc.) The goal of the Name Tags Script is to attempt to bridge this gap. How It Works The script functions by conducting a short series of nearestObject searches to find friendly units in front of the player and displays their names via a cut text. For a detailed description of the mechanics of the script see the readme included in the download. Acknowledgments The creator would like to thank the following individuals for their direct or indirect help thus far in making this script possible: -Spooner from OFPEC.com who provided insight into various scripting methods and concepts required for this script. Spooner's SPON_Recognise script was a major inspiration for the Name Tags Script. -Mandoble from OFPEC whose mando_drawing scripts gave me insights on how to utilize the event handler and vector commands that are the foundation of the Name Tags Script. -LeeHunt at OFPEC for his feedback and suggestions -Dslyecxi from Shack Tactical whose insight on the different applications for name tags in ArmA was helpful in developing this script. -TacticalGamer.com for their continual support of my editing projects and for beta testing.

New method works great! I plugged the new code in and instant success!

See first post for a new update video (#3). I had noticed that none of the airport, communications, or transmitter towers had warning lights on them (at least in the Alpha -- I know there is still a lot of lighting work in progress) so I added some red light sources to them that can be controlled by the grid. These are scripted only and do not involve config or model changes. The light settings still need a lot of tweaking (brightness, ambient, etc.) but I am not going to do too much with them until the lighting is more finalized. Again, my video settings are optimized for development, not rendering. EDIT. And......of course less than an hout after I post my update adding lights to towers BIS has done it organically!!!!!!!!! No worries, I am happy to see them officially in game. I can easily adjust the code to turn theirs on and off to to get the best of both worlds!

Wow! That is fantastic Tilion! Thank you! I understand that it is not final and I will remain flexible. I cannot wait to modify my code to take advantage of this. This type of feedback and attention is what makes BIS so great!

I have not checked the latest dev builds, but at least in the stable branch, the switchLight command to turn off street lamps is not yet working in the Alpha. Once it does, my AEG - ArmA Electrical Grids Script Pack and Addon for ArmA 3 will help you accomplish that easily. In the meantime the only option is to use setDammage or hideObject to destroy or hide them.

See first post for a new update (#2) and another video. Like in the A2 version, I have added the mission maker option to require players to use a password (mission maker chooses the password) to access the grid control system. In keeping with A3 taking place a few decades from now, before a player enters the password, the system attempts to use facial recognition to authenticate access. It is just for show to increase immersion, but it is a neat effect and another example of using the new PiP feature to display a live image on screen (in this case in a dialog). It still needs some tweaking such as hiding the player's view between the logon screen and the system screen and of course there are no computer objects yet in game so I am "logging in" from a cash register, but is fully functional otherwise.

I do not use a sound source, I have a game logic use "say" or "say3d" since it is invisible and deleteVehicle works without a problem. ---------- Post added at 11:08 ---------- Previous post was at 10:44 ---------- Here is a simple version: // Create side and group for logics if no already existing side or group. _side = createCenter sideLogic; _group = createGroup sideLogic; // Create a global variable (public if necessary) to determine when to play a sound. myBoolean = true; // Create a game logic at the desired position and give it a name. "Logic" createUnit [[0,0,0, _group, "mySoundLogic = this;"]; // Play the sound (make sure it is defined somewhere like Description.ext, a config file, etc.). while {myBoolean} do { mySoundLogic say ["mySound",5]; // "Say" the sound. sleep 5; // Adjust delay to match length of your sound. }; // When you want to stop the sound, make the variable false and delete the logic (it does not have to be the same script) to make it stop immediately.. myBoolean = false deleteVehicle mySoundLogic;

In AEG I have game logics use the say command to play the sound and then deleteVehicle the logic when I need it to stop. It stops immediately. I then re-create the logic if I need to start the sounds again.

There is a function called BIS_fnc_relPos that you should look. You pass to it an object or position (in your case Object A), a desired distance, and a direction in degrees. If you combine this function with BIS_fnc_randomInt, you can randomize the distance and direction each time object B spawns. Example: private ["_distance", "_direction", "_randomPos"]; _distance = [1,500] BIS_fnc_randomInt; // Random distance between 1 and 500m. _direction - (0,359] BIS_fnc_randomInt; // Random direction between 0 and 359 degrees. _randomPos = [myObject, _distance, _direction] call BIS_fnc_relPos; // The position at the random distance and random direction from myObject (rename myObject as required).

the find command returns the index of the first element it encounters in the array, not all of the elements. So, assuming there is a match, count will only ever be 1. So, when I read your first post I assumed you were looking for names of vehicles, not actual class names. If you are looking to simply count the number of a certain type of vehicle, that is a differrent process. What exactly do you want to know?

So what you want to do is find a string within a string. There is an A3 BIS function for this called BIS_fnc_inString but that does not help you in A2 unless you re-create it. There is a CBA function (for A2 and A3) called CBA_find that will also find a string within a string. If you do not want to use CBA you could create your own "find a string in a string" code. Since you know exactly what you find, here is a simple way to do that. It is a little messy but it is quick and should work (but is untested). // Set Scope private ["_unicode", "_vehicleCount", "_string", "_array"]; // Init ServerVcls (unless this is done somewhere else). ServerVcls = ["Atv_1", "Atv_2", "Atv_3"]; // Init priave variables needed later. _unicode = [41,74,76]; // A, t, v in Unicode (case-sensitive) _vehicleCount = 0; // A count of the times an instance of "Atv" is found in ServerVcls // Loop through all of the elements of ServerVcls using forEach. { _string = _x; // Get the (next) string value of the selected element in the array ServerVcls. _array = toArray _string; // Convert the String into an array. //If the array is more than three elements then it could start with "Atv". if (count _array > 3) then { // If the first three elements of _array equal the first three elements of _unicode then the string begins with "Atv" and increment the vehicle count. If ((_array select 0 == _unicode select 0) && (_array select 1 == _unicode select 1) && (_array select 2 == _unicode select 2)) then { _vehicleCount = _vehicleCount + 1; }; }; }; forEach ServerVcls; You can make this cleaner by extracting the first three elements in _array and then converting it back to a string using toString then just compare strings instead of array elements.

You could try the super class "ReammoBox", "ReammoBox_F", and "WeaponHolderSimulated" as they also appear to be superclasses of different weapon holders.

@Foffy - I can make no promises, but after initial release for A3, I will look at how much effort would be required to backwards-port the same capability to AEG A2. The custom dialog uses commands that are available in A2/OA, but I would still have to make some significant changes to the core of the simulation to make it work. I will let you know how as thing develop. Thanks for suggesting it.

As I mentioned in response to ItsThomas, I have the remote logon system ported over from Chernarus and adapted so that it will work for every island eventually supported by AEG automatically. Click on a electrical grid node on the left to see a description of it, see its location on the map (automatically), and if operational connect or disconnect it from the grid by clicking on the appropriate button. See the first post for a link to a preview video.

The secret is in this post from 2011 (#21 in the thread): http://forums.bistudio.com/showthread.php?115250-User-Interface-Editor&p=1867742&viewfull=1#post1867742 Long story short, after you export it as config and finishing defining the rest of your dialog, then load the mission where it is defined (i.e it atually works in-game), open the GUI editor, select import from config and type the following in the input box: missionConfigFile >> "MyMissionDialog" Replacing "MyMissionDialog" for whatever is the name of your dialog. I have not tried for a dialog added via an addon so in that case you would use configfile >> "MyMissionDialog" with perhaps CfgPatches in between configFile and the name of your dialog. Important Note: Before you import it from config, make sure you have your grid type set to whatever it was when you exported it or have it in your dialog (e.g. GUI_Grid, Safezone, etc.) BEFORE you import otherwise all of your x,y,w,h values will probably get screwed up when you re-export it.

There is a new command for A3, setParticleClass, that can be used to manipluate some of the new effects. I have not used it yet, but it appears to simplify a lot of the work. If you search for serParticleClass, there are a couple of threads. That being said, you could probably still use drop and particle sources to manipulate as well. All of the new particle parameters and the particle models can be found in CfgCloudlets by dePbo'ing data_f or via the Six Config Browser or the Community Modding Bible. Edit: I also believe DMarkwick uses the underwater bleeding effect in JTD Flies for ArmA3, so you may want to check that out as well.

@Chapple - Thanks! @ItsThomas - I did have that feature in CEG and AEG for A2, but only for Chernarus since it required a custom GUI. I did not expand it to other islands because the GUI alone took me over 40 manhours to create since it used resources customized for Chernarus. That being said, I am looking into "remote logon" as a possible option for the A3 version and I have some ideas of how I can do it without having to create a custom GUI for each island. I will keep you posted as it progresses.

Tank, Check out this Biki article. It is for TOH but for the most part it is the same as A3: http://community.bistudio.com/wiki/User_Interface_Editor_(Take_On_Helicopters) Ctrl-I will import from a dialog config I believe and various of ctrl-S will export