RimBlock
-
Posts
1140 -
Joined
-
Last visited
-
Days Won
3
Content Type
Profiles
Forums
Articles
Posts posted by RimBlock
-
-
Haha, just beat me too it....
-
Hey Rim, just out of curiosity why do you have us place the server-side modifications in the server main directory instead of MPMISSIONS\(map)\custom\....
with the previous version I had just relocated and changed the paths myself, but now you have more in there and I'd rather not start breaking things.
These files are usually in the dayz_server.pbo and have no need to be sent to the clients (which is what happens to the files in the MPMissions folders). This is partly to cut down on space but also for better security.
The server side files can either be in a server side folder sitting inside the ARMA II OA folder (name it anything you want, I just chose custom) or you can just put the files back int he dayz_server.pbo using something like PBO Manager. Just make sure wherever you put them, you change the paths in the relevent files to point to the new location (inside or outside the pbo).
How exactly would i test to see if this is working..?
With A Plot for Life turned off (default state)
Place a plot pole, build an object, die, go back to the plot pole and build another object: Not able to build = Sucess.
Now try with removing items, upgrading and downgrading items, placing, unlocking, locking packing safes, same with tents, sqme with locked doors.
With A Plot for Life turned on (via the DZE_APlotforLife = true; variable in the init.sqf).
Place a plot pole, build an object, die, go back to the plot pole and build another object: Able to build = Sucess.
Now try with removing items, upgrading and downgrading items, placing, unlocking, locking packing safes, same with tents, sqme with locked doors.
With Take item ownership from the plot pole turned on (via DZE_PlotOwnership = true; set in the init.sqf).
1. Have someone else you are not friendly to build a plot pole and a few items (floors, walls etc).
2. Go and remove the plot pole and build your own plot pole.
3. Take ownership of items from the plot pole options.
4. Remove an item (should take 3 cycles if you own it for most items or 6 if you don't own it).
5. Check the DB to make sure the last number in the worldspace field is your SteamID for those items.
There is lots of other testing you can do but those are the basic indicators that it is installed ok.
Think im just tired 3am :( Cant find these files anywhere. Looked in Sanp Pro, P4L and nothing. I know where to change the paths but need the files first lol
I had presumed that Raymix had merged the building framework and his snap build pro together but this may be wrong. The files are available on the Epoch Github (https://github.com/vbawol/DayZ-Epoch/tree/master/SQF/dayz_code/actions) .
The original thread on this is but I may just take the files and include them in my package after checking with Raymix to make sure he has no objections. The files from the Git are the ones I tested with and work fine with Epoch 1.0.5.1 as well.
-
In 2.31 i noticed this in the server functions
};
_PUID = [_player] call FNC_GetPlayerUID;
diag_log format["SAFE %5: ID:%1 UID:%2 BY %3(%4)", _objectID, _objectUID, (name _player), _PUID, _statusText];
};
};
But would _PUID work? Cause I don't believe it is used for 1.0.5.1_PUID is just a variable.
If you mean "Does FNC_GetPlayerUID work as it is a function only available in 1.0.5.2" then the answer is yes as I have included it in the release (it is in the compiles.sqf).
-
Hello,
iam a little confused about the install instructions and not sure, if version 1.0.5.2 is required to make plot4life 2.3.1 working.
also this part is unclear to me:
Snap Build Pro has been merged with the player build framework by Raymix for Epoch 1.0.5.2. Download both and extract them. Copy the files to a directory of your choice but exclude the following files which I have supplied already merged and linked in the compiles.sqf. - player_build.sqf - player_build_create.sqf - player_build_plotCheck.sqf - player_build_publish.sqf - snap_build.sqf - modular_build.sqf Link the other files from Snap Build Pro and the modular player build framework in the compiles.sqf as needed (the lines should already be there, just search for DZE_modularBuild).
I ve got a fresh install of 1.0.5.1, no custom scripts, maybe someone is willing to share his knowledge on how to make those two scropts work together...
thanks in advance
greetings ryker
Ok, this is kinda hard to make clear.
This update was built for 1.0.5.2 but as 1.0.5.2 has been delayed a number of times I have pulled it out and modified it so it will work with 1.0.5.1. 1.0.5.2 is not required.
I would suggest;
- Install this mod.
- Extract Snap Build Pro (in to its own 'custom' directory)
- Do not use the Snap Build Pro compiles.sqf
- Open the A Plot for Life v2.31 compiles.sqf
- Search for " if (DZE_modularBuild) then {"
- Change the following lines to point to the files that you extracted from the Snap Build Pro release (i.e the ones that with the path that starts "z/addons/".
player_build_countNearby
player_build_states
player_build_needNearby
player_build_getConfig
player_build_buildReq
player_build_controls
- Leave the ones that have the paths that start "Custom\A_Plot_for_Life" as they are pointing to the files I have already merged.
- Make the other Snap Build Pro amendments as listed in Raymixs instructions (for the .hpp file etc).
- You should be good to go.
@everyone,
I have just spotted a typo (copy paste error) in the compiles.sqf
Line 109
player_build_plotCheck = compile preprocessFileLineNumbers "player_build_plotCheck\player_build_plotCheck.sqf";
should be
player_build_plotCheck = compile preprocessFileLineNumbers "Custom\A_Plot_for_Life\Action\player_build_plotCheck.sqf";
I will amend the download and the file on GitHub later tonight.
-
Hi Rimblock,
Think you made a wise decision there, i stopped maintaining our 1.0.5.2 dev server a few weeks back when they kept pushing the deadline forward.
- Are you still thinking about doing a customized plot pole management system like the Plot Management mod? I'd like all of our custom plot stuff in one place.
- Is there like a 'latest' player_build.sqf file both you and Raymix maintain? I don't mind merging them myself, but i'd rather have some sort of official one so it's less likely to produce errors :P
Cheers,
f3cuk
Yeah, seeing the pull request sitting there for around 3 weeks after I worked long hours to get it done for the stated deadline is quite irritating. The new features were written for the 1.0.5.2-RC version and so rather than re-engineer for 1.0.5.1 I was able to just pull the code out of the pull request and include a couple of extra code snippets from 1.0.5.2 to make it work with 1.0.5.1 so I could release here as a mod.
With a couple of plot management systems out there (based around the plot pole) it is actually quite easy to pull them together. It sorta feels like putting a GUI on this is just re-inventing the wheel although I may look at merging one of their releases into this mod with a bit of tuning.
The code used in this mod was based on the latest release Raymix had uploaded to the Epoch base code. Myself and Raymix are pretty well aligned on ideas and view and we are working together on bits and pieces so I am sure we will both be working to keep the merged files up to date where possible.
I have compared all files of v2.31 and now this:
if (count _inventory > 0) then { if (_type in DZE_> 17:32:06 Error position: <_inventory > 0) then { if (_type in DZE_> 17:32:06 Error Undefined variable in expression: _inventory 17:32:06 File mpmissions\DayZ_Epoch_11.Chernarus\custom\server\server_monitor.sqf, line 192 17:32:06 Error in expression < ["OEMPos", _pos, true];What can i do to fix the problem?
Have you installed any other mods apart from this one ?.
A Plot for Life does not touch the inventory side of things so it looks like another merged mod may be causing an issue or a typo. I didn't see any errors for the final cut of code I released on a new build Epoch server.
So I'm guessing DiffMerging the latest files won't work. I think it's better if I start with a vanilla install.
Diffmerging may be ok although if you have precise base building and vectors and plot management gui all installed then it will be much trickier.
I would recommend a clean server build if possible, a period of testing and then putting live.
I have done some testing but would suggest you do your own, especially with the "Take plot ownership" function and doubly so if you have large bases on your map.
@Everyone,
Please provide feedback on how the 'Take Ownership' is working for you and how people are liking (or not) the plot boundary on/off with the lighted road cones. I did want to do flashing lights but there seems to be a limit to the number of light sources visible as I could not get them all lit and flashing at the same time.
-
Sounds nice. Tell me you are putting in drag and drop and multiple slot spaces per item (no more 12 car tyres in your trouser pockets) ;) .
Ok, multiple slots per item may not be as popular but it just feels so much more realistic that way.
-
-
Should do.
Although... with only 5 mtrs between the plot pole radii and a +20 maintainence range you will probably end up with one plot owner potentially having to maintain another plot owners items. The 14 mtr difference was put in to stop one plot owner building a structure (think seige tower) in order to breach the walls of another plot owners structures :) .
One other consideration would be the object volume load on the server. Bigger plot radius = more objects = more server load, although if you are coming from a no plot pole environment then you probably have that already.
-
i just added the new updated build vectors for snappro 1.4.1, and I haven't even launched the server yet to test it and saw this update.
Without getting too indepth it seem the balance between Snap Pro, Plot For Life, Plot Manager, and Build Vectors is a very delicate one. Any expectation of this breaking anything? I will give it a shot here in a few minutes after I verify I did the vectors installation correctly.
This covers Snap Pro the merging for snap pro. Plot manager should not be too difficult and build vectors I have not really looked at. I would expect server monitor and player_build / snap_build to be the most affected files (although Snap Build is spread over the modular build files now).
compiles.sqf wrong paths
if (DZE_modularBuild) then { player_build = compile preprocessFileLineNumbers "Custom\A_Plot_for_Life\Action\modular_build.sqf"; player_build_countNearby = compile preprocessFileLineNumbers "\z\addons\dayz_code\actions\player_build_countNearby.sqf";//no such file player_build_states = compile preprocessFileLineNumbers "\z\addons\dayz_code\actions\player_build_states.sqf";//no such file player_build_needNearby = compile preprocessFileLineNumbers "\z\addons\dayz_code\actions\player_build_needNearby.sqf";//no such file player_build_getConfig = compile preprocessFileLineNumbers "\z\addons\dayz_code\actions\player_build_getConfig.sqf";//no such file player_build_plotCheck = compile preprocessFileLineNumbers "player_build_plotCheck\player_build_plotCheck.sqf"; player_build_buildReq = compile preprocessFileLineNumbers "\z\addons\dayz_code\actions\player_build_buildReq.sqf";//no such file player_build_create = compile preprocessFileLineNumbers "Custom\A_Plot_for_Life\Action\player_build_create.sqf"; player_build_controls = compile preprocessFileLineNumbers "\z\addons\dayz_code\actions\player_build_controls.sqf";//no such file player_build_publish = compile preprocessFileLineNumbers "Custom\A_Plot_for_Life\Action\player_build_publish.sqf"; snap_build = compile preprocessFileLineNumbers "Custom\A_Plot_for_Life\Action\snap_build.sqf"; } else { player_build = compile preprocessFileLineNumbers "Custom\A_Plot_for_Life\Action\player_build.sqf"; };Please read the install instructions (also available in the download package).
Take note of the section which says...
Snap Build Pro has been merged with the player build framework by Raymix for Epoch 1.0.5.2. Download both and extract them. Copy the files to a directory of your choice but exclude the following files which I have supplied already merged and linked in the compiles.sqf.
- player_build.sqf
- player_build_create.sqf
- player_build_plotCheck.sqf
- player_build_publish.sqf
- snap_build.sqf
- modular_build.sqf
Link the other files from Snap Build Pro and the modular player build framework in the compiles.sqf as needed (the lines should already be there, just search for DZE_modularBuild).
This means you have to put the paths in depending on where you put the other files for those mods which are not included in this release (as they are not my mods).
-
Anything listed like "STR_EPOCH_PLAYER_53" is defined in the stringtable.xml file. This is used to centralise strings and allow for different language translations using the localize function.
If you want to override it then just change it to text in the fn_selfactions file for maintenance.
(DZE_PlotPole select 0) should hold the current set plot radius for the server.
For building the plot pole, this one is more tricky as I believe it is using the displayName from the class files. Some class files can be redirected but the ones relating to the buildables cannot.
You could possibly redirect the code that gets the class entry description from the class files if the class is for plot poles and then inject your own description rather than take the one from the class displayName. SHould be pretty simple but you may have to dig around a bit to find out which script does that when in the gear menu.
-
It should be ok from a game mechanics point of view.
Removal only check for the buildable owner and not the plot pole so should not be affected. Players will not be able to upgrade / downgrade items (half wall -> full wall / add locks to doors etc) for items that are out of range of a plot pole.
Cannot comment much on base destruction as I don't use it.
Maintain only looks for items in range of the plot pole. If it is out of range then it will not be able to be maintained and will 'expire' once its damage hits 1 (the Epoch DB events do the damage on a daily basis).
THere is a variable to set the plot pole range. It is an array of two numbers, the first is the plot size and the second is how close another plot pole can be built to an existing plot pole. I don't have the variable name to hand but a quick search on the forums should turn it up as there have been lots of threads asking for it.
-
New version uploaded (See first post).
This is a rewrite to enable it to be turned on and off via a variable (on server reboot).
Please backup your databases and thoroughly test before putting live.
This will rewrite ownership on buildables if "Take plot item ownership" is enabled.
-
Due to the Epoch team needing to spend the majority of their time on A3Epoch, the pull request has not yet been included in the Epoch code.
I have now completed the plot boundary on / off option on the plot pole and I have now also completed the "Take item ownership" option, also from the plot pole (owner only). I wanted to integrate them with the code to be included in to Epoch core build which is 1.0.5.2-RC2 but due to its delays, I have decided to offer A Plot for Life v2.31 as a standalone mod in the mean time.
I have removed the original pull request and will be making another with these extra features shortly.
What v2.31 offers.
- The whole system is is switchable between characterID and PlayerUID by setting a variable.
- All items built after the mod is installed with have the PlayerUID and the characterID stored for ownership checking (locked buildables will only have the PlayerUID stored as the characterID field is used for the lock code).
- Includes the 1.0.5.2. code to allow either SteamID or BIS PUID (written by icomrade).
- Setup to easily integrate with the modular build system and Snap Build Pro (activated by setting a variable). Common files are merged but you do need to download the other files for those two mods for it to work.
- You can turn on the plot boundary from the plot pole and remove it. Currently I am using the road cones with lights on top which are also visible at night. They can be changed.
- Take Ownership is available from the plot pole to the plot poles owner and allows them to take ownership of all buildables in range excluding locked storage (safes / lockboxes), tents, locked doors. This can be changed as it is all controlled via variables. The core idea is that this will align peoples bases to the new system for steamID storage on legacy bases. It also means that raiders can raid a base, replace the plot pole, take ownership and not get full access to locked areas but not have 6 cycles to remove stuff etc after taking over. Depending on the size of the base, number of objects etc this could put a bit of load on the server / DB. It is also turn off or on-able via a variable so you can set it only to allow players to realign their bases and then disable the option.
- New function to check ownership or friendly status of a given object.
Current state.
Just testing the code as a standalone mod.
Need to check the plot boundary markers allow vehicle passage.
Need to confirm / account for plot objects already owned but without a SteamID saved in the objects record.
I am expecting to release next weekend, maybe sooner.
-
Thanks for the mention Zupa.
A chance to break in would be good as I have been playing around with the idea of bobby trapping a door with a frag mod :D ....
Just as an aside, I am just writing the instructions for my add-on for A Plot for Life which gives a plot owner the option to take ownership of all buildables on the plot (excluding safes, lockboxes, tents and locked doors - all configurable).
Meant mainly for people to align their old buildables to the A Plot for Life v2+ system but would also allow raiders to place their own pole and take ownership.
If you are using the inventory (wep / mag / backpack) fields then is should work fine.
- dzrealkiller and cen
-
2
-
Make sure that they are not unlocked buildables (like cinderblock walls and such) as they also have a CharID of 0.
Cars/Aircraft/Boats with a CharID of 0 are vehicles that are not keyed, and are either random generated, or mission saved (if you have vehicle saving missions).
Buildables with a CharID are lockable such as doors, safes, lockboxes, etc.
err, all buildables in vanilla Epoch have a characterID of the builders characterID at the time of building.
It is what is checked when players interact with them (i.e. remove, upgrade, downgrade). Locked buildables overwrite it with the door / lock code.
@OP,
Try running the following in a sql client to get an idea of what object type in your DB have a characterID of 0.
select distinct classname from object_data where characterID = 0;
You will get a list of classes which should give you a fair idea of what the items are and then can decide based on that.
Only non-owned items have a characterID of 0 but be careful as players may be using cars etc they have found (and so do not own). I would check the lastupdated date and inventory as well.
-
I do not know where this is controlled but would have a look in player_updateGui.sqf as this is the code that controls the food / drink / heat etc UI elements so is probably a good bet.
-
If your going as cheap as possible you could go with the G3258. Thats the unlocked dual core Pentium. Its only 70$ and with a solid 20-40$ cpu cooler you can reach 4.5 overclock NP. You can get a B85 or even H81 motherboard that are 40-90$ to overclock it. (not all boards can overclock) I would go with a solid z97 that way you can upgrade a year later to the unlocked broadwell cpu's that are 14nm.
Didn't know the G3258 was unlocked! Yeez that's a lot of CPU power for only a few bucks. Combine that with a decent cooling solution, a small SSD, some other cheap parts and I'm pretty sure you can build your own
dedi box that outperforms 95% of the current epoch serverspc that runs Epoch (Arma 2/3) perfectly.Something like would run
any epoch serverARMA perfectly- Intel Pentium G3258 Boxed € 56,93
- Gigabyte GA-Z97P-D3 € 74,95
- MSI GeForce GTX 750 Ti € 131,04
- Cooler Master N300 (KKN1, closed) € 30,50
- Cooler Master Seidon 120V € 35,80
- Crucial CT51264BA160BJ € 34,42
- be quiet! System Power 7 350W € 34,85
- Crucial MX100 128GB € 58,49
Total € 456,98 (inc. vat)
(P.s. There are hardly any H81 / B85 boards that are unlocked, more important however is that their components are often not build to be OC'd (including weak mosfet cooling) so it's not really safe to OC them either)
Edit: Oops not talking servers. Changed the post a little.
This is where I was looking for a test server. The G3258 AE seems to have popped up at just the right time. My only concern is that it is dual core only. This would mean that the OS and ARMA would have to share ;) .
As for playing, both myself and my son have i5-2400s (Sandy) and for the most part the game plays fine. Mine was a bit jerky on A3 but then I am also playing on a Radeon 7950 @ 2560 x 1440 (27" IPS Dell monitor).
I recently upgraded my HTPC to an i3-3240 (3.4GHz 2 core no HT) with a Radeon R7-265 (IIRC) and it plays fine at 1920x1080 over our projector.
If I was not so bothered by price, I would probably be looking at a E5-1620v3 Xeon (3.5GHz, 4c8t, max 768GB DDR4 4 channel up to 2133 ECC, 40 PCIe lanes) which is pitched around $294 (tray only). Only just out so no real reviews out there but should match with a X99 board and they are being listed all over the place now.
-
I have not found any link to any source whatsoever? I know you didn't mean wrong by it, but the whole relying on 3th party dll (without source available) files is wrong to begin with. I'm not saying they aren't thrustworthy, just that it is not healthy having to rely on devs being just that. I'm am a full 100% sure if I release an easy to install fully working Single Currency mod including a custom Hiveext.dll that is malacious, people would download and install it on their server no questions asked. This is a huge security problem and far bigger then potential exploits on 998/999.
If they are unwilling to release I may have to dive into this myself. Luckily the source from the current one is still available and I'm pretty sure i'll be able to implement custom 999/998 calls. The only thing bugging me is that I'm going to have to buy a ~500 dollar license for a product (Visual Studio) that I'll probably never use again. Also it brings me back to the reinventing wheel part cause this has already been done
On the link I posted is a line "Unofficial source files with 999 for epoch hive:" with a link underneath. It links to rajkostos original source from which the Epoch hive .dll is taken. THis code still has the 998 / 999 calls in it.
Fully agree with published .dlls without source and without compiling yourself unless it is from a trusted source.
For compilation, install Visual Studio Express for Desktop (scroll down the page). It is free.
Ongoing dev work is a big concern if using a .dll not aligned to the mod as Sanbird says which can be a big problem with locked down calls.
@Sanbird, that would be fine in a world where everyone was 100% open and hones. How many people wouldn't mention the fact they are using the 998 / 999 .dll when asking for support knowing they would not get any if they did....
My intention is not to side with anyone or view really (just seems like flogging a dead horse TBH as the Epoch team have made their views clear), it was just to mention that there are sets of code and compiled .dlls out there if people wish to take the risk in using them.
I will not be using the hiveext.dll for my own servers mods anymore.
-
-
Now when you say minimal. Is that with 25+ players or just with a few? By the sounds of it the mod would increase a lot of server stress with more players online. If so anyway to cut down on the stress it is causing?
Minimal compared to what vanilla Epoch is doing with like for like player numbers.
It does more or less the same as vanilla Epoch but gets the ownership data from a different variable.
Server restart may be a little bit slower but that is likely to be the only difference that would possibly be noticeable.
-
The mere fact that you suggested it to me without having tested it or knowing what's inside supports that statement.
Which is why I made the statement (i.e. use at your own risk ;) ). Zupa made a link to the source code on the same page although it all comes down to trust in the end, in this case that the avaiable source code was used to compile the .dll.
Also to note. Zupa has kindly made the compiled dlls available for people and this is not meant to be anything negative directed towards Zupa at all, more a highlight of the risks that exist using code from the internet in compiled form.
For those who have not seen it, BIS have a page on safety considerations of using .dll (extentions) with ARMA here.
-
Zupa made a hiveext.dll with 998/999 calls available in the single currency thread
I am not using it and have not tested at all.
VBAwol has flip / flopped on the subject a number of times on Github and I can see his point of... to an extent. Unfortunately just citing the age old "Its insecure" does not in anyway help quieten down the baying masses who would like to leverage it.
I have adked VBAwol and a few others who trot out the "Its insecure" line what is so insecure that cannot be managed with server side sqf and DB security / restrictions and have yet to hear any sort of answer from anyone on this.
TBH I think the problem is that Epoch is pitched or has evolved in to an almost 'one click' install meaning lots of people out there without very much technical knowledge are able to run their own servers. This has helped Epochs popularity greatly and I would imagine VBAwol and the other devs would like to keep this door open. Supplying a Hiveext.dll with 998 / 999 calls with Epoch opens up large risks for server owners without any grounding in DB security and server side sqf coding if they implement it or mods using it. This then causes massive knock-on effects support wise for the mod and is likely to damage its reputation.
The dev team are stretched thin at the moment with the A3 Epoch work, the Twitch streaming. Pull requests and work on DayZ Epoch seems to have slowed down significantly (My A Plot for Life pull request is still sitting waiting for inclusion in the Epoch code ;) ;) devs....). Cant see anything official happening with the hive at all.
There are also other options out there as well as using Zupas Hiveext.dll with the 998/999 calls. ARMA2Net is one which Sanbird has extensive knowledge of.
For the people saying "Just go and make your own version.". The hiveext is built in c++ which is a whole new kettle of wax ( ;)) to scripting in sqf. A lot of people dont have the skill set and the majority dont have the time to learn it (myself included) and so we have to rely on others who do.
-
On 9/6/2014 at 3:58 PM, Powell said:
How much stress does this mod cause on a server ?
Minimal. It just looks at a different field when loading items from the DB and then does the same sort of compares when deciding if the player is the owner or friendly to the owner.
tent_pack.sqf just calls player_packTent (defined in compiles.sqf).
-
I would take a look at Plot Management as it disables the ability of a non-owner to remove objects (AFAIK).
They may be able to help over there or have a solution already.
A Plot for Life uses the standard Epoch removal mechanics and so you can remove anything but if you are not the owner or a friendly then it will take longer with more chance of breaking tools when doing so.
[Release] - A Plot for life v2.5. Keep your buildables on death. Take plot ownership
in A2: Epoch Mods (1.0.5.1)
Posted
I would stay away from merging in to the dayz_code.pbo as this is a client side file and will now not match the Epoch signitures which means that you will have to set verify signitures = 0 in the config file which then means any client can have their own code in the dayz_code.pbo and run it in your game.
Keep all the client side stuff in the mpmissions folders.
I personally keep all my server side stuff in the servers "custom' folder as it gives me easy access to modify if needed and it is not sent to the client. You will have to try it out or wait for someone else to advise on whether changing the dayz_server.pbo also causes the same problem with keys.