RoboMat

The easiest solution would be to use player:Say('Text I want to say') ... that would display the text above the player's head like shouting.
Of course you could use the drawString() function with the event I used for the coordinate viewer (can't remember what it's called) and simply remove / hide the string after a while.

table.insert and table.remove both have optional index paramters which allow you to specify at which position to insert / remove a value. Without them, the functions will always operate on the end of the table.
 

table.insert({ 'b', 'c' }, 1, 'a') table.insert would insert 'a' at the first position in the table and automatically shifts all the other values down accordingly.
 

table.remove({ 'a', 'b', 'c' }, 1)  table.remove would remove the first entry and shift the others down in this example.
 
The important thing to keep in mind is that this only works on sequences:
A small sidenote. If you have a sequence and want to add / remove entries at the end, I prefer this:
 

t[#t + 1] = 'bar' -- Insert new entry at the endt[#t] = nil -- Remove last entry in the tableThat's because I usually iterate over sequences using the '#' operator:
local foo = { 'a', 'b', 'c' } for i = 1, #foo do    print(foo[i])endThis should be faster than using table.remove / table.insert and ipairs / pairs, but for me it's just personal preference.

Well I guess you could say globals are easier to use. Generally people will tell you to avoid them and it is considered to be bad practice by many to use globals at all (although you shouldn't listen to that ... as always write something that works first and then worry about improving it). Personally I follow this, when I work on my own games - I like to keep things as separated  as possible.

Not sure if I understand the case you mention above, because you couldn't solve it easily with globals either. Basically wether you use the module thing I wrote above or use a global variable doesn't change much in terms of how you have to write your code.
-- GlobalModule = {};function Module.sayHello() print('Hello World');endThe difference is that you have more control over the scopes in your program. For example:
if true then local foo = 'visible'; print(foo);endprint(foo);The first print statement can "see" the foo variable as it is in the scope of the if block. The second print statement can't "see" it because the variable is discarded when the if statement ends.

What does this mean in terms of modding? You can give your different modules, functions, and variables a much more confined and controlled space in which they live. So basically modules only need to know about the stuff that really concerns them.

This also has some benefits for speed because usually accessing a local function / variable is faster than accessing the global scope.

PZ is pretty extreme in that regard as all of their lua modules live in the global scope. I have no idea though if it would bring any (noticeable) performance improvements if they'd refactor their code to use locals.

Have you tried iterating over the "userdata" returned by getAllRecipes()? Chances are, it's a java array.
 

local function convertUserdata(ud) local t = {}; for i = 1, ud:size() do t[i] = ud:get(i - 1); end return t;end

Looks like the crafting menu swallows keypresses. I'll post a new ticket in the bug tracker.
Btw.: Here's a shorter version of your code using a look-up-table:

local keys = {};-- The look up table for the Konami code.local lut = { 30, -- A 48, -- B 205, -- Right 203, -- Left 205, -- Right 203, -- Left 208, -- Down 208, -- Down 200, -- Up 200, -- Up}local function onKeyPress(key) print(key); -- Insert the pressed key at the first index and shift all other keypresses. table.insert(keys, 1, key); if #keys < #lut then -- Return early if we haven't got 11 key presses yet. return; elseif #keys > #lut then -- Discard old keypresses. keys[#lut + 1] = nil; end -- Traverse table from behind. local code = true; for i = #keys, 1, -1 do -- Compare keypresses to look-up-table. if keys[i] ~= lut[i] then code = false; end end if code then -- Call your cool stuff here. print('KONAMI CODE YAY!'); endendEvents.OnKeyPressed.Add(onKeyPress);Issue is here: http://theindiestone.com/forums/index.php?app=tracker&showissue=2060

"Kahlua2 does not include any io or debug library. Some parts of the debug library may be added in the future, but the io library is better left added as a custom extension if necessary. The same thing goes for the os library, which is only partially implemented."
Looks like you are out of luck here.

Okay, NOW I understand what the problem is
One way to fix this, is to simply append the version to the filename.
E.g.:

cheatcore_v121.luaIf you now release a new version you call it:
cheatcore_v130.luaThis way it will not override the previous versions that any other mod might use since the game loads them as separate files.

Well it won't be easy, because floors aren't filled the same way as the rest of the containers. You could try spawning the stuff on the fly while the player is moving, but that might kill the performance depending on how you do it.
This is an example for how you can spawn stuff on the floor (or a container).

for _, item in ipairs(self.itemsInBag) do if item then -- If the floor is selected add the items to the ground. if container:getType() == "floor" then player:getCurrentSquare():AddWorldInventoryItem(item, 0.0, 0.0, 0.0); else container:AddItem(item); end end endNot sure if you can somehow access the tiles while the world is loaded or when a new chunk is loaded.

Well it won't be easy, because floors aren't filled the same way as the rest of the containers. You could try spawning the stuff on the fly while the player is moving, but that might kill the performance depending on how you do it.
This is an example for how you can spawn stuff on the floor (or a container).

for _, item in ipairs(self.itemsInBag) do if item then -- If the floor is selected add the items to the ground. if container:getType() == "floor" then player:getCurrentSquare():AddWorldInventoryItem(item, 0.0, 0.0, 0.0); else container:AddItem(item); end end endNot sure if you can somehow access the tiles while the world is loaded or when a new chunk is loaded.

Of course it will be instantly executed. Using the brackets aka (9) calls the function. You could try using an anonymous function as a wrapper:
 
local MorningOption = subMenuTime:addOption("Morning/9 A.M", worldobjects, function() ISUICheatMenu.SetTime(9) end) 
If that doesn't work you'll have to use the ugly solution of creating a function for each variable (9, 12, etc.).

Of course it will be instantly executed. Using the brackets aka (9) calls the function. You could try using an anonymous function as a wrapper:
 
local MorningOption = subMenuTime:addOption("Morning/9 A.M", worldobjects, function() ISUICheatMenu.SetTime(9) end) 
If that doesn't work you'll have to use the ugly solution of creating a function for each variable (9, 12, etc.).

The shout text is hardcoded somewhere on the Java side.
I overwrote it in my player taunts mod by simply rebinding the key to call my own function.

The shout text is hardcoded somewhere on the Java side.
I overwrote it in my player taunts mod by simply rebinding the key to call my own function.

The tool doesn't matter. You can use any pixel program you want (e.g. Pyxel Edit).
What you need is to adhere to the isometric perspective of the tiles.
Just check out these tutorials:
http://theindiestone.com/forums/index.php/topic/6312-custom-tilesets-and-fences-for-pz-map-editor/?hl=%2Bisometric#entry84988
http://theindiestone.com/forums/index.php/topic/7310-create-own-tilesets-2brains-tutorial/?hl=%2Bisometric

The tool doesn't matter. You can use any pixel program you want (e.g. Pyxel Edit).
What you need is to adhere to the isometric perspective of the tiles.
Just check out these tutorials:
http://theindiestone.com/forums/index.php/topic/6312-custom-tilesets-and-fences-for-pz-map-editor/?hl=%2Bisometric#entry84988
http://theindiestone.com/forums/index.php/topic/7310-create-own-tilesets-2brains-tutorial/?hl=%2Bisometric

It's been ages since I coded for PZ so don't expect this to work on your first try, but it should give you a "simple" base to build on:

local customLootTable = { male = {-- Stuff }, female = {-- Stuff },}local SPAWN_CHANCE = 100;local function spawnZombieGoo(room, containerType, container) -- Check if it is the right type of container. if containerType == 'inventorymale' or containerType == 'inventoryfemale' then -- Chance 1 out of 100 to spawn something. if ZombRand(SPAWN_CHANCE) == 0 then -- TODO: Select random item from your custom loot table. container:AddItem(customLootTable.male.item); end endendEvents.OnFillContainer.Add(spawnZombieGoo);You'll need to have a function which draws randomly from your custom loot table (where I put the TODO). IIRC I have a function like that in my Mod Utilities found here on the forum.

It's been ages since I coded for PZ so don't expect this to work on your first try, but it should give you a "simple" base to build on:

local customLootTable = { male = {-- Stuff }, female = {-- Stuff },}local SPAWN_CHANCE = 100;local function spawnZombieGoo(room, containerType, container) -- Check if it is the right type of container. if containerType == 'inventorymale' or containerType == 'inventoryfemale' then -- Chance 1 out of 100 to spawn something. if ZombRand(SPAWN_CHANCE) == 0 then -- TODO: Select random item from your custom loot table. container:AddItem(customLootTable.male.item); end endendEvents.OnFillContainer.Add(spawnZombieGoo);You'll need to have a function which draws randomly from your custom loot table (where I put the TODO). IIRC I have a function like that in my Mod Utilities found here on the forum.

I think GameTime is the right place to look for this.

For the light values for a tile you could check IsoGridSquare.

I think GameTime is the right place to look for this.

For the light values for a tile you could check IsoGridSquare.

http://theindiestone.com/forums/index.php/tracker/issue-796-lua-require-broken/

http://theindiestone.com/forums/index.php/tracker/issue-796-lua-require-broken/

Nope, unfortunately not. I know Binky has been working on one, but there is no information if and when we can expect it to be released to the public.

You should be able to distinguish the soups by checking their item names.

Get used to it.

Yeah, if you look into (IIRC) MainCreationMethods.lua you'll find all traits. You can make all traits profession based or probably reduce their cost to zero. Both should work.