Banjo

I don't know if this is strictly classed as a "bug", but it is not possible to write journals, etc. using blue pens, red pens or crayons. Only black pens ("pens") and pencils can be used.
 
I took a look at the code and I think it might be because "ISInventoryPaneContextMenu.lua" contains the following line:
        local editable = getSpecificPlayer(player):getInventory():contains("Pencil") or getSpecificPlayer(player):getInventory():contains("Pen")
... that should be...
        local editable = getSpecificPlayer(player):getInventory():contains("Pencil") or getSpecificPlayer(player):getInventory():contains("Pen") or getSpecificPlayer(player):getInventory():contains("BluePen") or getSpecificPlayer(player):getInventory():contains("RedPen") or getSpecificPlayer(player):getInventory():contains("Crayons")
 
???
 
Currently, I use a modded version of "ISInventoryPaneContextMenu.lua" to fix this, but it wold be great to have it fixed officially, if possible. It doesn't make sense if I can't write with a blue pen but can with a black one, surely?

Simple question, related to my other thread but since nothing showed up in searches I thought it would be better to ask in a new one so others can find it for help if they want to do the same...
 
EDIT: SOLVED!
 
I figured it out, but for those who are wanting to know how, here's the code from Robomat's awesome Co-Ordinates Viewer mod...
 
        local absX = player:getX();
        local absY = player:getY();

        local cellX = absX / 300;
        local cellY = absY / 300;
        local locX = absX % 300;
        local locY = absY % 300;
 
absX and absY are "absolute" co-ordinates (where in the whole game world you are)
 
cellX, cellY, locX and locY are "relative" co-ordinates (current cell and location within it, as used in start spawns)
 

I don't know if this is strictly classed as a "bug", but it is not possible to write journals, etc. using blue pens, red pens or crayons. Only black pens ("pens") and pencils can be used.
 
I took a look at the code and I think it might be because "ISInventoryPaneContextMenu.lua" contains the following line:
        local editable = getSpecificPlayer(player):getInventory():contains("Pencil") or getSpecificPlayer(player):getInventory():contains("Pen")
... that should be...
        local editable = getSpecificPlayer(player):getInventory():contains("Pencil") or getSpecificPlayer(player):getInventory():contains("Pen") or getSpecificPlayer(player):getInventory():contains("BluePen") or getSpecificPlayer(player):getInventory():contains("RedPen") or getSpecificPlayer(player):getInventory():contains("Crayons")
 
???
 
Currently, I use a modded version of "ISInventoryPaneContextMenu.lua" to fix this, but it wold be great to have it fixed officially, if possible. It doesn't make sense if I can't write with a blue pen but can with a black one, surely?

I get the exact same thing! Have posted a few times on the Steam forums with no response and was thinking I needed to post here now, so glad someone else finally mentioned it!
 
Using IWBUMS build 41 (latest).
 
I've got an older ATI graphics card and using Windows 7, but never had serious display issues with PZ (been playing since Kate & Baldspot!) until now. A new card would be nice, but obviously not possible during a real-world pandemic so hopefully that's not the only solution!

Simple question, related to my other thread but since nothing showed up in searches I thought it would be better to ask in a new one so others can find it for help if they want to do the same...
 
EDIT: SOLVED!
 
I figured it out, but for those who are wanting to know how, here's the code from Robomat's awesome Co-Ordinates Viewer mod...
 
        local absX = player:getX();
        local absY = player:getY();

        local cellX = absX / 300;
        local cellY = absY / 300;
        local locX = absX % 300;
        local locY = absY % 300;
 
absX and absY are "absolute" co-ordinates (where in the whole game world you are)
 
cellX, cellY, locX and locY are "relative" co-ordinates (current cell and location within it, as used in start spawns)
 

I hope you don't mind RoboMat, but I updated this mod of yours to work on Build 27.  I added a poster.png, changed the version number and added a local 'updatedby' variable.  It's posted here:
 
http://www.mediafire.com/download/1q4id2gg058ln0j/RMCoordinateViewer_v0.7.3.zip

The 2D player-model is very pixelated in comparison to the rest. 3D model is just fine.
 
Looks really nice. Just better imo. And i cant see how the artstyle changed.
 
 

I'm not berating anyone, and of course you are free to and even should do what you feel is best for the project. I am just voicing my opinion that a little heads up before it went live would not have hurt anyone. This being your project, you are absolutely in the right to say that it could and would hurt things, but I think it's an over reaction to say that my post was berating the developers. This sudden change will be an exciting surprise to most and a blind-siding nightmare to others. I have no strong opinion either way.

snip
 
Yes, I agree, you do get thirstier faster.
 
I think the moodle thing is actually very interesting. As in real life everyone wants to be in a state of comfort. The moodles present discomfort, and the player wishes to alleviate it even if it is only mild. I think it adds to the game, it shows our pampered nature and why, realistically we wouldn't survive for a long time. The inability to ration food or water would be a huge problem for most people and I think it should be re-added as a challenge for players.

When I think of it, I don't know why "auto-drinking" is a thing. No one is constantly sipping from a water bottle. When they're thirsty they drink. For instance, when I sit at my desk and I'm thirsty I get a cup of water and I drink the cup of water.
 
I think the oddity of it is made more apparent when you think if you had a piece of food in your inventory and you auto-ate it.

I definitely support this idea. Sandbox is what makes PZ an amazing game compared to most others. Giving the player more freedom to design their apocalypse would be very welcome, and this would be a fantastic way to do so.

Adding your own isn't very hard; I've just finished updating my old mod that adds new ones and it works fine. I'll upload it in the next day or two, so feel free to look at it to figure it out, though the best starting point is the Basic Profession and Trait Template mod available on this forum.
 
As for removing them, I'm not sure if that would be possible without editing MainCreationMethods, which isn't the best idea is it will be outdated quickly by game updates. Though you could possible replace existing professions with your own with some work?

I'm a bit confused why this isn't already in the game, given the point of Sandbox is to let us set things up however we like. We can set 'Instant' but not 'Never' for when water and/or electricity gets shut off right now.
 
Would it be possible to please add a 'Never' option for water and electricity, so we could have them never shut off if we wish?
 
Obviously this would *only* be a Sandbox option, not something for regular difficulty modes or challenges!
 
Hopefully this would be very easy to implement and give the player more choice in setting up their Sandbox games as they wish (for roleplaying terms, it could be that your game area is in a 'quarentine' zone where power and water are suppied from outside since the rest of the world is uninfected).

I'm a bit confused why this isn't already in the game, given the point of Sandbox is to let us set things up however we like. We can set 'Instant' but not 'Never' for when water and/or electricity gets shut off right now.
 
Would it be possible to please add a 'Never' option for water and electricity, so we could have them never shut off if we wish?
 
Obviously this would *only* be a Sandbox option, not something for regular difficulty modes or challenges!
 
Hopefully this would be very easy to implement and give the player more choice in setting up their Sandbox games as they wish (for roleplaying terms, it could be that your game area is in a 'quarentine' zone where power and water are suppied from outside since the rest of the world is uninfected).

I'm a bit confused why this isn't already in the game, given the point of Sandbox is to let us set things up however we like. We can set 'Instant' but not 'Never' for when water and/or electricity gets shut off right now.
 
Would it be possible to please add a 'Never' option for water and electricity, so we could have them never shut off if we wish?
 
Obviously this would *only* be a Sandbox option, not something for regular difficulty modes or challenges!
 
Hopefully this would be very easy to implement and give the player more choice in setting up their Sandbox games as they wish (for roleplaying terms, it could be that your game area is in a 'quarentine' zone where power and water are suppied from outside since the rest of the world is uninfected).

Very small patch should be dropping (dropped?) soon, so that GOG players can play on the same mp servers as steam-deployed versions of the game, running in nonsteam mode. That was a bug, relating to game version strings that should be fixed now, thanks to the wonderful work of EasyPickens

Convenient Bags

Convenient Bags (previously Unpack Bags) is a mod for Project Zomboid which adds several new features to the vanilla item containers.

OverviewAdd tags to a bag to allow quick sorting of items Quickly pack items into a bag Quickly unpack items from a bag Quickly drop all equipped bags via keypress Includes translations for English, German, French, Russian and Finnish Tiny AVC Support


Unpacking Bags
Bags can be quickly unpacked via a context menu. The bag will drop its contents into the container in which it currently is contained (this can be the player's inventory, a container or even the floor). If the container is full the bag will only be partially emptied.

Adding tags
Tags can be added to a bag to limit it only to certain types of items. Click on the bag you want to edit and select "Edit Tags". A small text box will show up, allowing you to add or remove tags. This can be an item category (Food, Weapon, etc.) or an item's full or partial name (Water, Bowl, Garbage Bag). You can add multiple tags at once by separating them with a comma (e.g.: Food, Hammer, Butter Knife).

These tags are used by the packing option (see below).

Packing Bags
Bags can also be conveniently filled with items. Clicking on "Pack items" will move all items in the same container as the bag except for containers and equipped items into the bag.

By using tags this option can be limited to certain types of items. If a bag has at least one tag only items fitting the tag will be transferred into the bag.

Turn Tail
The mod also allows you to use a key (Default: 'X' - can be changed in the options menu) to quickly drop equipped bags in case of an emergency. This might come in handy if you are overencumbered while being ambushed by some zombies.

The bags will be dropped in the following order:Bags equipped in primary slot Bags equipped in secondary slot Bags equipped on the back This feature was inspired by the original "Turn Tail" Mod by The_Real_Al.

 

As stated, we're currently looking if this can be worked out.
It might be something out of our hands though so we can't guarantee or promise something at this point, as I'm sure you understand. It's not like we didn't have this on our minds.
I'm confident we'll find a way

Sorry, folks! I got delayed by "real life" for a few weeks, but am now back to post my mods as intended. Yay?
 
In an attempt to ensure that my time-sapping "mapping research" project last month wasn't totally in vain, I'm starting my mod posting with my "alternate start" mods...
 
----------
 
1. START MEGA-LIST
Mod type: alternate start / modder's resource
 
Starts the player randomly in one of the many interesting locations scattered all over the entire map.
 
This is less of a playable mod and more of a fun-to-mess-around-with one, or a basis for your own mods/coordinate research. Most locations are commercial ones (shops, warehouses, etc.)
 
Included in the file is an Excel spreadsheet with my mapping research data so far (it will also auto-generate spawn code from co-ordinates when entered in the correct columns).
 
Got a favorite map spot or somewhere cool you've found and want to start at? Post/PM me the co-ordinates and I'll update the mod to include it!
 
DOWNLOAD
 
(Apologies to those I promised this weeks ago! Hope it comes in handy!)
 
----------
 
2. START AT DIXIE MOBILE PARK
Mod type: alternate start
 
Starts the player somewhere in Dixie Mobile Park, south-east of Muldraugh. For more zombies, play in Sandbox mode with Zombie Distribution set to 'Uniform'.
 
DOWNLOAD
 
(I love this location!)
 
----------
 
3. START AT FARMVILLE
Mod type: alternate start
 
Starts the player somewhere in the farming community to the distant northwest of Muldraugh. For more zombies, play in Sandbox mode with Zombie Distribution set to 'Uniform'.
 
DOWNLOAD
 
(Hey, devs... how about placing a small shop or two in that "farmville" map region?)
 
----------
 
Also currently in progress:
Mod that determines your start location based on your profession (with several random choices for each profession, and supporting popular custom profession mods like Xmod, Action Hero and my own WIP profession mod). ----------
 
Install Notes:
 
Being fairly OCD about mod organization, I always include easy uninstallers, but they will only work if you use my default mod install path ("mods" in the Steam/game subfolder).
 
NOTE: ALL MY MODS UNLESS STATED ARE FOR THE STEAM "BETA" TEST VERSION (2.9.9.17). SOME MAY NOT WORK WITH THE VERY RECENT "INTERIM" x64 STEAM TEST BUILDS OR EARLIER (NON-STEAM) BUILDS.
 
I hope to eventually update for compatibility with the interim build, but due to instability and what appears to be a lot of code-breaking differences (or bugs, but I'm leaning towards the former) I just don't have time to figure out what I need to change right now.
 
----------
 
I'll update this first post with new mods as I get them updated and playable. My professions one and my "fixes" are next...

I suggested this on the old forums but wanted to repeat it here...
 
Way back when the pistol and reloading mechanism was a mod, not part of the vanilla game, the "hardcore" reloading style was the only one available. Although realistic, it was rather buggy and definitely not user-friendly, and I definitely support making the "style" of reloading an option in PZ's settings rather than forcing one set style (easy, normal, hardcore) on the player.
 
However, the old mod version of reloading had something that I don't think was included when it was incorporated into the vanilla game version: shotguns had to be "pumped" between shots.
 
If you hadn't tried it, it sounds dreadful and annoying, right? But I recall that once I got used to it, it was such a visceral, cool-feeling concept of shooting, whacking space to rack the shotgun slide, shoot, repeat. It did take getting used to, but it made the shotgun feel more "real" to me than any shotgun in any other game. It also balanced out the power/capacity of the gun (especially compared to the pistol) nicely, IMO.
 
What I'd LOVE to see is this added back in. Not forced, because I'm sure loads of new players would utterly hate it, but with added via a menu option (below "Reloading" in the Options menu?) to let the player choose between:
 
Easy: Shotguns are all semi-auto (as the game is now) Normal/Hardcore: Shotguns must be pumped before each shot (as described above)  
Keeping this option separate from the pistol reloading would satisfy players (like me) who wanted one
but not the other.
 
Ideally, this would only affect the current shotgun in the game ("pump action"), so at some point in the future, either vanilla or via a mod, a new double-barrel shotgun (never needs to be pumped but only holds two shots) could be added for balance and variety. It would also allow for bolt-action rifles to be added to the game at some point too.
 
All that is "future stuff" that doesn't need to be worried about now, yes, but getting the basis of a "cock/rack before each shot" gun mechanism into the game at this point would make such future additions more viable as well as making shotguns more realistic (right now, why ever use a pistol instead of a shotgun?).
 

I suggested this on the old forums but wanted to repeat it here...
 
Way back when the pistol and reloading mechanism was a mod, not part of the vanilla game, the "hardcore" reloading style was the only one available. Although realistic, it was rather buggy and definitely not user-friendly, and I definitely support making the "style" of reloading an option in PZ's settings rather than forcing one set style (easy, normal, hardcore) on the player.
 
However, the old mod version of reloading had something that I don't think was included when it was incorporated into the vanilla game version: shotguns had to be "pumped" between shots.
 
If you hadn't tried it, it sounds dreadful and annoying, right? But I recall that once I got used to it, it was such a visceral, cool-feeling concept of shooting, whacking space to rack the shotgun slide, shoot, repeat. It did take getting used to, but it made the shotgun feel more "real" to me than any shotgun in any other game. It also balanced out the power/capacity of the gun (especially compared to the pistol) nicely, IMO.
 
What I'd LOVE to see is this added back in. Not forced, because I'm sure loads of new players would utterly hate it, but with added via a menu option (below "Reloading" in the Options menu?) to let the player choose between:
 
Easy: Shotguns are all semi-auto (as the game is now) Normal/Hardcore: Shotguns must be pumped before each shot (as described above)  
Keeping this option separate from the pistol reloading would satisfy players (like me) who wanted one
but not the other.
 
Ideally, this would only affect the current shotgun in the game ("pump action"), so at some point in the future, either vanilla or via a mod, a new double-barrel shotgun (never needs to be pumped but only holds two shots) could be added for balance and variety. It would also allow for bolt-action rifles to be added to the game at some point too.
 
All that is "future stuff" that doesn't need to be worried about now, yes, but getting the basis of a "cock/rack before each shot" gun mechanism into the game at this point would make such future additions more viable as well as making shotguns more realistic (right now, why ever use a pistol instead of a shotgun?).
 

EDIT:
The contents of this mod have all been merged into my new mod CCCP with some changes and many new items and recipes]
 
 
Alright, here it is, my first mod.
Nothing earth-shattering, I just started adding some new items and recipes to the game and figured I might as well share it with the community.

So far, everything seems to work fine in the current Beta (2.9.9.17 open and hidden beta), the items show up and the recipes work "vanilla" and with "crafthelper" and "lockpicking" mod running.
Backup your saves or start a new one if you want to try this, I can't guarantee that it works older versions and/or different mods.
Shouldn't cause any issues, it's just a few text files and a lua distribution script, but who knows....
 
So, without further ado:


 
A mini-disclaimer here:
Originally I was using the [sic] Food Expantion: Jerky 1.0 [sic] mod by jerrylwatsonjr, but that one hasn't seen any updates since August and is not set-up to work with the mod loader. So instead I grabbed some pieces, simplified some recipes and absorbed it into this one. If there are any objections to this I will remove the jerky pieces from the mod.
 
 
New Items:


 
Baking Tray (not new, but added to the distribution list)
Canned Apple
Canned Peach
Canned Pear
Chocolate Chip Cookie
Dough
Cookie Dough
Pizza Dough
Dark Chocolate
White Chocolate
Garlic Powder
Herring
Homemade Bread
Jelly and Jam (Strawberry, Apple, Orange, Wildberry, Grape)
Jelly Sandwich
Peanut-butter Sandwich
Peanut-butter and Jelly Sandwich
Liquid Smoke
Marinade (Simple and yummmy-yummy, for Jerky)
Mason Jar
Pasta
Pasta Bowl
Pepper
Pie Plate
Homemade Pie
Pizza (boring, simple and awesome as pie and in slices)
Salt Shaker
Sliced Onion
Sliced Tomato
Sliced Apple
Soy Sauce
Stir-Fry
Worcestershire Sauce
Yeast
 
New Recipes:
 
Slice Apple
Slice Onion
Jelly and Jam (Strawberry, Apple, Orange, Wildberry, Grape - cooks a pot, then refill to mason jars)
Bread
Sandwiches (Ham, Ham and Cheese, Peanut Butter, Peanut Butter and Jelly, Jelly)
Pizza (boring, simple and awesome, makes pizza pie that can be sliced)
Pasta (simple and awesome, can be refilled into bowls)
Marinades and Jerky (Marinade plus any sort of meat creates Homemade Jerky)
Fried Herring
Pie (makes whole pie, can be sliced after baking)
Chocolate Chip Cookie
Stir Fry
 
and probably something else that I missed.
 
I recommend using Crafthelper to see all the combinations
 
Link:
https://www.mediafire.com/?xakg33vl9r693n8
 
Extract the archive to your C:\Users\[user]\Zomboid\mods directory
 
Permission (Click the spiffo for more information):
 


Use it as you like or merge it into your own mods, but if you post it with those items or recipes, mention where it came from.

I'm posting this in WIP for now so you guys can test it if you like and give feedback on the balance of items/recipes and any bugs/compatibility issues you may find.

Enjoy.

-M

RoboMat's Modding Tutorials
- An introduction to modding for Project Zomboid -


 

I - Introduction
I1 - Where to start
I2 - What is needed
I3 - Lua Tutorials
I4 - Other Resources
 
II - The first steps
II1 - Getting the connection
II2 - The entry point: Events
 
III - The first mod
III1 - Preparations
III1a - Folders
III1b - Our mod's identification card
III1c - The actual lua script
III2 - Adding items to the inventory
III3 - Handling keys
III4 - Detecting the correct key
 
IV - Custom professions
IV1 - Creating a custom profession
IV1a - The foundation
IV1b - Creating the profession
IV1c - Creating a new trait
IV1d - Custom Spawnpoints
IV1e - Custom Profession Clothing
IV1f - Putting it all together
IV2 - Linking Professions / Traits to game mechanics
 
 


I. Introduction
Hello there, this is my attempt to write a few modding tutorials for the community. I will try to update this whenever I have some spare time.


1. Where to start
First things first. When I started looking into the code of Project Zomboid and the different mods I was a bit confused. There was the source code in Java, the additional code in Lua and the scripting language and I didn't really know which one to look into. To spare you this confusion I'll explain their purpose shortly:
 
Java: Most of the source code of Project Zomboid is written in Java. While you can modify the java files it is not recommended. According to the developers changing the java source code won’t be necessary in future versions of Project Zomboid, so we won’t look into that. Eggplanticus has made a nice post about how to spelunk in the Java source if you want to try it nonetheless. Lua: There already are parts of the source of PZ that have been ported to lua. If you really want to get into modding, you won't get around learning its syntax. Scripting: At the moment it is only used for easily adding items to the game. While we will cover some of the basics of the scripting language we will mostly work with lua coding.
2. What is needed
Basically to edit a lua file you can use any standard text editor that is capable of saving simple (unformatted) text files. So Wordpad (Windows) or TextEdit (Mac OS) will do. While it is possible to create a script with those programs they miss many features a specific IDE will give you (syntax-highlighting, auto-formatting, etc...).
I prefered working with Eclipse IDE with an extra lua plugin installed for quite some time, but recently switched to IntelliJIdea - haven't been looking back ever since. There are other free alternatives like gedit, Notepad++, ZeroBraneStudio or XCode for example. Find one that works for you and stick with it. Remember: It's not the program that does the work. None of them will turn you into a RobertJohnson over night, they only make your life easier.


3. Lua Tutorials
If you have some experience with programming already Lua will probably be fairly easy to pick up for you. I mainly used the official manual to learn the language, but of course there are many other great tutorials out there. From time to time I check the lua wiki and of course stack overflow.

Just to be as clear about this as possible: This won't be a tutorial about lua. It will be a tutorial about modding Project Zomboid. If you don't understand parts of my code, you probably should learn some basic lua syntax first. If there is one thing I don't like then it's people who don't even take the time to read through the tutorial notes, then copy&paste the code and finally spam the thread with questions about "why it doesn't work".
Don't be that person (unless you are Rathlord).


4. Other Resources
For more tutorials you should visit pz-mods.net and the tutorial section on the indiestone forums. If you have further questions you can post them in the modding help section of the the indiestone forums and one of the many coders will help you for sure.
 
 
TOC
 
 
Last updated: 12.11.2013
 


II. The first steps
Okay now that we got that out of the way let's move on to the actual modding part.


1. Getting the connection
To mod the game we somehow have to interact it. Lua's main purpose lies on extending existing programs written in other programming languages. As mentioned in the previous chapter the main base of Project Zomboid was written in Java. That's where the connection between lua and the java source code happens. With lua we can access all the public functions written in the Java source code.
 
-- lua function function doStuffInLua(_player) -- getSpecificPlayer() is a public method defined in the java source code -- that returns the player. We can access it through lua. getSpecificPlayer(_player); end  
But how do we know which methods there are!? Well, we can look at the javadoc. It's basically a complete list of all methods in the Java source code and it has even been updated to 2.9.9.15 recently. If you want to be on the save side I suggest that you open the source code and look through it yourself. I use a small programm called JD-GUI for that purpose. It has a useful search function that can search through the whole source code. In the course of this tutorial I will mark methods we call from java so you don't have to worry too much about that at the moment.

Eggplanticus also released a good tutorial on how to decompile the java source over here.


2. The entry point: Events
So now we know that we can call Java methods from our lua code, but we still don't know how we actually execute our lua code. We need something that runs our code, when Project Zomboid runs. This will be done with Events. You can think of events as entry points to the source code of the Project Zomboid source code. Once Project Zomboid encounters an Event from a mod it calls the associated function.
 
 
 
-- the function we want to execute function sayStuff() -- Java: we get the first player local player = getSpecificPlayer(0); -- Java: let the player speak player:Say("I like turtles."); end -- this event will be fired every ten ingame minutes. -- In this case sayStuff() is the associated method and -- thus will be executed every ten minutes. Events.EveryTenMinutes.Add(sayStuff); This short "mod" lets the player talk about his love for testudines every ten minutes in the game. Nothing great but it gets the point across. There are already many different events added to the game which we can use for our mods and the developers are constantly adding new ones. For a somewhat complete list check out the Event Reference on pz-mods.net. Don't worry though, we will use some of them throughout this tutorial so you will slowly get the hang of it.
 
 
 
TOC
 
 
Last updated: 01.10.2013
 


III. The first mod
Let's continue with a little more complex example. We will create a small cheat script that adds some items to the player's inventory when a certain key is pressed.


1. Preparations
At first we're going to set up a proper folder structure and all the files we'll need to get the mod to work with Project Zomboid. Please note that this tutorial has Version 2.9.9.17 and later in mind and thus is going to use the structure needed to work with the modloader. If everything is done right our mod will later on appear in the game like this:
 
 
 


The almighty RobertJohnson has released a more in-depth tutorial about the modloader and mod.info functions. Once that version is released I'm going to update this post too!


a.) Folders
Please note, that the folder structure might slightly variate depending on what IDE you are using. I'm going to show you the end-structure which I use when I release my mods:
 
 
 
 


I named the topmost folder (we are going to call this the base folder from now on) after our mod: CheatMod. This base folder is going to contain ALL of our mod files. The "media/lua" folder is basically the location of the vanilla lua files. When we drop our mod into the modloader it is going to copy the files in our base folder to their specified location in the PZ source files. This way our mods don't overwrite any base files and the mod can be removed from the game at any time without breaking it. Yay for the nifty modloader!


b.) Our mod's identification card
The modloader needs some way of identifying the mods given to it. This is done by the so called mod.info file. It is a simple (unformatted!) text file which contains some important information about our mod. It must be put into the base folder:
 
 
 
 


To make it work we will have to fill it with information of course. Copy this to your mod.info file:
 
name=Cheat Mod (1.0.0) poster=poster.png description=This mod is used to explain modding for Project Zomboid. It is going to show several aspects of modding from start to finish. -by RoboMat id=CheatMod  
name: The name of the mod. poster: The image file that is displayed in the mod menu in PZ. description: A short description of your mod. I am not sure how many characters this supports. id: The id of our mod. This is used to identify our mod. The id must have the same name as the base folder of our mod (in this case: CheatMod). If you drop you folders into your Project Zomboid "mods" folder now it would already display it as a mod in the game:


Of course this isn't really a mod yet. We still need to give it some functionality


c.) The actual lua script
The last file we need to create is the lua script file. We are going to call it "AddItems.lua" and put it into "media/lua/Mods/CheatMod". Make sure that you really are using the correct suffix of ".lua".
 
 


Now we are set and ready to begin working on our first mod!


2. Adding items to the inventory
We are going to start with a simple script that allows us to add a few items to the player inventory as soon as a certain key is pressed. Adding items is a fairly easy task as you will see. Open your AddItems.lua and enter the following code.
 
 
 
local function addItems() local player = getSpecificPlayer(0); -- Java: get player one local inv = player:getInventory(); -- Java: access player inv -- Java: add the actual items to the inventory inv:AddItem("Base.Axe"); inv:AddItem("Base.RippedSheets"); inv:AddItem("camping.TentPeg"); end As with the previous examples our starting point is the player. We need to "get" him first with getSpecificPlayer(0). We then can access his inventory with the getInventory() call. "getInventory()" returns an ItemContainer which happens to be the player's main inventory. This means we now can use all the java functions defined for the ItemContainer.class and one of them happens to be the nifty AddItem(...) function.

If you look at the javadoc of this function you will notice that it expects a String as a parameter. What it doesn't tell you is, that it actually needs the module of the item you want to add and the name of the item itself. You can read our example above as "add item Axe from module Base". The code above would give the player an axe, some bandages and a tent peg from the camping module.

How do you find out the modules and names of the items? Of course by looking through the source files. All items are currently located in "/media/scripts/items.txt", "/media/scripts/newitems.txt", "/media/scripts/camping.txt" and "/media/scripts/farming.txt". Just take a look at these files - the rest should be self explanatory.


3. Handling keys
As we haven't defined an event yet, the function is pretty useless right now. We want the items to be added whenever the player presses a key and luckily the devs have given us the great OnKeyPressed event for that purpose. Let's add it to our mod:
 
local function addItems() local player = getSpecificPlayer(0); -- Java: get player one local inv = player:getInventory(); -- Java: access player inv -- Java: add the actual items to the inventory inv:AddItem("Base.Axe"); inv:AddItem("Base.RippedSheets"); inv:AddItem("camping.TentPeg"); end -- Will be fired whenever we press a key. Events.OnKeyPressed.Add(addItems); This event will be called whenever a key is pressed in the game. The only problem is, that the event doesn't care which key that is. If we would leave our mod like this, the player would get spammed with countless items. We need to fix that!


4. Detecting the correct key
One of the great things about events is, that some of them pass useful parameters to the function which is called through the event. The OnKeyPressed event for example passes the number of the pressed key to the function. The called function in this case is of course "addItems()". To use the parameter we have to slightly modify our code another time:
 
-- We added the parameter to the function which -- will be passed to the function as soon as the -- event fires. local function addItems(_keyPressed) local key = _keyPressed; -- Store the parameter in a local variable. print(key); -- Prints the pressed key to the console. -- We test if the correct key is pressed. if key == 25 then local player = getSpecificPlayer(0); -- Java: get player one local inv = player:getInventory(); -- Java: access player inv -- Java: add the actual items to the inventory inv:AddItem("Base.Axe"); inv:AddItem("Base.RippedSheets"); inv:AddItem("camping.TentPeg"); end end -- This will be fired whenever a key is pressed. Events.OnKeyPressed.Add(addItems); Notice the _keyPressed parameter that was added to our function. You might wonder about the leading undaerscore. It is just a thing of coding style that I like to do, to be able to distinguish parameters from local variables in the function's body. The same goes for storing the parameter in the local variable "key". It might seem superfluous at first, but if you want to change the content of this variable later on, you can easily do that by changing its declaration at the top of the functions instead of having to track down every single occurence.

Anyway, they _keyPressed parameter will receive a number corresponding to the pressed key and pass it into our function. Unfortunately I'm not to sure which numbering method is used in Project Zomboid, but I think it might be the one from LWJGL. You can use the print(key) call in the function to easily find out all numbers you need to know anyway.

Basically we just have finished our first real mod. Save the AddItems.lua and copy your base folder into the Project Zomboid-mods folder. Now you can go into the game and enable your mod (restart the game afterwards!). Once you are in the game now, you should be able to cheat items into your character's inventory by pressing the 'P' key on your keyboard.
 
 
TOC
 
 
Last updated: 12.11.2013
 


IV. Custom professions
Admittedly our first mod isn't very impressive so we are going to expand it a bit. The biggest problem at the moment is, that the player can cheat weapons into his or her inventory every playthrough, which might ruin legit savegames.

1. Creating a custom profession
That's why we are going to create a custom "Cheater" Profession and link the cheat code to it.

a.) The foundation
Of course we need to create a new lua script. I'm gonna call it "CheaterProfession.lua" and save it in its own folder (Note: Basically it doesn't matter where you save your lua files, but good structuring will make it easier for you and others to organize and understand your project).



After creating the file open it and add the following lines:
 
 
-- CheaterProfession.luarequire'NPCs/MainCreationMethods';require'NPCs/ProfessionClothing'; This basically makes sure that the file is loaded after those two files which enables us to use their functions. (If someone has a more technical explanation feel free to PM me or comment below!).

b.) Creating the profession
Now we can start with actually creating the new profession. Add these lines to your CheaterProfession.lua
 
 
 
-- CheaterProfession.lua require'NPCs/MainCreationMethods'; require'NPCs/ProfessionClothing'; local function initProfessions() -- Java: Create a new profession. local cheater = ProfessionFactory.addProfession("cheater", "Cheater", "Prof_rm_Cheater"); -- Java: Add a custom trait called Undesireable (no one likes cheaters ). cheater:addFreeTrait("rm_undesireable"); -- Java: Add the vanilla trait Nightowl. cheater:addFreeTrait("NightOwl"); end  
Lets go through the code. The part of it which actually creates / registers the new profession is:
 
 
local cheater = ProfessionFactory.addProfession("cheater", "Cheater", "Prof_rm_Cheater"); It calls the addProfession(String type, String name, String IconPath) function of the ProfessionFactory. The parameters are used like this:
type: Used to identify the profession internally in the game's code. name: Human readable name which appears in the game's menus etc. iconPath: Name of the custom icon to be displayed in the game. If we would leave the code here it would create a fine new profession without any traits though. That's where the remaining two lines come into play:
cheater:addFreeTrait("rm_undesireable"); This adds a (you probably guessed it) trait to the profession we just created. "rm_Undesireable" is the trait we are going to create in a few seconds whereas "NightOwl" is one of the vanilla traits. Of course PZ doesn't know "rm_undesireable" yet, so we still have to actually create it. Lets do it.

c.) Creating a new trait
We add a new function above the one we created above to initialise the traits.
local function initTraits() TraitFactory.addTrait("rm_undesireable", "Undesireable", 0, "Allows you to cheat.\nShame on you!", true); end Quite similar to the ProfessionFactory we used above, the TraitFactory class allows us to add a new trait by calling addTrait(String type, String name, int cost, String desc, boolean profession). Let me explain those parameters:
type: This is the internal name used in the games code. It's also the name of the custom icon to be displayed in the game. ! Has to be lower case ! name: The human readable name displayed in menus etc. cost: Determines how many trait points it will cost to select this trait. desc: The description which appears when you hover over the trait. profession: If set to true the trait won't appear as a selectable trait but instead stays a "profession-only" trait. It really is as easy as that Now you actually already have a fully functional profession which you could play with. But it still is lacking two important parts of the profession system: Spawn points and custom clothing colours.

d.) Custom Spawnpoints
Spawnpoints determine where in the Gameworld the player will appear when the game starts. Before we can add a new spawnpoint though we of course need to find out its coordinates in the game. For this purpose I have created the "Coordinate Viewer", which displays the player's coordinates as a small overlay in the game.

So if our cheater profession should start in the large warehouse (where else!?) the game will show us a player position of X: 3110 and Y: 1809. Unfortunately we can't use those "absolute" coordinates for the spawning code. We have to calculate the "relative" coordinates instead. Don't worry though - it is pretty easy. Basically you just need to divide the absolute coordinates by 300 to get the cells, but more importantly you have to ignore the remainder. Our coordinates for the big warehouse would be X: 10 and Y: 6 then. Now we have the cell in which the player should spawn. Relative to that position we need the exact coordinates and this is where the remainder comes into play. Still using the above coordinates the remainders of the division would be for X: 110 and for Y: 9.

This probably sounds more complicated than it is. I suggest that you read through this post by The_Real_AI who maybe explains it a bit better.

Now that we have calculated the coordinates, we need to tell the game to use them.
 
-- Set custom spawn points for this profession. -- Modelled after spawn code by RegularX. Thanks to -- The_Real_Ai for his explanation on how to calculate -- them. local function initSpawnPoints() local spawn; -- Create a Spawnpoint in the large Warehouse. spawn = { { worldX = 10, worldY = 6, posX = 110, posY = 8, }, } -- Add our profession to the list of spawnpoints for Muldraugh. BaseGameCharacterDetails.spawnPoint.MuldraughKY.cheater = spawn; spawn = { { worldX = 39, worldY = 23, posX = 138, posY = 100, }, } -- Add our profession to the list of spawnpoints for West Point. BaseGameCharacterDetails.spawnPoint.WestPointKY.cheater = spawn; end Basically we have created a local table which holds our calculated coordinates and added it to the global table BaseGameCharacterDetails.spawnPoint.

Take a look at the last line of the function:
BaseGameCharacterDetails.spawnPoint.WestPointKY.cheater = spawn; We create a new index cheater and give it the value of our spawnpoint. It is essential that this index uses the type (check the parameters above) of your profession or else it won't work. It is probably self evident but MuldraughKY holds all spawns for Muldraugh, whereas WestPointKY creates spawns in West Point.

e.) Custom Profession Clothing
Finally we are going to add some custom colors for the profession clothing. The System is quite similar to the spawn points above: Basically we are going to create a table which holds all values for male and female "cheaters".
----- Set custom clothing and clothing colors for this -- profession. local function initClothing() local clothes = {} ProfessionClothing.rm_Burglar = clothes; end We create a table called clothes which will hold all of the necessary values. Then we have to make two nested tables to separate the "male" and "female" clothes (this means the guy can have blue and the lady pink colors for example - yay ).
local function initClothing() local clothes = { male = { }, female = { }, } end Now we will add all the values need to create the clothes. First we declare which type of clothing item the character should wear. The male character is going to wear a Shirt and Trousers and the female character gets a Blouse and Skirt.
----- Set custom clothing and clothing colors for this -- profession. local function initClothing() local clothes = { male = { topPal = "Shirt_White", top = "Shirt", bottomPal = "Trousers_White", bottom = "Trousers", }, }, female = { topPal = "Blouse_White", top = "Blouse", bottomPal = "Skirt_White", bottom = "Skirt", }, } end You probably are wondering why there are two variables (top and topPal) for each item for example. As far as I understand the system the "pal" stuff just sets the color palette for the specific item. Why we have to do that ... I don't know It is something we gotta have to ask the devs.

Last but not least we are going to give some colours to those clothes. Those values will be stored in two seperat tables called topCol and bottomCol. As you probably figured the first determines the colours of the top the character wears, whereas the latter determines the clothes for pants, skirts, etc.

PZ uses the three values Red, Green and Blue (RGB) to calculate the final colour. Those values have a floating point range from 0 to 1 which was a bit strange for me at first considering that most programs and games I've used use values from 0 to 255 I will leave it to you to figure out which values return which colour. In my example here all clothes will be black:
----- Set custom clothing and clothing colors for this -- profession. local function initClothing() local clothes = { male = { topPal = "Shirt_White", top = "Shirt", bottomPal = "Trousers_White", bottom = "Trousers", topCol = { r = 0.1, g = 0.1, b = 0.1, }, bottomCol = { r = 0.1, g = 0.1, b = 0.1, }, }, female = { topPal = "Shirt_White", top = "Shirt", bottomPal = "Trousers_White", bottom = "Trousers", topCol = { r = 0.1, g = 0.1, b = 0.1, }, bottomCol = { r = 0.1, g = 0.1, b = 0.1, }, }, } ProfessionClothing.cheater = clothes end Just like the spawnpoints we add the table of our cheater profession to the global table called ProfessionClothing with the last line of the function.

f.) Putting it all together
We still need to tell PZ to call our functions once the game boots so that our custom values are initialised. We wlll use our beloved Events for that. Add these lines to the end of your CheaterProfession.lua file:
 
Events.OnGameBoot.Add(initTraits); Events.OnGameBoot.Add(initProfessions); Events.OnGameBoot.Add(initSpawnPoints); Events.OnGameBoot.Add(initClothing); We are done here. Congratulations you have created your first custom Profession

The complete file should look like this:

 
TOC
Last updated: 12.11.2013
 

2. Linking Professions / Traits to game mechanics
What we want to do now is link a special game mechanic to the trait of the profession we just created. Of course this isn't a must, but it doesn't make much sense to implement a trait that doesn't have any effect in the game, does it? You will see that it is actually pretty easy. Let's get to it.
Coming soon™...
 
 
 
TOC
 
 
Last updated: 08.11.2013

Hello,
 
So, couple of things.
 
The modData is a table, not an object (tho a table is an object.. Erm wait ), mean we only save modData["stuff"] and not modData.stuff.
 
Then, you used "HasBanjoCheatersLoadoutItems" at first, but your test to spawn item is : if(playerData.HasBanjoStarterItemsCheat == "false") then
So it should be : if(playerData["HasBanjoCheatersLoadoutItems"] == "false") then
Because it's not the same variable you used (HasBanjoCheatersLoadoutItems/HasBanjoStarterItemsCheat), and it's a table (the ["stuff"] thingy).
 
Also, there is an event specially for new game only : OnNewGame, use it instead of your trick
 
Because i'm a fun guy, here's the code fixed (but you really should use OnNewGame ) :
 

Spoiler BanjoCheatersLoadout = {}

BanjoCheatersLoadout.GiveCheatersLoadoutItems = function()
    local player = getSpecificPlayer(0);
    local playerData = player:getModData();
    playerData["HasBanjoCheatersLoadoutItems"] = playerData["HasBanjoCheatersLoadoutItems"] or "false";

    if(playerData["HasBanjoCheatersLoadoutItems"] == "false") then
        player:getInventory():AddItem("Base.Axe");
        player:getInventory():AddItem("Base.Hammer");
        player:getInventory():AddItem("Base.Saw");
        player:getInventory():AddItem("Base.Screwdriver");
        player:getInventory():AddItem("Base.Torch");
        player:getInventory():AddItem("Base.Battery");
        player:getInventory():AddItem("Base.TinOpener");
        player:getInventory():AddItem("Base.Lighter");
        player:getInventory():AddItem("camping.CampingTentKit");
        player:getInventory():AddItem("Base.BathTowel");
        player:getInventory():AddItem("Base.WaterBottleFull");
        player:getInventory():AddItem("Base.WaterBottleFull");
        player:getInventory():AddItem("Base.TinnedSoup");
        player:getInventory():AddItem("Base.TinnedSoup");
        player:getInventory():AddItem("Base.TinnedSoup");
        player:getInventory():AddItem("Base.Nails");
        player:getInventory():AddItem("Base.Nails");
        player:getInventory():AddItem("Base.Nails");
        player:getInventory():AddItem("Base.Nails");
        player:getInventory():AddItem("Base.Sheet");
        player:getInventory():AddItem("Base.Sheet");
        player:getInventory():AddItem("Base.Sheet");
        player:getInventory():AddItem("Base.ShotgunSawnoff");
        player:getInventory():AddItem("Base.ShotgunShells");
        player:getInventory():AddItem("Base.ShotgunShells");
        player:getInventory():AddItem("Base.ShotgunShells");
        player:getInventory():AddItem("Base.BigHikingBag");
        player:getInventory():AddItem("Base.Duffelbag");
        playerData["HasBanjoCheatersLoadoutItems"] = "true";
    end

end

Events.OnGameStart.Add(BanjoCheatersLoadout.GiveCheatersLoadoutItems);

 
Don't hesitate to add "print" function everywhere to check if your mod is loaded, to debug the variables you use, etc.
Also, press F11 (default key) to bring the lua debugger add break point, it's really helpfull to see what's wrong
 
Cheers !

Ohley potatoes, You've just made my dreams come true!