Search the Community

Version 2.1 Released. Alternative selling/buying system. ( Run default & this one next to each other ). Supported: Config traders Single Currency & Default Currency Selling/Buying everything from and to Gear/Vehicle/Backpack Not supported No database traders (database traders make your server slow) No ability to buy or sell vehicles. What was added to 2.0 Default Currency Supported Item Filter Info display of selected Item Buying to gear and backpack What was added to 2.1Fixed content display of vehicles and backpacks. Description Sell directly from backpack, gear or the vehicle ( close) where you were driver from. Decide which items you sell. Traders will only make it possible to trade the items they accept ( goes fully automatic, so only items they accept will be listed on the left). You push items to the right to sell, only the items on the right willl get sold. Safety measurements Double checks what was deleted from backpacks/vehicles so that people can not cheat. Can only sell from your backpack and the vehicle were u was the last driver from ( in 30m radius) Update 1.0 - 2.0 instructions Delete your old 'zupa' folder Paste the new 'zupa' folder Edit the config.sqf to match your server Done https://github.com/DevZupa/AdvancedTrading/releases/tag/v2.1 Items only show for admins when using infiSTAR AH & Admintools ?! Update infiSTAR to latest version. edit config.sqf to reflect your server correctly. Installation instructions Code: https://github.com/DevZupa/AdvancedTrading/releases/tag/v2.1 Install Instructions 0. Drop the zupa folder in your mission file 1. In your fn_selfactions.sqf Place: _buyV = player addAction ["<t color='#0059FF'>Advanced Trading</t>", "zupa\advancedTrading\init.sqf",(_traderMenu select 0), 999, true, false, "",""]; s_player_parts set [count s_player_parts,_buyV]; above // Database menu _buy = player addAction [localize "STR_EPOCH_PLAYER_289", "\z\addons\dayz_code\actions\show_dialog.sqf",(_traderMenu select 0), 999, true, false, "",""]; s_player_parts set [count s_player_parts,_buy]; 2. in description.ext, add the following on the bottom #include "zupa\advancedTrading\ZSCdefines.hpp" // if u don't have it from ZSC #include "zupa\advancedTrading\advancedTrading.hpp" 3. Add the following exceptions to your antihack if needed AdvancedTrading 711197 4. Edit the config.sqf to match your server. Screenshots:

Hello Community i need help . Sorry for my bad english. Im from germany and i need help. I Have Advanced trading and Single currency 3.0 (without global banking) from zupa, and when i sell or buy in the normal trading menu , the trader dont use coins from me. With advanced trading menu the trader use coins for the item. Pls help me. Thx

I have looked but can't find any info on this anywhere.... I wanted all of my buildables to be set to right click the toolbox. I have it all set up right with 46 items in the drop down menu. The drop down menu will not load and it breaks the crafting window when I load that many. I haven't tried to figure out how many possible entries I can have in the drop down menu without breaking anything, but i did just try to put 4 items in it and it worked fine. Does anyone know: ---how many entries the menu will hold without breaking ---If it is possible to change the max number of items it holds ---Or if i just have to make a second right click entry for the toolbox and have a whole other crafting window pop up with a different sets of items? Thanks in advance!!!

FYI, this guide is for advanced arma coders. This guide will assume you know how to pack/unpack PBO's, edit files, and are comrfortable with coding. You must also have an understanding of locality as in client vs server side. A note on locality: Your mpMissions folder is NOT only client side. When I started coding I made this assumption and I was wrong. Lesson 1: Event Handlers Basics Event handlers are the bread and butter of Arma2 MP coding. They are little logic functions that the server sets aside until they are called by a public variable. In my experience they have very low overhead so don't be afraid to make use of them. example 1: Change players skin Add this code to the bottom of your init.sqf (in your mpMission) // expects: [_playerUID,_CharacterID,_skinClassName] // this line says ONLY run on the ClientSide. The server will see this and ignore it. This means that when a client gets this command, they and only they will execute this. if (!isDedicated) then { "PV_ChangePlayerSkin" addPublicVariableEventHandler { // handle our packet. _this select 0 returns the PV name, _this select 1 returns our input packet _packet = _this select 1; // should contain [_playerUID, _characterID, _skinClassName] _playerUID = _packet select 0; _characterID = _packet select 1; _skinClassName = _packet select 2; // set our player to the skin [_playeruid,_characterID, _skinClassName] spawn player_humanityMorph; }; }; Ok so now we got our event handler set up, if any client sends the PV "PV_ChangePlayerSkin" all clients connected will execute this event handler. Here is how we send the command to all players. This code can be called anywhere, on a client, or from the server itself. example: PV_ChangePlayerSkin = [_playerUID,_CharacterID,_skinClassName]; publicVariable "PV_ChangePlayerSkin"; But you may be asking, how do I set just a single player's skin instead of everyone on the server? We do this with publicVariableClient. I am unsure if you can call this command from clientside as I only use it serverside but here is how you do it regardless. // lets assume we want to set our cursorTarget's skin (the player we are looking at) _player = cursorTarget; _owner = owner _player; // owner command returns the client # we will need for the next step. _playerUID = getPlayerUID _player; _characterID = _player getVariable ["CharacterID","0"]; _skinClassName = "FR_GL"; // my personal skin PV_ChangePlayerSkin = [_playerUID, _characterID, _skinClassName]; _owner publicVariableClient "PV_ChangePlayerSkin"; // only send the PV to the specific client Now when we send our public variable we only send it to the client we wish to. There are a myriad of ways to get player objects loaded into memory but that will be covered later.

We all know that feeling, you just got your server tweaked and optimized just how you like it and an Epoch update comes out! OH NO! what do we do? Wait for the mod authors to release their own patch? Hell no! We diffmerge! If you followed my guide on how to override mod files, you may be asking "what happens if the files we overrode changed on an update?" well the answer depends if it was changed. Here is how you can locate all the changes if there are any and make the changes needed to keep your server running. What you'll need: Diffmerge, A working copy of DayZEpoch Server, modifications Difficulty: Advanced Scenario 1: An epoch mod update came out and you being a good admin want to make sure there were no changes made to your reference file. For this guide, we will assume you modified the variables.sqf by using my tutorial Locate the files you have made changes to Locate the original file Diffmerge the two files and compare changes, merging where necessary Right click your original file and select "Diffmerge->Open With Diffmerge" Click "Browse" on the 2nd line referencing the "right" file. Note diffmerge always goes from left to right. Meaning the file you wish to change or update needs to be on the right hand side! Here's what the diffmerge window looks like, note the changes in red. You can see where we added the new class reference. If we click the down arrow (Next Change) we can scroll all the way to the right and see where we added our new skin That's it. Just take a look at all the changes and use your reasoning to determine if you need to make changes. If you are being studious, you may have noticed a few more changes near the bottom of the file represented by the red "-" on the left. Ignore these, normally you would only see the top two changes.

Ok so I'm being a bit ambitious and creating a sweet admin-controlled event system. Been picking AxeCop's brain this weekend and figure I bugged him enough. For this example, I need to display an admin menu if the following conditions are met (Event_Started = true, Match_Started = true, Round_Started = true) These variables will be initialized and handled on the server side. However, I need my admins to know the status so that certain menus can be called depending on the status. Aka if I start an event, wait till player slots are assigned before starting match. The variables MUST be broadcast to all JIP and new clients ( I know how to do this so far ), so publicVariableEventHandlers are the best solution for me. I have two options as I see it to grab these variables. 1. Have a separate handler for each variable ex: "PV_Event_Started" addPublicVariableEventHandler { Event_Started = _this select 1; }; "PV_Match_Started " addPublicVariableEventHandler { Match_Started = _this select 1; }; "PV_Round_Started " addPublicVariableEventHandler { Round_Started = _this select 1; }; 2. Have a single handler for all variables that expects all 3 booleans to be passed at once "PV_StatusHandler" addPublicVariableEventHandler { private ["_packet"]; _packet = _this select 0; Event_Started = _packet select 0; Match_Started = _packet select 1; Round_Started = _packet select 2; }; I think #2 looks cleaner but I feel both solutions are dirty... Passing 3 booleans every time a status updates when I only need to pass 1 is kind of dumb. Feels like too much data being handled would slow things down. However, having the client handle 3 events vs 1 sounds dirty as well. My question is mainly which of these methods would work the most efficiently? Possibly I could branch out #2 to use a switch statement to only update whatever variable is passed to it. edit: guess I kind of answered my own question. In looking over these options, I feel below is the most elegant of solutions. It requires me to write the least amount of code, handle the least amount of data, and it is modular in that I can use it for more than just this project. like this: // populate client data "PV_StatusHandler" addPublicVariableEventHandler { private ["_packet"]; _packet = _this select 1; _variableName = _packet select 0; _value = _packet select 1; // determine what variable we want to update switch (_variableName) do { case "Event_Started": { Event_Started = _value }; case "Match_Started": { Match_Started = _value }; case "Round_Started": { Round_Started = _value }; }; };

What we are doing: Setting up an automated build process to compile the server and mission PBO on restart Why: Ever needed to make changes to your server but had to wait for server restart? Ever missed that window and had to wait another 3 - 4 hours till your next restart cycle? I hate that! Requirements: PBOmanager, notepad++, firedaemon(optional) or knowledge of editing your batch scripts, a dev environemnt (you do have a dev environment don't you?), a dedicated server Difficulty: Advanced Ok guys, as stated before it is a huge pain in the ass to have to wait till your server goes down to push changes. Why not automate it so that you can make your changes and be done with them? So to start off you really should have a dev environment that mirrors your production environment. I'm talking about a dev server here people. Quick and dirty, just copy and paste your folder containing the Arma2OA install (you know the folder with @DayZ_Epoch_Server in it) to another directory. Doesn't matter what the name is but you need to make changes here before you make them on your production server so you can verify that you didn't break anything. Step 1: Install PBO manager if you have not. you can get it here: http://www.armaholic.com/page.php?id=16369 Step 2: If you do not have unpacked folders of your PBO's living next to them in their proper directories, unpack your pbo's so that you have a folder with the same name in the same directory. This is where you will make your changes. Step 3: Create a batch script to run BEFORE your server starts. This PBO will automatically pack up the folder into a PBO overwriting your old one. Here is the content of my batch script "pbopack_dev.bat" (note that this is for the dev server, your path will not be the same" "C:\Program Files\PBO Manager v.1.4 beta\PBOConsole.exe" -pack "D:\dayz\DEV_Epoch1\@DayZ_Epoch_Server\addons\dayz_server" "D:\dayz\DEV_Epoch1\@DayZ_Epoch_Server\addons\dayz_server.pbo" "C:\Program Files\PBO Manager v.1.4 beta\PBOConsole.exe" -pack "D:\dayz\DEV_Epoch1\MPMissions\DayZ_Epoch_11.Chernarus" "D:\dayz\DEV_Epoch1\MPMissions\DayZ_Epoch_11.Chernarus.pbo" Step 4: Integrate batch script into your current server restart method. I use firedaemon, if you use a batch script, just make sure you run the previous batch before you start your server but after you have shut it down. for firedaemon users, just add the batch script to the "pre-service programs". Give it a nice 15 second timeout to ensure we didn't start the server too fast. That's it. Verify it works without breaking anything and you can implement this for your production servers. Development and Deployment strategy: Ok so I touched a little about this earlier but you MUST use a development environment. Any programmer who has worked in a professional environment will know that you NEVER EVER EVER make changes to production code. Firstly, its dangerous, secondly, it makes you look bad if you break a critical system because you were too lazy to test it properly. Always make changes to your dev server first before you migrate those changes to the live prod environment!!!!! Ideally, you would want to have an exact mirror of your production server so that you can accurately verify your changes don't break something. Here's how I do it. Initial Setup: 1. Copy entire DayZ server directory to a new one (this only needs to be done once) 2. Backup your DayZ database and insert it as a new one (I use "DayzEpoch_DEV" for this) 3. Modify your hive.ini so it points to your dev database 4. Make changes on dev server and verify results. After Setup: 1. Delete "@DayZ_Epoch_Server" and "mpmissions" directories from the DEV server folder. 2. Copy over "@DayZ_Epoch_Server" and "mpmissions" from your PROD server folder into the DEV server folder. 3. Make changes you need to the folders (no need to recompile as our script above does that for us) 4. Verify changes Migrating changes from DEV to PROD on a Live server: 1. TEST YOUR CHANGES IN DEV 2. Navigate to your PROD server directory and delete the PBO's unpacked folders you wish to modify 3. Copy the unpacked folders from your DEV server to the PROD server 4. Wait for server restart to automatically recompile the folders into PBOs