[Release] 2.1 Plot Management - UPDATED Object Counter

[cen]

Seems to have fixed the issue!

[cen]

Now there's an issue with removing ore veins and supply crates!

[Soul]

just a heads up but shouldnt there be edits in player_buildingDowngrade.sqf aswell?

_friendlies = _nearestPole getVariable ["plotfriends",[]];
_fuid  = [];
{
	  _friendUID = _x select 0;
	  _fuid  =  _fuid  + [_friendUID];
} forEach _friendlies;
_builder  = getPlayerUID player;
// check if friendly to owner
if(_builder in _fuid) then {
	_canBuildOnPlot = true;
};

[Soul]

 In server_monitor.sqf & server_updateObject.sqf

Original.

if (typeOf (_object) == "Plastic_Pole_EP1_DZ") then {
_object setVariable ["plotfriends", _intentory, true];
};

Fix:

if ((typeOf _object) == "Plastic_Pole_EP1_DZ") then {
_object setVariable ["plotfriends", _intentory, true];
};

small bugfix, shouldn make much difference but thats how it should be done.

[rosska85]

Now there's an issue with removing ore veins and supply crates!

 

Still able to remove ore veins and supply crates here. Do you have any errors popping up in the rpt? 

 

just a heads up but shouldnt there be edits in player_buildingDowngrade.sqf aswell?

_friendlies = _nearestPole getVariable ["plotfriends",[]];
_fuid  = [];
{
	  _friendUID = _x select 0;
	  _fuid  =  _fuid  + [_friendUID];
} forEach _friendlies;
_builder  = getPlayerUID player;
// check if friendly to owner
if(_builder in _fuid) then {
	_canBuildOnPlot = true;
};

 In server_monitor.sqf & server_updateObject.sqf

Original.

if (typeOf (_object) == "Plastic_Pole_EP1_DZ") then {
_object setVariable ["plotfriends", _intentory, true];
};

Fix:

if ((typeOf _object) == "Plastic_Pole_EP1_DZ") then {
_object setVariable ["plotfriends", _intentory, true];
};

small bugfix, shouldn make much difference but thats how it should be done.

Woops, I did actually add it to player_buildingDowngrade but forgot to include it in the readme. 

And also woops on the server monitor. We used that variation for all of our code on base building 1.3 and never had any problems, didn't even notice haha. 

[DeanReid]

Working great :) I noticed you also had doorManagement on your github,  I tried looking through the forums but never seen the post for it, is it the same way to install just rename plot to door or is that still a WIP? 

[Zupa]

Door will be released tomorrow

[Chief501st]

So will players still be able to use the plot pole after death?

[kaotix]

 

Warning Message: No entry 'mpmissions\__CUR_MP.Chernarus\description.ext/PlotManagement/Controls/RscShortcutButton_7004.soundPush'.

Warning Message: Size: '/' not an array

Warning Message: No entry 'mpmissions\__CUR_MP.Chernarus\description.ext/PlotManagement/Controls/RscShortcutButton_7004.soundClick'.

Warning Message: Size: '/' not an array

Warning Message: No entry 'mpmissions\__CUR_MP.Chernarus\description.ext/PlotManagement/Controls/RscShortcutButton_7004.soundEscape'.

Warning Message: Size: '/' not an array

 

I'm getting lots of the above when you open the dialog to manage the plot pole. It works, but the player sees an error in game first, then you just get RPT spam on the client side.

Did I miss something?

[rosska85]

Now there's an issue with removing ore veins and supply crates!

Sorry, I was running a different remove.sqf. What you can try is (not had a chance to test it yet) in remove .sqf, change 

if(_IsNearPlot > 0)then{
_thePlot = _findNearestPoles select 0;
_owner =  _thePlot getVariable ["ownerPUID","010"];
_friends = _thePlot getVariable ["plotfriends", []];

{
  _friendUID = _x select 0;
  _fuid  =  _fuid  + [_friendUID];
} forEach _friends;

_allowed = [_owner];	
_allowed = [_owner] +  _fuid;
};
if (!((getPlayerUID player) in _allowed || typeOf _obj  == "Plastic_Pole_EP1_DZ")) exitWith { cutText ["You are not allowed to remove this structure." , "PLAIN DOWN"]; }; 

to this

if(_IsNearPlot > 0)then{
_thePlot = _findNearestPoles select 0;
_owner =  _thePlot getVariable ["ownerPUID","010"];
_friends = _thePlot getVariable ["plotfriends", []];

{
  _friendUID = _x select 0;
  _fuid  =  _fuid  + [_friendUID];
} forEach _friends;

_allowed = [_owner];	
_allowed = [_owner] +  _fuid;
if (!((getPlayerUID player) in _allowed || typeOf _obj  == "Plastic_Pole_EP1_DZ")) exitWith { cutText ["You are not allowed to remove this structure." , "PLAIN DOWN"]; };
}; 

It's currently exiting the script before it gets to the stage where it checks if it's a modular/wreck/vein etc. This should cause it to only exit if it doesn't match a UID to an item within range of a plot pole.

So will players still be able to use the plot pole after death?

Provided they add themselves to the pole when they first build it, yes. 

[cen]

Thanks, I'll test it out!

[RimBlock]

Hi Guys,

 

Where are you setting "ownerPUID" ?.  I only see getvariable for it, no setvariable.  I assign this variable in my A Plot for Life mod but if this mod is independant of it (i.e. from the first page "If you dont use plotForLife mod and you add yourself to the plot, you will alwyas be able to build even after you die.") where are you setting it on object load and what are you setting it with (CharacterID / SteamID) ?.

 

A couple of points you may also want to make people aware of (fore warned is fore armed and all that)...

 

If this mod is installed then player will be able to build on the plot if they are a PlotPal after their death.  Some server owners don't particularly want this (hence my mod not being everywhere and the reason VBAwol asked me to optionise it for the inclusion in to the Epoch base code).  

 

Probably also worth making Server owners aware of the potential downsides of allowing PlotPals unrestricted build rights on their plot when they are not there.  I suspect the requirement to look at the plot owner before you can build on the plot was put in there to stop people befriending the plot owner then griefing their plot whilst the owner was away.  Taking that restriction out may open the doors to this sort of behavior again.  Considering the amount of work server admins may have to do trying to get peoples bases un-griefed it would probably be worth letting them know the risk.  Judicious management of who to add will of course help to mitigate this a lot though.

 

Nice mod.  Plot builder maintenance from the plot pole makes more sense than the tag friendly system.

[rosska85]

Hi Guys,

 

Where are you setting "ownerPUID" ?.  I only see getvariable for it, no setvariable.  I assign this variable in my A Plot for Life mod but if this mod is independant of it (i.e. from the first page "If you dont use plotForLife mod and you add yourself to the plot, you will alwyas be able to build even after you die.") where are you setting it on object load and what are you setting it with (CharacterID / SteamID) ?.

 

A couple of points you may also want to make people aware of (fore warned is fore armed and all that)...

 

If this mod is installed then player will be able to build on the plot if they are a PlotPal after their death.  Some server owners don't particularly want this (hence my mod not being everywhere and the reason VBAwol asked me to optionise it for the inclusion in to the Epoch base code).  

 

Probably also worth making Server owners aware of the potential downsides of allowing PlotPals unrestricted build rights on their plot when they are not there.  I suspect the requirement to look at the plot owner before you can build on the plot was put in there to stop people befriending the plot owner then griefing their plot whilst the owner was away.  Taking that restriction out may open the doors to this sort of behavior again.  Considering the amount of work server admins may have to do trying to get peoples bases un-griefed it would probably be worth letting them know the risk.  Judicious management of who to add will of course help to mitigate this a lot though.

 

Nice mod.  Plot builder maintenance from the plot pole makes more sense than the tag friendly system.

Yeah the instructions are geared solely towards plot for life just now. I did already say he'll need to add in alternates to some of the instruction stages like I had on my page for people not running plot for life.

 

The function of the mod (allowing players to build with friends even after death) is actually a founding principle of creating it, at least it was for me. So it's pretty much the intended behaviour and anything less wouldn't be worth having haha. It is mentioned in the first line of the OP that players with "ALWAYS" have access to build even after death, until they are removed. 

 

The up side to this though, is that the plot owner (or somebody they've added) has to manually add the person, it doesn't happen automatically when they befriend them. They have to consciously go to the pole and select to add that player and it will then display that persons name on the list of people who have build rights. So it's easier to keep track of who can build on your plot than just basing it from the friendly system where you can easily lose track of who you have and haven't befriended. 

 

Back when I worked on base building 1.3, having the option to create a base around one pole with multiple people 'owning' it was a key principle and that's what I originally set out to do with this too. I know myself and my friends who play on our server all build together, and we've got a few other players who come on together and all like to build together and it gets annoying if you can't build because the person who placed the pole is offline. It's probably not suitable for all servers I'd guess though, but at the end of the day a player shouldn't give somebody else access to build on their plot unless they trust them.

[RimBlock]

Yeah the instructions are geared solely towards plot for life just now. I did already say he'll need to add in alternates to some of the instruction stages like I had on my page for people not running plot for life.

 

The function of the mod (allowing players to build with friends even after death) is actually a founding principle of creating it, at least it was for me. So it's pretty much the intended behaviour and anything less wouldn't be worth having haha. It is mentioned in the first line of the OP that players with "ALWAYS" have access to build even after death, until they are removed. 

 

The up side to this though, is that the plot owner (or somebody they've added) has to manually add the person, it doesn't happen automatically when they befriend them. They have to consciously go to the pole and select to add that player and it will then display that persons name on the list of people who have build rights. So it's easier to keep track of who can build on your plot than just basing it from the friendly system where you can easily lose track of who you have and haven't befriended. 

 

Back when I worked on base building 1.3, having the option to create a base around one pole with multiple people 'owning' it was a key principle and that's what I originally set out to do with this too. I know myself and my friends who play on our server all build together, and we've got a few other players who come on together and all like to build together and it gets annoying if you can't build because the person who placed the pole is offline. It's probably not suitable for all servers I'd guess though, but at the end of the day a player shouldn't give somebody else access to build on their plot unless they trust them.

 

Sure, just with the statement on the first page saying A Plot for Life is not required, it seems a little confusing.  I did see the comment on your original thread which is why I was a little surprised.

 

The concept is good.  Just suggesting making the downsides or functionality a little clearer.  Some may not realise that "always" also means after death (i know, i know but it may not occur to some).

 

Sure people should not add them unless they trust them but then people are people and don't always do what would seem to be the most logical thing.  The off shoot is that the admins will probably have to deal with any griefing so it is probably worth letting them know before they install it that this feature of Epoch vanilla has also been changed.

 

A suggestion to help mitigate the open build policy for PlotPals...

 

How about setting a couple more variables.

 

PlotCanBuild (Covers the whole plot for everyone).

PlotPalCanBuild (Covers individual builders enabling individual builders rights to build to be turned on or off).

 

Would be easy to store them in the inventory field

[PlotCanBuild],[[steamID], [buildername], [Canbuild]]

 

Amend the gui with two more buttons, one for changing the PlotPals build rights and one to change the whole plots build rights for all (only changeable by the plot pole owner and admins).  Would add much greater control and granularity to build rights on the plot and should be pretty easy to implement.

[Rocu]

Nice work, Zupa. Is this compatible with SC?

[Zupa]

Nice work, Zupa. Is this compatible with SC?

 

yes it is., compatbile with anything it should be

[StiflersM0M]

mhhh got one problem, my class RscStructuredText is allready defined, any ideas ?

Know its coming from my custom PlayerGUI.

[cen]

Major bug. Anyone can remove anything regardless of being added on a plot or not!

[rosska85]

mhhh got one problem, my class RscStructuredText is allready defined, any ideas ?

Know its coming from my custom PlayerGUI.

You should just be able to remove that definition from the defines.hpp included with plot management.

 

Zupa, just to let you know, the remove.sqf needs some attention. With the way you've set it out in the instructions it prevents people removing ore nodes, supply crates, etc. I tried a quick messy fix last night by moving the exitwith section inside the if (_plotPole > 0) section but that just seems to make it so anybody can remove anything. Currently trying to restructure it so it doesn't exit before so many of the checks are carried out.

[Zupa]

Major bug. Anyone can remove anything regardless of being added on a plot or not!

false

[Zupa]

Makign fix 

[Zupa]

The fix

 

_obj = _this select 3;
_isModular = _obj isKindOf "ModularItems";
_isModularDoor = _obj in ["Land_DZE_WoodDoor","Land_DZE_LargeWoodDoor","Land_DZE_GarageWoodDoor","CinderWallDoor_DZ","CinderWallDoorSmall_DZ"];


if(  ( _isModular ||  _isModularDoor ) && !((getPlayerUID player) in _allowed)    ) exitWith { cutText ["You are not allowed to remove this structure." , "PLAIN DOWN"]; };

[rosska85]

 

The fix

 

_obj = _this select 3;
_isModular = _obj isKindOf "ModularItems";
_isModularDoor = _obj in ["Land_DZE_WoodDoor","Land_DZE_LargeWoodDoor","Land_DZE_GarageWoodDoor","CinderWallDoor_DZ","CinderWallDoorSmall_DZ"];


if(  ( _isModular ||  _isModularDoor ) && !((getPlayerUID player) in _allowed)    ) exitWith { cutText ["You are not allowed to remove this structure." , "PLAIN DOWN"]; };

 

 

 

That will still exit the script before allowing removal of wrecks, ores veins, supply crates etc. I think we'd be better moving the check back to fn_selfActions so people only get the option to remove items if they actually can, that's why I'd left it there before.

[StiflersM0M]

That will still exit the script before allowing removal of wrecks, ores veins, supply crates etc. I think we'd be better moving the check back to fn_selfActions so people only get the option to remove items if they actually can, that's why I'd left it there before.

but it prevents the remove from objects who are not on the list or ?

[Zupa]

That will still exit the script before allowing removal of wrecks, ores veins, supply crates etc. I think we'd be better moving the check back to fn_selfActions so people only get the option to remove items if they actually can, that's why I'd left it there before.

 

are veins, wrecks, supply crates modularItems?