Contributing to FlashPunk


(Zachary Lewis) #1

Continuing the discussion from Welcome to the FlashPunk Developers community!:

If you have a suggestion or want to submit a bug for FlashPunk, you can do so on the FlashPunk Issues page.

If you have made a change to your own fork of FlashPunk, you can submit a pull request. To view outstanding pull requests, check out the FlashPunk Pulls page.

If you’re not sure how these features work, GitHub has a fantastic help section that clearly explains all of this functionality so you don’t need to be a git pro to contribute!


(Abel Toy) #2

We can work on fixing the open Issues, right?


(Zachary Lewis) #3

Yeah, you may update anything you’d like in your fork of the repo, then submit a pull request.


(Abel Toy) #4

So, I changed something and made a pull request. Then, I changed something completely different and also wanted to make an independent pull request, but the second pull request includes the commits in the first one. How can I avoid this?


(Zachary Lewis) #5

For a baseline understanding of how to fork and issue pull requests, check out Using Pull Requests.

To understand this system, it’s important to note that a pull request is the amalgamation of changes of a branch, directed at a branch and repository. If you made two separate changes on the same branch, your second pull request would include both of those changes. This is fine if both changes fix the same issue; however, if they are two separate issues, problems can arise. This is where branches come into play.

Here’s an example of how Frank would submit two seperate change requests to Sarah’s repository:

  1. Frank finds two bugs in Sarah’s code, Little Bug and Big Bug.
  1. Frank forks Sara’s repository.
  2. Frank creates a branch from frank/master named littlebug-fix and gets to work fixing little bug.
  3. When Frank is finished fixing Little Bug, he creates a pull request from frank/littlebug-fix to sarah/master.
  4. Frank creates a branch from frank/master named bigbug-fix and fixes the big bug.
  5. When Frank is finished fixing Big Bug, he creates a pull request from frank/bigbug-fix to sarah/master.
  6. Sarah already has a fix for little bug, so she closes Frank’s first pull request.
  7. Sarah merges Frank’s second pull request into sarah/master to fix Big Bug and closes Frank’s second pull request.

Does this answer your question?


(Abel Toy) #6

It did, thank you! Can we, then, remove unused branches once the issue has been fixed and merged?


(Zachary Lewis) #7

You may remove them once you’ve merged them into your master branch, but there’s no real reason to do so. They aren’t hurting anything, and it’s always good to be able to look back through your changelist.

As a git purist, I’d argue against it, but as someone who suffers from VC-OCD, I’d argue for it. :tongue:


(Jim Young) #8

I have a couple of suggestions I wanted to run by the community. I’ll implement them myself if people agree they are a good idea but thought I’d canvas opinion.

Suggestion 1: Allow entities to be ordered by “priority” when adding them to the world Rationale: I didn’t realise until recently that entities are always added to the front of the list, which I understand is for efficiency. In the past my world class’s update routines have always become a little heavy and difficult to maintain. In my latest development I am trying to develop entities as “components” loosely following an MVC pattern with the idea of creating easily reusable chunks of code, and a sparse World update function. I don’t know if it is overkill but I would like to have some control over the order they update. This change would obviously affect the World and Entity class so I would implement it so that using priority is totally optional.

Suggestion 2: Entity class to have “queuedToAdd/Delete” functions (or some better name) Rationale: Following on from previous rationale regarding component based entities. It would be good to know when an entity has been added to the add/delete queues, not just when they have been added/removed. This way the entity can take responsibility and ownership for adding any entities it needs to the world and they would be available at the same time.

Suggestion 3: FlashPunk has the handy Create and Recycle methods so the Entity class should have an init function which is called by Create. Rationale: Object recycling is very good but it would be nice to have an init function that is automatically called an people and override. This would essentially take the role of the constructor and the constructor would only be used for one time only initialisation. This would hopefully encourage object pooling and enforce a useful pattern.

Finally, I recently created a MaskableStamp graphic class. It essentially allows you to programmatically populate a vector with alpha values which you can apply to a Stamp. Think destructible terrain in Worms. If anyone thinks it would be useful I can clean up the comments and create a pull request for it.

That’s it for now, prob have some more soon.


(Alex Larioza) #9

@Jim

Suggestion 1: There is the bringForward() and sendBackward() functions of the world class, but there is really now way to specify a specific order. This would be a handy function to have on certain occasions.

Suggestion 3: If this is implemented, you wouldn’t be able to customize the parameters of the function (ie adding/removing parameters). Since overloaded functions require the same parameters.


(Jim Young) #10

The bringForward() and sendBackward() functions effect the entities order on the render list, not the update list, effectively modifying their z order.

Agreed that is a potential limitation for suggestion 3 but I have often thought the Create method should allow the optional supply of a dynamic list of parameters i.e. Create(MyEntity, { x:10, y:15, visible:false });


(Alex Larioza) #11

Ah oops, forgot about generic objects. :blush:


(Darien) #12

If we’re allowed to make feature requests, I’d love to have a stable sort algorithm. I ended up wanting one for a project I did about a year ago, and found out that AS3’s default sort is unstable; I was far too stupid to implement one myself, and ended up applying a really ugly kludge that I hated and still hate. :smiley:


(Zachary Lewis) #13

This topic was automatically closed after 30 days. New replies are no longer allowed.