EasyPickins

I fixed the time it takes to transfer heavier items, it should be the same as earlier versions (not released yet!). I added moving some of the items when the action is interrupted. So if you're moving 10 logs and stop half-way through, 5 will be moved. The transfering of stacks was changed because the framerate would drop when the player had 5000 nails in their inventory for example. That would create 5000 timed actions and would refresh the inventory window 5000 times. In the new system there is only one action per 50 items. But the times should work out the same (after the fixes that haven't been released yet).

I think that's flat tires slowing the car down. The speed limiter just prevents speed over 55, it doesn't stop the car. If you're running into unloaded chunks though, the brakes are applied.

Anything under max pressure (40 in this case) will add some slow-down. So get as close to 40 as you can (press spacebar to stop inflating whenever you choose). Pressure below Max + 5 = 45 looks like it won't have any ill-effects. Looking at the tire-inflation action, as soon as you hit 45 the tire is destroyed.

That's caused by under-inflated tires. It was supposed to work that way (since October) but wasn't due to a bug.

That's the limit for zombies in loaded parts of the map. There can be many more zombies than that in unloaded parts of the map.

The different zones (TownZone, Forest, etc) haven't been done in Riverside yet. Loot only respawns in TownZone and TrailerPark zones.

This is our latest TileProperties.txt. Put it in your C:\Users\XXXX\.TileZed folder. TileProperties.txt

Here is a fix for the delay when performing actions that occurs when many zombies are around. Unzip this into the zombie/vehicles/ directory. It will replace a bunch of .class files. zombie_vehicles_PathDelayFix.zip

Do you mean when you try to do an action that involves the player walking to some place (including getting in a vehicle)? I noticed this, it happens when a lot of zombies are waiting to find a path of their own. The player has to wait until the zombies' paths are calculated. This will need to be changed so player paths are handled first.

I found the problem with loot respawning. Parking stall objects were added to the map for build 39. Build 38 doesn't know about those parking stalls, and treated those objects as regular zones, which caused the larger TownZones to be chopped into smaller parts. The large zone around Gigamart was chopped into pieces too small to contain Gigamart, so no loot would respawn there. Unzip the attached file into the zombie/iso/ directory on the server. Also, delete the server's map_zone.bin file. Clients might want to do the same, I'm not sure if the parking stall zones will break anything on the client. But this fixes loot respawn in multiplayer. zombie_iso_LootRespawnFix.zip

If you PM me the building's TBX file I will try to find the problem.

My fix to lights isn't released yet.

The light not being visible I fixed yesterday. But the fuel option worked for me in the Steam build, I can't see any reason it wouldn't show up as long as you have a battery in inventory. Does the "Remove Battery" option show up?

What does it mean you can't put new batteries in the Lamp on Pillar? The "Insert Fuel' menu option doesn't appear in the context menu, or nothing happens when you click the option?

The tilesets are now the latest as of Nov 20, 2017.

I found a bug just now where the fridge sound isn't playing when logging back in (or turning the generator on). But the fridge was still cooling the food.

Regarding generators, is the only bug now that they shut off after the next hour passes? In that video, the house is surrounded by microwave ovens. In build 35.15, generators were changed so that each stove/radio/tv/fridge/freezer subtracts 1/3 fuel. That would explain why the generator suddenly shuts off after an hour, all the fuel is gone. The other bugs in the video should have been fixed. Actually, there's still a bug with multiple generators in the same area. If one is on, and another is off, the one that was turned on/off last determines whether the area is powered or not. This is due to a limitation of how squares are marked as having power or not.

I'll have to check with Mash on what's ready to be released.

Latest Version here: https://theindiestone.com/forums/index.php?/topic/23816-latest-tilezed-worlded-and-tilesets-may-17-2018/ WorldEd was updated to fix this bug sometimes seen when using custom maps: java.io.EOFException at zombie.iso.IsoLot.readInt(IsoLot.java:66) at zombie.iso.IsoMetaGrid.Create(IsoMetaGrid.java:1019) at zombie.iso.IsoWorld.init(IsoWorld.java:1609) at zombie.gameStates.GameLoadingState$1.runInner(GameLoadingState.java:248) at zombie.gameStates.GameLoadingState$1.run(GameLoadingState.java:223) at java.lang.Thread.run(Unknown Source) 1508124820812 45, 33 The error is caused when the name of a room has a newline character in it. This can happen if you are copying and pasting room names in BuildingEd. Running "Generate Lots" again on any affected cells should prevent this error.

It seems to be working here. Can you post a screenshot of how your generator / fridge is arranged, in case there is something unusual about it?

It looks like a problem with a mod file called ZombieBehaviour.lua.

There's a new Sandbox option under the World category, "Rotten-Food Removal". This is the number of days after food becomes rotten that it is removed from the world. It won't remove rotten food from Compost bins.

Was this a brand-new savefile, or did you create the new character using a savefile your previous character died in?

That's right. The game started with specific trees placed in TileZed. Then the erosion system was added (it was a mod originally) that replaces the original vegetation_trees tiles with new seasonal ones. That replacement happens while the game is running. Later, the jumbo trees were added. While generating the binary lot files, WorldEd replaces vegetation_trees tiles with a generic tile called jumbo_trees_01_0. The game then sees that while loading the map and replaces the generic tile with random jumbo tree tiles. (Well it's not quite random; the erosion system has different "soil types" that determine the type of tree that's placed. The mapper has no control over the soil type.) The editor can't display jumbo trees (due to them being twice the size of every other tile). So putting jumbo trees in the editor would be an issue just because of that. Trying to place specific types of jumbo trees would require changing WorldEd (to write something specific instead of jumbo_trees_01_0) and changing the game's Java code (to deal with whatever WorldEd put in the lot files).

You can place specific trees from the non-jumbo tree tilesets (e_americanholly_1, e_redmaple_1, etc). So you should be able to write a new rule in Rules.txt that only places those types of trees.