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

[RimBlock]

OK cool, I'm not nearly as crazy as I thought B). I just kept staring at your files like " You WILL make sense to me NOW!" and the I just started winging it. Thankfully Ryker's last post showed me something is wrong with my snap pro install after setting modularbuild to false and everything went back to normal.

That in itself is a little weird though because you have merged everything except dayz_spaceinterrupt.sqf and the points.hpp IIRC. I copied over my spaceinterrupt from Raymix's DL and maybe thats whats gone wrong, because otherwise I have done everything correctly. Does the getpos function error I showed you mean anything to you, or should I talk to Raymix?

 

Also, what is the path you use to call your server custom folder, from what I can see all calls are location specific or they have the "z\" prepend. I don't know how to call back a directory or two -_-.

I see in your instructions that you call the server monitor just by using "custom\system\server_monitor.sqf". So I guess my question is then, how does the compiler know the difference between the "custom" folder in MPMISSIONS and the "Custom" folder in the root directory? I didn't think sqf was case sensitive but I promise to LOL at myself if that's it.

 

Ok, the getpos error is not an error with getpos.  The error is with the nformation being passed to it.  It is expecting to get an object passed to it and it is receiving an array.  Have a search throught he files you hve amended for any getpos calls and check what is being passed in the calls.  Put in some diag_log lines if needed.

 

For the custom server folder, if the server is running the code (i.e. it is in a 'if (isdedicated)' or '(isserver)' clause) then it will look for the path relative to the ARMA home directory.  THis means you can put custom code on the server outside of the server.pbo file and the clients do not see it (smaller mission file uploads, a bit more protection against scripters).  It ilso allows modders to better protect their work if they are not publicly sharing as some people scrape mods from mission files for their own server.

 

If the code is being run on the client  (i.e. it is in a 'if !(isdedicated)' or '!(isserver)' clause) then the base relative file path is from the mpmissions/[map] directory.

 

Took me a while to find out about the server side custom folder (can be called whatever you like) as th info is fairly well burried in the ARMA Wiki.

 

I installed this with Snap_Pro and when I enable modular build it doesn't work, starts building by showing the ghost object, but I have no control over it after that. Any ideas what could be causing this? I've checked all the files multiple times and I pretty sure they are in/pointing to the correct location.

 

Also, the server files aren't included in the Dropbox download?

 

Sorry, it had been a pretty rought week.  Please bare with me.  I will get them added tonight.

[poweredbypot]

Yeah thats a pretty sound assessment Rim. I would be more than happy to help you test and give some feedback, I want a build that includes those major build related mods all together, and as you said none of it will ever get there if we dont test it.

I'm not putting my server public until it is 100% ready and as thoroughly tested as I can manage, so in the meantime I have no qualms using it as testing fodder if you have an incomplete idea ( incremental backups ftw!).

 

Also I don't what methods you guys use to stay in contact but I've asked for Raymix's input on the issue and the last few posts in his snap pro thread are on the same topic we're discussing here.

[RimBlock]

Yeah thats a pretty sound assessment Rim. I would be more than happy to help you test and give some feedback, I want a build that includes those major build related mods all together, and as you said none of it will ever get there if we dont test it.

I'm not putting my server public until it is 100% ready and as thoroughly tested as I can manage, so in the meantime I have no qualms using it as testing fodder if you have an incomplete idea ( incremental backups ftw!).

 

Also I don't what methods you guys use to stay in contact but I've asked for Raymix's input on the issue and the last few posts in his snap pro thread are on the same topic we're discussing here.

 

Sure on testing, the more the merrier.

 

Incremental backups you say.... mysqldump incremental backup options.  Would need a little work storing a few details and I hate Windows cmd language but with that information linked, someone should be able to put a small script together.

 

Will check out Raymixs Snap Pro thread.  Really need to sit down in fromt of my test server to get to the bottom of the issue though.

[Tricks]

Hey RimBlock I have a question for you I cant find the answer for. Installed everything and seems to be working fine however after building a plot pole I cannot upgrade anything. Says there is a plot pole nearby eventhough its mine.

After restart I cannot build at all without replacing the plot pole.

[RimBlock]

Does the plot pole have the steamID in the DB worldspace field ?.

 

Have you got A Plot for Life turned on or off ?.

 

Have you got Snap Build Pro installed and turned on or off ?.

 

Can you build fine ?.

 

Can you remove fine ?.

 

There are quite a few variables to narrow down before I can give a more directed answer.  The more info you can provide the better.

[poweredbypot]

Does the plot pole have the steamID in the DB worldspace field ?.

 

Have you got A Plot for Life turned on or off ?.

 

Have you got Snap Build Pro installed and turned on or off ?.

 

Can you build fine ?.

 

Can you remove fine ?.

 

There are quite a few variables to narrow down before I can give a more directed answer.  The more info you can provide the better.

 

Yes steamID is in the worldfield

 

Plot for life installed and on with NO Snap pro = everything works fine

 

Plot for life with snap pro ON = broken

 

Just P4l I can build fine, I honestly didn't test removing but I will in a second.

 

with snap pro enabled you can begin a building action, and you will get the ghost preview but you have no controls from there (cannot rotate or place, or even cancel)

 

Sorry I'm late on the response but we are at nearly exact opposite timezones and my wife is super pregnant and a little testy.

[poweredbypot]

Ok, here is All the diffs between the whole install package in a nice little 7z. If theres anything else I can test that will help the process let me know!

 

Linky!

[poweredbypot]

in player_build_plotcheck.sqf:

// End script early if item is plot pole and another one exists within defined radius

if(_isPole && _IsNearPlot > 0) exitWith {

    DZE_ActionInProgress = false;

    cutText [(localize "str_epoch_player_44") , "PLAIN DOWN"];

Shouldn't this be:

// End script early if item is plot pole and another one exists within defined radius

if(_isPole && _IsNearPlot > 1) exitWith {

    DZE_ActionInProgress = false;

    cutText [(localize "str_epoch_player_44") , "PLAIN DOWN"];

because if it is a pole and none are nearby the result would still be 1, thereby cancelling building?

 

I tested this on my setup, no change in getting stuck at the point of building an object but that doesn't mean that I'm necessarily wrong yet.....

 

UPDATE:

 

WOOOOOOO! I THINK I finally found a real bug, and not just something I screwed up! this change stopped the error where other items would not recognize a nearby plot pole with modular build enabled.

I will keep working my way through the modular build and update this post with whatever I find.

 

Second Edit:

I think this may be the issue in question:

 

In player_build_controls.sqf

_object = _this select 0;
_isAllowedUnderGround = _this select 1;
_location1 = _this select 2;
_objectHelper  = _this select 3;

Should be:

_object = _this select 0;
_isAllowedUnderGround = _this select 1;
_location1 = _this select 2;
_objectHelper  = _this select 4;

Because:

 

_controls = [_object, _isAllowedUnderGround, _location1, _position, _objectHelper] call player_build_controls;

FLEXING MY NERD MUSCLE!!!

you can also change the above line found in modular_build.sqf to the following:

_controls = [_object, _isAllowedUnderGround, _location1, _objectHelper, _position] call player_build_controls;

 

 

 

After testing this DOES fix the issue with not being able to control the object but the help context does not appear, nor do you get the snap enabling option. I think I'm getting closer.

 

Third Edit:

snap pro is called from player_build_create.sqf but I don't see anywhere that the location of snap pro is ever given to the modular_build series of events EXCEPT within snap_build.sqf. That to me seems the likely reason that I can manipulate and build objects, but not turn on snap points or get any non-cancellation related messages (cancelled because of movement, combat, etc all still appears, as well as build stage notifications).

 

also snap pro references itself inside snap_build.sqf (weird?) but the path points to the server pbo and not "custom\A_plot_for_life\action\..." but even changing those did not fix the current issue, again because I believe snap_build.sqf isnt being called to properly.

 

Update:

I found the reference for the snap_build.sqf location in compiles so that's definitely not the issue. I found another issue inside snap_build.sqf:

 

if (isClass (configFile >> "SnapBuilding" >> _classname)) then {    
    ["","","",["Init",_object,_classname,_objectHelper]] spawn snap_build;
};

this calls snap_build with an array that contains 4 statements, the last of which is another array that conatins 4 statements. But when we look at snap_build.sqf:

snapActionState = _this select 3 select 0;
_object = _this select 3 select 1;
_classname = _this select 3 select 2;
_objectHelper = _this select 3 select 3;
_selectedAction = _this select 3 select 4;

 

We can see here that it is first off pointing to a statement in the array that is blank, so the first selection should be "4" in all cases instead of 3 BUT, and this is where I think I may end my usefulness :angry:, the snap function is looking for 5 statements to declare variables with and only 4 exist.

 

The one that gets left out is _selectedaction which is only referenced WITHIN snap_build.sqf

 

I know this is wrong but I don't know what to do about it, hopefully someone can direct me from here.

 

 

Update #2:

Another something I found is here in snap_build.sqf:

 

//Snap config file
_cfg = (configFile >> "SnapBuilding" >> _classname);
_whitelist = getArray (_cfg >> "snapTo");
_points = getArray (_cfg >> "points");
_radius = getNumber (_cfg >> "radius");

 

If I understand correctly this is calling a config file for snap pro called "SnapBuild" and looking within it for matches to the _classname of the object trying to be built. It then goes on to look for an array of "snapTo" (compatible snapping objects list) and then "points" (snap points I assume) and finally a number called "radius" (most likely how far away one snap point will activate another to snap to).

This to me screams "snappoints.hpp" but how in the hell will the compiler know where that is with the above sequence?

 

Another Edit, lol:

 

No, the above is incorrect, the call is looking for a class named "snapbuilding" for which will be the config file variable "_cfg" from now on. That makes more sense, but I still don't understand how it knows where to look for said file.

[raymix]

in player_build_plotcheck.sqf:

Shouldn't this be

if(_isPole && _IsNearPlot > 1) exitWith {

because if it is a pole and none are nearby the result would still be 1, thereby cancelling building?

Nah, this statement will only be true if more than 1 plotpole is present.

What you want is either

if(_isPole && _IsNearPlot > 0) exitWith { // more than NONE

if(_isPole && _IsNearPlot => 1) exitWith { //equals to one OR more

[poweredbypot]

 

Nah, this statement will only be true if more than 1 plotpole is present.

What you want is either

if(_isPole && _IsNearPlot > 0) exitWith { // more than NONE

if(_isPole && _IsNearPlot => 1) exitWith { //equals to one OR more

 

But 1 would be a safe number to proceed:

 

if it is a pole (1) + there are none nearby (0) = you should be able to build a plot pole if there is not another nearby (1)

 

If it is NOT a pole (0) + there IS one nearby (1( the function to check ownership/firendly comes after)) = then you should be able to build whatever object you are holding since plot ownership checks and plot pole necessity checks havent been done yet(1)

 

if it IS a plot pole(1) + there IS another nearby (1) = then you should NOT be able to build another plot pole (2)

[lordgeorge]

Just a query guys, i have been testing the server_monitor both server and mission side. Is there any benefit to mission side as i have not seen any difference ?

Cheers

[RimBlock]

But 1 would be a safe number to proceed:

 

if it is a pole (1) + there are none nearby (0) = you should be able to build a plot pole if there is not another nearby (1)

 

If it is NOT a pole (0) + there IS one nearby (1( the function to check ownership/firendly comes after)) = then you should be able to build whatever object you are holding since plot ownership checks and plot pole necessity checks havent been done yet(1)

 

if it IS a plot pole(1) + there IS another nearby (1) = then you should NOT be able to build another plot pole (2)

 

I think you are getting mixed up between + and &&.  + is to add two values together.  && is a logical condition.

 

The actual check could be better written as

if ((_isPole) && _IsNearPlot > 0) exitWith { // more than NONE

_isPole is a boolean (true / false) remember, not numeric.  _isNearPlot is numeric as it is a count of Plot poles nearby.

[RimBlock]

Just a query guys, i have been testing the server_monitor both server and mission side. Is there any benefit to mission side as i have not seen any difference ?

Cheers

 

Yep.

 

• If you keep it server side, it will not need to be downloaded when player login.  
• This file is only run by the server so no need for the client to have it.  
• If you pass it to the client then more chance of someone taking it apart in order to find a loophole to be exploited.

 

I would say to keep it serverside  ;) .

[poweredbypot]

I think you are getting mixed up between + and &&. + is to add two values together. && is a logical condition.

The actual check could be better written as

if ((_isPole) && _IsNearPlot > 0) exitWith { // more than NONE

_isPole is a boolean (true / false) remember, not numeric. _isNearPlot is numeric as it is a count of Plot poles nearby.

Yeah I know that, I was just using it for the sake of explanation.

Edit: sorry I see the double quotes now, that makes more sense.

[RimBlock]

 

 

in player_build_plotcheck.sqf:

// End script early if item is plot pole and another one exists within defined radius

if(_isPole && _IsNearPlot > 0) exitWith {

    DZE_ActionInProgress = false;

    cutText [(localize "str_epoch_player_44") , "PLAIN DOWN"];

Shouldn't this be:

// End script early if item is plot pole and another one exists within defined radius

if(_isPole && _IsNearPlot > 1) exitWith {

    DZE_ActionInProgress = false;

    cutText [(localize "str_epoch_player_44") , "PLAIN DOWN"];

because if it is a pole and none are nearby the result would still be 1, thereby cancelling building?

 

I tested this on my setup, no change in getting stuck at the point of building an object but that doesn't mean that I'm necessarily wrong yet.....

 

UPDATE:

 

WOOOOOOO! I THINK I finally found a real bug, and not just something I screwed up! this change stopped the error where other items would not recognize a nearby plot pole with modular build enabled.

I will keep working my way through the modular build and update this post with whatever I find.

 

Second Edit:

I think this may be the issue in question:

 

In player_build_controls.sqf

_object = _this select 0;
_isAllowedUnderGround = _this select 1;
_location1 = _this select 2;
_objectHelper  = _this select 3;

Should be:

_object = _this select 0;
_isAllowedUnderGround = _this select 1;
_location1 = _this select 2;
_objectHelper  = _this select 4;

Because:

 

_controls = [_object, _isAllowedUnderGround, _location1, _position, _objectHelper] call player_build_controls;

FLEXING MY NERD MUSCLE!!!

you can also change the above line found in modular_build.sqf to the following:

_controls = [_object, _isAllowedUnderGround, _location1, _objectHelper, _position] call player_build_controls;

 

 

 

After testing this DOES fix the issue with not being able to control the object but the help context does not appear, nor do you get the snap enabling option. I think I'm getting closer.

 

Third Edit:

snap pro is called from player_build_create.sqf but I don't see anywhere that the location of snap pro is ever given to the modular_build series of events EXCEPT within snap_build.sqf. That to me seems the likely reason that I can manipulate and build objects, but not turn on snap points or get any non-cancellation related messages (cancelled because of movement, combat, etc all still appears, as well as build stage notifications).

 

also snap pro references itself inside snap_build.sqf (weird?) but the path points to the server pbo and not "custom\A_plot_for_life\action\..." but even changing those did not fix the current issue, again because I believe snap_build.sqf isnt being called to properly.

 

Update:

I found the reference for the snap_build.sqf location in compiles so that's definitely not the issue. I found another issue inside snap_build.sqf:

 

if (isClass (configFile >> "SnapBuilding" >> _classname)) then {    
    ["","","",["Init",_object,_classname,_objectHelper]] spawn snap_build;
};

this calls snap_build with an array that contains 4 statements, the last of which is another array that conatins 4 statements. But when we look at snap_build.sqf:

snapActionState = _this select 3 select 0;
_object = _this select 3 select 1;
_classname = _this select 3 select 2;
_objectHelper = _this select 3 select 3;
_selectedAction = _this select 3 select 4;

 

We can see here that it is first off pointing to a statement in the array that is blank, so the first selection should be "4" in all cases instead of 3 BUT, and this is where I think I may end my usefulness :angry:, the snap function is looking for 5 statements to declare variables with and only 4 exist.

 

The one that gets left out is _selectedaction which is only referenced WITHIN snap_build.sqf

 

I know this is wrong but I don't know what to do about it, hopefully someone can direct me from here.

 

 

Update #2:

Another something I found is here in snap_build.sqf:

 

//Snap config file
_cfg = (configFile >> "SnapBuilding" >> _classname);
_whitelist = getArray (_cfg >> "snapTo");
_points = getArray (_cfg >> "points");
_radius = getNumber (_cfg >> "radius");

 

If I understand correctly this is calling a config file for snap pro called "SnapBuild" and looking within it for matches to the _classname of the object trying to be built. It then goes on to look for an array of "snapTo" (compatible snapping objects list) and then "points" (snap points I assume) and finally a number called "radius" (most likely how far away one snap point will activate another to snap to).

This to me screams "snappoints.hpp" but how in the hell will the compiler know where that is with the above sequence?

 

Another Edit, lol:

 

No, the above is incorrect, the call is looking for a class named "snapbuilding" for which will be the config file variable "_cfg" from now on. That makes more sense, but I still don't understand how it knows where to look for said file.

 

Cool, all of this is Raymixs  :D .

 

One thought that rings a bell.  I had a lot of fun with the config files when testing with pbo files.  I suspect, this may be the case here.  The Epoch build files will get from the PBO config files.  For standalone I believe you need to reference missionConfigFile rather than configFile.

 

Change that and see if it fixes it.

 

Thanks for the trouble shooting you have done for this  :) .

[raymix]

For standalone I believe you need to reference missionConfigFile rather than configFile.

This ^

 

Modular build was taken from @mod style config files, to convert them to mission file, configFile needs to be renamed to missionConfigFile (rest is the same, just simple rename required)  :)

 

Leave this as is, blanks are later required by addActions to work, since they are referencing back to their origin script. Can't exactly remember why, but it was quite complex problem due to nature of addActions and to convert it to single array was more pain than gain, just wasted time.

["","","",["Init",_object,_classname,_objectHelper]] spawn snap_build;

@RimBlock, you seem to be using older broken version of modular build, mate. In fact there's quite a lot of fixes and optimization :D

https://github.com/raymix/DayZ-Epoch/commit/903f5d8572e4c42c21d6e1d28dea65248128bf81

This one is also using same updated code SBP 1.4.1 uses (except snap_build, that one got extra pull request later due to bugs on NAPF map)

 

@poweredbypot:

You are correct about _objectHelper, but check these files here, these are up to date and fixes that:

https://github.com/raymix/DayZ-Epoch/blob/master/SQF/dayz_code/actions/modular_build.sqf

https://github.com/raymix/DayZ-Epoch/blob/master/SQF/dayz_code/actions/player_build_controls.sqf

[lordgeorge]

Yep.

 

• If you keep it server side, it will not need to be downloaded when player login.  
• This file is only run by the server so no need for the client to have it.  
• If you pass it to the client then more chance of someone taking it apart in order to find a loophole to be exploited.

 

I would say to keep it serverside  ;) .

Well thast the we have been running it for some time, just wanted to query it. I have some custom work in there floating about, hence keeping it our the way :P . Had some wierd reported issues recently but nothing serious :)

 

Cheers :D

[RimBlock]

This ^

 

@RimBlock, you seem to be using older broken version of modular build, mate. In fact there's quite a lot of fixes and optimization :D

https://github.com/raymix/DayZ-Epoch/commit/903f5d8572e4c42c21d6e1d28dea65248128bf81

This one is also using same updated code SBP 1.4.1 uses (except snap_build, that one got extra pull request later due to bugs on NAPF map)

Cheers Raymix. I will touch base with you on Sunday as my wife has just told me we are all going to Pulau Ubin for an overnight stay. I do have my laptop but am unsure of the connectivity there. Go to commune with nature, bring all your technology with you :).

[Havoc302]

Man, I wish RimBlock, RayMix, Striker, Zupa and ToejaM would get together and merge, P4L, Snap Pro, Build Vectors, Plot Management and CPC Indestructible Bases together into one awesome centralised tool, it's seriously giving me headaches trying to get them all working together. You could just have a variable in a main config file to turn each module on and off.

 

Then put the whole damned thing as one giant tool into Epoch 1.0.5.2.

[poweredbypot]

rim and ray tried to call out for collaboration, but it not many (if any) answered.

[BetterDeadThanZed]

Man, I wish RimBlock, RayMix, Striker, Zupa and ToejaM would get together and merge, P4L, Snap Pro, Build Vectors, Plot Management and CPC Indestructible Bases together into one awesome centralised tool, it's seriously giving me headaches trying to get them all working together. You could just have a variable in a main config file to turn each module on and off.

 

Then put the whole damned thing as one giant tool into Epoch 1.0.5.2.

 

1.0.5.2 was scrapped. 1.0.6 is 14% completed with a target date of 31 October, but don't count on it.

[BetterDeadThanZed]

The directions make no sense on this:

 

•  [server directory]\mpmissions\[map name]\[some other standard files not related to this mod like mission.sqm]
•  [server directory]\mpmissions\[map name]\init.sqf
•  [server directory]\mpmissions\[map name]\init\[some files]
•  [server directory]\mpmissions\[map name]\custom\PlotForLifev2\[somefiles]

There's no custom\PlotForLifev2 folder in the archive. The archive I downloaded has Action, Compile and Init folders.

[Semezky]

The directions make no sense on this:

 

 

There's no custom\PlotForLifev2 folder in the archive. The archive I downloaded has Action, Compile and Init folders.

 

 

Yup, and there was not any server files for this mod:)

[RimBlock]

Yep, I packed up my test servers mpmissions folder by mistake.

 

Home now and looking at Raymixs newer Modular Building files.  Will put up another download later.

[RimBlock]

New version up (v2.33) fully merged with Snap Pro v1.41.

 

Tested working with modular build framework and snap pro.

 

Links in the first post.  Install instructions in the download zip or on the Git (also linked in the first post).

 

Post up bugs as you find them please.

 

@Raymix,

 

I have added a new variable (global) for the path of snap_build.sqf as I see it is called from within itself.  This made it easy to define in the compiles.sqf once with the other modular / snap pro defines and that single define then takes effect wherever it is needed (took me a bit to track them down  ;)  ).

 

All files taken from your Git so should be the latest.  Your git and thread are also referenced in the install and the link on the first page.