Fix Data.clear() and add Emitter.simulate(time)

[jacobalbano]

Incorporates a change to the Data API as discussed here, and adds a method to the Emitter class which allows the passage of time to be simulated for "pre-warming" particles. Demo and discussion here.

[zachwlewis]

Is the desired use of clear() just to flush data in memory and not on disk? I feel this is the best approach, but I just want to make sure it is working as intended.

So, to delete a save file, a user would have to do the following:

Data.load("slot1");
Data.clear();
Data.save("slot1");

[zachwlewis]

Other than making sure clear() is functioning as intended, this looks good to go.

[jacobalbano]

Yep, that's how I intended it to work. My thinking was that all the other data functions work with the currently loaded SharedObject, so clear() ought to as well, plus I can think of times when you might want to clear data and not immediately flush it.

[zachwlewis]

If I could get another pair of eyes on this, I'd feel comfortable merging it. 👀

/cc @azrafe7 @useflashpunk/librarians

[zachwlewis]

Also, is ae0e560 part of this pull request? What is that doing? Something with vectors, apparently.

[jacobalbano]

I'm still not super good at github so I don't know if that one is included in this pull request. It fixes FP.choose() not working with a Vector of int, uint, or Number. Those types are handled differently in memory, so you can't convert Vector. to Vector.<*>,

Prior to this, passing FP.choose() a vector of ints would result in the whole vector being returned, and sort/shuffle would have no effect.

[zachwlewis]

Pull requests are used to request the changes in a source branch be pulled into a target branch.

Usually, you'll want to create a branch per feature (I'd name this one "emitter-simulation"), then complete your feature in that branch. Once your feature is complete, or when you're ready to have eyes on it, you would submit a pull request. Then, if changes are made to that branch (like fixing a bug or updating a function definition), those changes are automatically added to the pull request.

If you submitted a pull request from "master" and you committed anything else to it, whenever the pull request is pulled, it'll get those changes as well.

As a rule of thumb, don't submit anything directly to master. Create a branch for the feature you're working on. When it's complete, submit a pull request, pull that feature branch into your master branch, and safely remove your feature branch. This also makes it easier to contribute to other repositories.

On Wed, Jan 21, 2015 at 12:11 PM, Jacob Albano [email protected]
wrote:

I'm still not super good at github so I don't know if that one is included. It fixes FP.choose() not working with a Vector of int, uint, or Number. Those types are handled differently in memory, so you can't convert Vector. to Vector.<*>,

Reply to this email directly or view it on GitHub:
#144 (comment)

[jacobalbano]

Gotcha. I'm used to Bitbucket/Mercurial, and pull requests work a little differently over there.

So I should have my own personal fork of Flashpunk, which stays up to date with the official repo. When I make changes, I branch my own repo, and submit pull requests from there?

[azrafe7]

👍 I'm OK with the changes (also agree that Data.clear() shouldn't flush()).

Didn't know about the Vector thing, http://stackoverflow.com/questions/5054418/how-to-test-if-an-object-is-a-vector clarified it.

[jacobalbano]

It had me scratching my head for quite some time. I was doing this:

var choice:int = FP.choose(myChoices);

The result was coming up 0 every time when I used a Vector., but it worked fine with arrays. I guess Vectors become 0 when coerced to ints? I dunno.