Jab

I am confused. What exactly are you trying to do?

The version just upgraded yet again. Going to wait until either TIS Says 33 is done and 34 is being worked on, or the version doesn't upgrade for a few days.

I'm waiting until they stop updating the public branch like every other day. It would be pointless to consistently update this mod until then..

Could be the server, could be the mod you are using. Not sure if i need to modify server code to support custom model flags. It's possible that it's on my end.

Update is live. Hope things work flawlessly. I just tested it.

It would be a while for anyone who does not have the source modifications and knowing where to place the modified code, so Anyone besides TIS staff (or me with my knowledge of that area of code I'm modifying), would take a little while.

Regarding my previous post, I had no idea that the IWBUMS would upgrade to official on that day. I was more concerned over the build taking longer and longer to release, and things stagnating. It's hard to say how I feel about that, mostly because it would sound like complaining, rather than general concerns and care for what is a good game. I also didn't realize how much of a staple this mod has become to the bigger picture of server and mod networks for the game, and i appreciate those who have messaged me about this. I will get to pushing a 33 build as soon as I can. I'm thinking about changing my mind about canceling this mod. It isn't too much work to update. Another concern I have towards this mod is the simple fact that it cannot be distributed as easily as traditional / standard mods for this game, due to the nature of the mod being byte code, which is compiled, which both TIS and Valve would not appreciate being distributed. I've thought about this a lot. I could make a simple installer. I could do a lot of things about this, however, I felt that many people would be frustrated with whatever i decided to do to make installing ModelLoader easier (Past experiences with modding). tl;dr: I'm glad to see a positive vibe towards ModelLoader, and this may reverse my decision to possibly end the mod. Thanks for the support, guys!

As PZ winds into Build 33, I don't think that I will make anymore future releases of this mod, possibly 33 being the last one. I feel that this is a rather simple implementation of a component that has long been desired in this game, and is quite a bother to update, given the nature of the mod's implementation. Also, not being able to put this on Steam is a real bother. Things feel very slow in PZ and I've been doing work in other games in the meantime. Great game with a lot of potential, among other things...

Ahhah! It has something to do with deaf -trait. So I guess this new sound system can't handle that. I made another character without deaf trait and almost identical and it works. I wonder if this new audio system copes with null, or even uses null as a logic flag / state.

Going to look at verifying the scripts working with Blender 2.76b and focus on getting the export working properly.

Updated post. The channel has moved from DALNet to EsperNet.

I stalled on completing these scripts due to lack of time, and considered waiting on the animation updates possibly in 34, as to not waste time reinventing the wheel. I might be looking into working on this again soon though.

Did you make it a global static? Regardless, this is great news. That should alleviate some of the computation time on the Render side of the game.

There is no discounting of frailty of anything in the point that I am making. The point is, simply put, that the ability to utilize Hard memory I/O would alleviate some of the stresses that the current architecture of the engine supporting and rendering the sprites in Project Zomboid, that is currently loading all sprite sheets into RAM memory. Doing this should not be considered an issue. RAM memory is just as faulty, given the circumstances of manufacturing, warranty, and proper maintenance. Also, this doesn't need to apply to all sprites. You can also get around clothing sprite coloring by using a variety of toolsets given from even GL11, although from my understanding, the game currently utilizes up to OpenGL 2.2 API. There are ways to optimize the load-time, and the stresses brought on by the memory loading, even with Java. I'm only expressing 2 of them. This is my suggestion for later down the road for Project Zomboid, and I'm pretty confident in the work of the current developers handling that area will find something good, or even better than the options i know about for this kind of situation.

Although I agree that based on certain areas, there are a lot of sprites needed to be loaded to render, I don't see the weight of those loaded sprites doing much justice to the game's overall memory efficiency. It does make sense to load in a sprite/dope sheet the way it is now, due to the configuration of each angle on each sheet. However, there are various techniques which can be used to dampen the load of the sprite sheets in memory, be it through chopping sprites during runtime, or layer pre-rendering and unloading, asynchronously to avoid java's memory heap from allocating more memory. Loading and unloading shouldn't be too much on a storage device now, and I wouldn't consider that to be a concern for the majority of players. I hear more about RAM , or graphics memory, than storage issues. Although TIS has bigger priorities to take on, this would be something to look at when focusing on ways to increase the efficiency of the game's overall process of handling and managing render states and assets in general.

I'm quite curious as to whether or not TheIndieStone has tried or tested memory management of sprites, as well as other assets loaded pre-game and in-game to cut a lot of the memory overhead. Just throwing this topic up to sound this question and suggestion.

Didn't make the models for ORGM, just gave a way to load them. Thanks though

Why did you do this in Python 2? Preference? I feel like I may actually attempt to do something like this, with the actual save file format if I ever get the spark of the moment for PZ again. Good job though.

My mod is java based. Any class file in my system that is updated in the game requires me to go in and update those files. IWBUMS is unpredictable and has no set candidate scheduling, and requires me to consistently update my mod if I so choose to follow IWBUMS. If the scheduling was consistent, I would probably do some IWBUMS versions.

Are you releasing this alternate variant of the mod publicly yet? This is something I've wanted to do for a very long time but never got around to doing so. Ya its been out and ive ahd a lovely team of coders and testers helping me. Just got a great java scripter on my team to see if we can fix the games old aiming system which never got implemented because the devs abondoned it for a simpler version. just look on the steam workshop unde recents and its ORMntMans real gun mod edit by jether. add me on steam if you want to help test since just a few people cant decide what is truly balanced. You seem inclined to repeat this eveywhere, so let's make it very clear: The current aiming system works fine and there's not much reason to expand on it right now, though a combat update is planned in the future. What scope that combat update will take, we currently don't know. That's not abandonment. Good luck. We all have our opinions on certain mechanics on the game. I would rather challenge someone to make something better and prove their opinion with evidence than call em out on their opinion, regardless of how strongly worded their opinion is.

I would suggest using Blender to render out more blocks using isometric perspective (Orthographic). Make sure to turn off mip-mapping and use "NEAREST" for texture filtering. (Coming from someone who spent years wrestling with Minecraft 3D stuff.) Edit: Now that I think of it, there might already be iso tools without the use of Blender or some other 3D editor. Anyways, this is one way.

Not sure why. I have no idea what your anti-virus is, and even still that's a first.

A head's up to new-comers to ModelLoader: I do not wish to support IWBUMS versions. Unless there are stretches between versions for IWBUMS, the frequency of updates for this mod and the time it takes to go through each version is too time consuming.

Not sure if the map data format is a public thing, however, I was considering attempting a generator back when I had time. The devs want a static map, and that makes sense. It is tempting to try RNG maps with all the work to put behind making it possible.

Yes. The only thing stopping me is thinking how people can either hijack the installer and maliciously inject content, or how questionable the method is in general. Edit: I've also been in this situation more than once. People really do concern over these, regardless of the countless amount of virus scanners and security these days.