Jump to content

lorneagle

Member
  • Posts

    56
  • Joined

  • Last visited

Reputation Activity

  1. Like
    lorneagle got a reaction from mikeyoh in Multiplayer coding questions   
    Soooo since noone answered this I had to figure it out myself. And like a keener, I answer my own question. Jjust for reference if someone searches for this in the future
     
    First you have to understand what data is stored on the server and what is stored on the client.
     
    The server manages all map assets, such as cabinets and the loot in it, zombie corpses on the ground, camp fires, windows, doors, burned ground and so on. As your character moves around the map your client will constantly request map data from the server. The smallest map entity is a GridSquare and it contains all the object that were just mentioned. Whenever you want to interact with something on the server, like turning on a camp fire, you have to communicate with the server.
     
    The client stores all the character assets such as his weapon, inventory, XP, skills, condition and so on. So when you move stuff around in your bags you will not communicate with the server. As soon as you drop something on the ground however, the server is notified.
     
    The folders
    Zomboid mods have three different  lua folders:
    client  shared server These folder's purpose is code organisation. Simply putting code into server doesn't mean it is executed on the server and not on the client. In single player for example all code is executed no matter in which folder you placed it. 
     
    So what determines if code is executed on the server or client?
     
    Usually you hook your code into the existing code using Events:
    ZXBmulti = {}--Event handlerZXBmulti.test = function() print("I was called");end-- Register event handlerEvents.OnWeaponSwing.Add(ZXBmulti.test); Now in SP, all these events are fire locally BUT in multiplayer some Events are only fired on the client side while others are only fired on the server. Consequently the event hook you chose determines where your code is executed.
     
    Example:
    OnWeaponSwing - Is executed on the client
    OnWeaponHitCharacter - Is executed on the server So the folders are simply to organize your code, typically
     
    client           Put all your UI logic like menus here
    shared           Put everything else here
    server           Put all your server logic like, what happens when a zombie is hit, here
     
    Execute code only if you are client or server or if its a local SP game
     
    As I mentioned before: When you play a local game all code is always executed because all events are fired locally.
    This can cause problems because you want some of your code to only be executed if you are the client in a multiplayer game, or when you act as a server. To solve this problem IS gave us three helpers:
     
    isClient()
     
    This returns true if you are the client in a multiplayer game, but false in a local game or if you are the server
     
    isServer()
     
    This returns true if you are the server in a multiplayer game, but false if you are client or local game
     
    getWorld():getGameMode() == "Multiplayer"
     
    This returns true if you are in a ... (guess )
     
    Client Server communication
     
    The basic pattern is to use
     
    sendClientCommand to send a message to the server
    sendServerCommand to send a message to the client
     
    These commands will trigger an event on the other side which you can hook you code into
    OnClientCommand - is triggered on server side when a client command is sent OnServerCommand - is triggered on client side when a server command is sent Example Client to Server
     
    Client
    if isClient() then sendClientCommand(char, "myModule", "myMethod", {foo = "bar", difficulty= "easyPZ"}); end Server:
    MyClientCommands.OnClientCommand = function(module, command, player, args) if not isServer() then return end if module ~= "myModule" then return end; if command == "myMethod" then --dostuff endendEvents.OnClientCommand.Add(MyClientCommands.OnClientCommand);For server to client you follow the same pattern but use sendServerCommand an OnServerCommand respectively.
     
    Moddata
     
    Moddata is a great sink for any data you want to store with an object. Let's say you want to save the currently loaded ammo type with a weapon you'd do something like:
    weapon:getModData().loadedAmmo = "NuclearLaserRailProjectile"However you must be aware that if you modify the moddata of an object client side, it is not modified server side. IS added methods to sync client/server object like sendObjectChange or transmitModData but these methods are not universally supported by every class.
    So whenever you modify moddata on client side and rely on it on server side you will have to send a client command and modify it on the server.
     
     
    I hope this helps someone understand how to get their mod multiplayer ready in the future
  2. Pie
    lorneagle got a reaction from sirius in Multiplayer coding questions   
    Soooo since noone answered this I had to figure it out myself. And like a keener, I answer my own question. Jjust for reference if someone searches for this in the future
     
    First you have to understand what data is stored on the server and what is stored on the client.
     
    The server manages all map assets, such as cabinets and the loot in it, zombie corpses on the ground, camp fires, windows, doors, burned ground and so on. As your character moves around the map your client will constantly request map data from the server. The smallest map entity is a GridSquare and it contains all the object that were just mentioned. Whenever you want to interact with something on the server, like turning on a camp fire, you have to communicate with the server.
     
    The client stores all the character assets such as his weapon, inventory, XP, skills, condition and so on. So when you move stuff around in your bags you will not communicate with the server. As soon as you drop something on the ground however, the server is notified.
     
    The folders
    Zomboid mods have three different  lua folders:
    client  shared server These folder's purpose is code organisation. Simply putting code into server doesn't mean it is executed on the server and not on the client. In single player for example all code is executed no matter in which folder you placed it. 
     
    So what determines if code is executed on the server or client?
     
    Usually you hook your code into the existing code using Events:
    ZXBmulti = {}--Event handlerZXBmulti.test = function() print("I was called");end-- Register event handlerEvents.OnWeaponSwing.Add(ZXBmulti.test); Now in SP, all these events are fire locally BUT in multiplayer some Events are only fired on the client side while others are only fired on the server. Consequently the event hook you chose determines where your code is executed.
     
    Example:
    OnWeaponSwing - Is executed on the client
    OnWeaponHitCharacter - Is executed on the server So the folders are simply to organize your code, typically
     
    client           Put all your UI logic like menus here
    shared           Put everything else here
    server           Put all your server logic like, what happens when a zombie is hit, here
     
    Execute code only if you are client or server or if its a local SP game
     
    As I mentioned before: When you play a local game all code is always executed because all events are fired locally.
    This can cause problems because you want some of your code to only be executed if you are the client in a multiplayer game, or when you act as a server. To solve this problem IS gave us three helpers:
     
    isClient()
     
    This returns true if you are the client in a multiplayer game, but false in a local game or if you are the server
     
    isServer()
     
    This returns true if you are the server in a multiplayer game, but false if you are client or local game
     
    getWorld():getGameMode() == "Multiplayer"
     
    This returns true if you are in a ... (guess )
     
    Client Server communication
     
    The basic pattern is to use
     
    sendClientCommand to send a message to the server
    sendServerCommand to send a message to the client
     
    These commands will trigger an event on the other side which you can hook you code into
    OnClientCommand - is triggered on server side when a client command is sent OnServerCommand - is triggered on client side when a server command is sent Example Client to Server
     
    Client
    if isClient() then sendClientCommand(char, "myModule", "myMethod", {foo = "bar", difficulty= "easyPZ"}); end Server:
    MyClientCommands.OnClientCommand = function(module, command, player, args) if not isServer() then return end if module ~= "myModule" then return end; if command == "myMethod" then --dostuff endendEvents.OnClientCommand.Add(MyClientCommands.OnClientCommand);For server to client you follow the same pattern but use sendServerCommand an OnServerCommand respectively.
     
    Moddata
     
    Moddata is a great sink for any data you want to store with an object. Let's say you want to save the currently loaded ammo type with a weapon you'd do something like:
    weapon:getModData().loadedAmmo = "NuclearLaserRailProjectile"However you must be aware that if you modify the moddata of an object client side, it is not modified server side. IS added methods to sync client/server object like sendObjectChange or transmitModData but these methods are not universally supported by every class.
    So whenever you modify moddata on client side and rely on it on server side you will have to send a client command and modify it on the server.
     
     
    I hope this helps someone understand how to get their mod multiplayer ready in the future
  3. Like
    lorneagle got a reaction from sirius in Multiplayer coding questions   
    Hey guys,
    I've been working on getting my mod to work on multiplayer and since there are very little resources on that topic I have a few questions.
     
    isClient() / isServer() 
     
    What these methods do is clear, however when I call isClient() in a file that is located in shared it returns false although
    the initial call flow was triggered client side. So I execute a UI action located in client and call my reload script located in shared but isClient() returns false.
     
    Can anyone give me further information on these two methods?
     
    ModData
     
    I noticed that if I modify moddata on client side, it will not affect the moddata on server side. Now I looked through the existing code and found:
     
    transmitModData() - That sounds like exactly what I need, however it is not available on the HandWeapon object
                                       weapon:transmitModData() - Object tried to call nil
     
    player:sendObjectChange('addItem', { item = kit } ) - Seems to send a request to the client to add an item, I'm not sure if every object supports this and what the exact syntax is, can I just call any method on the target remote object with parameters? Can anyone elaborate on this function?
     
    Does anyone have another idea how I could sync the modData of an object betwen client and server?
     
    My first attempt to use sendClientCommand - process it server side and change the moddata failed to accomplish what I need.
  4. Like
    lorneagle got a reaction from Seal in Multiplayer coding questions   
    Soooo since noone answered this I had to figure it out myself. And like a keener, I answer my own question. Jjust for reference if someone searches for this in the future
     
    First you have to understand what data is stored on the server and what is stored on the client.
     
    The server manages all map assets, such as cabinets and the loot in it, zombie corpses on the ground, camp fires, windows, doors, burned ground and so on. As your character moves around the map your client will constantly request map data from the server. The smallest map entity is a GridSquare and it contains all the object that were just mentioned. Whenever you want to interact with something on the server, like turning on a camp fire, you have to communicate with the server.
     
    The client stores all the character assets such as his weapon, inventory, XP, skills, condition and so on. So when you move stuff around in your bags you will not communicate with the server. As soon as you drop something on the ground however, the server is notified.
     
    The folders
    Zomboid mods have three different  lua folders:
    client  shared server These folder's purpose is code organisation. Simply putting code into server doesn't mean it is executed on the server and not on the client. In single player for example all code is executed no matter in which folder you placed it. 
     
    So what determines if code is executed on the server or client?
     
    Usually you hook your code into the existing code using Events:
    ZXBmulti = {}--Event handlerZXBmulti.test = function() print("I was called");end-- Register event handlerEvents.OnWeaponSwing.Add(ZXBmulti.test); Now in SP, all these events are fire locally BUT in multiplayer some Events are only fired on the client side while others are only fired on the server. Consequently the event hook you chose determines where your code is executed.
     
    Example:
    OnWeaponSwing - Is executed on the client
    OnWeaponHitCharacter - Is executed on the server So the folders are simply to organize your code, typically
     
    client           Put all your UI logic like menus here
    shared           Put everything else here
    server           Put all your server logic like, what happens when a zombie is hit, here
     
    Execute code only if you are client or server or if its a local SP game
     
    As I mentioned before: When you play a local game all code is always executed because all events are fired locally.
    This can cause problems because you want some of your code to only be executed if you are the client in a multiplayer game, or when you act as a server. To solve this problem IS gave us three helpers:
     
    isClient()
     
    This returns true if you are the client in a multiplayer game, but false in a local game or if you are the server
     
    isServer()
     
    This returns true if you are the server in a multiplayer game, but false if you are client or local game
     
    getWorld():getGameMode() == "Multiplayer"
     
    This returns true if you are in a ... (guess )
     
    Client Server communication
     
    The basic pattern is to use
     
    sendClientCommand to send a message to the server
    sendServerCommand to send a message to the client
     
    These commands will trigger an event on the other side which you can hook you code into
    OnClientCommand - is triggered on server side when a client command is sent OnServerCommand - is triggered on client side when a server command is sent Example Client to Server
     
    Client
    if isClient() then sendClientCommand(char, "myModule", "myMethod", {foo = "bar", difficulty= "easyPZ"}); end Server:
    MyClientCommands.OnClientCommand = function(module, command, player, args) if not isServer() then return end if module ~= "myModule" then return end; if command == "myMethod" then --dostuff endendEvents.OnClientCommand.Add(MyClientCommands.OnClientCommand);For server to client you follow the same pattern but use sendServerCommand an OnServerCommand respectively.
     
    Moddata
     
    Moddata is a great sink for any data you want to store with an object. Let's say you want to save the currently loaded ammo type with a weapon you'd do something like:
    weapon:getModData().loadedAmmo = "NuclearLaserRailProjectile"However you must be aware that if you modify the moddata of an object client side, it is not modified server side. IS added methods to sync client/server object like sendObjectChange or transmitModData but these methods are not universally supported by every class.
    So whenever you modify moddata on client side and rely on it on server side you will have to send a client command and modify it on the server.
     
     
    I hope this helps someone understand how to get their mod multiplayer ready in the future
  5. Like
    lorneagle got a reaction from TheZ in Multiplayer coding questions   
    Soooo since noone answered this I had to figure it out myself. And like a keener, I answer my own question. Jjust for reference if someone searches for this in the future
     
    First you have to understand what data is stored on the server and what is stored on the client.
     
    The server manages all map assets, such as cabinets and the loot in it, zombie corpses on the ground, camp fires, windows, doors, burned ground and so on. As your character moves around the map your client will constantly request map data from the server. The smallest map entity is a GridSquare and it contains all the object that were just mentioned. Whenever you want to interact with something on the server, like turning on a camp fire, you have to communicate with the server.
     
    The client stores all the character assets such as his weapon, inventory, XP, skills, condition and so on. So when you move stuff around in your bags you will not communicate with the server. As soon as you drop something on the ground however, the server is notified.
     
    The folders
    Zomboid mods have three different  lua folders:
    client  shared server These folder's purpose is code organisation. Simply putting code into server doesn't mean it is executed on the server and not on the client. In single player for example all code is executed no matter in which folder you placed it. 
     
    So what determines if code is executed on the server or client?
     
    Usually you hook your code into the existing code using Events:
    ZXBmulti = {}--Event handlerZXBmulti.test = function() print("I was called");end-- Register event handlerEvents.OnWeaponSwing.Add(ZXBmulti.test); Now in SP, all these events are fire locally BUT in multiplayer some Events are only fired on the client side while others are only fired on the server. Consequently the event hook you chose determines where your code is executed.
     
    Example:
    OnWeaponSwing - Is executed on the client
    OnWeaponHitCharacter - Is executed on the server So the folders are simply to organize your code, typically
     
    client           Put all your UI logic like menus here
    shared           Put everything else here
    server           Put all your server logic like, what happens when a zombie is hit, here
     
    Execute code only if you are client or server or if its a local SP game
     
    As I mentioned before: When you play a local game all code is always executed because all events are fired locally.
    This can cause problems because you want some of your code to only be executed if you are the client in a multiplayer game, or when you act as a server. To solve this problem IS gave us three helpers:
     
    isClient()
     
    This returns true if you are the client in a multiplayer game, but false in a local game or if you are the server
     
    isServer()
     
    This returns true if you are the server in a multiplayer game, but false if you are client or local game
     
    getWorld():getGameMode() == "Multiplayer"
     
    This returns true if you are in a ... (guess )
     
    Client Server communication
     
    The basic pattern is to use
     
    sendClientCommand to send a message to the server
    sendServerCommand to send a message to the client
     
    These commands will trigger an event on the other side which you can hook you code into
    OnClientCommand - is triggered on server side when a client command is sent OnServerCommand - is triggered on client side when a server command is sent Example Client to Server
     
    Client
    if isClient() then sendClientCommand(char, "myModule", "myMethod", {foo = "bar", difficulty= "easyPZ"}); end Server:
    MyClientCommands.OnClientCommand = function(module, command, player, args) if not isServer() then return end if module ~= "myModule" then return end; if command == "myMethod" then --dostuff endendEvents.OnClientCommand.Add(MyClientCommands.OnClientCommand);For server to client you follow the same pattern but use sendServerCommand an OnServerCommand respectively.
     
    Moddata
     
    Moddata is a great sink for any data you want to store with an object. Let's say you want to save the currently loaded ammo type with a weapon you'd do something like:
    weapon:getModData().loadedAmmo = "NuclearLaserRailProjectile"However you must be aware that if you modify the moddata of an object client side, it is not modified server side. IS added methods to sync client/server object like sendObjectChange or transmitModData but these methods are not universally supported by every class.
    So whenever you modify moddata on client side and rely on it on server side you will have to send a client command and modify it on the server.
     
     
    I hope this helps someone understand how to get their mod multiplayer ready in the future
  6. Like
    lorneagle got a reaction from Maris in Multiplayer coding questions   
    Soooo since noone answered this I had to figure it out myself. And like a keener, I answer my own question. Jjust for reference if someone searches for this in the future
     
    First you have to understand what data is stored on the server and what is stored on the client.
     
    The server manages all map assets, such as cabinets and the loot in it, zombie corpses on the ground, camp fires, windows, doors, burned ground and so on. As your character moves around the map your client will constantly request map data from the server. The smallest map entity is a GridSquare and it contains all the object that were just mentioned. Whenever you want to interact with something on the server, like turning on a camp fire, you have to communicate with the server.
     
    The client stores all the character assets such as his weapon, inventory, XP, skills, condition and so on. So when you move stuff around in your bags you will not communicate with the server. As soon as you drop something on the ground however, the server is notified.
     
    The folders
    Zomboid mods have three different  lua folders:
    client  shared server These folder's purpose is code organisation. Simply putting code into server doesn't mean it is executed on the server and not on the client. In single player for example all code is executed no matter in which folder you placed it. 
     
    So what determines if code is executed on the server or client?
     
    Usually you hook your code into the existing code using Events:
    ZXBmulti = {}--Event handlerZXBmulti.test = function() print("I was called");end-- Register event handlerEvents.OnWeaponSwing.Add(ZXBmulti.test); Now in SP, all these events are fire locally BUT in multiplayer some Events are only fired on the client side while others are only fired on the server. Consequently the event hook you chose determines where your code is executed.
     
    Example:
    OnWeaponSwing - Is executed on the client
    OnWeaponHitCharacter - Is executed on the server So the folders are simply to organize your code, typically
     
    client           Put all your UI logic like menus here
    shared           Put everything else here
    server           Put all your server logic like, what happens when a zombie is hit, here
     
    Execute code only if you are client or server or if its a local SP game
     
    As I mentioned before: When you play a local game all code is always executed because all events are fired locally.
    This can cause problems because you want some of your code to only be executed if you are the client in a multiplayer game, or when you act as a server. To solve this problem IS gave us three helpers:
     
    isClient()
     
    This returns true if you are the client in a multiplayer game, but false in a local game or if you are the server
     
    isServer()
     
    This returns true if you are the server in a multiplayer game, but false if you are client or local game
     
    getWorld():getGameMode() == "Multiplayer"
     
    This returns true if you are in a ... (guess )
     
    Client Server communication
     
    The basic pattern is to use
     
    sendClientCommand to send a message to the server
    sendServerCommand to send a message to the client
     
    These commands will trigger an event on the other side which you can hook you code into
    OnClientCommand - is triggered on server side when a client command is sent OnServerCommand - is triggered on client side when a server command is sent Example Client to Server
     
    Client
    if isClient() then sendClientCommand(char, "myModule", "myMethod", {foo = "bar", difficulty= "easyPZ"}); end Server:
    MyClientCommands.OnClientCommand = function(module, command, player, args) if not isServer() then return end if module ~= "myModule" then return end; if command == "myMethod" then --dostuff endendEvents.OnClientCommand.Add(MyClientCommands.OnClientCommand);For server to client you follow the same pattern but use sendServerCommand an OnServerCommand respectively.
     
    Moddata
     
    Moddata is a great sink for any data you want to store with an object. Let's say you want to save the currently loaded ammo type with a weapon you'd do something like:
    weapon:getModData().loadedAmmo = "NuclearLaserRailProjectile"However you must be aware that if you modify the moddata of an object client side, it is not modified server side. IS added methods to sync client/server object like sendObjectChange or transmitModData but these methods are not universally supported by every class.
    So whenever you modify moddata on client side and rely on it on server side you will have to send a client command and modify it on the server.
     
     
    I hope this helps someone understand how to get their mod multiplayer ready in the future
  7. Like
    lorneagle got a reaction from nater in Multiplayer coding questions   
    Soooo since noone answered this I had to figure it out myself. And like a keener, I answer my own question. Jjust for reference if someone searches for this in the future
     
    First you have to understand what data is stored on the server and what is stored on the client.
     
    The server manages all map assets, such as cabinets and the loot in it, zombie corpses on the ground, camp fires, windows, doors, burned ground and so on. As your character moves around the map your client will constantly request map data from the server. The smallest map entity is a GridSquare and it contains all the object that were just mentioned. Whenever you want to interact with something on the server, like turning on a camp fire, you have to communicate with the server.
     
    The client stores all the character assets such as his weapon, inventory, XP, skills, condition and so on. So when you move stuff around in your bags you will not communicate with the server. As soon as you drop something on the ground however, the server is notified.
     
    The folders
    Zomboid mods have three different  lua folders:
    client  shared server These folder's purpose is code organisation. Simply putting code into server doesn't mean it is executed on the server and not on the client. In single player for example all code is executed no matter in which folder you placed it. 
     
    So what determines if code is executed on the server or client?
     
    Usually you hook your code into the existing code using Events:
    ZXBmulti = {}--Event handlerZXBmulti.test = function() print("I was called");end-- Register event handlerEvents.OnWeaponSwing.Add(ZXBmulti.test); Now in SP, all these events are fire locally BUT in multiplayer some Events are only fired on the client side while others are only fired on the server. Consequently the event hook you chose determines where your code is executed.
     
    Example:
    OnWeaponSwing - Is executed on the client
    OnWeaponHitCharacter - Is executed on the server So the folders are simply to organize your code, typically
     
    client           Put all your UI logic like menus here
    shared           Put everything else here
    server           Put all your server logic like, what happens when a zombie is hit, here
     
    Execute code only if you are client or server or if its a local SP game
     
    As I mentioned before: When you play a local game all code is always executed because all events are fired locally.
    This can cause problems because you want some of your code to only be executed if you are the client in a multiplayer game, or when you act as a server. To solve this problem IS gave us three helpers:
     
    isClient()
     
    This returns true if you are the client in a multiplayer game, but false in a local game or if you are the server
     
    isServer()
     
    This returns true if you are the server in a multiplayer game, but false if you are client or local game
     
    getWorld():getGameMode() == "Multiplayer"
     
    This returns true if you are in a ... (guess )
     
    Client Server communication
     
    The basic pattern is to use
     
    sendClientCommand to send a message to the server
    sendServerCommand to send a message to the client
     
    These commands will trigger an event on the other side which you can hook you code into
    OnClientCommand - is triggered on server side when a client command is sent OnServerCommand - is triggered on client side when a server command is sent Example Client to Server
     
    Client
    if isClient() then sendClientCommand(char, "myModule", "myMethod", {foo = "bar", difficulty= "easyPZ"}); end Server:
    MyClientCommands.OnClientCommand = function(module, command, player, args) if not isServer() then return end if module ~= "myModule" then return end; if command == "myMethod" then --dostuff endendEvents.OnClientCommand.Add(MyClientCommands.OnClientCommand);For server to client you follow the same pattern but use sendServerCommand an OnServerCommand respectively.
     
    Moddata
     
    Moddata is a great sink for any data you want to store with an object. Let's say you want to save the currently loaded ammo type with a weapon you'd do something like:
    weapon:getModData().loadedAmmo = "NuclearLaserRailProjectile"However you must be aware that if you modify the moddata of an object client side, it is not modified server side. IS added methods to sync client/server object like sendObjectChange or transmitModData but these methods are not universally supported by every class.
    So whenever you modify moddata on client side and rely on it on server side you will have to send a client command and modify it on the server.
     
     
    I hope this helps someone understand how to get their mod multiplayer ready in the future
  8. Like
    lorneagle got a reaction from trombonaught in Multiplayer coding questions   
    Soooo since noone answered this I had to figure it out myself. And like a keener, I answer my own question. Jjust for reference if someone searches for this in the future
     
    First you have to understand what data is stored on the server and what is stored on the client.
     
    The server manages all map assets, such as cabinets and the loot in it, zombie corpses on the ground, camp fires, windows, doors, burned ground and so on. As your character moves around the map your client will constantly request map data from the server. The smallest map entity is a GridSquare and it contains all the object that were just mentioned. Whenever you want to interact with something on the server, like turning on a camp fire, you have to communicate with the server.
     
    The client stores all the character assets such as his weapon, inventory, XP, skills, condition and so on. So when you move stuff around in your bags you will not communicate with the server. As soon as you drop something on the ground however, the server is notified.
     
    The folders
    Zomboid mods have three different  lua folders:
    client  shared server These folder's purpose is code organisation. Simply putting code into server doesn't mean it is executed on the server and not on the client. In single player for example all code is executed no matter in which folder you placed it. 
     
    So what determines if code is executed on the server or client?
     
    Usually you hook your code into the existing code using Events:
    ZXBmulti = {}--Event handlerZXBmulti.test = function() print("I was called");end-- Register event handlerEvents.OnWeaponSwing.Add(ZXBmulti.test); Now in SP, all these events are fire locally BUT in multiplayer some Events are only fired on the client side while others are only fired on the server. Consequently the event hook you chose determines where your code is executed.
     
    Example:
    OnWeaponSwing - Is executed on the client
    OnWeaponHitCharacter - Is executed on the server So the folders are simply to organize your code, typically
     
    client           Put all your UI logic like menus here
    shared           Put everything else here
    server           Put all your server logic like, what happens when a zombie is hit, here
     
    Execute code only if you are client or server or if its a local SP game
     
    As I mentioned before: When you play a local game all code is always executed because all events are fired locally.
    This can cause problems because you want some of your code to only be executed if you are the client in a multiplayer game, or when you act as a server. To solve this problem IS gave us three helpers:
     
    isClient()
     
    This returns true if you are the client in a multiplayer game, but false in a local game or if you are the server
     
    isServer()
     
    This returns true if you are the server in a multiplayer game, but false if you are client or local game
     
    getWorld():getGameMode() == "Multiplayer"
     
    This returns true if you are in a ... (guess )
     
    Client Server communication
     
    The basic pattern is to use
     
    sendClientCommand to send a message to the server
    sendServerCommand to send a message to the client
     
    These commands will trigger an event on the other side which you can hook you code into
    OnClientCommand - is triggered on server side when a client command is sent OnServerCommand - is triggered on client side when a server command is sent Example Client to Server
     
    Client
    if isClient() then sendClientCommand(char, "myModule", "myMethod", {foo = "bar", difficulty= "easyPZ"}); end Server:
    MyClientCommands.OnClientCommand = function(module, command, player, args) if not isServer() then return end if module ~= "myModule" then return end; if command == "myMethod" then --dostuff endendEvents.OnClientCommand.Add(MyClientCommands.OnClientCommand);For server to client you follow the same pattern but use sendServerCommand an OnServerCommand respectively.
     
    Moddata
     
    Moddata is a great sink for any data you want to store with an object. Let's say you want to save the currently loaded ammo type with a weapon you'd do something like:
    weapon:getModData().loadedAmmo = "NuclearLaserRailProjectile"However you must be aware that if you modify the moddata of an object client side, it is not modified server side. IS added methods to sync client/server object like sendObjectChange or transmitModData but these methods are not universally supported by every class.
    So whenever you modify moddata on client side and rely on it on server side you will have to send a client command and modify it on the server.
     
     
    I hope this helps someone understand how to get their mod multiplayer ready in the future
  9. Like
    lorneagle got a reaction from ddraigcymraeg in Multiplayer coding questions   
    Soooo since noone answered this I had to figure it out myself. And like a keener, I answer my own question. Jjust for reference if someone searches for this in the future
     
    First you have to understand what data is stored on the server and what is stored on the client.
     
    The server manages all map assets, such as cabinets and the loot in it, zombie corpses on the ground, camp fires, windows, doors, burned ground and so on. As your character moves around the map your client will constantly request map data from the server. The smallest map entity is a GridSquare and it contains all the object that were just mentioned. Whenever you want to interact with something on the server, like turning on a camp fire, you have to communicate with the server.
     
    The client stores all the character assets such as his weapon, inventory, XP, skills, condition and so on. So when you move stuff around in your bags you will not communicate with the server. As soon as you drop something on the ground however, the server is notified.
     
    The folders
    Zomboid mods have three different  lua folders:
    client  shared server These folder's purpose is code organisation. Simply putting code into server doesn't mean it is executed on the server and not on the client. In single player for example all code is executed no matter in which folder you placed it. 
     
    So what determines if code is executed on the server or client?
     
    Usually you hook your code into the existing code using Events:
    ZXBmulti = {}--Event handlerZXBmulti.test = function() print("I was called");end-- Register event handlerEvents.OnWeaponSwing.Add(ZXBmulti.test); Now in SP, all these events are fire locally BUT in multiplayer some Events are only fired on the client side while others are only fired on the server. Consequently the event hook you chose determines where your code is executed.
     
    Example:
    OnWeaponSwing - Is executed on the client
    OnWeaponHitCharacter - Is executed on the server So the folders are simply to organize your code, typically
     
    client           Put all your UI logic like menus here
    shared           Put everything else here
    server           Put all your server logic like, what happens when a zombie is hit, here
     
    Execute code only if you are client or server or if its a local SP game
     
    As I mentioned before: When you play a local game all code is always executed because all events are fired locally.
    This can cause problems because you want some of your code to only be executed if you are the client in a multiplayer game, or when you act as a server. To solve this problem IS gave us three helpers:
     
    isClient()
     
    This returns true if you are the client in a multiplayer game, but false in a local game or if you are the server
     
    isServer()
     
    This returns true if you are the server in a multiplayer game, but false if you are client or local game
     
    getWorld():getGameMode() == "Multiplayer"
     
    This returns true if you are in a ... (guess )
     
    Client Server communication
     
    The basic pattern is to use
     
    sendClientCommand to send a message to the server
    sendServerCommand to send a message to the client
     
    These commands will trigger an event on the other side which you can hook you code into
    OnClientCommand - is triggered on server side when a client command is sent OnServerCommand - is triggered on client side when a server command is sent Example Client to Server
     
    Client
    if isClient() then sendClientCommand(char, "myModule", "myMethod", {foo = "bar", difficulty= "easyPZ"}); end Server:
    MyClientCommands.OnClientCommand = function(module, command, player, args) if not isServer() then return end if module ~= "myModule" then return end; if command == "myMethod" then --dostuff endendEvents.OnClientCommand.Add(MyClientCommands.OnClientCommand);For server to client you follow the same pattern but use sendServerCommand an OnServerCommand respectively.
     
    Moddata
     
    Moddata is a great sink for any data you want to store with an object. Let's say you want to save the currently loaded ammo type with a weapon you'd do something like:
    weapon:getModData().loadedAmmo = "NuclearLaserRailProjectile"However you must be aware that if you modify the moddata of an object client side, it is not modified server side. IS added methods to sync client/server object like sendObjectChange or transmitModData but these methods are not universally supported by every class.
    So whenever you modify moddata on client side and rely on it on server side you will have to send a client command and modify it on the server.
     
     
    I hope this helps someone understand how to get their mod multiplayer ready in the future
  10. Like
    lorneagle got a reaction from Atoxwarrior in [ZomboidXBow] Update: 1.1.3 - Bugfix/Balancing   
    That's great feedback, thank you so much
    - I totally forgot about that crazy XP boost, I will fix that
    - I will play with the crossbow properties more, sound included....I don't want them to be too loud though, just wanted to add a bit of an edge
    - Adding a pistol to the recipe is a great idea!!!
    - Yeah, the whole quiver thing is bugging me, unfortunately at the time tI did not figure out how the weight reduction is done ( the item property didn't do anything  )
    - XP gain will be significantly reduced
    - I wanted to add attachable addons but I currently don't have the time
    - Muzzleflash is because the base class of crossbows is 'Firearm'. Maybe I can still deactivate it somewhere but so far I couldn't figfure out a way 
    - Repeater: I wanted the repeater to be strong, but limit its usability by making ammo less available. I reduced the amount of feathers that you get our of birds and pillows but I need to do more on that front
  11. Like
    lorneagle got a reaction from Livio Persemprio in [ZomboidXBow] Update: 1.1.3 - Bugfix/Balancing   
    I pushed a small update to resolve the container issue and nerf the crossbows a bit
    Aiming Perk OnHit modifier reduced - So the per level improvement on your hit chance is less than before Make crossbows more unique, giving each crossbow a specific use case rather than simply Repeater > Heavy > Wooden crossbow  Wooden Crossbow
       General usage crossbow for stealth operations, medium range
    Damage slightly reduced Makes a bit of noise (will attract zombies in short range 10m) Heavy Crossbow
       Long range snipe crossbow, long range
    Makes noise and attracts zombies within 25m (It has more range than that, so you can snipe zombies from a distance but you need to make sure the immediate area is clear) Repeater Crossbow
       To quickly dispose of small zombie groups at close/medium range
    Makes noise and attracts zombies in 15m range Removed piercing (only hits one target)  
    Note: That I just started experimenting with the weapon settings and I am planning to further refine the settings to give each crossbow a unique role
    Feedback is extremely appreciated
     
  12. Like
    lorneagle got a reaction from dnk3912 in [ZomboidXBow] Update: 1.1.3 - Bugfix/Balancing   
    ZomboidXBow

     


    Hey fellow zomboiders,

    This mod aims at bringing the crossbow experience to Project Zomboid. It offers a variety of craftable crossbow models and ammunition types with different properties.
    All of these recipes force you to continuously scavenge for resources to keep you ammunition supplies up and maintain your crossbows.

    As your character progresses he will get access to better recipes and crossbows will become more efficient. In the beginning you will miss often, be constantly out of ammo and probably want to go back to your Axe. But if you survive long enough to get your hands on a Repeater Crossbow with Aluminum Bolts ...

    Quick Features

    Supports Single Player and Multiplayer

    Mechanics
     
    Retrieve your bolts from zombie corpses. They might however break on impact Craft, carry and reload from a Bolt Quiver which adds an addtional bag slot Crossbows can break at any time. Your Carpentry and Electrician skill levels determine how likely it is to happen All crossbows support all ammo types Easily switch between ammo types by using the context menu  
    Crossbows

    Crossbows behave like all existing weapons: Aiming and Reloading will increase your skill level which in turn affects your chance to hit and your reload speed.

    Wooden Crossbow
    A simple crossbow

    Heavy Crossbow
    Requires Carpentry 3
    Strong crossbow that can hit up to two targets

    Repeater Crossbow
    Requires Carpentry 5 
    Powerful crossbow that can fire up to 10 bolts in rapid succession and hit up to two targets per shoot

    Bolts

    All bolts can be fired with any crossbow. Just have a crossbow equipped as primary, right click your desired bolt in your inventory load or set as default.


    Wooden Bolt
    Simple Bolt with high chance to break

    Aluminum Bolt
    Piercing - Allows you to hit one additional target with your crossbow.

    Fire Bolt
    Target has a 90% chance to be lit on fire. Most fun but most dangerous bolt with unpredictable outcome especially on IWBUMS branch. Don't use indoors!


    Requirements
    3DModels 32.16 Download latest version

    Installation Instructions

    All Items, Recipes and Documentation


    Known issues:
    All crossbows use the same 3DModel and Icon Crossbow 3DModel not 100% aligned Planned
    Test in MP Learn recipes through Books instead of hard skill requirements LOTS of balancing and tuning Better icons/models Attachments More ammunition types Misc stuff around crossbows  
    Feedback
     
    If you like this mod (or even if you don't) I'm happy to get your feedback, bug reports and improvement suggestions.
    I want this to be a balanced mod and I can only get there with the help of you guys
     
    Credit to
    Jab for his import/export script for 3D Models which works flawlessy and his ModelLoader
    Fuji for his pioneer work on how to get custom 3D Model into the game and basically giving me the chance to write the mod I                 wanted to write ever since I bought this game

    WolfClaw for his excellent 3DModel tutorial
    ORMtnMan and his Real Guns mod gun modding reference
     
    Livio Persemprio for testing and feedback which is so important for balancing

    Thanks guys!

    I hope you enjoy this mod, many survivors perished and half of Westpoint burned down during its creation
  13. Like
    lorneagle reacted to ganya in [ZomboidXBow] Update: 1.1.3 - Bugfix/Balancing   
    Damn forum update ate my topic notification...
    Thank You!
    Container Update works fine!
    Some Feedback:
    The new noise making is great! It can get you quickly into trouble with grown vegetation (as it did with me). I would even increase it by 50% for even more fun. Particularly the repeating xbow... its still very powerfull, maybe decreasing accuracy on Quickfire (if possible) would nerf it.
    I´m on Carpentry level 7 now and read the expert skillbook. Crafting a repeater xbow gives me 3000XP, what is as much as killing 3000 zombies...
    Crossbows have a muzzleflash (only visible at night).
    Maybe making Laserpointers, Scopes, Ammostraps and so on attachable to crossbows would be another way of specialising crossbows. And you can´t craft them in your Safehouse.
    Some minor things:
    -maybe adding a pistol to crossbow recipes (because of the metal parts) would make sense
    -plucking a dead bird, might result in feathers and a "plucked bird", that can be butchered for meat
    Things I change before playing:
    -reducing boltweight to 0.05, because the quiver dont give a weight bonus
    -reducing xp gain for making crossbows to +5/+10/+15, for bolts to +0.25 Carpentry and no electricity xp´s
    -raising required Carpentry skill to make crossbows to 3/5/7 ... should be even higher
  14. Like
    lorneagle got a reaction from Geras in [ZomboidXBow] Update: 1.1.3 - Bugfix/Balancing   
    I pushed a small update to resolve the container issue and nerf the crossbows a bit
    Aiming Perk OnHit modifier reduced - So the per level improvement on your hit chance is less than before Make crossbows more unique, giving each crossbow a specific use case rather than simply Repeater > Heavy > Wooden crossbow  Wooden Crossbow
       General usage crossbow for stealth operations, medium range
    Damage slightly reduced Makes a bit of noise (will attract zombies in short range 10m) Heavy Crossbow
       Long range snipe crossbow, long range
    Makes noise and attracts zombies within 25m (It has more range than that, so you can snipe zombies from a distance but you need to make sure the immediate area is clear) Repeater Crossbow
       To quickly dispose of small zombie groups at close/medium range
    Makes noise and attracts zombies in 15m range Removed piercing (only hits one target)  
    Note: That I just started experimenting with the weapon settings and I am planning to further refine the settings to give each crossbow a unique role
    Feedback is extremely appreciated
     
  15. Like
    lorneagle got a reaction from Geras in [ZomboidXBow] Update: 1.1.3 - Bugfix/Balancing   
    I'll look into it.
     
    I fixed the container bug and I'm currently testing some chances to the crossbows to balance them a bit and make the three crossbows a bit more unique so that you don't just go to the next 'better' crossbow but decide which crossbow to use based on the situation and your game style.
  16. Like
    lorneagle got a reaction from ShuiYin in [ZomboidXBow] Update: 1.1.3 - Bugfix/Balancing   
    ZomboidXBow

     


    Hey fellow zomboiders,

    This mod aims at bringing the crossbow experience to Project Zomboid. It offers a variety of craftable crossbow models and ammunition types with different properties.
    All of these recipes force you to continuously scavenge for resources to keep you ammunition supplies up and maintain your crossbows.

    As your character progresses he will get access to better recipes and crossbows will become more efficient. In the beginning you will miss often, be constantly out of ammo and probably want to go back to your Axe. But if you survive long enough to get your hands on a Repeater Crossbow with Aluminum Bolts ...

    Quick Features

    Supports Single Player and Multiplayer

    Mechanics
     
    Retrieve your bolts from zombie corpses. They might however break on impact Craft, carry and reload from a Bolt Quiver which adds an addtional bag slot Crossbows can break at any time. Your Carpentry and Electrician skill levels determine how likely it is to happen All crossbows support all ammo types Easily switch between ammo types by using the context menu  
    Crossbows

    Crossbows behave like all existing weapons: Aiming and Reloading will increase your skill level which in turn affects your chance to hit and your reload speed.

    Wooden Crossbow
    A simple crossbow

    Heavy Crossbow
    Requires Carpentry 3
    Strong crossbow that can hit up to two targets

    Repeater Crossbow
    Requires Carpentry 5 
    Powerful crossbow that can fire up to 10 bolts in rapid succession and hit up to two targets per shoot

    Bolts

    All bolts can be fired with any crossbow. Just have a crossbow equipped as primary, right click your desired bolt in your inventory load or set as default.


    Wooden Bolt
    Simple Bolt with high chance to break

    Aluminum Bolt
    Piercing - Allows you to hit one additional target with your crossbow.

    Fire Bolt
    Target has a 90% chance to be lit on fire. Most fun but most dangerous bolt with unpredictable outcome especially on IWBUMS branch. Don't use indoors!


    Requirements
    3DModels 32.16 Download latest version

    Installation Instructions

    All Items, Recipes and Documentation


    Known issues:
    All crossbows use the same 3DModel and Icon Crossbow 3DModel not 100% aligned Planned
    Test in MP Learn recipes through Books instead of hard skill requirements LOTS of balancing and tuning Better icons/models Attachments More ammunition types Misc stuff around crossbows  
    Feedback
     
    If you like this mod (or even if you don't) I'm happy to get your feedback, bug reports and improvement suggestions.
    I want this to be a balanced mod and I can only get there with the help of you guys
     
    Credit to
    Jab for his import/export script for 3D Models which works flawlessy and his ModelLoader
    Fuji for his pioneer work on how to get custom 3D Model into the game and basically giving me the chance to write the mod I                 wanted to write ever since I bought this game

    WolfClaw for his excellent 3DModel tutorial
    ORMtnMan and his Real Guns mod gun modding reference
     
    Livio Persemprio for testing and feedback which is so important for balancing

    Thanks guys!

    I hope you enjoy this mod, many survivors perished and half of Westpoint burned down during its creation
  17. Like
    lorneagle got a reaction from Wveth in [ZomboidXBow] Update: 1.1.3 - Bugfix/Balancing   
    I will move it to the steam workshop in the future. I will also consider the recipe. However I am currently very busy with two kids under two so I won't make any significant changes to the mod (except when it gets broken due to game updates) in the next 2-3 months.
     
    I will however come back and add more features as well as add it to the steam workshop and make balancing changes in the future.
     
    Also: I check in on this thread once or twice a week and answer PMs immediately.
  18. Like
    lorneagle got a reaction from Man_In_The_Purple_Hat in [ZomboidXBow] Update: 1.1.3 - Bugfix/Balancing   
    I will move it to the steam workshop in the future. I will also consider the recipe. However I am currently very busy with two kids under two so I won't make any significant changes to the mod (except when it gets broken due to game updates) in the next 2-3 months.
     
    I will however come back and add more features as well as add it to the steam workshop and make balancing changes in the future.
     
    Also: I check in on this thread once or twice a week and answer PMs immediately.
  19. Like
    lorneagle got a reaction from Livio Persemprio in [ZomboidXBow] Update: 1.1.3 - Bugfix/Balancing   
    I will move it to the steam workshop in the future. I will also consider the recipe. However I am currently very busy with two kids under two so I won't make any significant changes to the mod (except when it gets broken due to game updates) in the next 2-3 months.
     
    I will however come back and add more features as well as add it to the steam workshop and make balancing changes in the future.
     
    Also: I check in on this thread once or twice a week and answer PMs immediately.
  20. Like
    lorneagle got a reaction from khamseen in Multiplayer coding questions   
    Soooo since noone answered this I had to figure it out myself. And like a keener, I answer my own question. Jjust for reference if someone searches for this in the future
     
    First you have to understand what data is stored on the server and what is stored on the client.
     
    The server manages all map assets, such as cabinets and the loot in it, zombie corpses on the ground, camp fires, windows, doors, burned ground and so on. As your character moves around the map your client will constantly request map data from the server. The smallest map entity is a GridSquare and it contains all the object that were just mentioned. Whenever you want to interact with something on the server, like turning on a camp fire, you have to communicate with the server.
     
    The client stores all the character assets such as his weapon, inventory, XP, skills, condition and so on. So when you move stuff around in your bags you will not communicate with the server. As soon as you drop something on the ground however, the server is notified.
     
    The folders
    Zomboid mods have three different  lua folders:
    client  shared server These folder's purpose is code organisation. Simply putting code into server doesn't mean it is executed on the server and not on the client. In single player for example all code is executed no matter in which folder you placed it. 
     
    So what determines if code is executed on the server or client?
     
    Usually you hook your code into the existing code using Events:
    ZXBmulti = {}--Event handlerZXBmulti.test = function() print("I was called");end-- Register event handlerEvents.OnWeaponSwing.Add(ZXBmulti.test); Now in SP, all these events are fire locally BUT in multiplayer some Events are only fired on the client side while others are only fired on the server. Consequently the event hook you chose determines where your code is executed.
     
    Example:
    OnWeaponSwing - Is executed on the client
    OnWeaponHitCharacter - Is executed on the server So the folders are simply to organize your code, typically
     
    client           Put all your UI logic like menus here
    shared           Put everything else here
    server           Put all your server logic like, what happens when a zombie is hit, here
     
    Execute code only if you are client or server or if its a local SP game
     
    As I mentioned before: When you play a local game all code is always executed because all events are fired locally.
    This can cause problems because you want some of your code to only be executed if you are the client in a multiplayer game, or when you act as a server. To solve this problem IS gave us three helpers:
     
    isClient()
     
    This returns true if you are the client in a multiplayer game, but false in a local game or if you are the server
     
    isServer()
     
    This returns true if you are the server in a multiplayer game, but false if you are client or local game
     
    getWorld():getGameMode() == "Multiplayer"
     
    This returns true if you are in a ... (guess )
     
    Client Server communication
     
    The basic pattern is to use
     
    sendClientCommand to send a message to the server
    sendServerCommand to send a message to the client
     
    These commands will trigger an event on the other side which you can hook you code into
    OnClientCommand - is triggered on server side when a client command is sent OnServerCommand - is triggered on client side when a server command is sent Example Client to Server
     
    Client
    if isClient() then sendClientCommand(char, "myModule", "myMethod", {foo = "bar", difficulty= "easyPZ"}); end Server:
    MyClientCommands.OnClientCommand = function(module, command, player, args) if not isServer() then return end if module ~= "myModule" then return end; if command == "myMethod" then --dostuff endendEvents.OnClientCommand.Add(MyClientCommands.OnClientCommand);For server to client you follow the same pattern but use sendServerCommand an OnServerCommand respectively.
     
    Moddata
     
    Moddata is a great sink for any data you want to store with an object. Let's say you want to save the currently loaded ammo type with a weapon you'd do something like:
    weapon:getModData().loadedAmmo = "NuclearLaserRailProjectile"However you must be aware that if you modify the moddata of an object client side, it is not modified server side. IS added methods to sync client/server object like sendObjectChange or transmitModData but these methods are not universally supported by every class.
    So whenever you modify moddata on client side and rely on it on server side you will have to send a client command and modify it on the server.
     
     
    I hope this helps someone understand how to get their mod multiplayer ready in the future
  21. Like
    lorneagle got a reaction from Wveth in [ZomboidXBow] Update: 1.1.3 - Bugfix/Balancing   
    Update pushed Let me know if you have any problems
  22. Like
    lorneagle got a reaction from Wveth in [ZomboidXBow] Update: 1.1.3 - Bugfix/Balancing   
    Didn't forget but release got delayed....just saying 2 under 2
  23. Like
    lorneagle got a reaction from Wveth in [ZomboidXBow] Update: 1.1.3 - Bugfix/Balancing   
    I will update it this weekend. Had a lot of stuff going on in the past couple weeks (including a newborn ) so I only occasionally looked in here. 
     
    Should have a working version by Monday
  24. Like
    lorneagle got a reaction from Jab in [ZomboidXBow] Update: 1.1.3 - Bugfix/Balancing   
    I will update it this weekend. Had a lot of stuff going on in the past couple weeks (including a newborn ) so I only occasionally looked in here. 
     
    Should have a working version by Monday
  25. Like
    lorneagle got a reaction from Sieben in [ZomboidXBow] Update: 1.1.3 - Bugfix/Balancing   
    ZomboidXBow

     


    Hey fellow zomboiders,

    This mod aims at bringing the crossbow experience to Project Zomboid. It offers a variety of craftable crossbow models and ammunition types with different properties.
    All of these recipes force you to continuously scavenge for resources to keep you ammunition supplies up and maintain your crossbows.

    As your character progresses he will get access to better recipes and crossbows will become more efficient. In the beginning you will miss often, be constantly out of ammo and probably want to go back to your Axe. But if you survive long enough to get your hands on a Repeater Crossbow with Aluminum Bolts ...

    Quick Features

    Supports Single Player and Multiplayer

    Mechanics
     
    Retrieve your bolts from zombie corpses. They might however break on impact Craft, carry and reload from a Bolt Quiver which adds an addtional bag slot Crossbows can break at any time. Your Carpentry and Electrician skill levels determine how likely it is to happen All crossbows support all ammo types Easily switch between ammo types by using the context menu  
    Crossbows

    Crossbows behave like all existing weapons: Aiming and Reloading will increase your skill level which in turn affects your chance to hit and your reload speed.

    Wooden Crossbow
    A simple crossbow

    Heavy Crossbow
    Requires Carpentry 3
    Strong crossbow that can hit up to two targets

    Repeater Crossbow
    Requires Carpentry 5 
    Powerful crossbow that can fire up to 10 bolts in rapid succession and hit up to two targets per shoot

    Bolts

    All bolts can be fired with any crossbow. Just have a crossbow equipped as primary, right click your desired bolt in your inventory load or set as default.


    Wooden Bolt
    Simple Bolt with high chance to break

    Aluminum Bolt
    Piercing - Allows you to hit one additional target with your crossbow.

    Fire Bolt
    Target has a 90% chance to be lit on fire. Most fun but most dangerous bolt with unpredictable outcome especially on IWBUMS branch. Don't use indoors!


    Requirements
    3DModels 32.16 Download latest version

    Installation Instructions

    All Items, Recipes and Documentation


    Known issues:
    All crossbows use the same 3DModel and Icon Crossbow 3DModel not 100% aligned Planned
    Test in MP Learn recipes through Books instead of hard skill requirements LOTS of balancing and tuning Better icons/models Attachments More ammunition types Misc stuff around crossbows  
    Feedback
     
    If you like this mod (or even if you don't) I'm happy to get your feedback, bug reports and improvement suggestions.
    I want this to be a balanced mod and I can only get there with the help of you guys
     
    Credit to
    Jab for his import/export script for 3D Models which works flawlessy and his ModelLoader
    Fuji for his pioneer work on how to get custom 3D Model into the game and basically giving me the chance to write the mod I                 wanted to write ever since I bought this game

    WolfClaw for his excellent 3DModel tutorial
    ORMtnMan and his Real Guns mod gun modding reference
     
    Livio Persemprio for testing and feedback which is so important for balancing

    Thanks guys!

    I hope you enjoy this mod, many survivors perished and half of Westpoint burned down during its creation
×
×
  • Create New...