When you're developing a new application (at least, when I am), a lot of really boring stuff has to happen in the background before you get to all the sexy bits of clicking buttons and drawing laser guns. Here's one example of that.
The major conceptual problem I am facing at the moment is figuring out how to tie the multiplicity of items actually on the figure to the preview boxes once the items have been placed. Not to get too technical, but I keep track of all the current items in what's called an array. Each "element" in the array gets a number assigned to it, and if you have that number you can access the item behind the element. In the minis I used the very crude method of putting that number -- called the index -- into the actual name of the item and then cutting up the name when clicked to retrieve it.
Tonight I figured out a nice elegant way of getting that index number when the item's clicked. Which is very good, because now whenever an item is deleted I can just remove it from the array instead of doing like I did before, which was to leave every item ever added in and just marking the deleted ones as "inactive". That meant the array could get very large, which makes things run slowly. Now, though, I can keep the array limited to only items that are currently on the figure.
My stumbling point is back in the previews. When a user clicks on the preview item for an item that's currently being used (and maybe there are multiple copies of that item out there, like in my prior three Colt .45s example), I need some way to tie that preview button to the actual item in question (and in turn its index number).
So far I've been able to clean up a lot of the clutter that was in the minis, which were my first attempt at using Action Script 3 (the latest iteration of Flash programming). I hope I have a breakthrough tomorrow on this particular issue, because it's pretty key to the whole enterprise. I think once I get this one licked, most of the major development hurdles will be cleared and I can start serious code assembly. Currently it's all in pieces being tested, as I don't want to hash out a bunch of garbage that I then have to go back and correct as I get things figured out.
Such is the life of a programming hack!
Haha, glad you found a way to improve HM3.
Can’t wait for it, and can’t wait for more updates on it.
Hey I am feeling for you Jeff!
I actually fell asleep twice through reading that, so fully understand the pain you are going through!! lol
Seriously though it is great seeing these little updates, and how you are moving forward with HM3
Reading that made me have a new appreciation for what you do, and I didn’t even understand a lot of it.
just wondering are we going to be able to move items farther and all the way to the edges of the box? Because a lot of items will only travel so far in the box.
And also if you’re not already too swamped, you think it’s possible to try reverse masking. Basically when you mask an object, everything that is not masked in the object shows, whereas everything inside the mask disappears?
Don’t feel bad, most of it doesn’t make sense to me, either.
Re: the items moving around the box, that’s certainly possible. Not so with the reverse masking, unfortunately.
and that’s cool, thanks for replying. Keep not sucking, cause you’re good at that
Huh. I understood all of that. Arrays and indexes (indexi?) are fun. 🙂
As a longtime fan of HeroMachine 2 I am ecstatic to see that there is a new version in the works. Best of luck!