I gave you objectives to work on man. :P
Putting dependent goals into groups and working on one group at a time is a good way to work especially when you can only dedicate bits and pieces of your time. I used to work on projects randomly like you said, and after a long break I would come back to a lot of unfinished functionality and forgotten plans. Make sure you finish enough at a time so later you can pick things up again easily.
Pro tip: Plan everything out. When you know your good to go, make an objective list for things you want to accomplish in a set time period.
Here's a comment.
Thanks for the iterators, it is coming in handy! It will aid in SetPosition not crashing, but there are still issues. When an object respawns, it most likely will not have the same datum_index and therefor I lose the object I am holding. Do you know of a way that I could get the updated datum_index of the same exact object? It would actually solve a lot of problems if I just disable respawning, which would stop them from being destroyed and recreated. I guess I could update the spawn position in the scenario, then have it grab the nearest object after it respawns where I was last holding it. It sounds sketchy but that could work until I figure out something more plausible.
Info's in the mail.
Since the last public release of OS I went in and finished the data iterator so coders can now properly iterate a data array's active elements. The old way was very sketchy and just overall wrong as it didn't protect you from trying to access an uninitialized datum. The new iterator protects you from this.
So that was another reason why I needed you to upgrade to the new codebase before I could really assist you. If you're iterating over a data array (instead of just accessing a known datum) you can open Players.cpp and view the implementation of LocalPlayerIndex() to see how the iteration now works.
There isn't much of a test/debug framework in OS since I wanted to keep compiler generated code to a minimum (especially when it comes to initializer thunks) and also keep the complexity of the code to a minimum. Since the code is working with an otherwise black-boxed program, it's really difficult/cumbersome to do proper testing/debugging setups (not to mention the ugly start-up times!).
Before hand, I was using IDA to debug crashes in OS. Eventually I moved to VS (since it's able to provide a pretty much full debug environment) but during the pure IDA days, using minimal-complex code made navigating OS's assembly a lot easier. Shit heavy in templates (like STL) or code which provoked the compiler into generating thunks can be an eye sore or cause headaches when dealing with things at the assembly level.
I should be asking you to do the same thing Firescythe. This isn't my code that is crashing like I said, it's a clean release build without any added code.
If it's crashing when resetting the device then you probably have D3D resources in the default pool that haven't been released prior to calling reset. Run the game with DirectX in debug mode with full output, validation, etc. and see what it prints to the Visual Studio output.
Thanks for the update, and for using our blogs system!