Jab

Spectator mode would be useful for a few reasons: 1) Moderation / Administration, as opposed to being directly in-game, putting weight on the server in both terms of CPU processing and memory for your player. 2) Chatting with people from spectator, or people who don't want to play. 3) Watching other players in general. It would also be cool to limit spectator time for regulars, based on server configurations.

I like to clear fields of wild grass, and the erosion mod has fueled my insanity, thus spawning this idea in my noggin: What if we could find manual "push-mowers" in places like garages or ware-house crates where we walk slowly with them (like being over-burdened) and remove wild grass while walking? This opens up a box of ideas for something like floral maintnancing with farming.

Yeah. I like the idea of priming this function while standing. This is a like-concept to that of dungeon-crawlers, where items had text above them to signal their existence.

Hahaha.. I can imagine someome going insane, dragging a corpse with them.. "Come on, Jeffry. You're going to be late to the 'ceremony'... ". Great idea though. You could probably do something with wallets and I.D. That might make this even more useful. Edit: This could work really well with role-playing.

[No FireSpread V2] Here's a quick fix mod that takes the fire management and spreading and nerfs it. The mod basically nullifies the game function responsible for spreading fire, and destroying objects in the game. Fire may look like it's spreading on client but it in fact does not. This means corpses, buildings, trees and the such are not to be modified in the event of a fire. [Commands] There's a current issue with the client / server communication that can create false fires or not put them out entirely, so I created a command that gets rid of most (not freshly loaded fires) off the server: /extinguish Since I nerfed fire from destroying items, this can leave hord corpses lying around, so the same kind of command was made to remove corpses: /removecorpses [About] These were last minute hotfixes I made to help a few servers that wanted a temporary solution to the arcinists running around on multiplayer. These are not the best fixes (Im not proud of the code as it is a hotfix to messy decompiled code), but if you want this fix while multiplayer vanilla does not have a solution (They're working on it!), then use this mod. [Download link] https://dl.dropboxusercontent.com/u/31589881/Zomboid/firefix_V3.16.2.zip [instructions to install] NOTE: BEFORE YOU CONTINUE, COPY YOUR ZOMBOID FILES IF YOU RUN YOUR SERVER ON THE SAME FILES AS YOU PLAY YOUR GAME. IM NOT RESPONSIBLE IF YOUR GAME DECIDES TO CRASH. THIS MOD FUNCTIONS STRICTLY WITH MULTIPLAYER. The files are built in the same structure as a folder on your files called 'Zombie'. All you need to do is copy your zombie folder and paste it in the root directory of your zomboid copy. Overwrite the matching files, and the server mod should be installed. Enjoy. [Misc] While the devs do their thing and make their version of a fix for this issue, I will look into updating this and maintaining it need be. I don't know how long the fix will take for them as I am sure they have a ton of work / optimizing to do for multi-player. If you have any concerning thoughts about this fix during that time, or something doesn't work properly that is not listed above, make a post. I'll look into it.

Ok. I'll make a new thread for it in the meantime with info and what not.

added some quick commands for removing active fires "/extinguish" and active corpse removal "/removecorpses". Im hoping fire commands and corpse decay / removal will be a thing eventually.

The script will stop spreading, however, the building or whatever tile that fire is on will burn. the fix i did accessed methods not accessable / preventable to keep the fire from damaging structures as well.

The firespread fix for the servers was done using a java modification. I would like to release that content in the form of .class files (logically), however, it is not that simple. I would need permission to release those compiled files as they are a part of the core of the game. I'm making this post because a lot of people are asking about it. If people want this, and PZ Devs allow me to at least post the modified .class files, then I'll be happy to do so, and update the mod as well. Until then, I am not releasing the fix.

It's no doubt an interesting problem. You guys chose well when choosing Java, because of Java's goal to be platform independent. Maybe doing a JNI for the render code could be a possibility. There are also techniques which can be applied to work with the Garbage Collecter in a way that allows it to do it's job better. One way is to define object names outside of loops before declaring an object while inside a loop. I've moved repetitive objects to call to a private field. I noticed a slight difference with memory usage when dealing with very intensive operations.

It isn't entirely Java's fault. If it wasn't for Java's automatic garbage collection system, You'd have to do it yourself, although that isn't a terrible idea (If java ever got that option anyway). Part of it is due to Java wanting to be easy to use, and another part of it is platform independence. (Also noting Java cannot de-allocate memory until the process terminates, due to platform independency for processors that do not have a call to de-allocate memory.) That double-edged sword aside, It could be due to the game's draw calls, as I noted the game uses LWJGL for OpenGL. There could be some rough spots for draw calls / functions. I don't think it would be in the 3D portion. It could possibly be due to drawing the map itself. From my own experiences with optimizing java draws as much as I can, I learned that 2D drawing is a pain if you have so many items to draw. I would suggest possibly caching draw calls for each chunk for certain layers of static-objects. Compiling to a image might consume some memory, and it depends on how big the draw is and the call takes to execute and return. I'm wondering if the game attempts to try caching or some other form of memory storage technique to lighten the weight and time of the OpenGL draw methods. It could also come down to the way the game's physics engine works asynchronous with the graphics engine as far as updating and graphics projection goes. Also consider Object hotspots. Those are a bastard to deal with. Render engines try to steer as far away from object hotspots as possible when coding in a OOP language, especially Java. It could possibly boil down to all the stackframes and GOTO RETURN in the JVM causing some backup for the render methods because of this.

It could be a Object hotspot issue, or the way you handle your garbage collection (System.gc() / primitive vs. OOP data handling architecture). Not too sure about the missing stacktrace though. Edit: It could boil down to how the thread synchronize with the data too. Sleeping the thread has a dramatic effect on cpu usage, even if sleeping for 1ms). It all boils down to how the code is constructed, and I expect you guys know your Java.