Jump to content

RimBlock

Member
  • Posts

    1140
  • Joined

  • Last visited

  • Days Won

    3

Posts posted by RimBlock

  1. ...and there was me thinking people were using a heli to lift a car with a player standing on top of the car who would then build the parts.

     

    Can you tell I have spend many hours playing Just Cause 2 before moving on to Epoch :) .  Maybe worth a try though :o .

     

    The standing on preview is a lot more plausable.  Can you not just make the preview objects non-supportive (i.e. collision off for example) ?.

  2. Would it be a DayZ enhancement or a DayZ Epoch enhancement repository ?.

     

    Who would verify and approve pull requests for all the different mods within the Git ?.

     

    The advantage of the individual 'enhancement' makers having their own Gits is that they retain control over the code but others can still contribute (like the current Epoch Mod). 

     

    Possilby a DayZ Epoch enhancement branch hub would be nice where it would be a central place people could see and contribute too.  They could then initiate pull request to the origin Git for that enhancement for consideration in the original code which is still original maker controlled.

     

    Of course you would then need to get the enhancement makers to put their code up on Git which a lot, from what I have seen, do not yet do :) .

  3. It is possible to get the object id I believe, every time a station / fuel tank is used add it's id to a public variable array. Then count the number of times it appears in the pubvar next time it's used?

     

    This would then populate the array with used fuel tanks and leave unused ones as they are which may be more efficent than setting everyone of them with the findnearest on server start.

     

    This would not get around the lack of persistance across server restarts but would, along with the original suggestion from Halvhjearne for being able to set vars on non-persistant objects, provide a workable compromise. 

     

    Personally it still fills like a bit of a kludge due to lack of persistance  :) .

     

    Another alternative would be to use a holder object as storage in the DB where you could dump the array of current fuel capacities on server restart.  An object that would not have an inventory could have its inventory field used for alternative purposes like this.  Put it somewhere out of the way on the map and make sure it is not out of place and it should be fine.  make it invisible for extra security.  You then have persistant fuel supplies for all on map fuel tanks with no map editing, a small code change and one extra object.

     

    I will probably go this way with my own refueling mod although I probably would not have thought of it for map defined objects without this thread and bo your and Halvhjearnes input.

     

    Thanks guys.

  4. ...

     

     

    Unfortunately just at PreCheck step 3, I got an error message. I don't know if something is different in my MySQL server/client but I would very much appreciate if you can take a look and advise please.

     

     

    Steps to reproduce: I simply copied the SQL pre-check code and pasted into a new SQL query window in Navicat client. 

    MySQL server version info: "D:\MySQL\Program\MySQL Server 5.6\bin\mysql.exe  Ver 14.14 Distrib 5.6.19, for Win64 (x86_64)"

     

    Client info: Navicat v.9.0.11

     

     

     

    Hi MGM,

     

    I use MySQL Workbench as it comes with the MySQL install (inc. the free community version) and is pretty powerful (although still far from perfect).  It also gives a baseline as everyone has it, just like vi on UNIX servers.

     

    My suspicion is that NaviCat is not seeing the direct delimeter as the start of a code block and is therefore complaining at the end delimeter.

     

    Suggestions

    You could try MySQL Workbench and it should work without issue.

    Run the first "drop" command and then run the second "create" block of code without the delimeters around it (take out the "DELIMITER | " at the start and the "| DELIMITER ; " at the end).  Worst that will happen is that it will not create the function.  If it fails try adding a ";" after the "END".

     

    I am not near a MySQL server so cannot test for you so this is a bit of testing by proxy ;) .

     

    Let me know which way you have tried and the result and we can go from there.

  5. https://community.bistudio.com/wiki/nearestObjects

     

    again this is way more work than what it is worth, but you could make some custom hive calls and and then save all these objects fuel capacity aswell (alltho it most likely will slow down your server boot speed considerably), but imho its not worth the efford (for this game anyways, you should really move to a newer engine and do this).

     

    when i say arma, i dont mean arma 1, i mean arma as in whole unit of most bi games combined ... the code is rarely very diffrent and unless specified for a custom mod or utilizing new commands/functions, is in most cases both forward and backward compatible.

     

    Ok, so you need to search the entire map for all the classes of fuel tank on server boot and set the fuel variable.

     

    Sure you have said you do not believe it is not, in your opinion, worth the effort although I do not really agree with it especially, as you clearly note, the commands used tend to be transferable between engines in the ARMA series so the hope would be that it could be modified quite easily and therefore easily usable in Epoch for ARMA 3.

     

    Not sure that writing custom hive calls would be easier than turning map fuel tanks to Epoch objects.

     

    Anyway...

     

    So there are a couple of options available.

    Reference the map objects as non-persistent objects and set fuel capacity which is fine but would reset on server reboot.

    Convert the map fuel storage tanks to actual persistent DB objects where Epoch will track the fuel using existing methods.

  6. I would suggest that you get on Github and fork the repository, make the changes to the .hpp file and submit the change for consideration. 

     

    Other than that, the only thing I think you can do in order to test it is to start a local server on your computer and test it out, with ebayn0.0b's alteration above. 

     

    Yep, done and done.  Just need to test before putting int he pull request to save wasting VbAwols time when the whole Epoch team are very busy but want to test quickly to make sure it gets in to 1.0.5 (which it should do).

  7.  

    Problem:

     

    Plot poles only work after a server restart.

     

    Its a serious problem but i am happy that it works after the restart.

     

    Regards,

     

    Dutchy

     

    Hi Dutchy,

     

    That is not how it should work.

     

    What happens is that the plot pole will be generated in the world your client version of Epoch sees.  This new item is then sent to the server, asking the server to notify all the other clients looking at the same Epoch world that a new item now exists.  Then, based on set triggering events, the item will be written to the database.  The database is just used for persistence between server restarts and is not used for every time you use various items.  The copy of the world is modified in your computers memory and only updated to the DB every now and then to reduce network traffic and lag.

     

    So in order to assist, I will need to know a bit more.

     

    When you build a plot pole, does it appear ?.

    What message do you get if you try to build if it does appear ?.

     

    Any other information you could give would be good, step by step.

     

    Thanks

  8. Interesting for non-persistent objects.

     

    How would you suggest setting the starting fuel levels for all map based fuel containers ?.  Is there an easy way to do it ?.

     

    If the fuel levels are not persistent, is there any point setting fuel levels on restart for all map based fuel containers if the server is restarted every 4 hours or less ?.

     

    To my mind the only point in setting and tracking map based fuel containers is if they have a chance of getting fully emptied and need manual refilling (i.e. a fuel convoy) which then brings in other mission possibilities.

     

    I don't program for the original ARMA.  I program for ARMA II so do not need to worry about not having a persistent database backend and have to try and fake persistence or program without it.

  9. I see there are calls to FNC_GetPos which I have not found in the BIS functions list or anywhere else.  There is a ON_FNC_GetPos setup in the EvacChopper_init.sqf

     

    I suspect the FNC_GetPos should be ON_FNC_GetPos and due to the missmatch the _location variable is not being populated so the helipad has no location to be placed.

     

    I do not have the JAEM mod installed so anyone want to test ?.

     

    adding 

    DZEdebug = true;

    to the init.sqf file will allow more debug information which I would expect to throw an error relating to this.

     

    RB

  10. I got the script I was looking at in post from link working. Will experiment with it further in a few days once I got other stuff out of the way. Might end up removing all fuel tanks off the map and inserting them through the DB so I can attach the script directly to them as appose to a different object, but I need to learn this map editing first ><

     

    That would probably be the best way to go to do it properly but will involve a lot of work finding all the fuel tanks, removing them and putting persistant DB objects in their place.  You could then track fuel amount as you would any other vehicle but would have to set a starting capacity (usually set in the vehicle class files).  If these were in place then the fuel tanks could be used just like fuel trucks (non-movable of course).

     

    Would love to add the amended map to my Better Refuelling mod if you ever get round to doing it and are willing to share (with full credits to you of course).

  11. A plot for life should have no effect on this mod at all as they do not share any of the same resources.  I will have a quick look at the new  v 1.4 JAEM code to see if I can help OtterNas3 spot anything later today.

     

    Do note that if you are using JAEM v1.4 and you have a helipag from JAEM v1.3 then you may need to recreate it as the playerUID used to link the helipad to you mad have changed slightly depending on how OtterNas3 has leveraged my playerUID -> charID function and if you have any letters in your PlayerUID.

  12. The problem is that map fuel tanks are not persistent db objects but are map objects. These objects have no fields / variables in which to store things like full capacity AFAIK.

    I am working on a better refuelling script (see my sig for the link) and was looking around the same thing as you are wanting maybe with a refuelling convoy refilling the fuel tanks in a cycle or at request after paying.

  13.  

    "PlayerUID with Characters"

    A new check is implemented for these Players with the Arma2 anniversary edition.

    Like RimBlock wrote me in a PM these Players have characters in their PlayerUID and cause the Database entry just hold numeric it doesnt worked good for them.

     

    I tooked the function from RimBlock his "A Plot for life v1.1" and implemented it in the JAEM scripts so that should not be a problem anymore

    As i took this function from RimBlock his scripts i gave Credits to him here! Dont know who wrote it first if it not was RimBlock himself!

     

     

    The concept was first seen by me in the same sort of mod by WGC GeekGarage (as noted in my credits of )

    but I rewrote it from scratch to make it a lot more efficient and remove any dependency on extra third party scripts he was using.

     

    There are a number of potential limitations as noted in my thread and I hope to soon work on another mod which will completely remove them.  If the technique works (and it should) then it will make things a lot easier to tie items to playerUIDs and should be able to implement on just about all objects.

  14. I'm also seeing this.  I haven't started digging myself, it's not so annoying to make it a priority :)  However, the only thing I installed from this thread is that plot boundary action, since I had already converted to playerUID.

     

    Having taken a look on my own server, the "show plot area" does not easily disappear but it will disappear if you look at another object.  Maintain area is using the exact same method and also gets stuck if you do not look at another object.

     

    The remove object (i.e. block wall or doorway) disappears when you stop looking as the object but if you look from one object to another quickly then it will also stick.  This sometimes leads to removing a section of floor or wall next to the one you wanted to remove.

     

    The upgrade option from buildables seems to work much better than the others and quick looking from buildable object to another buildable switches the option accurately.  The upgrade menu item code checks the current item against another global variable of the "s_player_lastTarget" to see if the cursor target has changed since the last upgrade item was added.

     

    So, the current restriction that you need to look at anther object for the menu item to disappear and as it will take a fair amount of effort to improve that I am inclined at this point to leave it like that.  I plan to rewrite the whole playerUID for buildables function so would rather limit my work on this one to big(ish) bug fixes if any more are seen.

     

    If anyone wants to look at a more robust way of doing this then please feel free and if you want to make it available tne post it here and I will put it in the first post with full credits. 

  15. Ok, 

     

    So exactly where is it not working.  

    • It works fine multiple times until you die and then it will not work at all ?.  
    • Does it delete the heli evac marker ?. 
    • Are you able to remove the heli evac marker ?.
    • Is "evac_needRadio" in EvacChopper_init.sqf set to 0 or 1 ?.
    • Does the new character have a radio ?.
    • Is the option to call the ecav chopper in the new characters scroll wheel menu ?.
    • If you place the evac marker and then exit the game and login again doe sit still work ?.
    • Anything else strange happening ?.

     

    Another thought is that when you first login the script looks for evac points you own within 40,000 mtrs.  If you are further away it will not find them and it only checks at your first login.  What you can try is...

    • Die  ;) .
    • Login as a new character.
    • Move to where your previous character placed the heli evac point.
    • Logout.
    • Login (should be at the heli evac point).
    • Go somewhere and try to call an evac.

     

    That will prove if it is a range issue or not.

     

    Those questions may help me narrow down the issue without having to breakdown the entire set of scripts.

     

    Thanks.

  16. Anyone have "show plot boundary" staying after you use it whether you're looking at plot or not? I'm triple checking but I'm pretty sure I followed the instructions on that part correctly.

     

    Anyone else seeing this ?.

     

    The scroll wheel options can be a bit touchy sometimes and not refresh when they should especially if you have lots of stuff in the fn_selfactions.sqf or fn_damageactions.sqf files.

     

    I don't recall seeing this problem myself but if others are also seeing then I will have a dig and see what may be going on or how it could be improved.

     

    Thanks

    RB

  17. Ok Thanks for looking into it but it seems to now work but only until you die?

     

    Thanks

     

    I would imagine that is how it is meant to work ??.  How did it work before (I though it was not working) ?.

     

    It can, of course, be amended to work by relating the evac point only to the playerUID fairly easily.  I have PM's OtterNas3 regaring his JAEM script and if he has no more real interest in supporting or he is fine with it then I will look at doing that and putting out there as a seperate "JAEM for life" release (obviously with full credits to OtterNas3).  That way people can decide which way then want to run their servers (persistant to the playerUID or loose it all on character death).

     

    RB

  18. Yo dude I really want to use your Skript but the Dropbox link seems to be outdated can you update/fix it or is it just for me?

     

    The two posts above yours would indicate it is not only you.

     

    OtterNas3 is listed as being online in the last 24 hours so I have PM'd him regarding this.

     

    I also some understand people are experiencing issues with this mod.  I have found the solution to one problem with the evac not working due to a change BIS made after the release went live.  I will put it up here if OtterNas3 agrees but I think it is only fair to ask first as it is his mod and he may wish to fix it a different way (its his mod to support after all). 

     

    If anyone is desperate then they can PM me and I will privately direct them to the instructions or you can have a search about on the forums.

     

    Lets see what he comes back with.

  19. Last item from my quick check.

     

    CallEvacChopper.sqf

     

    Search for (should be line 34).

    _evacCallerUID = (getPlayerUID player);

    Change to 

    _evacCallerUID = [player] call convertPlayerUID;

    That should sort out any issues with playerUID -> object characterID conversions.

     

    Note: I see nothing so far that would be affected by my plot pole mod from this quick check.  This is an inherent issue with the evac chopper code.

     

    Let me know how it goes.  I will look a bit deeper if this does not sort the issue out.  I would also advise removing any current evac sites and remake them as they may not be setup correctly.

     

    If you check your character_data table and have no playerUIDs with letters then this will most likely not do anything.

×
×
  • Create New...