[Release] - A Plot for life v2.5. Keep your buildables on death. Take plot ownership

[RimBlock]

litl confused: why moved server_monitor.sqf to mission directory???

 

and if that's true?

 

server_funtions.sqf

 

under

server_updateObject = compile preprocessFileLineNumbers "\z\addons\dayz_server\compile\server_updateObject.sqf";

 

add line

 

server_publishFullObject = compile preprocessFileLineNumbers "\z\addons\dayz_server\compile\server_publishFullObject.sqf"

 

and more line in  Server_monitor.sqf

 

repack pbo not done? work method?

 

1. To enable install without needing to touch the server pbo file.

 

2. Yes there is a new script for the server called server_publishFullObject.sqf

 

3. Yes you need to add the new script to the server_functions.sqf

 

4.  You can add the files to the server pbo file and change the links to point to them.  Whichever you prefer.

[Tanita-Corp]

@RimBlock thx mate. 

[Zupa]

@RimBlock thx mate. 

 

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";

[Tanita-Corp]

 

 

execVm "C:\supersecretserverfiles\server_monitor.sqf";

ohhhh cool

y best zupa

[RimBlock]

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.

[Zupa]

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.

 

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 )

[RimBlock]

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.

[Zupa]

You should get active on skype and join our server/scripting channel, it's getting the active epoch guys together, we're just missing you and raymix ( and the epoch devs, but they don't care).

 

There is also a hacker in it ( i'm not sure about his intentions, but he tend to care and share the latest news on hacks). If he wasn't usefull i kicked him out the first day :)

[smexy]

Was this mod supposed to be installed first? All the files you are asking me to call for have edits in them and I can't just replace them... Is this install different than other mod installs where you don't tell what to edit in the files and just give the vanilla files with edits in them?

 

EDIT: Also I have plotmanagement installed, I can't really tell what the difference is because plotmanagement says you can still build there even after you die?? Isn't that what this script is supposed to do?

 

 

EDIT2: First part I read back in the thread and I was right, time to look up that notepad method xD

[RimBlock]

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.

[smexy]

 

 

9:39:54 Server: Object 3:108 not found (message 99)

9:39:54 Server: Object 3:109 not found (message 91)

9:39:54 Server: Object 3:113 not found (message 91)

9:39:54 Server: Object 3:112 not found (message 98)

9:42:53 Server: Object 3:136 not found (message 91)

Followed the instructions all the way through, I'm pretty sure I've installed it correctly. What exactly can I check for to make sure it's working properly?? I have base takeover option on false.

 

Also are these errors serious? I'm just putting down plotpoles to test.

 

Not sure if its related but shooting a wood wall isn't allowing me to maintain it.

[RimBlock]

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.

[smexy]

Alright, any idea why shooting buildables won't let me damage them so I can maintain? I did a fresh install with all your files. It worked when I used my server hostings default settings, did I miss a setting to allow them to be damaged? Is it because I'm admin maybe?

[RimBlock]

This mod does not touch maintenance.

 

Have a check in the DB to make sure the buildables are getting damaged.

[smexy]

On a fresh install I'm getting the GUI lock-up like the other user was a few pages back but his seemed related to updategui being 1.0.6 version. Any idea why mine might be locking up? I've pointed to default player_updategui.sqf and it still locks up after entering combat.

 

How do I enable debugging to see what's causing it to lock up?

[RimBlock]

-showscripterrors on the client startup parameters and DZEdebug = true; in your init.sqf

[smexy]

Unfortunately I don't have access to the start.bat on my server host right now so if anyone has a fix for the GUI locking up I would love to know what it was!

 

 

Whoops didn't realize it was client

[ReDBaroN]

Hi RimBlock, first off, thanks for another great mod :)

 

However, I'm having a problem....

 

I'm also relatively heavily modded so, went down the diffmerge route.

 

Everything works fine, take down a plot, replace it, take ownership, remove items. Locked Items not able to be removed, plot boundary showing just fine. SteamID's showing in the worldspace column for the object. No errors in the rpt. All good....

 

The problem I have, is that after a server restart, the removed items reappear. If I remove them for a second time, after another restart they have gone finally. But, can't understand why they didn't stay gone the first time.

 

Not sure if this helps but, after taking ownership through the plot pole, I checked the ObjectID in the db and it had removed the old row with the old ObjectID and replaced it with a new row with a new ObjectID and my SteamID in the worldspace column. So, this part is all good I think... but, when I used infiSTAR's 'i' key to retrieve target information before trying to remove the item, it still shows the old ObjectID in game which no longer exists in the db, even though I had taken ownership through the plot pole.

 

So, it seems that somehow the db is not updating the game and is then letting me remove the object that's already deleted from the db. Therefore, it's not removing the new entry after taking plot ownership which explains having to remove it finally for the second time.

 

Any ideas.....?

 

Thanks

 

EDIT: I have made sure to run my tests without turning anything on in infiSTAR

2nd EDIT: I have run the same tests with infiSTAR disabled. Same result as outlined above.

[smexy]

For anyone who needs to fix GUI locking up, find player_guiControlFlash in compiles.sqf and replace that whole section with,

player_guiControlFlash = 	{
		private["_control"];
		_control = _this;
		if (ctrlShown _control) then {
			_control ctrlShow false;
		} else {
			_control ctrlShow true;
		};
	};

[ReDBaroN]

Hi RimBlock, first off, thanks for another great mod :)

 

However, I'm having a problem....

 

I'm also relatively heavily modded so, went down the diffmerge route.

 

Everything works fine, take down a plot, replace it, take ownership, remove items. Locked Items not able to be removed, plot boundary showing just fine. SteamID's showing in the worldspace column for the object. No errors in the rpt. All good....

 

The problem I have, is that after a server restart, the removed items reappear. If I remove them for a second time, after another restart they have gone finally. But, can't understand why they didn't stay gone the first time.

 

Not sure if this helps but, after taking ownership through the plot pole, I checked the ObjectID in the db and it had removed the old row with the old ObjectID and replaced it with a new row with a new ObjectID and my SteamID in the worldspace column. So, this part is all good I think... but, when I used infiSTAR's 'i' key to retrieve target information before trying to remove the item, it still shows the old ObjectID in game which no longer exists in the db, even though I had taken ownership through the plot pole.

So, it seems that somehow the db is not updating the game and is then letting me remove the object that's already deleted from the db. Therefore, it's not removing the new entry after taking plot ownership which explains having to remove it finally for the second time.

 

Any ideas.....?

 

Thanks

 

EDIT: I have made sure to run my tests without turning anything on in infiSTAR

2nd EDIT: I have run the same tests with infiSTAR disabled. Same result as outlined above.

Have just done another complete fresh install on my test server this morning and again, same result as above... :(

 

Have also gone back through the 2nd install and diffmerge checked all the files again and everything is in line with the instructions..

[RimBlock]

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.

[ReDBaroN]

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.

Thanks RimBlock.

 

In your latest release and instructions, you have left the compiles call to remove.sqf as the default call to dayz_code. The other 2 calls from selfactions point towards the new custom action folder.

 

Because I have remove.sqf already overridden to decrease the chance of gem drop on ore mining, I have tried the following:

1. Taking out my previous version of remove.sqf and merging my very minor change into yours. Then changing the compiles call as well to the new custom\ap4l\action\remove.sqf - same issue as above, having to remove twice
2. Keeping your remove.sqf in the action folder with the 2 other calls to it as per the instructions and keeping my remove.sqf in the custom folder with the compiles call pointed to that - same issue as above, having to remove twice
3. EDIT: Have now tried with the remove.sqf compiles call to dayz_code as in the new custom compiles.sqf in the download for plot4life. Still won't remove objects on first attempt.

What I haven't tried but, am about to, is to leave the compiles call going off to the remove in dayz_code. But, I have a feeling that this will then make gem drops 40% again which doesn't really work on my server as we use gems as higher currency and a ruby is worth 10 BC's....

 

I'll report back with my findings but, thought I would add the info about my remove override.

 

EDIT: Additional info... in the server RPT the taking ownership is working fine too as I can see the items being deleted and new published e.g.:

14:15:03 "PUBLISH: Attempt 2c532b00# 1058646: small_wall.p3d"

14:15:03 "PUBLISH: Created WoodSmallWall_DZ with ID 1710930526103"

14:15:03 "DELETE: B 1-1-C:1 (BaroN) REMOTE Deleted by ID: 112106"

14:15:03 "PUBLISH: Attempt 2c55b900# 1058608: wood_floor.p3d"

14:15:03 "PUBLISH: Created WoodFloor_DZ with ID 17112305485183"

14:15:03 "DELETE: B 1-1-C:1 (BaroN) REMOTE Deleted by ID: 112029"

14:15:03 "PUBLISH: Attempt 2c530800# 1058651: small_wall.p3d"

14:15:03 "PUBLISH: Created WoodSmallWall_DZ with ID 17108305705185"

14:15:03 "DELETE: B 1-1-C:1 (BaroN) REMOTE Deleted by ID: 112122"

14:15:04 "DELETE: B 1-1-C:1 (BaroN) REMOTE Deleted by ID: 112056"

14:15:04 "PUBLISH: Attempt 2c547900# 1058617: small_wall.p3d"

14:15:04 "PUBLISH: Created WoodSmallWall_DZ with ID 1706430527141"

14:15:04 "PUBLISH: Attempt 2c532400# 1058647: small_wall.p3d"

14:15:04 "PUBLISH: Created WoodSmallWall_DZ with ID 171553052473"

14:15:04 "DELETE: B 1-1-C:1 (BaroN) REMOTE Deleted by ID: 112110"

14:15:04 "PUBLISH: Attempt 2c55ab00# 1058610: wood_floor.p3d"

14:15:04 "PUBLISH: Created WoodFloor_DZ with ID 17064305498181"

14:15:04 "DELETE: B 1-1-C:1 (BaroN) REMOTE Deleted by ID: 112031"

14:15:04 "PUBLISH: Attempt 2c55b200# 1058609: wood_floor.p3d"

14:15:04 "PUBLISH: Created WoodFloor_DZ with ID 171603054712"

14:15:04 "DELETE: B 1-1-C:1 (BaroN) REMOTE Deleted by ID: 112030"

14:15:04 "PUBLISH: Attempt 2c530100# 1058652: small_wall.p3d"

14:15:04 "PUBLISH: Created WoodSmallWall_DZ with ID 17156305672182"

14:15:04 "DELETE: B 1-1-C:1 (BaroN) REMOTE Deleted by ID: 112128"

14:15:04 "DELETE: B 1-1-C:1 (BaroN) REMOTE Deleted by ID: 112189"

14:15:04 "PUBLISH: Attempt 320e5600# 1062044: drevena_bedna.p3d"

14:15:04 "PUBLISH: Created WoodCrate_DZ with ID 1716930532596"

14:15:04 "PUBLISH: Attempt 2c559600# 1058613: small_wall.p3d"

14:15:04 "PUBLISH: Created WoodSmallWall_DZ with ID 17064305738182"

14:15:04 "DELETE: B 1-1-C:1 (BaroN) REMOTE Deleted by ID: 112049"

14:15:04 "DELETE: B 1-1-C:1 (BaroN) REMOTE Deleted by ID: 112156"

14:15:04 "PUBLISH: Attempt 320d8f00# 1062036: drevena_bedna.p3d"

14:15:04 "PUBLISH: Created WoodCrate_DZ with ID 170473053825271"

14:15:04 "DELETE: B 1-1-C:1 (BaroN) REMOTE Deleted by ID: 112038"

14:15:04 "PUBLISH: Attempt 300aeb00# 1062012: workbench.p3d"

14:15:04 "PUBLISH: Created WorkBench_DZ with ID 170463055012183"

14:15:04 "DELETE: B 1-1-C:1 (BaroN) REMOTE Deleted by ID: 112187"

14:15:04 "PUBLISH: Attempt 320e5d00# 1062043: drevena_bedna.p3d"

14:15:04 "PUBLISH: Created WoodCrate_DZ with ID 170493056421274"

14:15:04 "PUBLISH: Attempt 2c55a400# 1058611: small_wall.p3d"

14:15:04 "PUBLISH: Created WoodSmallWall_DZ with ID 17041305501091"

14:15:04 "DELETE: B 1-1-C:1 (BaroN) REMOTE Deleted by ID: 112036"

14:15:04 "PUBLISH: Attempt 2e07eb00# 1062105: small_wall_door_anim.p3d"

14:15:04 "PUBLISH: Created Land_DZE_WoodDoor with ID 17180305463275"

14:15:04 "DELETE: B 1-1-C:1 (BaroN) REMOTE Deleted by ID: 112507"

 

And this is me removing the objects now having taken ownership of them:

14:16:32 "DELETE: B 1-1-C:1 (BaroN) REMOTE Deleted by ID: 112056"

14:17:25 "DELETE: B 1-1-C:1 (BaroN) REMOTE Deleted by ID: 112106"

14:18:18 "DELETE: B 1-1-C:1 (BaroN) REMOTE Deleted by ID: 112110"

14:18:51 "DELETE: B 1-1-C:1 (BaroN) REMOTE Deleted by ID: 112128"

14:19:36 "DELETE: B 1-1-C:1 (BaroN) REMOTE Deleted by ID: 112122"

14:20:11 "DELETE: B 1-1-C:1 (BaroN) REMOTE Deleted by ID: 112049"

14:20:54 "DELETE: B 1-1-C:1 (BaroN) REMOTE Deleted by ID: 112036"

14:21:33 "DELETE: B 1-1-C:1 (BaroN) REMOTE Deleted by ID: 112507"

 

But, they still reappear on server restart and still only finally go if I remove them the second time.

 

RimBlock, can you tell me what diag_log line you want me to add to remove. ObjectUID does seem to match everywhere though...

[RimBlock]

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.

[ReDBaroN]

Thanks RimBlock, will try it as soon as I get a chance later this evening.

 

Just fyi, the ObjectUID definitely stayed the same on both old and replaced (post take ownership) objects in my testing. So as the old objects were deleted and the new ones added, they kept the same ObjectUID but then had new ObjectID's.

 

Will post back with my results.

[RimBlock]

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.