[utility mod]ModHelper(wip)

[s_f]

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

Edited July 18, 2021 by s_f
updated attachment

[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.