s_f

Started work on a new module ItemWrapper which is to add additional functionalities non-intrusively around item types (note: NOT InventoryItem, but the item definition objects). The basic idea is to make it easy to query/find relations between items (and recipes) to hopefully achieve the following: 1) get rid of manual "compatibility patches" to support new items in other mods, by using general scripts to automatically find and include items that can be used by a mod instead. (e.g. giving new weapons with accompanying ammo to NPCs in an NPC mod) 2) allow programmatic discovery of item relations. e.g. automatically find and detect "package" item types that can be "unpacked" into some item that we want (via recipes that exists), without hard-coding. This is prob an important step towards better AI, imo. e.g. allow AI to figure out how to acquire some item types from available (esp trivial ones like unpacking) dynamically (so should work with other mods without manual work) To make it efficient, internal lookup tables are constructed and remembered whenever they are needed for the first time, so that subsequent use will be fast.

Result of a recipe has to be multiplied with the "Count" of the result item's definition. e.g. for the above case, 556Bullets have a Count of 5 in the item definition item 556Bullets { Count = 5, Weight = 0.025, AlwaysWelcomeGift = TRUE, Type = Normal, DisplayName = .556 Ammo, DisplayCategory = Ammo, Icon = RifleAmmo308loose, MetalValue = 1, } item 556Box { Weight = 1, AlwaysWelcomeGift = TRUE, Type = Normal, DisplayName = Box of .556 Bullets, DisplayCategory = Ammo, Icon = RifleAmmo308, MetalValue = 40, } This seems very unnatural from data perspective though. I am guessing that this is done by dev because it is easier to generate loot in units of "Count" for "heap type" items of large numbers. But it creates semantic inconsistency. e.g. if I say double the count to make 556Bullets appears in units of larger number, say 10, which effectively doubles the number if it found without changing the distribution, it messes up the recipes: Each Box unpacks to 12x10 = 120 bullets now. But in reverse, it just takes 60 bullets to make a box. Well, it may make some players very happy, but it is still an issue. Suggestion to dev (if anybody is actually reading this in a seemingly semi-abandoned forum/community) 1. Do not use Count in recipes. only use it for distribution. (for for backward compatibility, make all count 1, and use another parameter to denote properties related to distribution) 2. Fix the recipes and related systems (multiply the result count by the previous count for the result item type) ^ reason for this is that it won't break any existing mods that currently uses the count to correct recipes. and also makes the recipes independent of loot generation

EDIT: Solution in next post. I noticed that the "count" required for packing/unpacking ammo boxes differs by a factor of 5. Why is this so? recipe Open Box of .556 Ammo { 556Box, Result:556Bullets=12, Sound:PutItemInBag, Time:5.0, } recipe Place .556 Ammo in Box { 556Bullets=60, Result:556Box, Sound:PutItemInBag, Time:5.0, }

seems like the modding community (for scripting) is either not very active, or this forum isn't the place? If anybody know of a better place to get help on scripting, please give me the directions. It will be very much welcomed. Or it may seem that my foray into PZ modding have to be ended prematurely...

Adding an example: Example: possible emergent behavior possibly achievable from above model: Scenario: Survivors before meeting zombies. - Hungry ones will try to find and eat food - Tired ones will rest (sit on ground, or nearby chairs) - Inhured ones will try to treat/bandage. Scenario: Survivors met with zombies. - All previous actions (from bnefore meeting zombies) are interrupted. - Cowardly ones may simply run away, while others will try to fight back while the odds are good. - But when the odds turns bad (more zombies approach), they may all try to run away, especially after their allies started running. - When they are cornered and have no way else to run, some whose personality "never gives up" will continue fighting until they die. - Those not so strong mentally may simply breakdown and do nothing or panicked and do panicky things while the zombies pull them down to feast on them - Others may decide to end their lives, ranging from a bullet to the under chin, or for the more vengeful type, throw a hand grenade at his feet. ------------------------------------------------------------ Possible common 2-tier ai mode structure that drives all the above behavior: - Mode(T1): Fight or Flee or Giveup - active when there is immediate danger. - Mission(T2):Fight, goal:all hostiles dead - Task:discreet attack (not to draw attention from zombies further away, using quiet melee or silent weapons) - Task:all-out attack(just use best weapon and any other means necessary) - Mission(T2):Flee, goal:no hostiles near - Task:Flee to: (tries to flee to a spot or in a direction) - Task:Flee: (tries to flee based on concentration of danger) - Mission(T2):Giveup, goal:die - Task:Do nothing - Task:Panic (do random stuff/scream/throw/drop items) - Task:Suicide (choose a means available) - Task:Vengeful end (choose a means that may also hurt nearby hostiles) - Mode(T1): Survival - active when a need is high enough - Mission(T2):Tend to Injuries - Task: Tries to ask ally for help - Task: Tries to treat it - Task: Tries to find necessary items - Task: Tries to ask for necessary items - Mission(T2):Tend to Hunger - Task: Find and Eat food from inventory - Task: Find and Eat food from surrounding - Task: Ask allies for food - etc Basically, each NPC ai selects an activated mode based on priority. The Mode will continuously (periodically) evaluates the current context and sets/changes the Mission (potentially interrupting current mission) An active Mission will loop to examine the options available to fulfil the goal (i.e. Tasks) and picks the most attractive one (based on objective factors like NPC status. item availability and environment and subjective reasons like NPC preferences and personality) as well as odds of success (e.g. if previous attempts failed, then the Task becomes less attractive) At the same time the Mode-Selector will also (periodically) checks if the current Mode is no longer applicable, or if another higher priority Mode is activated and may switch the Mode where necessary (interrupting all current missions and tasks as a result).

--- TL;DR: imagined model for ai-related stuff meant to drive NPC (mods). Should be of interest only for mod developers related to NPC stuff. --- a (wip) simple conceptial model for NPC ai (for potential NPC mods) dumped for ideas exchange. Pls note that it is just a first attempt made over a short period of time by a relatively new player who does not understand the whole game system that well yet. So take it with a pinch of salt if something is not applicable (will appreciate feedback on those though) as it is mostly just a dump of ideas without much follow-up on applicability and feasibility. ------------------------------------------------------------ 1. model Entity stats - Needs, Character (preferences), Attribute (skills and psuedo-skills). Basically made up of what is already in-game, plus whatever that is required as extra. May potentially have a custom-need framework that allows 3rd party mods to add their own derived needs (needs that are determined by existing stats/needs/context) ------------------------------------------------------------ 2. model Entity memory - long term memory, including group/faction shared memory, short term memory e.g. seeing the party leader use a particular door/window/sheet rope (so potentially will use it when following), interaction memory (talked to this guy, that guy gave me something etc, did some farming work etc) Basically split into 2 types: a. static memory which are always persistent data used by the engine. e.g. remembering where the base is, or which faction/party the entity is in b. historical events (long term ones which are important ones that are kept, short term ones which are removed after some time. e.g.daily/weekly/monthly) c. general knowledge (see point 6 Helper modules - knowledge) ------------------------------------------------------------ 3. 2-tier mode-based AI - I'm not expert in ai, but this seems to be the easiest way to implement a more "responsive" AI, but having basic "modes" which assess the needs, availability of means to satisfy the needs, then decide what to do based on the weight, modified by character (preferences). Each mode basically provides a list of pre-determined "goals" to satisfy some needs, and routines to list out the "means" of sastifying those needs along with the desirability (usually based on how effective the means is, modified by entity's character) The weights may also be modified indirectly by moodlet (e.g. a "suicide" goal may have a positive weight for very negative "depression"(need) which usually will not be considered at all unless depression is really, really high. But say some happenings (memory) recently caused a "depressed" moodlet which seriously increase the depression for a time. If not rectified quickly, the NPC entity may suddenly find that "suicide" goal very attractive, and will look for "means" to achieve it) Above this, there is a "mode-selector" which changes the mode based on "urgency". A mode of higher urgency always takes precedence, and only when the mode of higher urgency reaches "satisfied", will the mode-selector "drop down" to the modes of lower urgency and so on (based on mode-specific evaluation functions) Note that this just the basic model for the individual AI. The actual weights and actions available depends on the entity context. e.g. if alone, an NPC entity will have to be more autonomous, compared to NPC in a group. What is different though is just the possible tasks available in each context and weights for selecting. The structure of the ai model doesn't really change (though it is possible to insert/remove/swap the modes) the "modes", "goals" and "means" can potentially be modified/extended by other mods (in addition to the core set provided) E.g. of modes in order of "urgency". a. Fight or Flee - basically in the face of immediate danger (that can harm/kill the entity within a short period of time if unattended). Danger can be hostile enemies, but also things like hazards like fire, or conditions like potentially fatal unjuries. This simple mode basically only results in two kinds of outcome: whether to fight and contain the danger (kill/drive away hostiles, extinguish fires, treat injuries) , or to flee from the danger (only those applicable like enemies and hazards. you cannot escape from your wounds). A sub-group of this is to "fight" for another entity of relevance (e.g. an NPC doctor in a party treating serious wounds for party members once he is no longer in immediate danger) It will become "satisfied" when there is no longer immediate danger around. b. Short-term Survival - longer term than immediate danger, but will threaten the Entity's existence if not attended. Basically attending to current needs like treating injuries, food, water, rest, heat ,hygiene c. Long-term Survival - different from short-term survival, this mode tries to to longer-term (predicted) needs, often by producing/acquiring/stocking up the corresponding kinds of supplies. e.g. scavenging/foraging/farming/water-purification d. Idle - when the above modes are satisfied or stalled (cannot be fulfilled currently), will switch to this ladst mode which is filled by all other possible tasks, which are selected based on the entity's context and character. This mods is always "active" as the lowest priority mode. - skilling : reading skill books/exercise - equipment maintenance : swapping/repairing/resupply (ammo/food/water) - leisure : reading, watching tv, listening to radio, talking, playing games, rest Each mode will have an "activation" function and a "satisfaction" function. when activated, the mode will become active, and if it is of higher priority/urgency than current mode, mode-selector will switch to the mode immediately (and perform task selection and take action). When satisfied, the mode will become inactive, and mode-selector will choose next mode with highest priority. Extensions to this (by 3rd party mods) can be: adding new "goals" and "means" to an existing mode, or adding new modes with a different priority/urgency which will automatically be considered by the mode-selector. ------------------------------------------------------------ 4. Missions, Tasks and Actions (note: not directly related to any in-game code classes of similar names) These are states and classes which is sort of orthogonal to the 2-tier mode-based AI. in my simplistic definition: a. actions - the lowest level is simply that. an action. it doesn't have a goal and the result is not handled within the action (but by the context that performs the action). It just performs (or attempts to at least). Actions should be close to what the game can perform at the lowest level (most of the time, one-to-one with in-game Action class). e.g. pickup/equip/drop/use/unequip an item (which must exists, already be nearby/in inventory and accessible), rack/reload firearms, perform interaction with fixed item/tile (must already be in range) b. task - may consist of one or more actions, with evaluation of the outcome (whether success or fail, and any task-specific sub-results). Tasks can potentially be hierarchical (main task spawning sub-tasks). A task MUST eventually complete. E.g. for tasks: find something to eat (which can spawn sub tasks of looking for food, and actually moving there and then eating it), it must either end with succesfully eating something, or failed if it cannot be achieved. c. mission - an on-going context with set goal(s). It will have a component that generates tasks from the goal and actual context (e.g. environment, entity abilties) to attempt to fulfil that goal. It will not end by itself, and will simply loop to generate more tasks when the current tasks are completed or interrupted (or idle if there are no tasks generated). Instead, it will prob be started and stopped from outside (e.g. AI mode-selector, or player actions/orders). E.g. of missions: fight mission (idles until all hostiles dead or interrupted), flee mission (idles when no more immediate danger, or no possibility of escape left), maintain-needs (tries to survey entity need and generate tasks to fulfil those needs otherwise idles). (Note that if a mission is idling, it will prob satisfy the correpsonding ai mode to change modes for other behavior modes) By combining missions, tasks, actions with the 2-tier mode AI, hopefully, we can achieve a basic ai model that is flexible enough to model a wide-enough range of behavior. It will also become possible for developers to collaborate in a more organized manner, by breaking down the work specifically. E.g. some developers can concentrate on improving/perfecting some basic tasks, which can be used by other developers who design "missions", which in-turn can be aseembled into "modes" that can be executed by the mode-selector during run-time. ------------------------------------------------------------ 5. Entity interaction model (currently just conversation) Basically a simplistic model for NPC interaction with other NPCs or the player. Currently, I list down the following simple kinds: a. flavor speech - these does nothing consequential, but just displays speech from the NPC which does not require response. e.g. battle-cry when fighting, or random mumbling to self b. casual interaction - these are non-commital interaction requests where response is not necessary, but another NPC may potentially repond. e.g. greeting (other NPC may greet back if the greeting itself is not a reponse already, or just ignore it), chat (talks about random stuff, can pick from events in "Memory", response can be approval/disapproval/neutral, and then if the NPC is interested, may "counter" with another chat from his/her own Memory) When the addressed party is the player, may need some kind of non-intrusive conversation response interface which will quickly fade away (assume no response) if not addressed within a short period of time. c. important interaction - these are commital interaction request where the addressed party must respond (where usually one of the response will be to reject the interaction). E.g. asking for food/water/supplies, or asking for help with injury. When the addressed party is the player, may use similar response intrerface as casual interaction but with longer timeouts, which assumes "rejection" if not addressed within the time. d. notification - these are meant to send notifications to NPC(s) nearby with no expectations of response. e.g. "Hostiles spotted!" (which can caused friendly NPCs nearby to switch AI-mode to fight-and-flee faster, without having to actually see the hostile themselves). Or "(resource) spotted" when scavenging, such that nearby NPC with some needs (like food/water) can potentially come and pick it up. Prob still need more work to build this up into an implementable model. Each kind of interaction is seen as a "protocol" which is provided as "base-class/template" that can potentially be extended by 3rd party modders and still be integratable into the system. Each "protocol" can also define its weights wrt needs and character, so that they can potentially be integrated in to the AI model (used in tasks) (e.g. instead of hard-coding interactions to fulfil some tasks, the task can dynamically examine all interactions including those added by 3rd-party, and make them available to the NPC entities) For each kind of interaction, there can also be a speech-pattern model which can selects an exact speech pattern based on the NPC attributes and character (e.g. a gentle, elderly male ex-cook, vs a young, hot-tempered female student). Ideally, speech patterns can be freely extended by 3-rd party mods. ------------------------------------------------------------ 6. Helper modules These are more general modules which I think would be useful. The reason for listing them separately is because they may potentially be used (re-used) by many tasks/missions, so instead of each task/mission developer coding the functions in their own creation, provide a common library so that tasks/missions can be developed and used more easily. - Survey - I imagine that this module will consists of functions which surveys the in-game environment objectively (no preferences/heuristics, which should be done subjectively on the results). E.g. look for all containers with some inventory item within a specified region (list of rectangular bounds), or list of all potential entry points to a specific regions - Assess - often using the results from Survey module, this module will add priorities/weightages by analyzing those results with some supplied conditions/weights. E.g. prioritize the potential entrances to a region based on security (hostile), hazard (fire/glass), ability (e.g. strength to climb sheeet-rope, climb over fence, key to unlock a door < allow NPC to carry keys and automatically lock/unlock doors) - Schedule - allowing NPCs to make long term plans by making schedule for pre-planned tasks or make a time-table for regular tasks. Provides (in-game)date-time-based functions in addition to a "table" that can be indexed/sorted by (in-game) date-time. - Plan - companion to schedule. Should include functions that can predict or allocate how long a task will last (potentially allow decision to interrupt a task to go to next task in schedule, or to cancel next task). Prob uses Survey/Assess a lot too. - Knowledge - basically a tuple-based model of relating custom concepts, so that it may become possible to "teach" NPCs new concepts and use them dynamically in AI instead of being hard-coded. e.g. instead of hard-coding "food" related code, instead define the "hunger" concept (based on the in-game need) and relate it to "food", and then relate it to the possible sources of food including the related tasks. So in the future, by just defining new relations to existing concepts, the knowledge-base can be used to figure out how to satisfy certain goals without explicit coding. Very far-fetched and may not be feasible (computationally speaking), but this is the foundations of "general" ai Prob not feasible to be used as basis for all tasks, but once the basic tasks that can satisfy gameplay are up, can potentially try to do "knowledge-based tasks" which makes use of the knowledge model to figure out what to do dynamically. May have more which I forgot atm, (which is why it is good to dump ideas once in a while), but I think that is already a lot to write (and read). If you have read the whole post until here, thank you for your time, and if you have ideas, comments, suggestions, pls add them to this post for further discussions. until next time

EDIT: nvm. solved it myself. The solution is as follows (for people who might need it) ---- -- Assume that we have a scriptItem we get from getSCcriptManager():getAllItems() local scriptItem = ... -- the way to access some properties/methods like MaxAmmo and MagazineType is to use the id to create an InventoryItem local item = InventoryItemFactory.CreateItem(scriptItem:getFullName()) -- then we can access those properties local magazineType = item:getMagazineType() local maxAmmo = item:getMaxAmmo() Hope this is useful for somebody ---- I supposed that getScriptManager():getAllItems() returns all item definitions in the game as a Item type. However, it does not seem to have some methods/properties that the in-game InventoryItem type does for example getMagazineType()/MagazineType getMaxAmmo()/MaxAmmo Both the methods and the properties are undefined. How could I get such properties from the Item type (returned by getAllItems)? Thanks in advance

Adding more info It seems that the file "recipecode.lua" cannot be found/required. I have the testing code in "shared", but the above file is in "server". How is the server, shared and client folders managed? I had thought that they will be overlapped wrt require, but is not sure how the code should be split. If I am writing something in shared (as a utility) that needs the above file, how can I access it?

I am trying to look into a possibly better "standard" for manipulating items (adding/removing/changing etc) via items The aim is to allow mods to mesh better together without having to explicitly know each others content or list each other as explicit requirement (prob used to order how the scripts are "built" when the game starts) For item manipulations, I've broadly categorized into 3 categories (if anybody has ideas on improvement, please comment) 1. Item adding 2. Item manipulation/removing 3. analysis/mass processing (e.g. prepare lists of items in "categories" for use by some mods). The categories have to be executed in order for things to work. counter e.g. If a mod tries to say, halve all item weight (via code), but is executed BEFORE a mod that adds items, then the weight modification will not be applied to the items added by 2nd mod. Or if a "analysis" mod e.g. one that dynamically assigns item category by inspecting each item is executed before item adding/manipulaton, then some items will not get assigned categories or get "outdated" categories (because it is already changed) So ideally, for many mods dong things to items via lua script (note: not the txt item script), each mod that does any of the 3 operations will break up the 3 parts of the code, and use game events to order them such that all part 1 of all mods gets executed before all part 2 and so on. My problem now is that: what are the suitable in game events for each of the 3 parts (multiple options if possible)? So far, I only have one candidate which is OnGameBoot, which can be potentially used for part 2/3 (leaving part 1 to be executed when the mod scripts are loaded, so don't need to attach to game event). OnGameStart doesn't seem right as the 3 parts are not dynamic. Thanks in advance for any help/clarification/comment

Basically, I wanted to try modding. But I wanted to keep my sanity as well. So as a way of digesting what I have learnt (PZ and lua), as well as a way of paving the possibility of actually creating/extending a content mod (I am very interested in NPC related ones btw), I've started to put together a "library" of "building blocks" of sort initially for my own use. But it was slow, especially when I am stopped by many points which cannot continue until somebody can help me (e.g. in forums). So I thought of maybe sharing my current work and idea, with some goals in mind 1) See if there are people interested in collaborating on this together. Can hasten the development so that we can get to the interesting stuff better. Ideally, this can be released to community maintenance (if it is really not a piece of sh!t, that is). 2) potentially discover some good practices of structuring mods which can maybe give more opportunity to integrate without issues. The easiest way is the try to put a common piece of "gear" in them. 3) potentially provide some ready-made utilities to modders who needed them without having to write/search for them ourselves, in a uniform style/convention. I admit. I'm lazy. That motivates me Currently, the main "building blocks" I have working are: 1) Memos Basically an abstraction away from files that allows the user to read/write data in strings (or array of strings) or data objects (tables with simple data, nested tables ok but no cycles) persistently (currently it is implemented as files, but can be swapped with other serialization methods). Internally, objects are stored as JSON, which may be easier to use in some contexts. Variants of these corresponds with the file operators game engine provides, namely one specific to Mod folder and one for the user's Zomboid folder. I'm still working on one that is specific to a "world" (savegame), so that custom add-ons data to save-game can be easily added by mods. 2) Event A simple implementation for publish-subscribe pattern. Meant to construct more complex subsystem than being used directly though. It is also used to implement a component EventManager in the mod which provides an easy way for mods to publish custom events and potentially be subscribed by other mods so that they can potentially collaborate (without having to see/touch each other's code). Can also be used to transform native game events into custom events (e.g. say a "multitick" event that callsback every N ticks), or to breakdown a single event to provide more fine-grained control, e.g. OnGameBoot may be triggering for some mods in an unspecified order unless the mods explicitly list other mods as requirements. The native event can perhaps be "broken down" into 3 sub events (OnBootImmediate, OnBoot, OnBootDelayed) which will be invoked in order, so that mods can specify at least which category it prefers and have the EventManager order the callbacks instead. 3) Predicate Helper classes to create predicates that can make some functions more general (e.g. pass in a different predicate to filter the results differently in the same function). The ideal case is to merge similar functions (with just a few lines difference in code) into the one function whose behavior can switched easily using predicates. 4) LootTable Simple way to help procedural generation of stuff (not necessarily just "loot"). Currently supports selection by weight (items with higher weight has proportionately larger range of being selected) and uniform selection (all items have equal chance). Say goodbye to having to insert many copies of items into a "loot list" just to make something appear more often. 5) List Patches and Extends the in-game LuaList (with backup implementation to work outside PZ). Potentially more convenient alternative (wrapper) for the native lua table. 6) ItemWrapper A wrapper around the in-game object for item definition ( returned by getScriptManager():FindItem()/:getAllItems() ) that provides additional functions non-intrusively. e.g. - getAmmoInfo() - returns additional info if item is a valid ammo. contain references to all relevant weapons, magazines - getAmmoMagazineInfo() - returns additional info if item is a valid ammo magazine. contain references to ammo used and all relevant weapons - getAmmoWeaponInfo() - returns additional info if item is a valid weapon that uses ammo. contain references to ammo/magazine used - getPackages() - returns array of records which tells what "packages/boxes" items can be unpacked into this kind of item. from recipes. Others are still in the work (or stalled until I get help...) See under doc subfolder for more info. EDIT: - updated to 1,2,0 ModHelper_1_2_0.zip

Hi. Seeking help regarding a particular thing with recipes (via lua) The "[Recipe.GetAllItemTypes.*]" tags are often seen in vanilla recipes, which I assumed is a short hand for managing extensible list of tools that serve the same function (Hammer, CanOpener, Saw, Screwdriver). However, there seems to be only a few categories, and I am not sure how items are actually added to the list (I suspect it is the "Tags" definition in items scripts?) I've found seemingly related definitions in recipecode.lua and tried to access the functions, but failed. requiring the file itself also failed. (I am not sure, but does the file being on server/shared/client folder matters?) Recipe = {} Recipe.GetItemTypes = {} Recipe.OnCanPerform = {} Recipe.OnCreate = {} Recipe.OnGiveXP = {} Recipe.OnTest = {} function Recipe.GetItemTypes.CanOpener(scriptItems) scriptItems:addAll(getScriptManager():getItemsTag("CanOpener")) end function Recipe.GetItemTypes.Hammer(scriptItems) scriptItems:addAll(getScriptManager():getItemsTag("Hammer")) end function Recipe.GetItemTypes.Saw(scriptItems) scriptItems:addAll(getScriptManager():getItemsTag("Saw")) end function Recipe.GetItemTypes.Screwdriver(scriptItems) scriptItems:addAll(getScriptManager():getItemsTag("Screwdriver")) I wonder if this feature still working? If so, how can I access it in game to translate a list item id, e.g. "[Resource.GetItemTypes.CanOpener]" into the actual list of item ids in the list? thanks in advance