Jump to content

RimBlock

Member
  • Posts

    1140
  • Joined

  • Last visited

  • Days Won

    3

Posts posted by RimBlock

  1. I downloaded the v2.34 from GitHub, although the last modification done was to the custom folder two days ago.

    I just checked again, I don't see a 2.4 in the branch I'm in, I see this:Epoch/A Plot for Life/v2.34 & Snap Pro v1.4.1 and the last folder has the older versions. Did you find the error in your compiles.sqf that I posted anyways? I got it from that exact location. I'll take another look and double check I'm in the right place though, thanks for the quick response!

     

    On GitHub, under RimBlock\Epoch in the top left, there is a dropdown box which will say something like "Master".  Change it to v2.34.

     

    I need to take the version numbers out of the folder names as I am moving to bersioning via branches in GitHub much like the Epoch team do.

     

    I have corrected the bug you found on the v2.4 branch and have confirmed the master branch does not have that update (master is still updated to a post v2.34 status).  I can also confirm that the version of compiles in the v2.34 branch is the one before my modifications to that function in compiles.sqf.

     

    If you look in the browers address bar, the next element after "blob" is the branch.  The address below is from branch "A_Plot_for_live_v2.4" 

    https://github.com/RimBlock/Epoch/blob/A_Plot_for_Life_v2.4

     

    Whilst the address below now is from branch "A_Plot_For_Life_V2.34"

    https://github.com/RimBlock/Epoch/blob/A_Plot_for_Life_v2.34/

     

    and the frollowing address is from the "Master" thread.

    https://github.com/RimBlock/Epoch/blob/master/'

     

    I will look at defaulting to the v2.34 branch to make it easier (default is usually "Master" on GitHub).

  2. Hey all, 

         Getting an error in my RPT logs after I tried to install this and server hangs at the splash screen,

     

    19:00:26 Error in expression <etPlayerUID = {
    private ["_onlyPUID", ""_who, "_PID"];
    _onlyPUID = _this select >
    19:00:26 Error position: <_who, "_PID"];
    _onlyPUID = _this select >
    19:00:26 Error Missing ]
    19:00:26 File mpmissions\__cur_mp.Tavi\Custom\A_Plot_for_Life\init\compiles.sqf, line 553
    19:00:26 Error in expression <etPlayerUID = {
    private ["_onlyPUID", ""_who, "_PID"];
    _onlyPUID = _this select >
    19:00:26 Error position: <_who, "_PID"];
    _onlyPUID = _this select >
    19:00:26 Error Missing ]
    19:00:26 File mpmissions\__cur_mp.Tavi\Custom\A_Plot_for_Life\init\compiles.sqf, line 553
     
    So I took a look at lines 552-560 in my compiles.sqf that came with it, Which looks like this:
     
    FNC_GetPlayerUID = {
    private ["_onlyPUID", ""_who, "_PID"];
    _onlyPUID = _this select 0;
    if ((count _this) == 2) then {_who = this select 1}else{_who = player};
    _playerUID = GetPlayerUID _who;
    if !(_onlyPUID) then {
    if !(DZE_APlotforLife) then {
    _playerUID = _who getVariable ["CharacterID", "0"];
    };
     
    I have not modified the compiles at all from the most recent, and did this fresh on a server without modifying any of the files besides exactly what was outlined out in the readme. If you need any of my files let me know and I'll be sure to upload them as soon as possible. Any ideas?

     

    /////EDIT//////

    Changed: 

    private ["_onlyPUID", ""_who, "_PID"];

    to:

    private ["_onlyPUID", "_who", "_PID"];

     

    Server is up and running but when a player places a plot pole, they are told they need a plot within 30 Meters to build.

     

    You downloaded the beta v2.4 code from GitHub. 

     

    Change the Github branch to v2.34 then download or download from the dropbox link on the first page of this thread (unless you are doing some beta testing for version 2.4).

     

    I will look at renaming the beta branch with "Beta" to make it clearer.

  3. Progress update.

     

    Merge of new position code

    The new changes for v2.4 (see first post in the thread) have been added to the modular build code.

     

    Rewrite of FNC_GetPlayerUID

    I have also rewritten the FNC_getplayerUID function whic was added to Epoch 1.0.5.2 (now 1.0.6) to allow server owners to switch between using the SteamID and tyhe old BIS PUID.  As it was never officially released and as the vast majority of people will now be using the SteamID I have modified it to check if the A Plot for Life variable is set and to return either the SteamID or CharacterID.  This means instead of 5 lines of code in each of the building sqf files I can now put only one or two (dep if the worldspace needs to be set).  

     

    New function FNC_GetPoles

    I have also added a new function called fn_get_poles.sqf.  Quite a few of the building scripts need to check if a plot pole is nearby and if so get the nearest.  The new function does this and returns the count of plot poles and the nearest alive pole.  Using it reduces the lines of sqf code by about 2 for each file it is called in.

     

    Beta Testing

    As it seems theres no with an interest to do any beta testing I need to sweeten the deal.  Anyone who helps with beta testing will get access to boobytrapping doors 4 weeks before it is released publicly.  The 4 weeks will start from the v2.4 release date and will include any bug fixing period.  

     

    Boobytrapping Doors - If you have a hand grenade then you can upgrade a locked door to boobytrap it.  If the incorrect door code is entered then the hand grenade will be dropped at the position the player was when they boobytrapped the door (make sure you are on the correct side of the door when setting the trap  ;) ).

  4. Nice, sounds like a plan. Let me know if you need testing done, happy to try it out. (already got the latest apfl running on our server so shouldn't be too hard)

     

    Would appreciate if you have some time to look at testing the current changes in the master branch on the Git for Player_Build (need modular_build to be set to false to use it) so I can confirm it is working, migrate the changes to modular build files and release and then I can concentrate on the menus.

     

    Have just noticed an issue (with Vanilla) with the max items limit check.  It is hard coded for 30 mtrs (known which is why modular build puts this value in a variable - DZE_checkNearbyRadius) but also it counts all items not just buildables. 

     

    Should really only check buildables so will probabl have to put in a {if in buildables array then inc buildable counter}count x; check.

     

    Variables for the new player_build.sqf.  Defaults in ().

    DZE_BuildInPlotRadius (false)         //Allow to build in plot radius without preview vanishing.

    DZE_BuildOnGround (false)             //Force max build height (see two options below)

    DZE_MaxNoPlotNeededHeight (15) //Max high items not requiring a plot pole can be built

    DZE_MaxPlotHeight = (0.5)               //Max hight a plot pole can be built

     

    Update: The missing fnc_setpos has been added back in to the compiles.sqf

  5. Cool,

     

    So for info.

     

    Owner

    Founded

    Object Count: XX of XX max

     

    Maybe Maintain can have the damage and Confirm has the cost.

     

    This will be a pretty big change so will take some time to complete.

     

    I will be updating the build for items 1-9 first which should be fairly quick, then will be debugging error reports whilst working on the menu system.

     

    I will put the server object load as a low priority behind the menu system.

     

    I alos wanted to add bobby trapped doors but will have to see how this goes first.

  6. Firstly, love the mod - an excellent add-on for epoch.

     

    I've modified this slightly, so that the owner of the object built within the plot is assigned the ownerID of the plot owner unless it is a safe, in which case it uses the player who built it.  This allows me to monitor player build numbers by plot pole to keep an eye on the object count of the server, as we know arma2 can't handle a large number of objects.  And the plot owner is ultimately responsible for the number of objects built within their plot.  I also use plot management so the plot owner can decide who can do what on the plot without having to tag as friendly all the time.

     

    To assist with build times I've also built in functionality to convert player built objects that don't require any interaction to player content - players can tag an item to remain in the database or be converted to player content - this is to help reduce the load times of the server whilst still being able to have the objects on the map.  In doing that, I provide object counts for the player showing:

     - count of database objects against plot build limit

     - count of player content objects

     - count of objects to delete

     - count of total objects

     

    I guess what I'm saying there, is the UI for plot management is handy, and if you are looking to build this in, then it provide greater flexibility.

     

    Thanks.

     

    Yep agree.  I think the objects built on the plot should be owned by the initial or only plot owner (if different from original).

     

    By player content do you mean the players can tag items to add to the mission files and then you manually do so ?.  If that is the case then that would mean you would have to manually remove them as well if they get removed / destroyed ?.

     

    I am looking to use the action menu rather than a GUI.  There are some GUIs around already and this will be lighter weight. 

  7. I still like the ability to enable / disable building rights (i.e. can disable builders while offline to stop people building while away without having to remove all the builders).

     

    Maybe

     

    Plot Menu

    1. Plot Info (like what ?)

     

    2. Maintain (cost)

    2.1 Confirm

    2.2 Cancel

     

    3. Owners

    3.1 Add 

    3.2 Remove

    3.3 View

    3.4 Cancel

     

    4. Builders

    4.1 Add 

    4.2 Remove

    4.3 View (Enable / Disable on the list via toggle when selected)

    4.4 Cancel

     

    5. Remove Plot Pole

     

    I also prefer limiting the players to the plot radius at most.  No point scanning the whole game world and creating a large list for the action menu.  Would need lots of scrolling which is not so user friendly.

  8. When I build wall or other buildables or when vehicles spawn in, Should they be saving in the database as follows: 

     

     

    Or Should it be like this:

     

     

     

    I had an issue where the server wouldn't start anymore and had this error in rpt.

     

     

     

    Once I deleted all the objects with the first worldspace I could log into the server with no problems.

     

    Currently the server is still writing it to the database as stated in the first quote and I am looking for advice to which is correct and how can i fix it. (I am pretty sure the second way is correct as the server runs.)

     

    First way is Epoch vanilla with A Plot for Lfe installed.

     

    Second way is Epoch Vanilla with A Plot for Life and Precise building installed.

     

    What mods do you have installed ?.

  9. Hey Rimblock,

     

    Love the fact that you keep working on this! Cheers.

     

    I actually like that everything gets an ownerUID, in some respect it gives you a bit more insight onto what is happening on the server without having to scroll through loads of logs. Plus i made some PHP monitoring stuff that is already dependent on it :P

    About number 9.) does that mean you are looking into the possibility of enhancing the "who can build on this plot" thingie? I would love some kind of native plot management for this mod, don't need a fancy menu for it though, i feel that is just excessive KBs for the mission file.

     

    Well the ownerUIDs for anything that does not have an ownerUID set in the worldspace field just drops in a '0' and so serves no real purpose at this time.  It could be leveraged to assign ownership to vehicles independant of the locking codes and could then be used to allow the owner to auto unlock their vehicles without a key (others would need a key).  I am very open to any other uses / ideas people may have and am happy to build with those in mind (although I may not put the code in to implement them if too far from the concept of this mod).

     

    Number 9 is just using a seperate function that is called when the ownership check is required and returns an array of [bool,bool] where the first relates to owner (true / false) and the second relates to friendly (true / false).  This is a pretty common check for the build system so cuts out a lot of duplicated code if fully integrated.

     

    Now, saying that, I could probably put together an action menu form of plot owner / builder management.  I got a two level menu system working quite well for selecting which vehicle to refule from a fuel truck in the 'better refueling' mod.  I could probably leverage that one.

     

    What functionality would we want to have from the plot pole ?.

     

    Plot Menu - Only available to plot owner.

    -------------

    1. Add builder

    2. Remove builder

    3. View builders

     -          Builders name (green or red to show whether they have build rights).

    3.1 Enable / Disable builders build rights

     

    Add builder will list characters within 10mtrs(??) of the plot pole.

     

    Will need to see if there is a way to update builders names with the last used name that SteamID used from the DB.  Just listing out SteamIDs seems pretty unfriendly but if there is no DB call then may have to do that or leverage another DBextention like extDB which I am working with for the A3 mod I am doing with Raymix.  I did want to keep this more independant of any 3rd party extras so it will be a last resort and only driven by popular demand.

  10. Haha, saved me trawling through all the code so it is appreciated regardless of whether you knew or not :) .  The bug may have gone unresolved if not for you and RedBaron (and many others through the 49 odd pages of this thread) helping to report and providing info on your searching around or testing.

     

    General chit chat spoiler

    Well 14 years is a fair amount of time.  Kinda hard justifying moving back to the UK in the near future.  It is very safe here (walking the streets at 3am with no worries), people are generally nice (i.e. rarely abusive) and the financial situation is pretty good (decent wages with only approx 5% income tax.  Sales tax is only 7%).

     

    I do miss the changing seasons and not having a garden for summer and the humidity here is a real pain for me and my electronic toys...

     

    Stay out of politics and you are pretty set although that seems like it could also be changing.

     

    anyway ;) .

  11. Great.

     

    So now v2.34 seems to be fairly stable I will continue with the new version.

     

    Current changes in the new version (currently in development).

     

    1. Leverages the new functions for positioning over land and sea.

    2. Option to walk around the whole plot when building rather than being limited to 5 mtrs from build origin.

    3. Walk around option can be turned off or on with a variable.

    4. If no plot pole required then the 5mtr build range is retained (stops people running around with preview walls as bullet blockers).

    5. 5mtr high limit from origin still in effect.

    6. Allows an optional check for height above ground / sea max (prevent sky bases).

    7. Can set max height to build plot poles (if 6. active).

    8. Can set max height to build items that do not need plot poles (if 6. set).

    9. Uses my new fn_check_owner.sqf to check ownership and friendly status (as take plot ownership does) - reduces code size in player_build.

     

    I am also going to take a look at improving the server object load at startup.  The current process is to load and object and process it then load another and process it.  I am going to look at loading an object and tagging it (typeof) and then once all the objects are loaded I will process them depending on what type they are (cars do not need ownerUIDs which they currently get with this mod).  There may also be some advantage is spawning code to deal with creating vehicles / buildables / others in parallel (yeah, yeah, not really in parallel as they will be scheduled).  If it works and provides some advantages then it may also make it easier for other mods to target only buildables (for vectors / precise building etc) rather than potentially everything loaded.

  12.  

    Alright it's working now

    I switched your code () with the old code from the original compiles (Regarding the player_guiControlFlash)

    And Icons Flash again :)

     

    Best Regards and do eat a Chicken Rice for me at Newton ;)

    Huppabubba 

    (HungEmmaoLP is letting me use his Account as I have not been added. Been waiting 2 Months now   ;) )

     

     

    Great, thanks for the confirmation and thanks again for the spot.

     

    Haha, I am out to the East away from the more traditional expat areas but my wife is a Singaporean ;) .  Chicken rice is pretty good but I am a sucker for prata (especially from Old Town)... much to my waistlines dismay.  Just found a local Harrys bar as well... after 8 years living here (to be fair it has only been there for 3 or 4 years and is quite well hidden) :D .

     

    2 months for an account seems pretty bad.  Is it not just auto email verification to get a forum posting account here any more ?.

  13. Hmm, maybe I didn't push it to the Git, it is on my local Git.  Will check tonight.

     

    Nothing much has changed in the master branch apart from player_build.sqf.  Compiles has an extra function but only player build uses it and there are a few more variables in variables.sqf.  Neither of the last two should cause any issues, just exclude player_build.sqf if you don't want the new beta changes.

     

    Version 2.34 has its own frozen branch now on the Git.

  14. Check you are using the latest version of player_updategui.sqf. an older release had a version based off of the 1.0.5.2 version but this was corrected a while ago and the 1.0.5.1 based version is on Github and should also be in the Dropbox file.

    If your version has dayz_dark_ui in it then it is the 1.0.5.2 version.

    The version up on Github is working Fine.

  15. You have errors all over your rpt file including for stuff that has nothing to do with this mod

     

    e.g.

    Line 13: File nissan_350z\config.cpp, line 244: '/CfgVehicles/350zBase/Library.libTextDesc': Missing ';' prior '}'
     

    You will need to go through them one by one and correct them.

     

    You don't seem to have linked in the server_functions.sqf correctly

     

    Line 401:  0:48:40 Warning Message: Script custom\init\server_functions.sqf not found
     
    Your selfactions has issues.
    Line 408:  0:48:40 File mpmissions\DayZ_Epoch_13.Tavi\custom\fn_selfActions.sqf, line 61
     
    Than you have errors all over the server_monitor.sqf
    Line 617 onwards: 0:48:43 File mpmissions\DayZ_Epoch_13.Tavi\custom\system\server_monitor.sqf, line 51
     
    Fix the linking in of the server_functions.sqf and a lot of the errors may go away.
  16. Ok, thanks for the update.

     

    On the issue of the tag friendly system, I am at a bit of a loss.  After tracking through the whole process last night there should not be any issues.  The only thing that is changed is whether to store the characterID or the SteamID in the players friendlies but the method for storing the actual value is the same as used in vanilla Epoch.

     

    What is actually not working with the tag friendly.  Is it that the other players name does not come up as green after tagging or is there more not working with the friendly system ?.

     

    The way it works in vanilla Epoch is that you tag someone as friendly and their characterID gets added to the friendlies variable (array) of your character (player) game object.  When that object is saved then the details are also saved in to the DB.  At the same time, the other players character gets a message that someone has tagged them and then they can do the same with the same results.  After this is done and both player characters have the other charactersID in their friendlies, and the next time (possibly the same time) the characters cursors touch the other player, they should light up as green and the below friendlyTo system is activated.

     

    Having someone in your friendlies list does not mean they can build as you need to look at them once to mark them as friendly.  If you have the other character in your friendlies and the other character has your characterID in their friendlies then you both get each others characterID added you the each characters friendlyTo variable.  This then determines if the other player can build on your plot.  The important bit on this is that the friendlyTo details are not saved to the DB and so are not set unless you look at the other players character again.

     

    You could add some diag_log lines in to the player_tagfriendly.sqf and player_updateGUI.sqf to see what the variables are but I am not currently seeing how A Plot for Life would cause a problem here.

     

    If you can pin it down some more then that would help.

     

    @everyone.

     

    There is a new player_build.sqf up on my Git under the master branch (A Plot for Life v2.34 now has its own branch).  This is an early beta and requires updates to the A Plot for Life custom compiles.sqf (new save position function added) and variables.sqf (new variables for the new added functionality).  Both also up on my Git on the master branch.

     

    To test it out;

    1. Download those 3 files from my Git and replace the standard A Plot for Life files with them. 

    2. Make sure you have set DZE_modularBuild to false (or don't set it as it defaults to false). 

    3. Set the new variables as required 

      - DZE_BuildInPlotRadius: Valid values are true or false (default) and this turns on whether you can run around anywhere in the plot radius without the preview getting cancelled due to moving more than 5 mtrs.

      - DZE_BuildOnGround: Valid  values are true or false (default) and this turns on whether to false plot poles to be built at DZE_MaxPlotHeight and other items that do not need a plot pole to be built at a max DZE_MaxNoPlotNeededHeight height.  The default values are 0.5 and 15 (values are in metres and can be overridden in the init.sqf).

     

    As this is only for the regular build system it will no use Snap Build Pro for this initial beta but if it is tested and works ok then I will merge the changes in to the modular build system that Snap Build Pro is also linked in to with this release.

     

    Please report any bugs / feedback to this thread or put a post up in my Gits issue tracker.

     

    I have also pushed up a new plot_take_Ownership.sqf file (slight amendment to use  FNC_GetPos for positions) and fn_check_owner.sqf (changed 'player' to '_player' which is passed to the script making it easier to use for checks agains other players for ownership as well as the calling player).  Both are very minor and will have no visible differences.

     

    The full details of all the changes are listed in this Git commit.

  17. Good to hear.  I have also seen issues disappear with a DB refresh.

     

    For the vanishing buildables, you could add a trigger to the object_data table to log any deletions.  You will need to housekeep it as it will grow quickly but it will show what was deleted when and may give some insight as to any common features of the rows being deleted.

     

    Save the following code in to a file and run it with your SQL client against a test DB  :) .  It should create a new table called object_audit and a new MySQL server event which will housekeep the object_audit table deleting anything older than 1 day (you can change this in the sql).

    -- Audit table
    
    DROP TABLE IF EXISTS `object_audit`;
    
    CREATE TABLE IF NOT EXISTS `object_audit` (
      `id` int(11) NOT NULL AUTO_INCREMENT,
      `tstamp` datetime, 
      `action` varchar(3),
      `ObjectID` int(11),
      `ObjectUID` bigint(24),
      `Instance` int(11),
      `Classname` varchar(50),
      `Datestamp` datetime,
      `LastUpdated` timestamp,
      `CharacterID` int(11),
      `Worldspace` varchar(128),
      `Inventory` longtext,
      `Hitpoints` varchar(512),
      `Fuel` double(13,5),
      `Damage` double(13,5),
      `notes` text,
      PRIMARY KEY (`id`)
    ) ENGINE=InnoDB  DEFAULT CHARSET=utf8 AUTO_INCREMENT=1 ;
    
    -- Delete trigger
    
    DELIMITER ;
    DROP TRIGGER IF EXISTS `deleteObjectAudit`;
    
    DELIMITER //
    CREATE TRIGGER `deleteObjectAudit`
    AFTER DELETE ON object_data
    FOR EACH ROW
    BEGIN
    	INSERT INTO object_audit (`tstamp`, `action`, `ObjectID`, `ObjectUID`, `Instance`, `Classname`, `Datestamp`, `LastUpdated`, `CharacterID`, `Worldspace`, `Inventory`, `Hitpoints`, `Fuel`, `Damage`, `notes`)
               select now(), "del", `ObjectID`, `ObjectUID`, `Instance`, `Classname`, `Datestamp`, `LastUpdated`, `CharacterID`, `Worldspace`, `Inventory`, `Hitpoints`, `Fuel`, `Damage`, "" from object_data where ObjectUID = OLD.ObjectUID;
    END//
    DELIMITER ;
    
    -- Housekeeping
    
    DROP EVENT IF EXISTS `housekeepObject_audit`;
    DELIMITER ;;
    CREATE EVENT `housekeepObject_audit` ON SCHEDULE EVERY 1 DAY COMMENT 'Housekeeps the player_alias table' DO DELETE FROM `object_audit` WHERE `tstamp` < DATE_SUB(CURRENT_TIMESTAMP, INTERVAL 30 DAY) 
    ;;
    DELIMITER ;
    

     

    I do have the code for insert and update triggers as well if anyone wants them.  They will add load to the MySQL server and the object_audit table will grow fast and will affect backup sizes unless the table is excluded from the DB backup.  Just shout if there is an interest.

     

    I may have a beta player_build.sqf ready for testing today with;

    1. Correct positioning over land or water.

    2. Option to walk around the whole plot when building rather than being limited to 5 mtrs from build origin.

    3. Walk around option can be turned off or on with a variable.

    4. If no plot pole required then the 5mtr build range is retained (stops people running around with preview walls as bullet blockers).

    5. 5mtr high limit from origin still in effect.

    6. Allows an optional check for height above ground / sea max (prevent sky bases).

    7. Can set max height to build plot poles (if 6. active).

    8. Can set max height to build items that do not need plot poles (if 6. set).

    9. Uses my new fn_check_owner.sqf to check ownership and friendly status (as take plot ownership does) - reduces code size in player_build.

     

    Note: Player_build.sqf is not used in A Plot for Life if DZE_modularBuild is set to true.

     

    I will release the player_build.sqf as a separate file for people who want to test.  If testing seems good / after fixing discovered bugs I will modify the modular build files with the changes, put it out for testing again and if all good will push out a new version of A Plot for Life with them included.

     

  18. Lookup publicvariableserver and eventhandler.

    You basically just need to create a public variable. Put an array of parameters you want to pass to the server side script and call the publicvariableserver command to pass it you the server. The server has an eventhandler listening for that variable changi get and when it does it calls a server side script with the contents of the passed variable (in whole or selected elements also possible if an array is passed).

    For an example, look at remove.sqf . It calls a public variable at the end. Check publceh.sqf to see where the eventhandler is defined and how it spawns the script server side.

×
×
  • Create New...