Zeros

I've uploaded the current version of the mod to the github. https://github.com/Li-Zero/PZ-Simplify Some stuffs are not included yet because they're in unfinished state. And, there's no comment for the new stuffs. So, you might want to take a look at the examples. And also the extension folder. There's nothing much but overall, it should enhance your coding style. Unless you like those heavily nested codes. Do take note that I've extended the 'require' function to include 'cache/lua/server_name' and root mod folders. The only problem is that, those files will print inaccurate errors if there's any and will be improvised if possible. The provided modloader is just an example and you don't need to pay attention to it for now. For those who needs tools for adding custom events and triggers, you can use available 'EventManager' and 'Events' modules. I've done some tests and it should work as expected. The methods for adding and removing hooks are finalized and wouldn't be changed. This also includes the 'CommandChannels' module. Lastly, I'm looking for collaborators to improve this framework. The direction for this framework would be providing the tools modders need and also workaround for architecture's limitations. Please pm me if you're interested. Please submit bug reports at github alright.

That's more to current game's architecture problem. It's not fully migrated from SP to MP. So, you might want to work on custom server data storage and grab data from player when they are connected.

Oh shoot... I made a mistake. When you are using 'getDescriptor' method to get the forename, you need to call 'getForename' instead of 'getForname'. That's how it's defined for player descriptor object. Sorry, I forgot about the inconsistent method names. if not isServer() then return end; local function WergioServerData() local players = getOnlinePlayers(); for i=0, players:size()-1 do local p = players:get(i); print(type(p)); print(p:getUsername()); print(type(p:isAsleep())); if p:isAsleep() then print(p:getUsername() .. " is asleep"); else print(p:getUsername() .. " is awake"); end local pd = p:getDescriptor(); print(type(pd)); print(pd:getForename()); print(pd:getSurname()); end end Events.EveryTenMinutes.Add(WergioServerData); As for the object type, I think you can try ':toString()' method for it. Not sure if this works or defined by the developers. Haven't test it yet.

The functions you called are meant to return the forename and surname of the first player on their pc. If you want to access the other player's name, you need to call 'getDescriptor' on the player's object. As for 'isAsleep' function, try it again for another error check because I went through the source and it really exists under super class (IsoGameCharacter) methods. if still not working, you can try 'isOnlyPlayerAsleep'. local players = getOnlinePlayers(); for i=0, players:size()-1 do local p = players:get(i); local str = string.format("%s %s (%s): ", p:getDescriptor():getForname(), p:getDescriptor():getSurname(), p:getUsername()); -- Try 'isAsleep' again for another error check -- if 'isAsleep' really don't really work, try 'isOnlyPlayerAsleep' if p:isAsleep() then str = str .. "is asleep"; else str = str .. "is awake"; end print(str); end

Heya developers, I tried working on database utility and 'getSteamID' is suffering from loss of precision. Could you please add a function to return player steamid64 as steamid? If you would like to do the bit shift method, you can refer to this image link. https://developer.valvesoftware.com/w/images/0/01/Steam_id_explanation.png https://developer.valvesoftware.com/wiki/SteamID Otherwise, if you would like to do the easy way, you only need to do this. (Please forgive me because the forum code editor wouldn't load for me) lConstant = 76561197960265728 lRemainder = lSteamID64 % 2 string.format("STEAM_0:%s:%s, lRemainder.toString(), ((lSteamID64 - lConstant + lRemainder) / 2).toString()) I don't recommend the easy way because you can't extract that one value which is the mentioned universe value inside the wiki. Thank you.

Hello developers, current 'getTableResult' and 'executeQuery' global functions require a game client to run those functions and this is forcing modders to make their own custom player data storage. It would be great if you can make it available for server-side modding. This would save us a lot of time. Thank you. And, I have a question about 'ServerWorldDatabase#executeQuery' function. The 'PreparedStatement' variable is not closed after using it. Will this not cause an issue for dedicated servers running 24/7?

Hi, is there's any database utility mod available or tutorial for it? I'm planning to add 'ping location' feature for my radar mod but it can be annoying if one has the intention to spam it. So, in order to deal with these kind players, I would like to add some sort privilege check which can be modified by server admins / mods. Would like to know if someone already made it before I make an attempt. Thank you. edited: It seems that the server sql database is only available for client side modding but not the server side which seems to be contradicting. I'll post a suggestion about making it available for server-side modding.. Anyway, please let me know if you know any utility mod for storing custom player data.

I encountered a critical issue when using the second version. Since the switch function is defined once without getting values from the table function arguments, it will use the very first upvalue, meaning that the function will not receive any new data. Therefore, I've added variable arguments parameter to the switch function. local validate = function(t) if (not t) then error("Switch: Argument is nil", 2) elseif (type(t) ~= "table") then error("Switch: Argument is not a table", 2) end end local switch = function(val, t, ...) validate(t) local args = {...} if t[val] then if (#args > 0) then return t[val](unpack(args)) else return t[val]() end else return t["default"]() end end local tSwitch = {} -- Example One - Without Arguments do tSwitch.Value = tSwitch.Value or { [1] = function() print("One") end, [2] = function() print("Two") end, [3] = function() print("Three") end, [4] = function() print("Four") end, [5] = function() print("Five") end, default = function() print("Unknown value!") end, } for i=1, 6 do switch(i, tSwitch.Value) end end --Example Two - With Arguments do tSwitch.Var = tSwitch.Var or { ["add"] = function(i1, i2) print(i1 + i2) end, } switch("add", tSwitch.Var, 5, 10) end

Hi, I need someone to evaluate which piece of code should used on rendering call. To be honest, I'm thinking of scrapping the FIRST VERSION because it's recreating table and closure. Worst case is recreating the closure on each call. I might be wrong about this hence I need someone to point out what I'm missing. I would appreciate it if there's better idea to improve the first version because variation one coding style is much more familiar. local validate = function(t) if (not t) then error("Switch: Argument is nil", 2) elseif (type(t) ~= "table") then error("Switch: Argument is not a table", 2) end end -- First Version local switch = function(val) return function(t) validate(t) if t[val] then return t[val]() else return t["default"]() end end end -- Variation 1 local function render(...) local i = 10 switch(i) { [1] = function() print("One") end, [10] = function() print("Ten") end, default = function() print("Unknown value!") end, } end -- Variation 2 local tSwitch = {} local function render(...) local i = 10 tSwitch.Value = tSwitch.Value or { [1] = function() print("One") end, [10] = function() print("Ten") end, default = function() print("Unknown value!") end, } switch(i)(tSwitch.Value) end -- Second Version local switch = function(val, t) validate(t) if t[val] then return t[val]() else return t["default"]() end end local tSwitch = {} local function render(...) local i = 10 tSwitch.Value = tSwitch.Value or { [1] = function() print("One") end, [10] = function() print("Ten") end, default = function() print("Unknown value!") end, } switch(i, tSwitch.Value) end

I went through the source again. The most legitimate way to transfer files is to use the server and client commands. You can try look at gameserver, gameclient and packettypes for more details. To be honest, I might have skipped some important things while scanning for related functions. If you need better transfer method, an external application might be required for clients to download the mods. Otherwise, try sending suggestion to developers to consider second option for downloading mods which is the game server. Anyway, since there's no other option left.. I can only try override player spawn now to create the timeout window.

No problem. And, your input is highly appreciated since there might be other solutions to current issues I encountered. I haven't test it yet since I had to streamline some processes involved with the mod loading. My mods became awfully messy after implementing the trial MP mod loader. This is delaying the test. I'm using server / client command events to transfer the files. I have no idea if there's other available file transfer method(s) but, the method I'm using only handle file request from clients after the server game logic starts ticking. This creates an issue of players needing a window to download / load mods without ruining the progress. Therefore, yes. I need some sort of timeout function. That's why I considered waiting lobby as an option since I was running out of idea on how to do it. Thanks for the heads up, I will look for the queue functionality later and see if it's possible. Otherwise, I can try radical approach I recently came up with such as overriding the player spawn process through character creation mod and create the window from there. As for the suggestion to hook the workshop download process, it might be possible if there's a way for clients to download the mods without waiting for the server game logic to start ticking. After giving some consideration, there's a need to look at how the server sandbox settings gets transmitted to the clients when connecting. There might be another file transfer method available. Thanks stuck. I almost forgot to check for other file transfer method.

I've not tested it yet but you can try this to play your sound. local soundManager = getSLSoundManager() local soundList = soundManager:getStorySounds() for i=0, soundList:size() - 1 do --print(soundList[i]:getName()) if (soundList[i]:getName() == "filename_maybe") then soundList[i]:playSound() end end --[[ -- There's two more sound managers available but I haven't look check any of it yet. getWorldSoundManager() getSoundManager() --]]

For custom player data, I recommend you to create your own player data storage instead of relying on player:getModData(). You can use player steam id as primary identifier and player character forename and surname as the secondary identifier. Reason for secondary identifier is because of the pc with co-op players. The only way to recognize who is actually who is to check the character's name. Related functions: player:getSteamID() player:getDescriptor():getForename() player:getDescriptor():getSurname() getModFileReader(strModId, strPath, false) - last argument is for creating a new file but i don't recommend it. getModFileWriter(strModId, strPath, bCreate, bAppend) FYI, getModFileReader returns a java bufferedreader object while the other one returns custom writer class with exposed write, writeln and close functions.

I've been busy lately so now I would like to give report my current progress on the mod loader. 1. Turning it from SP into MP based mod loader requires me to ensure that player request for server response and wait for it. Once established, only then can they start loading the mods. I haven't tested it on dedicated server yet but for listen server host, you can only get server response few seconds after you're spawned using the 'OnPlayerUpdate' event. This is caused by listen server to start ticking right after the host player start the player update tick. For MP clients, I think it might be fine to use 'OnConnected' event but this will need further testing which I am planning to do tonight. 2. Mods using the mod loader feature can only be loaded after player update start ticking or when connected if possible. Custom event is needed for mods that initialize data using those two events. 3. There might be a need for waiting lobby to ensure that the connected players has fully loaded the mods. 4. I tried sending read-only loading order array through server and client command but it's not working since metatable are not transmitted together with the array. So, there's a need to apply custom metatable after the client receive the data. 5. After going through intensive testing, it's possible to make clients join without having version mismatch issue. This require modders cooperation though. They'll need to make multiple workshop pages. - Server Mod: You don't need to enable the mod, just copy mod script files for server and clients to server folder. Server will let clients to download those client files when they joined the server. - Client Mod: Contain some other files such as textures, item definitions and etc. These files usually don't get updated that frequent. It's fine to enable it in workshop mod list. 6. Need UI for download progress. There you go. Sorry for the rough report though. I'll take a look at it later.

Nah, more like replacing the distribution logic with yours. Just in case you need better manipulation on the distribution. I had a look at the source again and the reason why your map items didn't spawn probably because the loot table you modified didn't get selected for loot generation. Single type of container can contain more than one loottable, and if you didn't force it, it has chance of not getting selected. Pretty sure those mods have the other loottable entry removed or set it's weight lower. Otherwise, there's high chance their items of not being spawned. Here's the problematic part. -- 'media/lua/server/Items/Distributions.lua -- Look at the procList -- Each entry is a loot table to be selected -- Related functions inside ItemPickerJava: #rollProceduralItem and #getDistribInHashMap gasstorage = { counter = { procedural = true, procList = { {name="JanitorChemicals", min=0, max=99, weightChance=100}, {name="JanitorCleaning", min=0, max=1, forceForTiles="fixtures_sinks_01_0;fixtures_sinks_01_1;fixtures_sinks_01_2;fixtures_sinks_01_3;fixtures_sinks_01_4;fixtures_sinks_01_5;fixtures_sinks_01_6;fixtures_sinks_01_7;fixtures_sinks_01_8;fixtures_sinks_01_9;fixtures_sinks_01_10;fixtures_sinks_01_11;fixtures_sinks_01_16;fixtures_sinks_01_17;fixtures_sinks_01_18;fixtures_sinks_01_19"}, {name="JanitorMisc", min=1, max=1, weightChance=100}, {name="JanitorTools", min=0, max=1, weightChance=100}, } }, crate = { procedural = true, procList = { {name="GasStorageMechanics", min=1, max=99, weightChance=100}, {name="GasStorageCombo", min=0, max=99, weightChance=80}, } }, metal_shelves = { procedural = true, procList = { {name="GasStorageMechanics", min=1, max=99, weightChance=100}, {name="GasStorageCombo", min=0, max=99, weightChance=80}, } } } Hope this new information helps with your next distribution test.

Create a new server profile first before you do a reset on your current server profile because it might be caused by different bug. That's why you should try this step first.

It's good to know that it's working as expected. I was suspecting the rolling magic mentioned by the developers user known as 'TheCommander' is not working that well when the item list is big (20+ items) and the number of rolls is low(4~6 rolls). Hence the reason why you can't find it in the previous test. No worries, it will get much better once you get used to it. Or, you can try improve your lua environment by simulating some keywords from other languages which I am doing right now. Yeap, that's a good idea. If you don't mind, I would like to suggest you to take a look at' zombie.inventory.ItemPickerJava' and see if you can simulate the distribution function. The distributions probably can be disabled by assigning empty table to 'ProceduralDsistributions.list' and then use 'OnPostDistributionMerge' event for custom distribution. I haven't check the code in details but based on the server ini, there might be a balance bug for safehouse. A safehouse might be able respawn loots as long no one is constructing anything inside and their item containers have lower amount of items than the respawn threshold. Do pay attention to that possible bug if you're planning to simulate or replicate the function for mod usage. Much better now. Do you mind if I use this? I'm planning to work on roguelike mod which focused on short term gameplay once my radar mod is completed and item distributions is in the checklist. And, no problem. Glad that I can help you.

No problem. And I missed one more folder. 'game_folder/media/lua/client/ISUI/PlayerStats' Good luck.

Hi Fekaziroh, is it possible that you can't place any item inside any other containers other than the floor? Can you still pick up those items on the floor? And, have you tried making a new server with new character? Your player data or character data might has issue. Your client logs has bunch of dupe item id errors and item transfer was rejected by the server because of it. Pretty sure this is anti-cheat measure for item duplication so, if you can play on new server without any problems, you might need to kill your current character inside your previous world or wipe all player data.

I had a look at the proceduraldistributions.lua and it seems like there should really be no problem with your second code. Just need to find out if the function is actually being called. The code has been edited with further improvements. Not sure if the variable argument version will work since I've not tried it yet.

You can bypass it actually. I already had a look at it. Find 'ISPlayerStatsUI.lua' inside 'game/media/lua/client/ISUI'. It also has information on how to programmatically assign traits and how to send those data on player creation. Try extend the 'ISPlayerStatsUI:setVisible' function. You can probably prevent character creation UI from being displayed by doing that. Look for the right function if it didn't.

Hi, have you confirmed that the new data has been properly inserted? Did you tested the second code on a new world? Or, tried using the first code again and see if there's any difference? The code looks fine to me. So, if you've already confirmed that the new data has been properly inserted or the event didn't call your function, that means it's probably the server loot spawn settings. It didn't generate new loots after the world was created. And I would like to suggest you to switch iterator with indexed for loop. It's much better for your case since you don't really need to declare the iterator function. Here's the clean version you can use for your server. More like anyone are welcome to use it. local MapItemList = { "MyFancyMap1", "MyFancyMap2", -- ... } -- edited: was looking at proceduraldistributions.lua for loot table names, looks like this one is clear to add local function getLootTable(strLootTableName) return ProceduralDistributions.list[strLootTableName] end --[[ haven't try variable argument yet so it might not work -- insertItem(tLootTable, strItem, weights separated by comma) -- insertItem(tLootTable, strItem, 50, 20) local function insertItem(tLootTable, strItem, ...) for i, iWeight in ipairs(arg) do table.insert(tLootTable.items, strItem) table.insert(tLootTable.items, iWeight) end end --]] local function insertItem(tLootTable, strItem, iWeight) table.insert(tLootTable.items, strItem) table.insert(tLootTable.items, iWeight) end local function preDistributionMerge() for i=1, #MapItemList do local strItem = MapItemList[i] -- CrateMaps Room local tLootTable = getLootTable("CrateMaps") insertItem(tLootTable, strItem, 50) insertItem(tLootTable, strItem, 20) -- variable version --insertItem(tLootTable, strItem, 50, 20) tLootTable = getLootTable("CrateMechanics") insertItem(tLootTable, strItem, 2) tLootTable = getLootTable("GasStorageMechanics") insertItem(tLootTable, strItem, 2) tLootTable = getLootTable("MagazineRackMaps") insertItem(tLootTable, strItem, 20) insertItem(tLootTable, strItem, 10) --insertItem(tLootTable, strItem, 20, 10) tLootTable = getLootTable("StoreShelfMechanics") insertItem(tLootTable, strItem, 2) end end Events.OnPreDistributionMerge.Add(preDistributionMerge)

In other words, you are suggesting for capacity based inventory system. This inventory system seems to fit your suggestion. It's a good suggestion but this thing can be done through mod if I'm not mistaken. Developers are quite busy so this suggestion might be pushed back to later date or not considered at all. So, there might be new / experienced modder wants to try making this mod. I'll try to write the general requirements here. Modders will need to figure out which one is suitable for server based and which is suitable for client based. 1. Set player max weight to higher number so that it wouldn't interfere with new calculation. Use this method 'player_instance:setMaxWeight(int newMaxWeight)' for it 2. Calculates the capacity used by an item using new formula which includes size and weight into calculation. 3. Creates new inventory UI which should display 'Capacity' instead of 'Weight' to avoid confusion. (Look for related inventory ui files at 'game_folder/.../media/lua/client/ISUI/' directory) 4. Creates a configuration file which includes new data for items which is weight and size for items, and max capacity for containers. Use this configuration to get data necessary for calculations 5. Tweaks the data until the capacity looks quite realistic. 5. Send new item data to all connected players so that they can pass it to their new inventory UI for calculation. Some steps might be missing but overall it should be good enough for any modder to try making it.

No problem, I'm working on something similar too since my mod keeps breaking whenever I make a big change. Just don't know if there's a mod version check when joining a server. Actually, I would like to say thank you since your thread gave me the direction for dealing with broken script update issue. Based on my experience with making a module loader, the path used by binary file reader / writer should also work the same way on client-side since there's no server / client validation. So, I did a quick test on window just now and confirmed it. Window user use the same folder for both server and client. Precaution is needed when using the binary file writer.

You can look at this mod. The author did describe some steps for displaying data. PZTracker General outline would be, save the data to a file, you create external program to read the file and send it to your website server.