peavey_p

But they did start straight away, all the way back in Fall/Winter of 2012! They started with the major architectural change of moving to a client/server network model, and they've kept us informed of a succession of complete rewrites of various subsystems since then: such as the physics engine to be used for ragdoll, item throwing, and the upcoming new vehicle system; the new nav mesh system for NPC pathfinding; the impending complete renderer rewrite announced a few weeks ago; as well as entirely changing how the engine handles guns, from simple config strings to first-class objects that support an attachment system; etc. etc. In short they've been undertaking significant engine subsystem replacement or redevelopment efforts at about every step along the way since shortly after Standalone was announced in Summer 2012. What they're doing isn't light work. Software development really does take time. I've been happy they've made the risky choices over the past 18 odd months to rewrite or replace so many significant components of the engine, with their stated long-term goal of building a better platform on which to run the eventual game.

I can't speak for Bohemia, but the following observation matches my own experiences in game development, more often than not: Nevertheless, while some folks have asserted that Dean should have started over with a different engine (and/or with Arma3) to make DayZ SA, that was never a realistic option given the original December 2012 release goal of repackaging the mod as a stand-alone Steam title with a few fixes. From that point forward, the scope of what was being attempted for DayZ SA became a moving target. But taking that into account, the technology decisions made by the DayZ dev team at each step along the way have seemed sensible (i.e. strategically incremental) considering the goals and constraints they have been operating under at each point the decisions were made.

Programmer on several games/engines from 1989 - 1998, primarily on Amiga, Sega Saturn, Sony Playstation 1. Even back then, the occasional bug could prove very difficult to track down -- particularly if the bug resided in a low-level subsystem that interacted only probabilistically with the rest of the engine, such as an Interrupt Service Routine which in some circumstance was trashing a register that wasn't properly saved, leading to what could be very intermittent and seemingly random odd behavior or crashes of the game. Today's engines tend to be coded at a slightly higher level, but are considerably larger and more complex systems of software than the ones we developed. So it is no surprise at all that there will sometimes be bugs that will take an extended length of time for the DayZ devs to reproduce, investigate, characterize, identify, and fix -- no matter how badly they might have wished to release to stable. And as Dean recently pointed out, the longer they defer the release to stable, the more painful for their team, who will be dealing with increasingly complex code branching and merging as development of new features continues in parallel with the experimental branch which to some degree becomes stuck in limbo while the remaining game-breaking bugs are solved, before it can finally be pushed to stable. tl;dr: The DayZ team themselves want to get 0.42 onto stable at least as badly as any of the complainers in these threads.

It shouldn't boggle the mind. I don't always agree with Joel on Software, but on the balance he got this one right: Things You Should Never Do, Part I We tend to want to scrap and rewrite systems from scratch in order to improve them, and this is a decision that tends to unfold with tragic consequences in large software systems when on a deadline. It seems evident that the standalone devs, about 15 months ago and under a then-looming deadline, opted for a surgical approach: implement a new client/server architecture while breaking a minimum amount of existing mod code. Based on Dean's comments it sounds as though such an approach allowed the old client script system to remain functioning, while providing a path to migrate scripts to the server side under the new architecture, in a piecemeal fashion. If so, it is then not incongruous to arrive at some point at a state where all of the following are true: <a> all key scripts pertaining to exploitable loot spawning mechanics have been moved to the new client/server architcture; <b> the old script architecture is still used for some non-security-impacting parts of the game logic; <c> a no-longer-needed hook which allowed for loot spawning via the old architecture is still accessible even though it should have been disabled but was accidentally overlooked. If this is the case, then the discovery and removal of any such now-unneeded-and-inadvertantly-still-active hooks in the old system would indeed constitute a genuine fix for the exploit, and not be merely the application of a band-aid measure. In large scale software development on legacy codebases the shortest distance between two points is generally not a total rewrite.