Jump to content

Kroenen

Member
  • Posts

    224
  • Joined

  • Last visited

Posts posted by Kroenen

  1. That is normal in Arma 3, when you do a marker on the map and somebody join the game, he will not see the marker, then the script must make a new marker if somebody joins the missions, don't know if it is possible or usefull.

    Wasn't there a workaround for this in Arma2? I seem to remember EMS had something that would refresh the markers when a new player joined.

  2. Install Instructions

     

     

    1) Pack the a3_epoch_server_zcp into a pbo and place it in the @epochive/addon folder of your epoch server.

     

    2) Add zcp.sqf to your mission

     

    3) Call zcp.sqf from init.sqf or anywhere u want :)

    execVM "zcp.sqf";
    
    
    

     

    u pack my folter to a pbo and place it next to the server PBO, do not call the init.sqf, it's a self booting system.

    ???

     

    Thats the opposite of what you say in the install guide

  3. That was good, is as intended, am looking at removing the spawn ability within a jammer radius, to be discussed, but leaving the ability to lure a sapper to anothers base. Someone in your team triggered a sapper to spawn and there is a very slim chance that will spawn a hive, then a random building is chosen so that was the perfect sapper wave :)

    Not sure I'm a big fan of that design. It makes the possibility of getting blown up completely randomly, and losing your entire base and vehicles, simply due to RNG.

     

    I'm all for sappers and sapper hives, but bearing in mind most servers will run pvp, this is just a little too much 'constant threat', especially since it essentially amounts to "at some point, you will be chosen at random to lose everything".

     

    Sappers, nor sapper hives should ever spawn 'ON' a player, or within the jammer range in my opinion.

     

    EDIT: Oh, and many people have said already, you don't need to do anything to spawn a sapper, they just appear at random.

  4. Exact same issue on our server. Have seen this on a number of vehicles, both land an air.

     

    Didn't check the rest, but did notice that following the restart, a heli that was damaged looked to be fully repaired, but still wouldn't fly (engine wouldn't start).

     

    EDIT: I noticed this with a Hatchback Sport. Same deal, crashed, and it repaired itself. I noticed on this particular vehicle, it also now seems to be able to do over 300km/h!!

     

    The heli that repaired itself but remained unflyable, I used admin to repair it and it was flyable again, so I'm wondering if the issue is confined to the Hatchbacks?

  5. I've been standing in the West trader for a while, and 4 sappers have come in and exploded near me. Never took any damage, so not sure what to say there.

     

    You're right about the spawning issue though of antagonists. Even with all 3 set at 0.03, they still spawn quite a lot even when just standing still not doing anything.

  6. OK, think I fixed it;

     

    On the first line of IgiLoadInit.sqf , it waits until it sees bis_fnc_init in the client RPT, which no longer seems to appear.Then it waits for time to be >0.  If you change it to bis_fnc_missionflow it seems to work again. 

     

    So, replace all of this;

    waituntil {!isnil "bis_fnc_init"};
    //if (isDedicated) exitwith {};
    //if (isServer) exitwith {};
    //waitUntil { !(isNull player) };
    waitUntil { time > 0 };
    

    With this;

    waituntil {!isnil "bis_fnc_missionflow"};
    

    And it seems to work.

     

    DISCLAIMER - I'm far from an experienced coder, and have no idea if this is the 'correct' way to do this, but it seems to work fine now.

     

    Hope that helps y'all :D

  7. I added the following to my scripts.txt on line 10 (relates to #9), and it seems to have fixed it for me. It's worthwhile looking at the tutorial on these forums regarding BE filters. Very helpful!

     

    This should be the line that starts 7 setvelocity

    !"_smokeg setVelocity _Gvel;" != "okeg setVectorUp (_Gvel call BIS_fnc_unitVector);"
    
  8. All these mumbo jumbo solutions which do not make any sense.... Point it north... make sure it is spawned... get into passenger seat first yada yada. Just accept the fact that they randomly explode. There is no way to test it. You can not have same conditions for the tests as you do not know what is affecting the explosions. Just because it doesn't explode when you do something doesn't mean it is a solution as you do NOT know what is causing it. Maybe the reason it doesn't explode is related to the amount of krypto you have in ATM? If it is equal number, it won't explode after reset, if odd - boom.

     

    I can have entire garage full of cars pointing in any directions that I imagine and they will be fine for 99 days and then I get in the 100th day and it explodes. Oh you say point it north? hahaha. Wow. Snake oil not a solution. As long as there is no idea what's causing it, forget about solutions.

     

    The real answer now is to just not keep anything inside your vehicles and everytime you enter them after restart expect a boom. Will save you a lot of time,

    As raaste pointed out, the vehicles falling through floors can be worked around by making sure it's been created AFTER the floor it sits on. The reason this works is because the database loads objects in order, so the floor loads 1st, then the vehicle. This has been tested, and works, and is far from being snake oil. I see your point about the pointing north, but again, I can see reasons that would work too. DB loads an object, THEN looks at it's orientation last. Detects it's already at 0 rotation (ie: points north), so doesn't need to spin it around.

     

    Your obvious lack of willingness to help pin down the problem and simply 'accept it' makes me wonder if you might work for EA ;)

  9.  

    Testing is going well with only a few critical bugs reported so far, a new server build has been pushed to our test servers that address the following issues.

     
    Server Side Changelog 0.3.0.1 b4:
    [Fixed] Crypto reset bug on death or fresh character.
    [Fixed] Server side vehicle immunity for 1 minute after initial server startup, should prevent accidental damage on spawn.

    Fingers crossed :D

  10. Had to resurrect this one a little. Over time we've noticed a few other 'explosive anomalies'. Sometimes it seems as a vehicle comes into view from a distance, you see it spin as if it's just loaded its rotation, then explode. Also freshly spawned vehicles seemingly stuck in the ground is quite prevalent (seen it on 4 servers now).

     

    Leaving enough room for vehicles to spin 360 makes a lot of sense, but we're seeing this happen to vehicles sitting in open ground too. In contrast, I've had an Ifrit parked 2 feet away from a wall for about 3 weeks now and no problems!

  11. There's something about the instructions I don't understand:

     

     

    I don't understand. My init.sqf has execVM "\z\addons\dayz_code\system\server_monitor.sqf"; and I make changes to the server's dayz_server\system\server_monitor.sqf for other mods. Do I need to change that line so it has dayz_server instead of dayz_code? If so, why?

    Did you get an answer to this Zed? I've just gotten to the same stage of the installation and wondering why as well.

     

    I have DZMS and WAI which also puts lines into dayz_server\system\server_monitor.sqf, and they seem to be working fine. This suggests to me that the dayz_server version is called from elsewhere?

     

    EDIT:

    Never mind, I found the answer. The dayz_code\system\server_monitor.sqf has the following;

    waitUntil{!isnil "bis_fnc_init"};
    execVM "\z\addons\dayz_server\system\server_monitor.sqf";
    

    So I guess you can just skip that step of the install.

×
×
  • Create New...