RimBlock
-
Posts
1140 -
Joined
-
Last visited
-
Days Won
3
Content Type
Profiles
Forums
Articles
Posts posted by RimBlock
-
-
Ok, putting in an idea for a change to the buildables placement mechanics.
Problem.
People being able to build flying bases.
Buildables dissapear if the builder moves more than 5mtrs from the starting build point.
Buildables not accurately getting position (still using [get/set]PosATL rather than FNC_GetPos and FNC_GetSetPos (the latter works correctly over sea and terrain).
Solution.
Buildable location will be measured from the plot pole to plot max size / 2 to calculate max distance before building is aborted.
Buildables cannot be built more than 45 mtrs above the ground / sea.
Change all legacy calls to newer FNC calls for positioning.
Results.
You should be able to start building and then walk around the whole plot (if so desired) without the buildable vanishing.
Buildables can only be up to a defined height (will be a global variable which is user overridable)
Building over water should work a bit better.
I will also look at putting in the local plot radius (proposed by f3cuk) at the same time.
Any comments or concerns then please shout out now.
-
Having a quick browse on this (again - with more knowledge on the build mechanics) I see two issues
1. The plot pole can be built more than "DZE_PlotPole select 0;" metres above ground level (30 by default giving a max height of 45mtrs) or items can be build above 45mtrs if no plot pole is required.
2. Items positions are checked relative to the player and not the plot pole (if the buildable is not a plot pole) or the players original position if plot pole requirement is turned off.
Seems the original code is trying to shoehorn two different possibilities in to a single block of code and the result does not really fit either situation as well as it could.
Buildables should be able to be built anywhere within the plot poles radius regardless of where in the plots radius the build process was started if a plot pole is required.
The player_build should also be using FNC_GetPos to check height above land or sea.
I will take a look over the weekend for A Plot for Life and look to back port it to standard Epoch 1.0.5.1 if it works well.
-
Ok, to drill down a bit on what appears to be working and what does not.
Old bases & Old friendly
Take ownership of base
Friendly cannot build before server reboot: Y/N
Friendly cannot build after server reboot: Y/N
Old bases & New friendly (post A Plot for Life install)
Take ownership of base
Friendly cannot build before server reboot: Y/N
Friendly cannot build after server reboot: Y/N
----
New bases (built post A Plot for Life install) & Old friendly
Take ownership of base
Friendly cannot build before server reboot: Y/N
Friendly cannot build after server reboot: Y/N
New bases (built post A Plot for Life install) & New friendly (post A Plot for Life install)
Take ownership of base
Friendly cannot build before server reboot: Y/N
Friendly cannot build after server reboot: Y/N
----
Own bases & New friendly (post A Plot for Life install)
Already owned base
Friendly cannot build before server reboot: Y/N
Friendly cannot build after server reboot: Y/N
Own bases & Old friendly
Already owned base
Friendly cannot build before server reboot: Y/N
Friendly cannot build after server reboot: Y/N
-
Ok, good to hear, was working on your comment from post
Only one problem we are now experiencing, if we tag each other as friendly, the friend can't build or remove as they can with default Epoch. Is this a feature? Only the plot owner can build and/or remove in P4L?
Ok so will concentrate on building only.
Do you have modular building turned on or not (DZE_modularBuild = true; ) ?.
-
Sorry, yes, after that line.
Then try to remove something where you are not the plot owner.
-
Ok, for testing, try adding the following to this mods remove.sqf
FInd
_nameVehicle = getText(configFile >> "CfgVehicles" >> _objType >> "displayName");
Change to
// For testing. diag_log format["[Remove.sqf] Player: %1 Friendlies: %2",player,_friendlies]; diag_log format["[Remove.sqf] Object: %1 Plot pole Owner: %2",_obj,_ownerID];
Post up the results which should appear in the client RPT file.
Edit: Actually, just typing it out...
It checks the plot pole owner not the object owner :D
-
Sorry, didn't get the chance last night. WIll try to find the time tonight.
-
Non-owners or friendlies should not be able to remove buildables (standard Epoch).
I have kept to the spirit of Epoch as much as possible so have left that side of it alone.
It shoulds like something is messing around with the friendlies system (which is a PITA TBH).
Is it not working correctly on a system with only Vanilla Epoch and A Plot for Life installed or are there other mods and if so which ones.
I can do a quick verify on my test system as it is currently up and running tonight and see if I have the same issue.
-
Ok so this is what I have so far.
Vanilla Epoch 1.0.5.1 & A Plot for Life v2.34
Place a plot pole
Build a metal floor and wood wall
Log off and stop server.
Change ownerID in the DB for those objects to a random SteamID (inc the last number by 1).
Start the server.
Login.
Remove the plot pole (no longer the owner).
Place a new plot pole.
Try to remove floor or wall: Fail, option does not appear.
Choose take ownership option from the plot pole.
Remove wall & floor: Items removed from game world but not from DB (still trying to remove original objects objectID): Fail.
Logoff
Stop server
Change objects ownership to different SteamID
add "_object setvariable["ObjectID", "0"];" line to plot_take_ownership.sqf under "publicVariableServer "PVDZE_obj_Delete";"
Start server.
Login
Try to remove floor or wall: Fail, option does not appear.
Choose take ownership option from the plot pole.
Remove wall & floor: Items removed from game world and the DB: Success.
If you take ownership and then reboot the server I suspect it will work straight away without having to add the extra line.
Github & Dropbox have been updated.
-
The mod is the Epoch Devs vision which may or may not be tinted by community feedback.
If the devs have said indestructable bases do not fit with that vision then it wont go in to the A3 Epoch mod. There really is no point on trying to convince them to change their mind.
Wait until it comes out and then either mod it yourself or get one of the modders here to do it.
The dev team have said there is a decent modding system planned so lets see how it turns out and if it is not as good as expected then there are a number of modders here who will most likely take up the challenge to do something to fix that.
Personally I am not a fan of indestructable bases but do believe there has to be some sort of protection whilst players are off the server. A number of decent options have been suggested but I kind of like the following solutions best;
- A general upgrade option to allow players to armour the walls (increase wall hitpoints and different model).
- Booby traps / vehicle & personnel landmines (craftable).
- Alarms
- Self destruct
Just think of the possibilities....
Create a nice little choke point raiders have to go through to get to the main base walls. They drive through it in a vehicle they plan to explode against the walls and boom... vehicle mine + vehicle = goodbye raider.
To counter, have some mine sweeping gear (vulnerable whilst sweeping).
To counter that have claymore boobytraps covering the minefield with tripwires (for when not at the base to stop minesweeping).
I also think that destroyed bases should leave a portion of the required crafting items behind that are 'salvaged' from the rubble...
-
You could try putting a sleep 1; after the setvariable line I suggested you added. I really want to see the server log report that the original item is deleted before the new item is published. As it is reporting it is publishing the new item (with the same OUID) before deleting anything with that OUID I can see why there would be no objects in the DB left. Both actions are reported in the same second and scripts do not always execute in the order they are called. Sending a 'completed' ack back from the server after the delete would be safer but would up the bandwidth usage and affect any other items using that delete server side script.
I cannot get to the link from the office so am not sure what the other mod is doing. A copy of your remove.sqf may help.
I may get a chance to spend a little time verifying the issue tonight.
-
Thanks for the info.
I am curious as to why your publish is displayed before your deletion ("Player 1 Takes ownership of the 2 half cinder walls through the plot").
It should delete and then publish.
In plot_take_ownership.sqf make sure the publicVariableServer "PVDZE_obj_Delete"; is before the publicVariableServer "PVDZE_fullobj_Publish";
So we have two environments.
DB env
Game env
Game env objects can have a number of states depending on the env.
New object before reboot (OID = 0, OUID = game calculated based on world position).
New object after server reboot (OID = DB autoassigned value on creation, OUID = game calculated based on world position at time of creation).
Old object (OID = DB autoassigned value on creation, OUID = game calculated based on world position at time of creation).
Object removal at a DB level (in the context of buildables) checks the objects OID and if it is not 0 it will use that for the deletion as it is guaranteed unique. If the OID is 0 then it will use the UID (which may not be unique but most of the time will be).
Object removal at a game world level does not happen in this mod. The variables attached to the object are just changed.
To remove an object if you are not the owner but are friendly give a penelty of taking twice as many cycles so the game thinks you are still friendly to each other for some reason. A far as friendlies goes, this mod only changes whether the SteamID is recored or the characterID is recorded in the player record for team members. If you have anything that plays with friendlies then it may knock this off.
A look at the character records from the DB may be helpful.
-
Hey RimBlock, good news and bad I'm afraid....
The good news is that did sort out the having to delete twice problem. Items removed the first time after taking ownership, stayed removed after a server restart. :) This testing was done on a legacy base with just me.
I asked one of my admins to come in so we could test still being able to remove after a legitimate death. I killed him and he could still remove so, that was fine too. :)
The bad news.....he built a new base, I then took the plot down, replaced it, took ownership and removed a wall. However, he could also still remove walls as well. He then took ownership back after replacing the pole. I could then still remove walls. However, his animation was 3 stages, mine was 6. We then realised we had been regression testing DayZ group Management earlier and when you join a group that automatically tags you as friendly. Even though we had disbanded the group before this test, we decided to restart the server and restart our test again.
Same thing happened, exactly the same way as described above.
Even more strange, after that restart, pretty much around 80% of the new base had vanished...a lot more than the 3 walls we had removed for the test.
When we looked at the ObjectID's of the remaining walls in game using infiSTAR show target info, I get a 6 digit number and the owner is shown as me, he gets a zero and the owner is shown as him. In the db, the steam ID is his but the ObjectID matches the 6 digit number I had received on target information in game.... :/
Any ideas....?
We're off to test on a legacy base now but, thought I should let you know this asap.
Thanks
EDIT: Now tested on a legacy base, same thing happening.
Also, importantly, what seems to be happening is that now the items are being duplicated in the db. They have the same ObjectUID but a different ObjectID. If one of us removes that item, both entries in the db are removed and the item is removed in game.
Ok, firstly ignore infinistar. AFAIK it is not tailored to work with A Plot for Life.
Friendlies are stored in characters current state field (with other data). There is a max of 5 and they should be pretty easy to spot. Delete them and the friendlies will be unlinked. The character will need to be logged off, delete the entries at the DB and then log the character back in.
What is in the DB is the key. If you place a pole and take ownership then you need to check the game logs with what is in the DB. New items will not have an objectID until the server is restarted and they are read in.
As what you are doing is quite complex, it would help if you bullet pointed your steps including server / client rpt file and DB table checks to confirm who does what when and what each person client state is and the server state is when each person is performing the action. As you can imagine, trouble shooting 2+ person interactivity can be quite tricky.
-
ObjectUIDs are based on object location. As the object does not move the ObjectUIDs should be the same even though they are re-calculated when the replacement object is created.
Thanks.
-
Seems the remove reference in the compiles.sqf only gets used by object_removeNearby.sqf which is not part of the player building code. I believe it is safe to keep it as it is.
As you can see with the take ownership messages you posted above, Items are being removed using the objectID and being created with the objectUID from the sqf code (just with reference to my previous post).
Just a thought after a quick look at the code.
In Custom/A_Plot_for_Life/Action/plot_take_ownership.sqf
Find
PVDZE_obj_Delete = [_objectID, _objectUID, player]; publicVariableServer "PVDZE_obj_Delete";
change to
PVDZE_obj_Delete = [_objectID, _objectUID, player]; publicVariableServer "PVDZE_obj_Delete"; _object setVariable ["ObjectID","0"];
I believe the take ownership is deleting and creating a new object record but in the game the object still remains and so the other fields are being updated (in game) but the objectID is staying the same as it was for the old object.
Give it a go and let me know. Will look deeper in to it tomorrow if it does not work.
Thanks for providing the feedback especially with so much detail.
-
Objectid is set by the database server and there is no way for the information to be read back in to the game world due to hiveext restrictions. Objectuid is set by the game.
Objectid is used when available. If not available then objectuid is used.
You can try adding a diag _ log line to remove.sqf to check the values for both of those.
I will have a look tomorrow to try and find what the issue may be.
-
-showscripterrors on the client startup parameters and DZEdebug = true; in your init.sqf
-
For the stuff I do, I ask for the modifier to PM me for permission (so I know what is going with my code on more than anything), original credit and a link back to my thread on the forums here.
Most of it just seems like common courtesy to me really.
Check the original mod makers thread for any requirements they may have posted. Contact them if you cannot find anything. I think most people are fine with it as long as they get credit and you are adding value (rather than changing a couple of variable names and taking credit for the full mod - which it sounds like you are not :) ).
-
This mod does not touch maintenance.
Have a check in the DB to make sure the buildables are getting damaged.
-
I have the same errors and I believe they are not related.
Place a plot pole, die, build a new item on the plot.
Get your frendlies to build, kill them, see if they can build again.
Unpack a new safe, open the safe (should not need to put in the code).
Have your friendlies open the safe (they should need a code).
Make sure modular build variable is set to true in your init.sqf and try snap building.
Have a look at the feature list on page 1 and I am sure you can come up with a few others.
-
Presumabily you could limit it to the plot pole owner or friendlies like building rights for Epoch are controlled on plots.
Triggers are expesive but you could make it a plot pole option or add it to the fn_selfactions as a get nearest object within 30m range and if ownerUID = player uid or owneruid in friendlies etc. Not very efficient but then fn_selfactions is already a pretty big mess. To reduce impact you could limit it to one in every 10 runs of fn_selfactions or something.
KillzoneKid also had an article on his site on using something as a short range trigger which may work well. Have a browse through his tutorials.
-
The files in the dropbox download are designed to be copied on to a new vanilla Epoch server.
If your server is already modded then there is more work to do and the quickest and easiest way to do it is by using something like diffmerge which allows you to see the differences between the two files and choose which differences to include in a third file (or overwrite the second file).
To find out the changes you can just extract the vanilla Epoch files that this mod has versions of and windiff against the modded versions to find the differences.
This version is more closely related to Epoch 1.0.6 (not yet released) than Epoch 1.0.5.1 for the building side of things which can make it a bit more tricky for the player_build stuff but is all ready for easy integration when (if) 1.0.6 is released.
-
Ya mate i don't know where u put them these days ^^ i still use my own version of your 1.x or 2.0 i think ^^ which was located in your mission file back then ^^
Didn't want to come over negative!
A side note:
I've been following some hack forums lately to see what's up in there and their was a "hack" that could pull server files of your server. ( But your prob heard about that to a while ago )
An early v2.x probably as that was the change to the SteamID. I think the initial versions had it is the mission folder due to urgency of getting a working version out there for people but this was later moved due to protecting against the concerns you just mentioned :) .
I vaguely remember something about a hack to read server files but TBH if it does exist then I think access to the hiveext.ini would be a bigger concern. I did have a quick scan of the bigger cheat sites but nothing popped up. Possible misinformation or bragging to get attention ... don't know. If you do come across a reference to it then would be grateful if you could PM me the link so I can take a look and see if there is anything I can do to minimise the effect for this mod and the A3 one.
-
But move the server_monitor back to server. I feel safer people not seeying what happends in my server_monitor ^^ ( but thats just my opinion and as i read now also Rimblocks No 4 statement.).
hey u can even put it somewhere like this ^^ so it won't be located in your pbo's.
execVm "C:\supersecretserverfiles\server_monitor.sqf";
The server mod files are only installed on the server if the install instructions are followed. There is no reason to put them in the mission folder sent to the client.
[Release] - A Plot for life v2.5. Keep your buildables on death. Take plot ownership
in A2: Epoch Mods (1.0.5.1)
Posted
The proposal will not increase range 9 building but will correctly enforce it. Building range will be measured from the plot pole and not from the player's starting position so there would be no building range extension.
I guess it should be pretty easy to optionise it.