Ghostrider-GRG

I need to revisit this code as it is sort of kludgy and I got lazy when I tried to get it to work. I need to attach a grenade to a random wheel and rework the logic for the settings. For now, if you want to disable the IEDs entirely try the following:
    blck_RunGear = false;  
    blck_RunGearDamage = 0;
    blck_VK_Gear = false;
    blck_VK_RunoverDamage = false;
    blck_VK_GunnerDamage = false;
    blck_forbidenVehicles = []; 
    blck_forbidenVehicleGuns = [];
   

It should work with pretty much any map. If you look in \custom_server\Compiles\Functions\GMS_fnc_findWorld.sqf you will see the maps for which I have entered world sizes and map centers, and how the default is set.

It should work with pretty much any map. If you look in \custom_server\Compiles\Functions\GMS_fnc_findWorld.sqf you will see the maps for which I have entered world sizes and map centers, and how the default is set.

Question 2: Yes, you should be able to add any additional items that you want those traders to sell.
Question 3.1: Yes, in principle but it would require significant revision of the code. You would have to adjust the sizes of the dialogs.
Question 3.2:  Yes, you can change them in the dialogs (tradedialog.hpp).
Quesion 3.3: In principle yes but you would need to rework the code.
Quesion 4: this enables or disables the ability of a player to move the dialog on the screen.
 

The absolut easiest way is using an own script to export the Objects.
I have written my own script for this. It is absolut easy to use.
Open your Eden Editor, make your Changes and run this code from the Console.
Then you have a complete standalone code (like with e3den) in your clipboard that you can paste into a sqf and call it from init.
https://pastebin.com/Cc0CtX36

@lesvieuxcrevards,
Look in the Missions subfolder.  For example, to change the messages for Blue missions, open custom_server\Missions\Blue\default.sqf, edit as required, save and repack the custom_server pbo.

Originally concieved by Blckeagls and supported here with permission
Completely rewritten  to remove bugs and add functionallity.
 
 
Current Version: Version 7.06
Current Build: 239
Description.
Built-in support for Epoch or Exile.
Updated: Built in Headless client support.
New: includes tools to export missions from A3EDEN Editor - minimal editing/scripting required to generate new missions once the design is completed in the editr.
A complete static and dynamic mission system rolled into one.
New:
Many new Missions (Thanks to Thomas_TKO)
CHANGES:   https://github.com/Ghostrider-DbD-/blckeagles-revisited-RC/blob/master/changeLog.sqf To download go to: https://github.com/Ghostrider-DbD-/blckeagles-revisited-RC
For installation see: https://github.com/Ghostrider-DbD-/blckeagles-revisited-RC/blob/master/INSTALLATION.txt
For a complete changelog see: https://github.com/Ghostrider-DbD-/blckeagles-revisited-RC/blob/master/changeLog.sqf
Credits:
    Epoch Mod developer team, and in particular AWOL whose code has provided many lessons in scripting.
  blckeagls - Original developer of mission system 2.0.2   Narines - bug fixes and improvements.   Bill (DBD Clan) example compositions.   cyncrwler for help with troubleshooting and testing   Brian Soanes for helpful changes and performance tweaks.   Grahame for many rounds of testing, feedback and suggestions regarding features.   zxbutchxz for extensive testing of AI behavior. MGTDB for the fix for an issue with interacting with captives/targets on Exile servers. Porkeld for the CBA compatability fixes and debugging. Thomas_TKO for debugging and many new missions. * Additional Credits include authors of other missions systems and scripts who's work influenced this release:
   Halve and He-Man.     Face (A3EAI)     KiloSwiss (SEM)     Hogscrapper (HC missions for A3)     the Vampire (DZMS and VEMF)     The FUCHS (EMS)     lazylink (early A2 Epoch mission system)     Matt11 (Wicked AI) Updates: License
This Mission System is provided under an Attribution Non-Commercial ShareAlike 4.0 Commons License.
http://creativecommons.org/licenses/by-nc-sa/4.0/
 
 

 

Build 60 is now on the github and includes fixes for the bugs noted above.
One major change is that players are no longer automatically given crypto for each AI kill. Players can still take crypto from AI Bodies.
Be sure to check the installation directions for information on change that you need to make to the Epoch configs for this to work.

Build 60 is now on the github and includes fixes for the bugs noted above.
One major change is that players are no longer automatically given crypto for each AI kill. Players can still take crypto from AI Bodies.
Be sure to check the installation directions for information on change that you need to make to the Epoch configs for this to work.

I want to second this! My players and I are delighted with this mission system now, it knocks all the others out of the park. AI are responsive and much more of a challenge and everything about the system seems to have just got better. Now all we need are for us to provide more custom missions to give BlackEagl's the same breadth of missions as SEM or WAI.

Open traders\init.sqf.
go to line 23 or so.
Change as follows:
//marker text for traders
_markertext = "";
Repack your mission pbo and you should have blue dots without text labels.
Cheers,
Ghost

I recently set out to add mods to a server and confronted the challenge of pulling the class names, formatting them in lists, and generating price lists. As there was no tool I could find to do this I have put one together. It allows server owners to pull class names for vehicles (Air, Land, boat), Weapons (arifle, srifle, launchers, etc), uniforms, vests, headgear, glasses, and output lists as either a simple list or a price list. That list is copied to the clipboard and can be pasted into any text editor. The price lists can be formatted in either Epoch or Exile format by changing a variable in init.sqf.
Version 0.42 adds a option to check CfgPricing (Epoch) or equivalent price lists (Exile). The tools will only include items for which no price is found in the output. This should be handy when updating price lists or other configurations to include new items added as part of an update of a mod. See the readme for information on how to configure the tool to take advantage of this function.
Version 0.4: adds a new function whereby one can extract only classnames with a specific root. For example, by setting GRG_Root = "Epoch" in the init.sqf, one can extract classnames that begin with Epoch. There are a few other minor optimizations and bug fixes, the most important of which are addition of some output to systemChat so that the user knows something is happening, and being sure that the checks against the arrays of items to be excluded from the output are all working properly.
The tool is now considerably smaller and correctly pulls names for backpacks, glasses and other items that it missed before.
For example, you could paste classnames of all default Arma vehicles in baseVehicles.sqf so that only the vehicles from the addon are shown in the output.
While I have written each of the modules, the original approach to weapons was influenced by a post from KiloSwiss on this topic  .
Download:
https://github.com/Ghostrider-DbD-/Config-Extraction-Tools
Installation:
Instructions for installation and use are on the Github.

I recently set out to add mods to a server and confronted the challenge of pulling the class names, formatting them in lists, and generating price lists. As there was no tool I could find to do this I have put one together. It allows server owners to pull class names for vehicles (Air, Land, boat), Weapons (arifle, srifle, launchers, etc), uniforms, vests, headgear, glasses, and output lists as either a simple list or a price list. That list is copied to the clipboard and can be pasted into any text editor. The price lists can be formatted in either Epoch or Exile format by changing a variable in init.sqf.
Version 0.42 adds a option to check CfgPricing (Epoch) or equivalent price lists (Exile). The tools will only include items for which no price is found in the output. This should be handy when updating price lists or other configurations to include new items added as part of an update of a mod. See the readme for information on how to configure the tool to take advantage of this function.
Version 0.4: adds a new function whereby one can extract only classnames with a specific root. For example, by setting GRG_Root = "Epoch" in the init.sqf, one can extract classnames that begin with Epoch. There are a few other minor optimizations and bug fixes, the most important of which are addition of some output to systemChat so that the user knows something is happening, and being sure that the checks against the arrays of items to be excluded from the output are all working properly.
The tool is now considerably smaller and correctly pulls names for backpacks, glasses and other items that it missed before.
For example, you could paste classnames of all default Arma vehicles in baseVehicles.sqf so that only the vehicles from the addon are shown in the output.
While I have written each of the modules, the original approach to weapons was influenced by a post from KiloSwiss on this topic  .
Download:
https://github.com/Ghostrider-DbD-/Config-Extraction-Tools
Installation:
Instructions for installation and use are on the Github.

Epoch Discord is open.
https://discord.gg/0k4ynDDCsnMzkxk7
Always a work in progress. Channels will be added as needed. 
Check pinned messages in the channel for latest updates!
Rules that apply here also apply there. DO NOT PM the dev's if they happen to be there! You may PM me or one of the other moderators.
Download the app at: https://discordapp.com/apps

I recently set out to add mods to a server and confronted the challenge of pulling the class names, formatting them in lists, and generating price lists. As there was no tool I could find to do this I have put one together. It allows server owners to pull class names for vehicles (Air, Land, boat), Weapons (arifle, srifle, launchers, etc), uniforms, vests, headgear, glasses, and output lists as either a simple list or a price list. That list is copied to the clipboard and can be pasted into any text editor. The price lists can be formatted in either Epoch or Exile format by changing a variable in init.sqf.
Version 0.42 adds a option to check CfgPricing (Epoch) or equivalent price lists (Exile). The tools will only include items for which no price is found in the output. This should be handy when updating price lists or other configurations to include new items added as part of an update of a mod. See the readme for information on how to configure the tool to take advantage of this function.
Version 0.4: adds a new function whereby one can extract only classnames with a specific root. For example, by setting GRG_Root = "Epoch" in the init.sqf, one can extract classnames that begin with Epoch. There are a few other minor optimizations and bug fixes, the most important of which are addition of some output to systemChat so that the user knows something is happening, and being sure that the checks against the arrays of items to be excluded from the output are all working properly.
The tool is now considerably smaller and correctly pulls names for backpacks, glasses and other items that it missed before.
For example, you could paste classnames of all default Arma vehicles in baseVehicles.sqf so that only the vehicles from the addon are shown in the output.
While I have written each of the modules, the original approach to weapons was influenced by a post from KiloSwiss on this topic  .
Download:
https://github.com/Ghostrider-DbD-/Config-Extraction-Tools
Installation:
Instructions for installation and use are on the Github.

I have thought about how to script the static missions but not actually set them up. My plan was to use a threaded approach to checking when to spawn the various components to reduce server load. I have to write a few scripts to handle that part, and add a template and set of functions for spawning all the static stuff. I put that all off because our dedi crashed a month ago and life outside of scripting has been busy. The statics will be in the next version.

I have thought about how to script the static missions but not actually set them up. My plan was to use a threaded approach to checking when to spawn the various components to reduce server load. I have to write a few scripts to handle that part, and add a template and set of functions for spawning all the static stuff. I put that all off because our dedi crashed a month ago and life outside of scripting has been busy. The statics will be in the next version.

WOW Ghostrider-DbD- fuck'en wow, I honestly haven't looked at the revisited version til now, as I was no real fan of the old mission system.
What revisited version has to offer in amazing, this is going on my little server with out a doubt.
Thank you for this rewrite, again wow.
cheers
natoed

One minor "bug" seems to have been introduced, though this may be intentional. Players often will start clearing loot from AI bodies before popping the mission crate. On my servers they will probably use the captured mission vehicles to store this loot. In previous versions (definitely in v.53) this was not a problem. Now in v.57 when the mission crate is popped the cargo of the mission vehicles is cleared, removing all the captured loot.
Given that the mission vics do not generally contain any cargo anyway, is this behaviour necessary? In the interim I believe I should just be able to remove line 36 in GMS_fnc_vehicleMonitor.sqf
[_v] call blck_fnc_emptyObject; Does that sound right? It's weird because this line was in the old code anyway...

I am really glad to see this request being considered for implementation. Below are my two cents as to how one might go about incorporating key objects in Epoch for Arma 3.
I see two attributes that could be used to ones advantage: Arma's almost infinite ability to add variables to objects, and Redis' kind of free-form data tables. Imagine that there is a Key Object that is Blue and looks like an A2 Dayz Epoch key. There is one such object available in the game, and thus only 1 class that must be defined  in the mod. The variables associated with this object might include an identifier (could be alphanumeric or numeric)  that tells Epoch which vehicle it unlocks using a system of unique vehicle ID numbers, and a descriptor for that vehicle (MRAP blah blah) that the player could have displayed. In an ideal world that descriptor would be editable to 'Ghosts Ultraviolet My Kitty Car'. If you wanted to get super-fancy you could link the Arma image of the vehicle to the key as well.
How would the unique identifiers be generated and stored? As either random numeric or alphanumeric values (think base 64?) generated at the time the vehicle is spawned during server restart, or as an index that is sequentially incremented each time a vehicle is spawned. Either way, the ID number would be stored in Redis using the same algorithm used for textures, inventory and other attributes of the vehicle. When the key is generated by whatever means, that same unique ID is tied to the key object along with any other descriptors (My Kitty Car, a2\...\texture.paa). Thus all information needed to use that key travels with the key object and is avalable for scripts to lock/unlock target vehicles/doors/safes.
How does one link keys, players, containers and vehicles?  The simplest solution I can see is to consider the case of a weapon with attachments, or a magazine that is not full. Here, the mod already stores unique information specific to that object in Redis and retrieves it when a Player spawns in, or a vehicle or container is spawned at server startup. I would think this basic approach could serve as a starting point for how to store information about Keys in Redis.  Again, three atributes would need to be stored using the model proposed above: vehicle ID, name and texture. So, we can link a vehicle to a key using a unique ID, track that ID as the key goes from player to player, player to container, and so forth, and store and retrieve information about the vehicle and key to/from Redis. That key will open only the vehicle with a matching vehicle ID number. If we imagine the vehicle ID number is stored on both the vehicle and key in a variable through _x setVariable["EPOCH_keyID",_z]  then we are all set for later lock/unlock requests in which we compare the EPOCH_keyID of the key and vehicle quite easily. 
That said, this leaves opportunities for lockpick/hacking, and creating master keys as follows.
A successful lock picking attempt would set the vehicle state (another variable) appropriately, or perhaps more optimally, set the vehicle ID to 0, making it unlockable but enterable by anyone. Purchase of a keypad or lock used for any other lockable object would add a unique id to the vehicle and key to the players inventory. To avoid any chance of duplication of vehicle IDs one might add a prefix like format["%2%2", " hacked", random(one gazillion)] or format["%1%2","traderKey",random(on gazillion)]  as a hypothetical example.
A master key kit would set the ID for all vehicles on which it was used to that of one the player specifies.
Being able to handle the case of a vehicle ID == 0  as meaning anyone can enter and no one can set a lock opens up additional possibilities for vehicles spawned in the wild and dealing with abandoned vehicles.
Vehicles are already stored with a time-stamp indicating when the Epoch lock expires. This could be re-purposed to tell the server when the vehicle is abandoned. Rather than tracking when the vehicle was locked the server would track when it was last access, moved or entered. Abandoned vehicles are deleted or have their Vehicle ID set to 0, returning them to the wild. 
If one spawns vehicles in the wild, one would simply spawn them with Vehicle ID == 0, which opens up all the possibilities noted above.
I hope these suggestions are helpful.
Cheers - Ghost
 
 

The issue is that for multiple items there needs to be a valid config. This can't be generated at startup (as far as I know). This also leads to inventory clutter which is why Epoch moved from a physical currency in the form of bars to a virtual one in the form of Crypto. Items aren't necessarily the way to go.
How I see keys being managed is a GUI menu accessed via the dynamic menu. You should be able to clone keys (with the correct resources), give out keys to nearby players, drop keys, view keys, possibly store keys in objects. The issue Altis ran into is having two inventories (the virtual and the physical). It would be a nice idea that if an object has any keys stored on it that a notification item is stored in the physical inventory of the object that can't be taken by a player (something like a key ring). Dead bodies should also have a loot keys option if the player had keys.
As for how it would work and prevent hacking, that is complex. I think this should be done like many websites do user accounts. With a salted MD5. The answer to unlock the vehicle is a password (in generated key form). When you use the key it is sending a password to be checked. That is sent through the script and "hashed" and compared to the hash from the database. If they match then the vehicle is unlocked. However to take the hash from the database and then crack it would be very time consuming. Something similar could be done.
But what if a hacker simply unlocks a vehicle using the unlock command? The antihack would need to check for players in unlocked vehicles without the correct hashed keys on them.
KK has a decent post on a hashing DLL he did a while ago.
http://killzonekid.com/arma-extension-hash_id-dll/

I am not against adding it back as I know that was a key feature of ours. If keys are added we need to consider how it might be done better as having to write external events to purge vehicles that are abandoned without any keys, etc. is a mess. Virtual keys maybe the way to go as adding 12500+ classes just to have keys in your inventory was also not ideal either but it did work.

If you want to propose the changes needed to make "virtual keys" happen I would welcome the challenge of merging it and making it work.

Maybe this one: 
Other helpful Redis lua resources:
https://www.redisgreen.net/blog/intro-to-lua-for-redis-programmers/
https://redis.io/commands/eval
https://www.compose.com/articles/a-quick-guide-to-redis-lua-scripting/

A while ago there was a wonderful tutorial on how one can use lua scripts to 'restock' or completely remove the invetory for traders which I have been using for some time. Included in that was a script to replace vehicles with vehicle repair kits or other goodies. I wondered if anyone who is more adept at these things would be willing to share an lua script that deletes vehicles altogether. Any assistance would be much appreciated.

I was getting a bunch of these after the update to 1.68. The have stopped since uploading the performance builds to the server. I follow the thread linked below for info about these updates.
 
https://www.reddit.com/user/Dwarden