RimBlock
-
Posts
1140 -
Joined
-
Last visited
-
Days Won
3
Content Type
Profiles
Forums
Articles
Posts posted by RimBlock
-
-
Hi Rimblock quick question, I'm running PP4L and SBP everything works as intended. However, when someone builds a non-locking storage (Gunracks, wooden crates, sheds etc) the builder cannot place items inside it. They can open the gear but cannot move items into it.
As far as I can tell other people can use it as normal but the builder can't without re-logging first. Any ideas what could cause this? I've compared files and can't find the error anywhere.
Edit:
The only significant change is I changed unlock vault to characterID from OwnerID because players could not access their safes.
and for some reason the addaction for plot boundary doesn't delete. I had it working so guess I broke it when trying to find a fix for the storage issue.
Make sure you have the latest version and the safes have the steamID in the worldspace field in the DB. I have provided SQL linked from the first post to help with aligning already built items with the system used in A Plot for Life. That is probably what is causing the issue with the safes.
I have never come across the issue with not being able to put items in any storage container. It should not be related to this mod unless there is a missing ";" somewhere causing a script to abort or something like that. Try setting "DZEdebug = true;" in the init.sqf and use -showscripterrors in the command line when calling ARMA2OA and it should show errors with scripts either whilst playing and / or in the client RPT file or server RPT file.
I have just installed this through the step by step process of editing all the files. I followed every instruction to the letter.
I am not able to: unlock safes or locked boxes. I am also not able to build after death (tested by placing a plot and wall, killing myself, and trying to build another wall).
The only deviation I had to change was using _object instead of _tmpbuilt due to my player_build.sqf being from Build Snapping. How could this cause errors with my safes? I changed everything from the tutorial as instructed.
Edit: I found one or two errors, but still can't build after death.
Were the safes already built before installing this mod (see above) ?.
If you cannot build after death it sounds like the DB saves are not recording the SteamID correctly. Check the DB and see if the worldspace field in the object_data table for your plot pole just build has a large number at the end.
-
Yep, should work perfectly fine as it only modifies the existing entries in the worldspace array :)
Great, that is what I thought.
Have you worked out the max length for the 3 values with [] and "" ?. Whilst the actual changes should not affect P4L, there may be a little issue with blowing the max field size especially with other mods looking to use the woldspace field for their persistant data too.
I have started a discussion on how best to manage usage of the worldspace filed http://epochmod.com/forum/index.php?/topic/15860-disscussion-on-usage-of-the-worlspace-field-by-mod-makers/?p=119210 so we can try to come up with a loose agreement between mod makers. Although it wont really affect this mod, you may want to jump in or keep an eye on it. Hopefully it will contain info from various mod makers intending to use this field so we can all agree and ajust accordingly.
-
As the Dev team seem dead set on not opening up the Hiveext.dll to allow mod makers to create and fire custom sql or stored procedures (999 & 998 calls) we are having to find alternative fields to store presistant data for our mods or resort to using various custom hiveext.dlls / solutions (ARMA2Net etc).
I personally prefer to work with the standard Epoch tools rather than being reliant on one or more third parties so I have stuck with finding space in other fields that can be utilised without any custom DB connectivity.
This has been done and supported in Epoch with the use of the characterID field to store door lock / safe lock and vehicle key combinations and witht eh currentstate field to store the tag friendly characterIDs.
When everything went to Steam, saving the playerUIDs in the characterID field was no longer an option (at the time) and so I started hunting around for another suitable place to save persistant data can came away with the worldspace field in object_data.
The filed is around 200 chars long (will check the actual figure when home and update) of which the world space cordinates only make up around 30-40 characters. That leaves around 150 characters for saving other date (with a bit of buffer for other future updates). This is more than enough for my v2 A Plot for Life mod.
Now it seems that great minds think alike (an fools seldom differ) and a number of other mod makers have been looking at using the same woldspace field for saving their persistant data and so in order to try and prevent future conflicts, I have put this thread up so we can discuss the usage of this field and adopt a 'best practices' loose agreement about who is using it for what and how to seperate the extra fields out.
My initial suggestion would be to create a nested array after the worldspace details with tags which can be defined by each mod maker.
i.e.
For my A Plot for Life mod, I may change a worldspace field value of
[10,[12345,12345]]
to
[10,[12345,12345]],[["P4L"],["playersUID number"]]
If another mod maker also wanted to use that filed for their persistant data like Stiker with his Vector build mod then he could add his data like
[10,[12345,12345]],[["P4L","Vectors"],["playersUID number", [[v1,v2,v3],[v4,v5,v6]]]]
The server monitor could then be easily amended to look for the tags when processing the object loads and deal with the corrisponding data accordingly.
Any other thoughts or suggestions from other mod makers out there ?.
-
@Striker
I am currently amending my A Plot for Life script to merge it with Epoch 1.0.5.2, Snap Build Pro and the modular building system whilst making it possible to turn it on and off. Details of the new files are on my Git here.
Someone else has proposed a change as they are also looking at using the worldspace field for something else to fo with vehicles. To this end I suggest we all get together and have a discussion on how best to utilise the worldspace field for different purposes so when, hopefully, this mod also goes in to the core Epoch build it will be able to fit right in with the minimum of effort (and will also be easier to intergrate for server owners before that point after 1.0.5.2 comes out).
The discussion is if you would like to join in.
-
Well, no changes to packVault.sqf ?
Yes, it appears the instructions from player_packvault.sqf are missing.
you can see on my GitHub or in my dropbox download.
-
Disable character removal from the world until after 10 seconds of the players client disconnection. On disconnection, move the character control to the server and then after the 10 seconds log them off. Obviously only for disconnects :) . That way if the kill the game, their character does not instantly vanish and makes combat logging via these methods pointless.
There was some disconnect code floating around to try and catch dupers on the forums that someone may be able to utilise.
-
Something like
if (_ispole) then {
cutText ["Maintain it or loose it !" , "PLAIN DOWN"];
};
at the end of the player_build.sqf should do the job.
More info on CutText can be found here so you can tailor it to your requiremnts.
-
-
Should be pretty easy but to what end ?. You could also report to the RPT file or have something checking the DB for any new plot poles saved in to object_data and tie it to a web front end (for admins etc) if desired. Lots of ways to do it, the best way depends on your desired overall outcome.
-
Sounds like you will need to throw in some diag_log lines to get variable values dumped to the client RPT file. Have a look at the ones already in the scripts and you should be able to work out how they work.
In player_buildingDowngrade
find
// check if friendly to owner
Change to// check if friendly to owner diag_log format["Player_buildingDowngrade: [ownerID: %1] [Friendlyto: %2]", _ownerID, _friendlies];
You will also need
DZEdebug = true;
in the init.sqf as well.
I would also clarify that you are calling my files for upgrade and downgrade especially with other mods installed. If you are referencing the files more than once in the compiles.sqg (or other files called from it) then you may be overwriting the link to my files.
-
Np :) .
Ok, so this only affects the up/down grade and not building new items ?.
I don't think tag friendly carries over to new characters as they are ... well... new character records in the DB :) . If they re-tag friendly can they then build ?.
There is also a requirement of having to look at the plot poles owner after logging in before being able to build on their plot. I suspect this is trying to restrict people tagged as friendly building on the owners plot without them being around.
In essence, I would;
Check the currentstate field for the new character with the previous characters currentstate field in the DB.
Get the new character to look at the owner before building.
See if the new character can tag friendly before building.
Failing that I would expect there to be an issue in the script files around the plot pole check section. Have a look for "if(_ownerID in _friendlies) then {" in both files and check there are no errors around that section.
Did you edit the files or download the mod from dropbox and do you have any other mods installed ?.
-
A quick update on the v2.3 development.
I am actually currently testing with the Epoch 1.0.5.1 base code but with Epoch 1.0.5.2-RC buildables as there were issues pboing the 1.0.5.2-RC files. I will upload the updated dayz_code.pbo when I have got all of the snap build pro parts included for others to test.
Currently this version is Alpha-1.21.
Parameters
A Plot for life:off
Modular Building system: off
Snap Build: off
This is the vanilla config to confirm it still works wilth all options off.
Tested
Place / remove plot pole: Working
Place / remove buildable: Working
Place / remove tent: Working
Place / unlock / lock / remove safe: Working
Upgrade / Downgrade: Not yet tested.
Overall results
Working fine with the new code using the vanilla characterID based ownerships. OwnerUIDs are being saved in the worldspace field as expected even with APfL turned off enabling it to be turned on and work at a future time without messing with the database.
-----------------
Parameters
A Plot for life:off
Modular Building system: ON
Snap Build: off
This is the vanilla config with the new modular build system Raymix put together and now part of Epoch 1.0.5.2-RC.
Tested
Place / remove plot pole: Working
Place / remove buildable: Working
Place / remove tent: Working
Place / unlock / lock / remove safe: Working
Upgrade / Downgrade: Not yet tested.
Overall results
Working fine with the new code using the vanilla characterID based ownerships and the new modular build system. OwnerUIDs are being saved in the worldspace field as expected.
-----------------
Next round will be
Parameters
A Plot for life:ON
Modular Building system: off
Snap Build: off
Issues to be resolved.
Fully merge Raymixs snap build pro in to the dayz_code.pbo I am using.
Some way of converting historical buildables and possibly handling BIS PlayerUID -> SteamID conversions on object load.
-
Everything works fine except players cannot upgrade or downgrade existing objects after death.
Cannot how ?. No option appears, option does nothing, plot ople not in range message ??.
-
I added to my test server and i cant unlock / type combo lock on safes i believe it because i dont own it but i want anyone to use a safe how would i change this i think it somewhere in the fn_selfaction.sqf
Version installed ?.
Check for "//Allow owner to unlock vault" in the fn_selfactions.sqf file.
Anyone should be able to unlock via the keypad.
Another option could be an error further up the file which is causing the script to exit without getting to that part (most likely).
------------
On another note. I have put an item up on the Epoch Git for tracking progress of the 2.3-Alpha builds for inclusion in to the Epoch core distribution here.
-
Anyone else getting lots of friendly fire kills on their server since the patch?
It seems sometimes the actions for players don't load and this seems to be directly related to the friendly fire bug, oddly a shift - flush fixes it for that player but often players dont realise until they are friendly fire killed.
Any ideas?
Edit: Just had a thought.
Recently I put in a fix to stop the loading screen issue which basically does "End loading screen" after a certain amount of time, now I can't say I've got stuck on this since but I'm wondering if the reason for it not loading is because it is hanging on loading the epoch actions or epoch related scripts, something a shift - flush fixes.
Since this fix now that I think about it, there has been a much higher increase of friendly fire related deaths so I'm thinking this could be related?
Any ideas devs?
This is the fix in this compiles.sqf
- Line: 437 if (dayz_clientPreload && dayz_authed) exitWith { diag_log "PLOGIN: Login loop completed!"; };
+ Line: 437 if (dayz_clientPreload && dayz_authed) exitWith {
+ Line: 438 endLoadingScreen;
+ Line: 439 diag_log "PLOGIN: Login loop completed!";
+ Line: 440 };
If I'm reading that right, its exiting the script so it doesn't continue to load the compile functions below? Either way this is where the problem is.
The code is called in a spawn {}; which runs it is a seperate process in parallel. This spawned process being exited should not affect the compiles.sqf completing.
Int he Github code the spawn starts at 436 and ends at 482.
The only endloadingscreen that looks relevant is in the player_monitor.fsm so there is probably a bug in there that is getting tripped. The FSM files need s tool to read (freely available) but for this reason, I suspect not a lot of people have taken a look.
-
PkP for light machine gun as I like the fact you can see outside the scope as well as though it making tracking fast moving targets or goups a bit easier.
I did like the M4SD but it just feels a bit weak.
I found a VSS on an AI and have been using that for a bit now. Silenced, scoped with 10 round mags although 20 round mags can be had from the black market trader at Starey.
I loved the M107 for sniping but tend to use the M40A3 most of the time as I can carry DMR mags and break them down in to 5 shot mags when needed to save space. Would like to try the M14 or even the EBR varient if it is available.
For a hand gun I was using the Makrov SD but just happen to carry a PDW I found now. Takes lots of mag types, can hold up to 30 rounds and does 899 damage per bullet. 899 x up to 30 bullets per clip = a lot of up close damage vs a 1911 or revolvers 4,500 damage if you actually hit... ;) . Spray and pray baby, if they get that close.
-
Can't see that path, asked me to log in first, then just gave me error that path does not exist. Think that one is not shared.
Hope it wasn't too difficult to integrate into modular
I have defaulted my fork of the Epoch repo to the A Plot for Life branch I am working on. Please take a look and see if that works. I don't see anywhere where access is restricted at all in the GitHub settings.
Only two files needed to be amended for the modular build set, one for checking the plot pole ownership and one for publishing. Worked out fairly easy ;) . Of course I then had to merge in your other commits that you keep on applying to the Epoch upstream :D .
Latest version, and RayMix's custom player_build. https://gist.github.com/raymix/51828217334b93b8ff42
Ok, so there is version 2.2.6 which is the live mod and there is v2.3 which is in Alpha-2 testing. I am guessing you are trying v 2.2.6.
I have never heard of building resulting in death unless there is an antihack running which may cause this but the A Plot for Life code is fairly simply integrated in and should not cause any issues especially as there are no new script files or global variables being passed around.
If you can perform these actions again and then post the RPT files in spoiler tags (see Raymixs sig for how to use them) and take a screen shot of the DB entries for the plot pole you are building near then I may be able to give a bit of direction.
-
I went to your GIT and don't see v2.3 download
Make sure you have selected the A Plot for Life branch from the dropdown box. That should take you here. I would suggest taking a look at the files posted in the dropbox link in the post above for a quick drop in solution but that also needs testing.
Place wall -> die -> attempt to upgrade wall = fail. Plot pole nearby.
Does anyone know what could be causing this?
Some more fundamental info would be helpful. What version are you using for example.
-
-
-
1052RC but you should just be able to pull out my files if needed which are the same files used in v2.2.6 plus variables.sqf
All files have "Alpha build - needs testing." as the comment.
You will need to set DZE_APlotforLife = true; in the maps init.sqf to turn it on.
-
You will need to grab from my Git here.
It is untested so please expect errors ;) .
I will look at doing some testing tomorrow as well.
-
-
Changelog?
In the first post and on GitHub.
[Release] - A Plot for life v2.5. Keep your buildables on death. Take plot ownership
in A2: Epoch Mods (1.0.5.1)
Posted
Update for A Plot for Life v2.3 (Epoch core merge build).
A Plot for life on / off
Modular building on / off
Snap Building on / off
Build and remove modulars: Working
Build / unlock / lock / pack safes: Working
Build / unlock / lock / pack tents: Working
Upgrade cinder walls: working.
Switching between A Plot for life off -> on kept ability to build on the same plot for plots / items build after the mod was added.
All files are in the dayz_code.pbo file so the mission file is just 50+k.
I am just updating my Git with the last couple of bug fixes and I will make my dayz_code.pbo available so people can just drop it in to the server and client @dayzEpoch/addons mod folder.
You will need to turn off verifySignatures = 0; in the config.cfg but as this is only intended for beta testing it should only be deployed on test servers.
The dayz_code.pbo is from 1.0.4.2 with the building stuff from the 1.0.5.2 RC files.
Core things to test along with the items above are tag friendlies, upgrade / downgrade doors with locks, dying and making sure you can build again (or not build if A Plot for Life is turned off).
I also added the following to the mission init.sqf
I will put the links up in the first post when uploaded.
Update: first post updated with download and config details. Enjoy.