RimBlock
-
Posts
1140 -
Joined
-
Last visited
-
Days Won
3
Content Type
Profiles
Forums
Articles
Posts posted by RimBlock
-
-
would be any unused field that normaly only stores integerial values.
Yep, from what I have read in the C++ code, the field types are locked. Changing them at a DB level is a non starter due to that (was why we could not change the characterID to a larger int size for SteamID storage).
It is well worth noting the max extension call return length. As you say, this is likely to be a big issue as we repurpose fields.
The standard hive has the large return call used for streaming the objects on server load. Does this not take the data in 'chunks' so as not to breach the max byte size ?.
@Zupa:
Yep your option 3 is what I would have gone for in your position. Just need to store the unique values and then plug them in to the code line when the object is loaded.
I was also looking at storing the playerUIDs in the gear field for the plot builder management but no longer need tt :) . The only thing about using the inventory is that the code uses ARMA functions to manage the inventory rather than it just being a variable attached to the object. There is no reason not to side step this of course.
I am currently testing out another extension to better suit my purpose as the Hiveext is just too crazy limited, not actively enhanced as requirements change by the developers meaning we have to rely on people like Soul with the skills to have the time and willingness to modify it.
-
The look is fantastic.
What mod are you using for the fog or did you write your own ?. What is the server load like with it ?
-
I am getting alot of these errors
if ((_rplayerUID in _friendlies) && (_playerU> Error position: <_rplayerUID in _friendlies) && (_playerU> Error Undefined variable in expression: _rplayeruid File mpmissions\__CUR_MP.Tavi\Custom\A_Plot_for_Life\Compile\player_updateGui.sqf, line 320 Error in expression <t getVariable ["friendlyTo", []];
Check you have the latest download. I defined this variable in the latest update but did not move the version number on. Check post 686 above for details of the change.
-
Oh well, it is good practice to define the vars anyway, so just enforcing it now. Hopefully that will sort it out :) .
-
Rimblock.
getting this when targeting other players:-
Error Undefined variable in expression _rplayeruid
file missions ....player_updateGui.sqf, line 320
if ((|#|_rplayerUID in _friendlies) && (_playerU....
Try adding
,"_playerUID","_rplayerUID"
to the "private [" line (line 1) at the end of the before the
];
Hopefully it is just that the local variables were not defined.
I will update the Git and dropbox files: Done.
-
remove.sqf fixed.
Uploaded to dropbox and ghithub.
Would be a whole lot easier if you can give some examples of the differences as I may be able to explain right away rather than downloading and having to compare both sets of files myself.
You cannot deploy the plot pole with which options out of the three turned on ?.
I have just built a plot pole with all 3 options set to true. No issue seen. If you can tell me what you did I can try and copy and see if I can reproduce.
-
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.
-
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.
-
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 :).
-
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 :) .
-
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 ;) .
-
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.
-
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.
-
I can assure you this isn't normal!! I had server prior to this with no modifications, when you build the owner can remove them upto i believe first server restart! i believe!
by default you cant walk upto someone's base and remove their entire building with scrolling! the scrip would have had to have added this , would anyone else agree or disagree on this?
Now if there is a fix for it can you please point me out to it?
Checking the code, some items can and some cannot.
Modular items cannot except the plot pole.
Built items can be removed (they are part of the _isdestructable check). These include hedgehogs, sandbags, fences, gates.
If floors can be removed then you will want to check the fn_selfactions.sqf (not part of this mod I believe) for any errors as that file controls what action items are displayed.
Do you have any other mods installed as if there is not an error in the fn_selfactions.sqf then there is an issue with ownership and if you have installed my A Plot for Life or one or more of the other building scripts then there may be a problem with the fn_selfactions.sqf getting the correct ownership details.
-
@ Moe: That is the normal functionality of Epoch. People have released mods to make items unremovable (which is pretty easy TBH) but Raymix has kept with the 'Sprit' the Epoch devs build Epoch on, i.e. people should be able to break in to others bases.
@Poweredbypot:
Is DZE_APlotforLife also set to true in the init.sqf ?.
The file which decides if you can build on a plot with the modular base building turned on is player_build_plotCheck.sqf. Glancing at the file on the Git for my release I do not see any obvious issues.
One other thing you could do is look at my fork of the Epoch 1.0.5.2-RC build as I have merged A Plot for Life in there and Raymix has his Snap Pro in there too. I used the relevent build files from there (merged in to the Epoch 1.0.5.1 pbos) to build a test server before putting in a pull request to Epoch. They should be a good baseline to compare with the ones in the standalone mod. I deliverately made subdirectories in the standalone mod with names matching those of the Epoch base code so people can quickly find where the corresponding files would be for comparison (yes... withe the exception of action which should be actions ;) ). Samve for the server files.
-
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.
-
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.
-
Good to see all you guys giving it a test and working to get it setup on your servers. Without that people like myself cannot finetune and sort out any issues.
What I am getting from the above is;
A Plot for Life v2.32 works ok.
A Plot for Life v2.32 with integrated Snap Build Pro does not currently work correctly.
Is this correct ?.
One word of caution with integrating vectors and precise building. Please make sure you amend the server_publishFullObject.sqf file as well as this file is used for the 'Take item ownership' plot pole action. It is not used for anything else and was written just for that feature to reduce the number of DB calls from 3 to 2 on saving buildables with inventories.
I will have a look at the issue with Snap Build Pro integration tonight when I get home.
I have not included integration for the other mods as;
a. They are not my mods.
b. If one of the other mods changes, and some of them seem to be changing quite rapidly, then I have to update the package again.
c. Snap Build Pro is an exception as it is quite mature. Raymix and myself are also happy to work together to make both mods better.
If any of the other mod makers wanted to work with me on integration then I would be mor ethan happy but the ones I have asked have not been so keen. I would guess they would rather their mod was no 'obsorbed' in to someone elses which is fair enough.
I would strongly suggest, if you want the A Plot for Life and Snap Build Pro integrations working then install just those mods and test at that point before installing anything else (pref on a test server). Throwing all the mods together at one time just makes a massive spiderweb of possibilities as to why something may not be working.
People may also want to try getting the spaceinterupt from the Epoch 1.0.5.2RC2 git as that is the one I used on my test server. I am not sure if there are any differences to the one on Raymixs git (Raymix supplied both).
My own test server is still sitting there with A Plot for Life 2.31 on it but no Snap Build Pro integrated so I should be able to work on it as soon as I get home.
-
Yep, thanks for the spot. Will change the version number in the description on the next commit. It does not make any actual difference.
Edit 1: Yep, only put that in if you have Snap Build Pro also installed.
Edit 2: Sorry, really don't know admin tools so cannot help there.
-
Edit, Reverted to 2.2 :P 2.3 Giving me a headache lol
Hi Paddy,
Which part is giving you a headache ?.
He means in the root of the directory. You should have 2 custom folders, one serverside and one client side.
Exactly.
I really thought I understood all this better but I guess not. I've done a completely standard installation and followed the instructions exactly. For all that effort however I'm missing something crucial as playerID is not added to the worldspace field when an object is built and I cannot for the life of me figure out why.
Now one thing that caught my eye is that with this new version it seems there is no necessary call or compile in init.sqf or elsewhere to activate the files included. I assume this is because of the new DZE_"" config options added to init.sqf.
My guess is that P4l isnt being loaded properly, or at all but I don't know why. As I said I followed the instructions to the T this time, but there is something missing I am just not seeing.
UPDATE:
So I basically just ignored the install instructions and did what best made sense. I believe everything should be working but I'm being held up by one error:
Error in expression <0,0]}; _thingy = _this select 0; _pos = getPosASL _thingy; if !(surfaceIsWater _> Error position: <getPosASL _thingy; if !(surfaceIsWater _> Error getposasl: Type Array, expected Object File mpmissions\__CUR_MP.Napf\custom\A_Plot_for_Life\init\compiles.sqf, line 582
The server boots fine and when I go to build I get an object preview image, but I have no controls of the object and cannot cancel the building action. The error in questions is within the FNC_getpos function but I personally don't see anything wrong. I included it for quick reference.
Nope, you are correct (my bad). That is what comes from spending too many hours coding.... I didn't list how to link the mod in to the missions init.sqf.
Instructions for linking in to your mission (will also add to the first post and to the install instructions in the download later today).
Open your mpmissions/[map]/init.sqf file
Search for
call compile preprocessFileLineNumbers "\z\addons\dayz_code\init\variables.sqf";
Replace with
call compile preprocessFileLineNumbers "Custom\A_Plot_for_Life\init\variables.sqf";
Search for
call compile preprocessFileLineNumbers "\z\addons\dayz_code\init\publicEH.sqf";
Replace with
call compile preprocessFileLineNumbers "Custom\A_Plot_for_Life\init\publicEH.sqf";
Search for
call compile preprocessFileLineNumbers "\z\addons\dayz_code\init\compiles.sqf";
Replace with
call compile preprocessFileLineNumbers "Custom\A_Plot_for_Life\init\compiles.sqf";
Search for
_serverMonitor = [] execVM "\z\addons\dayz_code\system\server_monitor.sqf";
Replace with (you may need to change this depending on where you put the server files).
_serverMonitor = [] execVM "custom\system\server_monitor.sqf";
Dont forget to set the two variables in the init.sqf as well to turn the features on as they are set to off by default.
Turn on A plot for Life (check ownership against SteamID).
DZE_APlotforLife = true;
Turn on Take Plot Ownership.
DZE_PlotOwnership = true;
After installing the rest of the Snap Build Pro files.
Turn on Snap Build Pro and the modular player build framework.
DZE_modularBuild = true;
-
I currently have nothing to do with the A3E build (including testing).
I think we will see if the A2 Epoch pull request goes in when I resubmit and then if the interest is high enough I will probably take a look after launch.
-
Ok so if I have it installed and working already then probably no real need to update it? Like no new features?
" there is a take ownership option to align old bases built before A Plot for Life v2+ was installed to the new ownership system (with some exclusions which can be user configured)."
There is also the plot boundary on and off plot pole option with lighted road cones to help building in the dark.
The take ownership is the big one though which can be used to align historical bases to the A Plot for Life ownership system but can also be used by raiders to take control of raided bases etc. It is activated by a variable in the init.sqf so can be turned off as well.
-
Version 2.32 released
- Added the rest of the modular build framework files to make it easier for everyone to install (thumbs up to Raymix for putting it together and giving permission for it to be included).
- Amended the install instructions.
Links to the dropbox and github files updated in the first post.
If you found and installed the modular build files then you probably do not need to change to 2.32.
-
you can do whatever you want to dayz_server.pbo. It won't affect bikeys or signing of the files.
Thanks for the clarification Cen.
So without going through the whole thread, mind if I ask which files I need to update to go from 2.24 to 2.31?
Everything in the download is different to the previous versions. The main reason being that this is built for inclusion in the Epoch base code and therefore, after installed it can be turned on or off (i.e. use characterID or SteamID for assessing ownership). This means any ownership checks have to take in to account whether it is turned on or off.
On the plus side, even if turned off, it still saves the SteamID in the worldspace variable so if later turned on the ownerships will work on older built items and there is a take ownership option to align old bases built before A Plot for Life v2+ was installed to the new ownership system (with some exclusions which can be user configured).
[Release] - A Plot for life v2.5. Keep your buildables on death. Take plot ownership
in A2: Epoch Mods (1.0.5.1)
Posted
PVDZE_fullobj_Publish is a new PV and may need whitelisting in various AH solutions. I did add an exception in my Battleeye configs and will post it up later today but I do not use Infinistar so cannot really help there.