v0.5.2 Progress Report

[leeor_net]

Welp, it's been awhile since I've really done much with OutpostHD or at least anything that's visible. Suffice it to say I've been semi-sort-of stuck with the problem of resource handling as outlined in this Redmine Task.

Real life has kinda sorta been kicking my ass lately so it's been difficult to truly focus but I have the problem ironed out on paper with a clear idea of what I need to do next. While the Roadmap shows that there's still a lot to do almost all of the final tasks are related and interdependent on each other... so it's actually not that much work even though there are a lot of tasks.

What I haven't noted or tracked is some of the internal code cleanup I've been doing. I noticed a lot of redundant code so I started pulling those into functions which just means that it's easier to spot a mistake in one part of the code than to spot it in one part of the code and have it copy/pasted in many sections.

Anyway, once I get out the rest of the resource handling logic (I didn't realize just how involved it is), I'll be pushing out v0.5.2 and then moving on to the next task of game saving/loading (find it annoying to have to constantly rebuild the same colony over and over when I could instead just load it from disk when I start the game and do my tests from that point on.

[leeor_net]

Just wanted to follow up on this -- I plan on getting the resource handling banged out today. I've got the changes planned out on paper and the problem effectively solved, now I just need to go into the code, unhook the temporary stuff I added just to get things moving, add in the new interfaces and logic, rehook everything back up and test. Assuming everything goes according to plan today, I expect to push out 0.5.2 this week and get started right away on the saving/loading (it's becoming a problem to rebuild a demo colony to test code every single time I make changes... time to improve that problem).

[leeor_net]

This is a little more involved than I thought it would be. I think when I started building the structure classes and the resource handling it was with a much simpler model in mind.

The more I look at the code and the prospect of modifying it to force it to do what I want, the more daunting the task seems. Which leads me to one conclusion.

It's wrong.

So that's where I'm standing. I'm literally going to gut a lot of the code, specifically with the way resources are handled and distributed. I have the Mine resource production code correct and doing what I expect it to so that, for me, is a good place to start.

Anyway, next week I genuinely have a few days off so I'm going to take that time to gut the resource and structure management and handling code and rebuild it with the new model in mind. Should make for something that's much, much cleaner and easier to maintain.

[leeor_net]

Okay, so, those who have been following, v0.5.2 has been a bitch to get through. If you haven't been checking out the repository I've committed a large number of changes and restructured and rebuilt a lot of the code base for OPHD -- the StructureManager in particular behaves very differently than it did before. Structures are now handled in a much different (and I think much more effective) method than before where they were all grouped together in a single list sorted by priority.

Anyway, attached is a screenshot of the changes to the StructureManager alone... pretty sure only programmers are going to understand it at all. This is one of the latest commits -- there have been 25 code revisions since the last release which for me is generally a lot.


BOTTOM LINE

Okay, so the important point is that there are massive, sweeping changes in the code between 0.5.1 and 0.5.2 but it doesn't look much different on the surface. I'm hoping by the end of the weekend to have 0.5.2 pushed so I can move on to saving/loading and truck routing.

Coming up soon on things like research, population and morale. Should be fun!

[Hooman]

Very pleased to read your progress.

You make much larger commits than I do. Some of those commit messages have quite a list of changes. I used to do that. I've now moved away from that practice. Now I try to separate out unrelated changes into unrelated commits, even if I worked on them in parallel. It's sometimes a bit of a pain to do. I found it makes it easier to verify a set of changes if you're ever doing code reviews with someone. This of course leads to a lot of commits. I've had around 30 commits in a day before, but that's unusual, and most of them are really minor changes. Occasionally a commit will consist of a 1 character fix to a typo in a comment. Or perhaps white space changes to a file, when someone didn't follow tab/space convention, or left trailing tabs and spaces at the end of lines. Generally though, when real work was being done, 3-10 commits per work day was quite common. It varied widely by task.


I'm curious how much time you typically spend coding in a single sitting.

[leeor_net]

I've been moving away from giant commits myself. Actually a lot of the most recent commits are related changes -- in the case of what I've been up to recently, rebuilding entire segments of the base code kind of requires a lot of changes.

But eh, as I move forward I doubt the changes will be so huge now that most of the big stuff is out of the way.

Depends -- when I get time to really think about what I'm doing I can be programming all day long (though I find myself thinking about the code more often than simply writing it, or reading over the code and thinking about ways to improve it, etc.), most programming sessions are a few hours at a time though, typically 3 - 5 hours.