conroy

ah thanks JShock, did that now. Wasn't aware, that it can be used for that.

Updated the script again to work with the latest A3 version and added some new functionality. Reworked the OP and added "Admin-Markers" to the script. (global markers, that can not be deleted by non-admin players) Also generally added more comments in several of the files and included an example mission. Practical usage on public servers is probably still limited, as players likely won't know how to use the marker prefixes. Maybe there are some who might find it useful for their organized sessions though. Also would be nice if a moderator could possibly change the thread title to "[Release] Additional Features For User-Placed Markers". ;)

Execute scripts/code via chat commands Description: A little mini-project I worked on, which allows you to intercept and use text, that was typed in the inGame chat-box. Any text, that starts with the special intercept character (by default "!"), will be passed on to a function and checked against all available chat-commands. If it matches one of the defined commands, the associated code for the command is executed. Any text after the initial command will be passed as an argument to the called function. Intercepted text is not sent to other clients and wont clutter up the chat history. The script folder comes with some examples, that show you how the commands are defined. ("module_chatIntercept\commands.sqf") The current version of the script does not have any extra functions included, apart from the example ones. It rather serves as a base to include your own functions and ideas, if you can come up with something interesting or practical. Usage: Simply execute the init.sqf inside the script folder on a clients machine. [] execVM "module_chatIntercept\init.sqf"; Inside the script folder are two files, which allow further configuration. The "config.sqf" (fairly empty atm) allows you to change the intercept-character. pvpfw_chatIntercept_commandMarker = "!"; "commands.sqf" defines the array of all available commands. (Edit this one or define the array somewhere else to customize the usable commands) The format is: pvpfw_chatIntercept_allCommands = [ ["command1",{/*code1*/}], ["command2",{/*code2*/}], ["command3",{/*code3*/}] /* etc */ ]; Download: Example mission: https://www.dropbox.com/s/ijnzhhd5gv104l3/pvpfw_chatIntercept_v02.Stratis.pbo Script folder: https://www.dropbox.com/s/lk2mq4yjt5242z2/module_chatIntercept.zip

Each marker needs its own unique name. Using _forEachIndex as part of the markers name would be a possible solution _hsmrk = createMarkerLocal [format["myMarker_%1",_forEachindex],getPosASL _x];

Uploaded v1.04, which should work again with the 1.16 patch. Also included a new experimental feature, that will display certain markers in the normal 3D view. By default only markers starting with "lz", "ei" and "e ", will be displayed this way. "LZ" markers are not shown to everyone, but rather only to certain classes, that are defined in the new config.sqf. (["B_Helipilot_F","O_helipilot_F"] by default) "EI" and "E " markers are only displayed for a few seconds and are rather meant as a hint to others, that a new hostile contact has been marked. It should also now be possible to place markers during the briefing screen, without breaking anything. A full reconnect is still required though, when someone wants to change to a different slot. There are quite a few debug messages active right now, though they are only shown once during the creation of the very first marker. Just search for the various "systemChat" commands, if you want to remove them.

Any non-local marker command will always transmit all the markersettings. It's possible to save a lot of bandwidth, when having some global markers, that frequently update, by using local commands, except for the very last one. This for example only uses a fraction of the bandwidth compared to all commands being global, while having the same effect. _marker setMarkerAlphaLocal 1; _marker setMarkerTextLocal ""; _marker setMarkerTypeLocal "mil_dot"; _marker setmarkerColorLocal "ColorBlack"; _marker setmarkerDirLocal 0; _marker setMarkerSizeLocal [1,1]; _marker setMarkerPos (getPosASL player);

if NOT(_groupType == "Mounted infantry") then {_marker setMarkerSizeLocal [1,1]; _marker setMarkerPos _pos}; should be if NOT(_groupType == "Mounted infantry") then {_marker setMarkerSizeLocal [1,1]; _marker setMarkerPosLocal _pos}; I guess, so that it doesn't broadcast the marker globally.

Was doing some test and can think of 2 reasons why that might happen. Either it wasn't a dedicated server, but a player-hosted one or the script wasn't executed quickly enough or had some kind of other delay. It's probably something I forgot to mention. The script has to be executed on the server before the mission actually begins. This means, that there can be no delay (waitUntil, sleep, etc. before it), as the server needs to have the "onPlayerConnected" eventhandler ready when the mission starts. (otherwise it cant give players a proper response) I tried to make the script compatible with non-dedicated servers: v1.02 (not well tested though) If you were on a dedicated one, try adding the script to the very top of the init.sqf or put the code to run it in a game-logic in the editor instead. edit: found out, that it might have already been non-dedi compatible as publicVariableServer and publicVariableClient seem to be able to trigger eventhandlers on the same machine? :confused:

The easiest solution would probably be to just edit the current english abbreviations in the "change.sqf to fit another language. Adding a lot of additional shortcuts for various languages would not be too good for the scripts performance and might end up in a lot of accidental marker-changes I would imagine.

It "is" working on dedicated servers with JIP ;) The only limitation right now is that a player needs to remember to reconnect, when he wants to go back to the lobby and change to a different slot. The script wont error out in that case, but it would simply not be able to tell his old and new markers apart from each other. Reason for this is, that a players ID will stay the same since he stays connected, but his internal counter for custom markers will start from 0 again. It's usually not a problem if a player only placed 1 or 2 markers so far. In that case a reconnect wouldn't even be necessary. Just create 2 empty markers and the script will be able to change them again once the 3rd one is created.

Additional Features For User-Placed Markers (intercept marker placement and execute code depending on their text) Description: This script will check for certain character prefixes in the text of markers and run the specified code, if a match is found. The functionality included in this release ranges from being able to easily change a markers appearance, to displaying them in 3D in the game world, as well as global "admin-markers", that can not be deleted by non-admin players. In theory you could execute any kind of script, that might be useful in a mission, once you assign it to a pre-defined markertext prefix. The script was initially used in an organized PvP environment, where it was necessary to quickly place markers, that contain a lot of information. It might be less suited for public missions, where players have little chance to get familiar with the scripts functions beforehand. (Especially since it all works off a markers text and not via an additional interface.) Basic-Features: Changing a markers appearance: The primary functionality of this script is to change a markers appearance. Certain 2 to 3 letter prefixes at the start of the markers text will influence its icon-type, size, color, text-modification, etc. (For example use the "ei" prefix to mark enemy infantry, which creates a red dot marker with an additional timestamp at the end) 3D Markers: Certain prefixes will not only change a markers appearance, but also make them visible in the 3d game world, without the need to open the map. You can specify the duration a marker will be visible, the 3D icon type and which class it should be visible to. (Anyone could mark LZs, that are then visible for allied pilots in 3D for example) 3D markers will become more transparent, when looking directly at them. Admin only markers: Kind of inspired by a recent discussion in the Script Makers Skype-Group. Admin are able to place markers, that can only be removed by themselves or anyone who logs in as admin after them. This can come in handy, if you want to display Teamspeak-Information, mission waypoints, etc., that other non-admin players should be unable to remove. (Default prefix for this is a double colon, "::" (has no effect if a non-admin player uses it). Serverside marker handling: Whenever a marker is created, the information is passed on to the server. (markername, who created the marker, position, text) You can then also run code there. For example logging the creation of a marker to the rpt among other things. Usage: Players: When you first open the map, the game will prompt you to double click anywhere. This will place an automatic marker to determine your inGame DirectPlay ID and initialize the clientside functionality. Afterwards you can place markers as normal, optionally utilizing the predefined prefixes in your markers text. Mission-Makers: Copy the module_markerIntercept folder into your mission and include the cfgFunctions.hpp in your description.ext with any new function tag (ideally use pvpfw). description.ext example: class CfgFunctions { class pvpfw { #include "module_markerIntercept\cfgFunctions.hpp" }; }; Alternatively you can also just execVM the folders init.sqf, though the cfgFunctions method is recommended. Script customization: See "module_markerIntercept\client\change.sqf" for changes, that are applied to markers depending on their text and "module_markerIntercept\server\init.sqf" for code, that is run serverside whenever a marker is created. Known Issues: A player has to completely reconnect, when he wants to change slots in the mission. Changing a slot while staying connected will prevent the script from getting the correct marker. (If the user already placed previous ones) See these 2 related feedback tickets: http://feedback.arma3.com/view.php?id=19879 http://feedback.arma3.com/view.php?id=17103 Download: Version 1.1 (updated for the latest A3 version, new functionality)

handleDamage will always give you the new total damage value for that selection. You need to do some calculations with the current damage values of the unit, before letting the eventhandler return the new damage player addeventhandler ["HandleDamage",{ _unit = _this select 0; _selection = _this select 1; _passedDamage = _this select 2; _source = _this select 3; _projectile = _this select 4; _oldDamage = 0; switch(_selection)do{ case("head"):{_oldDamage = _unit getHitPointDamage "HitHead";}; case("body"):{_oldDamage = _unit getHitPointDamage "HitBody";}; case("hands"):{_oldDamage = _unit getHitPointDamage "HitHands";}; case("legs"):{_oldDamage = _unit getHitPointDamage "HitLegs";}; case(""):{_oldDamage = damage _unit;}; default{}; }; _return = _oldDamage + ((_passedDamage - _oldDamage) / 20); _return }]; Give this a try and see if it works for you.

the player likely doesn't know where or what TAG_ammobox is, as it was created remotely on the dedi. You can either publicVariable the vehicleVarName, create the client marker on the global "marker_clear" marker or publicVariable another variable, that just contains the position, so the client can create his marker on it. You can give this a try maybe, this "should" create the marker on the "marker_clear" position (but didnt test it) ///run this bit on server only////// if (isserver) then { sleep 5; _location = AO_locations call BIS_fnc_selectRandom; _pos = getmarkerpos _location; AO_locations = AO_locations - [_location]; ["clear","Locate and Destroy","Locate and Destoy the Ammo Crate that is somehwere in the town it should be within 150 meter of the marker",true,["MissionAO",_pos,"mil_objective","ColorYellow"]] call SHK_Taskmaster_add; ////////PATROL MARKER///////////// _mrk1= createmarker ["marker_clear",_pos]; _mrk1 setmarkershape "ELLIPSE"; _mrk1 setmarkersize [180,180]; _mrk1 setMarkerColor "ColorRed"; "marker_clear" setMarkerAlpha 0; sleep .2; TAG_ammobox = createVehicle ["Box_NATO_Ammo_F",getmarkerpos "marker_clear", [], 0, "NONE"]; TAG_ammobox lock true; //TAG_ammobox addEventHandler ["HandleDamage", { if ((_this select 4) == "SatchelCharge_Remote_Ammo") then [{_this select 2},{0}]; }]; [TAG_ammobox,150,2] execvm "buildingpos.sqf"; MainAO setPos (getpos TAG_ammobox); sleep 2; /////DEBUG///////// if ((paramsarray select 0) == 1) then { _cid = floor(random 10000); _t = format["ammo is here%1",_cid]; [_t, TAG_ammobox, "Icon", [1,1], "TEXT:", _t, "TYPE:", "mil_dot", "COLOR:", "ColorGreen", "GLOBAL", "PERSIST"] call CBA_fnc_createMarker; }; }; //////run on client//////////// waitUntil{!isNull player}; if (playerSide == EAST) then { waitUntil{markerColor "marker_clear" != ""}; _eastmaekerpos = createMarkerLocal ["ammo_locationmarker", markerPos "marker_clear"]; _eastmaekerpos setMarkerColorLocal "ColorBlack"; _eastmaekerpos setmarkershapelocal "icon"; _eastmaekerpos setMarkerTypeLocal "mil_dot"; _eastmaekerpos setmarkertextlocal "Ammo Box Location"; };

probably need to post a bit more of the script to show what's run on the server and what is run on the client, because this looks like everything is running on the same machine.

Yes the server runs it in multiplayer. You should be able to add it to any mission, if you can make sure, that it won't interfere with existing scripts (which it normally shouldn't)