Jump to content

iben

Member
  • Posts

    100
  • Joined

  • Last visited

  • Days Won

    6

Posts posted by iben

  1. Hello guys,

    I've decided to leave this community. And that's why I'd like to say two things:

    1. Thank you guys for all your work for community. It was honor to be here! I wish you the best in your life...
    2. All my repos from Github are available. If you feel you would like to take ownership and take care of them, just let me know.
      I'll be happy to do it. All repos stays public for couple weeks, after that they will be removed. (Edit: Now available at @DAmNRelentless Github account)
      We are talking about:

    Enjoy game, stay cool!

    Cheers...
    iben

  2. 1 hour ago, _Lance_ said:

    Can this be made to work on DZMS missions as well?

    Hi @_Lance_,
    Short answer: autoclaim idea could be implemented into DZMS with additional coding. If more server owners will ask for such implementation, I can do it.

    My small advice outside question scope, if I may, pick only one mission system - just one system is already "heavy enough" with huge impact to server performace (but I'm pretty sure you know this well...).

    Cheers...

  3. 1 hour ago, l1nkrx7 said:

    its all active in customsettings heres my rpt load information

    
    20:20:42 "WAI: AI Config File Loaded"
    20:20:42 "WAI: Custom Config File Loaded"
    20:20:42 "DEBUG: Spawning a care package (Misc_cargo_cont_net1) at [3904.87,8384.17,0] with 3 items."
    20:20:42 "WAI: Initialising missions"
    20:20:42 "=== [IBEN WAI AUTOCLAIM ADDON, v1.0] || DEBUG [customsettings.sqf] >> Addon relative root >> [z\addons\dayz_server\WAI]"
    20:20:43 "WAI: AI Monitor Started"

    as can see its using wait mission init not iwac mission init or it would state: diag_log "WAI: Initialising missions with IBEN AUTOCLAIM ADDON";

    From above LOG, reason is wrong loading order. If you want to fix this, provide what I asked you in my last post (mainly server pbo file).
    There could be mutliple reasons why it's happening. It's nonsense to speculate - let me look to source, save some time.

    Before you do, try to use in your "WAI/init.sqf" (at the bottom):

      if ((preProcessFileLineNumbers ("\z\addons\dayz_server\WAI\customsettings.sqf")) != "") then {
        ExecVM "\z\addons\dayz_server\WAI\customsettings.sqf";
        waitUntil {WAIcustomConfigloaded}; // add this one
        diag_log "WAI: Custom Config File Loaded";
      };

    Cheers...

  4. 1 hour ago, Dr.Killmore said:

    YES... thank you so much my config was on Veteran autoSpot=0; now I changed it to Regular with veteran settings and autoSpot = 1; and all traders work without zoom you are a star thanks again :)

    I can't say thank you enough cheers...

    Your resume is going to help a lot of people, I guess! Thx for coming back with result...
    Cheers...

  5. On 2. 11. 2017 at 2:03 PM, Dr.Killmore said:

    Hello,

    Does anyone know why WAI is stopping some of the trader menu scroll options from working on some traders I have to right click/zoom on them to get an option for the trader menu. I tested it on a default server no mods and my traders was working correctly but once WAI is installed the problem begins.

    thanks.

    @Dr.Killmore, and other, maybe this will help:

    When you experience situation at trader that you have to zoom on trader - which happens mostly when you customized them - this situation IMO is not bug at all. Let me explain.
    fn_selfAction is using command 'cursorTarget'. It's in a nature of this command return only targets that are known to player. Let me cite:
     

    "While friendly targets are usually known to the player, enemy targets can be totally unknown,
    especially if "auto-spotting" (or sometimes called "auto-reporting") is switched off."

    Now I will skip some further techicalities and go directly to solution, that might be helpfull:
    So what I would to do is check your user config if "auto-spotting" is set to 1. If you are using veteran level, not sure if you can change it.
    So, you can customize your "regular" level, or use "veteran" level and consider zoom on trader as normal behavior - by zooming you are revealing target to be known to player.
    Recently I helped someone with this kind of problem and above solution worked. If not, probably "reveal" command is the key...

    Cheers...

  6. ===

    Credits:

    All credit belongs to all authors of used source files:

    ===

    Download v1.3.1 [Last update: 2018-01-16]

    ===

    Introduction:

    ... once upon a time, *mr. yeahBUT* and *mr. no_name* chatting:

    ---

    Q: mr. yeahBUT
    IWAC? OMG, what is it?

    A: mr. no_name
    Well, it's Autoclaim addon for WAI mission system.

    ---

    Q: mr. yeahBUT
    ...yeah, but is it usefull? What it can do?

    A: mr. no_name
    Not sure about the first question part... but it could be.
    If one of your server rules says somenthing like: "Player has to claim mission in sidechat and mark mission on map with name", well, this addon is just for you.
    It's fully automatic, which means - no more sentences like: "I forgot...", "Who is doing mission xy?", "Could you please remove your marker once mission is finished?" etc.
    This little addon will make all the job for you and your players.

    ---

    Q: mr. yeahBUT
    pffff... I have PVP server. Totally useless!

    A: mr. no_name
    Probably yes... Do you wanna hear more?

    ---

    Q: mr. yeahBUT
    hmmm.. not really, but I have nothing to do right now, so continue...

    A: mr. no_name
    ...OK my friend. I have certainly nothing to do either, so I will... :) What's your question?

    ---

    Q: mr. yeahBUT
    ok.. let's start with somenthing I can picture in my mind. Do you have any screenshot so I can see it in action?

    A: mr. no_name
    yeah, sure...

    1C582DD3D88465973FF3122C02977DC57F34634D

    ---

    Q: mr. yeahBUT
    What is that red circle around mission?

    A: mr. no_name
    This is somenthing I call it "claiming zone". You can configure it using these variables:

    iben_wai_ACzoneActivate = true; // Turn claiming border ON/OFF
    iben_wai_ACzoneMarkerColor = "ColorRed"; // Border color
    iben_wai_ACdistance = 1300; // Distance from mission center to claiming border

    ---

    Q: mr. yeahBUT
    hm.. 1300m? It's a little bit too much. Should be much shorter distance.

    A: mr. no_name
    It's completely up to you. If you want to be loved by your snipers, set it to 400m and set AI skills to max - no kidding, I experienced this setup already :))
    Also remember - there is somenthing called timeout distance in WAI - you can search variable `wai_timeout_distance` in WAI config.
    If `wai_timeout_distance` < `iben_wai_ACdistance`, mission can dissapear in front of player's face (which doesn't mean it's a bad thing...)

    ---

    Q: mr. yeahBUT
    Well, it's too bad. Can you imagine what happen if two or three missions spawns close to each other? You think it's not a problem player could claim multiple missions?

    A: mr. no_name
    How should I answer this question...? Let's start with this: When you try to setup any system, you should think about it.
    I mean - there are variables `wai_avoid_missions` and `wai_avoid_traders` in WAI config for example.
    Just use bellow formulas and you should prevent mission (mission claim zones) overlapping:

    wai_avoid_missions = ((iben_wai_ACdistance * 2) + 500);
    wai_avoid_traders = (iben_wai_ACdistance + 200 + 500);
    // ... also see picture bellow:

    01A930D625193C4A3D72C2368C505943870BC755

    ---

    Q: mr. yeahBUT
    That's nice, but I've already experienced mission placement is not perfect... there is a chance player will claim two missions!

    A: mr. no_name
    In fact, it's not possible. If player is already 'claimer', he is registered and system doesn't allow him to claim multiple times (you can see it in the video at the bottom).

    ---

    Q: mr. yeahBUT
    Alright... what's that flag with name? I don't want to expose player name!

    A: mr. no_name
    It's up to you again. You can configure all about player marker using these variables:

    iben_wai_ACshowNames = true; // If false, text = "Claimed by a player [realtime status info]"
    iben_wai_ACmarkerType = "hd_flag";
    iben_wai_ACmarkerColor = "ColorBlack";

    ---

    Q: mr. yeahBUT
    ok... yeah, but it's too bad to expose player by setting marker on his position...

    A: mr. no_name
    You are not exposing his position. Marker is created in random spot within given range. You can adjust it by setting variable:

    iben_wai_ACmarkerRange = 400;

    ---

    Q: mr. yeahBUT
    cool... so why not create flag object to be visible close mission? Cool idea, huh?

    A: mr. no_name
    yeah, sure it is :) You can use these variables:

    iben_wai_ACcreateFlagOjb = true;
    iben_wai_ACmarkerFlagClass = "FlagCarrierINDFOR_EP1";
    // ... see the picture bellow:

    948AE6E3D0B16880C657A1A47FF9AE54DB45E2DF

    ---

    Q: mr. yeahBUT
    How will player know about claiming is happening?

    A: mr. no_name
    You can enable message system and let player know. Just use bellow variable and install client side files: 

    iben_wai_ACplayerMsg = true;

    ---

    Q: mr. yeahBUT
    Yeah, but... still. Why should all players force to read useless msg that are not about them?
    Also... that's server resources waste to broadcoast so many msgs...!

    A: mr. no_name
    Actually msg is private. Only player involved is informed and can see the msg.

    ---

    Q: mr. yeahBUT
    Yeah... but there is couple more troubles. For example: Mission just spawn close to my position or I'm just passing by location.
    I don't want to be a part of mission fight, but still... I'm in zone... That's not good.

    A: mr. no_name
    You can use bellow variable and set it to some reasonable value in seconds.
    That gives passing by players enough time to decide to stay or leave claiming area.

    iben_wai_ACsafeClaimDelay = 60;

    ---

    Q: mr. yeahBUT
    Too many troubles... what about players in bases?

    A: mr. no_name
    Just make your decision if you want to allow players fight missions from base or not. You can use following variables.
    This way you can force autoclaim system to ignore these players.

    iben_wai_ACplotRestriction = true;
    iben_wai_ACplotRange = 30; // If 'iben_wai_ACplotRestriction' is true, what distance from plotpole is not allowed?

    ---

    Q: mr. yeahBUT
    Hm, but what if player claimed the mission and dies, loses connection etc. What then, ha...?

    A: mr. no_name
    As you can see at the above picture, there is marker with player name (or anonymous name) and so called `realtime status`.
    If player is alive and fighting inside claiming zone, status is `Active`. If player is gone - timeout is fired.
    That means, system will wait given time for claimer return. If timeout runs off, mission is free for claiming.
    You can set some reasonable time for timeout in seconds:

    iben_wai_ACtimeout = 300;

    ---

    Q: mr. yeahBUT
    What about my admins? I don't want them to claim missions just because they are helping inside zone...

    A: mr. no_name
    Yeah, got it. You can exclude your admins from system:

    iben_wai_ACexcludeAdmins = true;
    iben_wai_ACadmins = ["0","0"]; // List your admins UID's

    ---

    Q: mr. yeahBUT
    Wait! I'm using moving missions like 'patrol'. It's a nonsense to use autoclaim for that kind of missions!

    A: mr. no_name
    Agree. If you have any kind of moving missions, or custom missions you want to be free for all, just exclude them:

    iben_wai_ACexcludedTypes = ["patrol"];

    ---

    Q: mr. yeahBUT
    Ok then. So... I have couple more minutes before my favourite movie starts. So last a few questions:
    I believe you will face problems in such scenarios like: multiple players in the same time in the zone - who will be first?
    What about other players? And what about player or better players in vehicle?
    You will not be able to sort them out and it's gonna be chaos!

    A: mr. no_name
    Well, I made the best I could in given time and space. I don't want to go too deep, but imagin autoclaim system as somenthing like simple `memory buffer`.
    This buffer is **(a)** able to recognize all players in area (including all players inside vehicles); **(b)** is able to sort them out by distance.
    It's very small probability two players will reach the same distance in the same time - the only exception crossed my mind are players
    n the same vehicle - they share the same distance. But system is able to recognize them and sort them from driver to cargo.
    But anyway, system is able to handle these scenarios pretty well (at least I hope so according to test results);
    **(c)** System works in layers - from register list, wait list to claim list. Each layer is equiped by self-cleaning mechanism,
    so each list is real image of status in claiming zone. (self-cleaning means, once player leave area etc., he is kicked from list
    and next player in list takes his place - there are no `dead souls in list`).

    ---

    Q: mr. yeahBUT
    OK... here we go. So another loop for WAI. It's already server performace killer as it is...!

    A: mr. no_name
    Hm... good point! And no, we are not creating any extra loop (not single one...). We are using already existing loops -
    and we are using these loops only and only if it's reasonable and exiting them immediately if condition isn't met.
    According to couple weeks testing on populated server with cca 20 players, no FPS drop was recognized.
    BTW: you can add some debug logs to loop critical points and see the result.

    ---

    Q: mr. yeahBUT
    ...yeah, but I can imagine how installation is gonna be difficult...

    A: mr. no_name
    Actually, it's not. Visit this github repo and clone or download files. Follow repo structure and merge it with your server/client files.

    ---

    Q: mr. yeahBUT
    That's all you can say about installation??? Are you serious??

    A: mr. no_name
    No and yes. One more thing - addon is designed the way so you don't need to touch any of WAI core files (except a few lines in init).
    If you will follow repo structure, you can quickly switch between default WAI files and addon files by setting bellow variable to true/false.

    iben_wai_ACuseAddon = true;
    // :: WARNING > If you don't know what I mean by "merge files" at this momment,
    // :: you should probably wait a little bit and learn, before you start to play with (especially) server-side files.

    ---

    Q: mr. yeahBUT
    Hmmm... my movie has just started... have to go now. And BTW... your English sucks... and this addon too... bye...

    A: mr. no_name
    :( ... I know... bye...

    ===

    Later in time...

    ===

    Q: mr. yeahBUT
    Hey! IWAC is now part of WAI by default?

    A: mr. no_name
    Yes, it is. Since v1.2. It's updated for Epoch 1.0.6.2...

    ---

    Q: mr. yeahBUT
    I don't get it... Seems v1.3.1 is out and it's not the same version as WAI has inside the package. What does it mean?

    A: mr. no_name
    Well, it's just a little improvement. Couple days ago several people made a fix for "mission overlapping". We decided to stick with our approach.
     If you update to v1.3.1, you will get 2 new options in your 'customsettings.sqf' file (see bellow + detailed info in 'customsettings.sqf'_).

    Now, what is important:

    • 'iben_wai_ACcoordProtectorTimer' gvar means:
      "If you give me any value > 0 in seconds, I'm gonna protect your just finished mission area against new mission spawn for given time."
    • Protection is processed only if:
      • valid spot for new mission was already found;
      • there is at least 1 item in 'iben_wai_ACprotectedCoord' array
        (that means, at least one mission was completed and coordinates has to be protected agains new mission spawn).
    • If you decide to update and you don't want use this fix, just set 'iben_wai_ACcoordProtectorTimer' value to 0.
      Default position fnc will be used with default WAI fix (note: if you've already updated your WAI core files).
    iben_wai_ACcoordProtectorTimer = 300; // @since v1.3
    
    if (iben_wai_ACdevmode) then {
      iben_waiACfindPosLimiter = 999;     // @since v1.3
    };
    
    // :: If iben_wai_ACcoordProtectorTimer > 0 && iben_wai_ACdevmode is true,
    // :: you will see in your server RPT somenthing like that:
    
    // 19:14:07 "=== [IBEN WAI AUTOCLAIM ADDON, v1.3] || DEBUG [find_position.sqf] >> 'iben_wai_ACcoordProtectorTimer' active (300s) >> Initialising custom position FNC for mission coord protection..."
    // 19:14:07 "=== [IBEN WAI AUTOCLAIM ADDON, v1.3] || DEBUG [IBEN_fnc_AC.sqf] >> Currently protected missions coordinates (iben_wai_ACprotectedCoord) >> [[561.226,[12890.3,11228.4,0.0142517],"MainHero1"]]"
    // 19:14:07 "=== [IBEN WAI AUTOCLAIM ADDON, v1.3] || DEBUG [find_position.sqf] >> Spot found. Checking if spot is in protected coordinates >> iben_wai_ACprotectedCoord >> [[561.226,[12890.3,11228.4,0.0142517],"MainHero1"]]"
    // 19:14:07 "=== [IBEN WAI AUTOCLAIM ADDON, v1.3] || DEBUG [find_position.sqf] >> Loop complete valid position >> [6129.23,8784.35,0] >> in 1/999 attempts"

    ---

    The end.

    ===

    Showcase:

    ===

    IWAC - private server msgs, map markers, status, respawn:

    ===

    ===

    IWAC - multiple claiming protection, exclude plotpole area option:

    ===

    ===

    That's all I've got... enjoy, have fun...
    Cheers...

    ===

  7. 1 hour ago, juandayz said:

    @iben the new version recognize others players in mission zone and punish if they not leave the area¿?¿:blink: Pretty cool adition!!!

    Hi @juandayz,
    thx for asking :) Nope mate, let me explain, what you can see at the picture. When testing, I'm creating simulated mission zones on the fly. Because I'm alone on my dev server, you can imagine, how dificult is develop addon like autoclaim with no other players in :)))) So, I simulating vehicles as players... in search alg. I added part, when (in limited range) my specific vehicles (sim. player) is found, this vehicle is pair with specific static UID (sim. player UID). This way are ID's static so I can work with them safely. Because object name is so long, I translate it to display name (for debug msgs on the screen). Well that situation above happened before I decided pair ID's to certain types of veh. So that agent could trigger claiming mechanism :) Msg you can see is the first part - it's a part of dynamic memory buffer (see bellow) - checking for 'player' and gives info about time when player will be included into selection for claiming (because player could just passing by zone...).

    Now back to your question... punish? Of course not... if more players in the range, there is somenthing like dynamic memory buffer with auto self-clean ability (meaning it's always remembering current players in the range). That buffer has some rules helping him decide, who is first, who is next, who can, who cannot etc....

    Cheers...

  8. Hi guys...
    @DAKA,

    first version of autoclaim system was done 10 days ago.
    Since that time it's running on live populated server as testing sample.


    Currently I'm working on upgraded version which will include some findings from the test. So stay tuned for couple next more days, public release is on the way :)
    This is picture from older version - in two days new more advanced version will be ready for test run...

     

    PS: In case, yes, passing players through mission zone - plotpoles inside zone - who will be first if... - what happen if claimer dies etc - all is considered :)

    Cheers...

    ===

    As promised, making public solution for mission autoclaim. If anyone interested, download source files from github.

  9. Currently working on autoclaim system for AI missions. First version already succesfully running on populated server for some time, so having fun with further improvements befor public release.
    OK, just created simulated mission zone to start testing, when suddenly... totally unexpected agent comes...

    E6AEF4544E40654D96094D558BC9219F78FBEB5B

    So tell me... isn't dev work fun? :)

    Cheers...

     

     

     

     

     

     

     

     

     

     

  10. 7 hours ago, Angelone said:

    i can be a little rude when people like this guy just sit on these forums and talk alot of useless crap it would be better if they didn't reply at all,

    but about the side chat thingy it shouldn't freeze you if chat is open because you cant speak while chat is open that's why its a glitch and should be changed

    @lwbuk, thanks good you are just sitting on this forum and talk alot of useless crap! Your useless crap helps tons and tons guys here and people like you are the Gold for this forum.
    For one little post like from this guy does exist houndred thanks posts from users that understand, how to ask and receive answers from experienced scripters... Keep up your good work... !
    Cheers...

  11. I can feel huge amount of patience and time spending with this very good artwork! Thx for this. Aligning objects, placing... this requires lots of work :)

    It's amazing, thumbs up :)

    PS: When you step further, remember... sometimes less objects is more for game. Keep you perfect skills and gain a little more game perspective. Result will be outstandig!

    Cheers...

  12. On 29. 6. 2017 at 5:11 AM, BigEgg said:

    I would recommend using this method, but also making sure to add a uiSleep, as a continuous loop will cause some lag. You also cannot define the count of playable units before the waitUntil, as it sets the variable to a number, therefore the value will never be true as the amount will always show as the number of players that were on when the variable was set.

     

    The correct way would be:

    
    private "_neededAmount";
    
    _neededAmount = 10;
    waitUntil {uiSleep 5; count playableUnits > _neededAmount};

     

     

    Apology... I was commenting older stuff, not in current context...

  13. Hello guys,

    ...just released update to v1.2 (see changelog above)

    ===

    Main headlines:
    Thanks to great cooperation with @salival we managed make paint vehicles script compatible with Virtual garage and Key vehicle changer (VKC).
    That means for exmaple:

    • no more recoloring delay (cca 5sec) when vehicle was spawned from virtual garage
    • no more losing colors when player changed key of colored vehicle

    If you have paint vehicle script installed and along with virtual garage and VKC, you should definitely update all scripts to the latest version for better player experience.

    ===

    Paint vehicles script v1.2 you can download from here.

    ===

    Check updated version of scripts in action:

    ===

    Cheers... have fun!

     

  14. On 5. 7. 2017 at 2:46 AM, Hooty said:

    Just installed working great for me.  After pulling vehicles out of garage it takes like 5 seconds for the paint to come back, no biggie. Great Work easy install instructions, thanks for showing all the paint code for easy merging.

    Hi @Hooty,

    I heard about this problem a lot, so I finally looked into virtual garage source code.
    Problem is serverside file for spawning vehicle, that tries to recover object textures by statement stored using setVehicleInit.
    Not sure which VG version (salival, duke) do you use, but if there is that kind of problem, reason is still the same...it's common scenario to miss process init commands

    Fortunately here is easy fix that should make things right (example based on @salival VG version): 

    1. Go to server folder and find server_spawnVehicle.sqf file (probably in server compiles folder)
    2. Find part where script works with 'colours'
    3. Bellow that just put processInitCommands;

    ... like that:

    	// server_spawnVehicle file (server folder)
    
    	// [...]
    	if (_colour != "0") then {
    		_object setVariable ["Colour",_colour,true];
    		_clrinit = format ["#(argb,8,8,3)color(%1)",_colour];
    		_object setVehicleInit "this setObjectTexture [0,"+str _clrinit+"];";
    	};
    
    	if (_colour2 != "0") then {			
    		_object setVariable ["Colour2",_colour2,true];
    		_clrinit2 = format ["#(argb,8,8,3)color(%1)",_colour2];
    		_object setVehicleInit "this setObjectTexture [1,"+str _clrinit2+"];";
    	};
    
        processInitCommands; //@update here
    	// [...] rest of code

    This special command will process statements stored using setVehicleInit and you start getting your vehicles colored immediately without delay when you spawn them from garage.
    I've already sent fix to salival and he commited the fix to source code.

    Hope it helps for better player experience,

    Cheers...

  15. 12 hours ago, SKS.Goliath said:

    How can you adjust this ?

    Hello,

    the flexible way IMO (for universal usage in your dev work) is to adapt remote msg script from ZSC and apply it wherever you need. This way you can use multiple types of remote msgs (private, global, hint, titleCut, titleText, dayz_rollingMessages and dynamic text).
    For example for WAI you need to open "mission_winorfail.sqf" file and look for:

    // mission start
    if (wai_radio_announce) then {
      RemoteMessage = ["radio","[RADIO] " + _msgstart];
      publicVariable "RemoteMessage";
    } // ...
    
    // mission win
    if (wai_radio_announce) then {
      RemoteMessage = ["radio","[RADIO] " + _msgwin];
      publicVariable "RemoteMessage";
    } // ...
    
    // mission fail
    if (wai_radio_announce) then {
      RemoteMessage = ["radio","[RADIO] " + _msglose];
      publicVariable "RemoteMessage";
    } // ...

    RemoteMessage public EH (resp. remote msg fnc) takes 2 parameters: (1) type of msg; (2) msg text. If you want to change default WAI settings for msgs, just do:

    // for example for mission fail
    if (wai_radio_announce) then {
      RemoteMessage = ["rollingMessages", "Any message text"];
      publicVariable "RemoteMessage";
    } // ...

    If you will use the file from ZSC (for link look above...), stay focused - for some types of msgs second parameter '_message' is an array (private, dynamic text)!
    You can adjust remote msgs file or Wai winorfail file to fit your needs (the same is valid for example for DZAI - but you will need to do more work, because you need to unify remote msg public EH's).

    Hope it helps,

    PS: Check this link from this forum.

    Cheers

     

  16. Hello guys,

    @vbawol - and other guys from epoch team ... and guys releasing addons:

    I cannot express how I'm greatfull for your hard work. As a developer I can understand the cost of that work ... you shared your skills, free time, money, heart...
    Let me tell you something:

    Epoch is not dead and never be!
    Why? Because you created something wonderfull for many kids - kids that started coding the most effective way - write some code - see the result immediately - in your favourite game.
    That means, you helped a significant amount of people to start something new and grow as a developer-beginner. And you will never know - someday someone
    asks famous developer - "How did you start coding?" - and he answer - "Well, once I played Epoch mod and ...".

    And there is more what your work means for others... Thank you guys from deep of my heart! You guys are my heroes...

    Cheers

  17. 4 hours ago, kingpapawawa said:

    took a lot of trial and error, i think mostly because you have defined things that already exist in zsc and i didnt see where you instructed me to remove any current defines.

    I'm very sory for your troubles. Thx for sharing your feelings.
    (... just in case you're asking for help - here is one: just use repo files as it is and add things they're not there (and follow pattern how to add extra files),
    or just do not add any files into your pack, that's already there. Try to understand, repo for this script is not build common way as it's stated at least in the first post.
    If you know, how to work with server/client files as server owner, that should not be a problem. If you do not, don't hesitate to ask specific question here on forum - 
    there are a lot of experienced awesome guys willing to help)

    Cheers

  18. 9 minutes ago, JakeQue said:

    I've never had to do that before for a plugin, so I think you could maybe break that down for future reference and make people aware that in those files there's client / server / both sections make sure you paste these bits under each section relevant. 

    Understood, there was a discussion about this before, you can check it out here.
    For rest of your comment - yeah, sometimes we need to be creative when mergin couple plugins code. But as I said, feeling good you made it working and share your experience her for others. Thx a lot for that...

×
×
  • Create New...