Multiple Element Growth Options && Spirit Image autosizing & scaling

[resonant-gamedesign]

Two changes:

For Element Growth, this implements OR and 2 of the same (AND not implemented) Required adding a 'backslash' image to separate the OR elements Required a change that may have consequences - growth-cell gain icon. is now "display: inline-block;" instead of just block Also, I changed the bottom margin on the elements to 7px from 10px... this made them line up better.

Changing the image sizing required reworking the order of things that happen in MAIN (so that the special rule can resize before the image sizes itself).

I hope I'm doing things correctly. Never used GitHub before.

[LokiMidgard]

This looks correct, for a pull request ;)

This is not required but especially when changing somthing graphically I like to put screenshots/images of those changes in the pull request, or at least some examples.

But I also havn't done it in every pull request I did...

[resonant-gamedesign]

Are the three commits related to the adversary already part of the pull? Will this pull update with every change I make to my master? If that's the case, I guess I should branch my master? I'll add images next time - where do I add those? As comments?

[resonant-gamedesign]

See example for 1) spirit image scaling (though you'll want to play around with that), 2) an example of 2 of the same element, and 3) an example of an OR (it works for 3 elements as well, and more but once it overflows bad things happen).

[LokiMidgard]

Are the three commits related to the adversary already part of the pull? Will this pull update with every change I make to my master? If that's the case, I guess I should branch my master? I'll add images next time - where do I add those? As comments?

Yes from the branch you created the pull request you get all new commits. If you want to remove some commits you could force push to your branch I think...

You can also edit the original pull request if you want.

[resonant-gamedesign]

I'm OK with these all being one big push, but I'll segment future work so its not overwhelming. I assume whoever is moderating the master file will want changes to be clear and separate instead of a whole mess of them at once.

[resonant-gamedesign]

I think I'm doing something wrong. I don't mean to push all my changes to the main repository, and certainly not all at once. Any clever solutions?

[resonant-gamedesign]

Well, I've really gotten into this. Big changes are primarily in the growth options. Here are some examples:

[LokiMidgard]

I think I'm doing something wrong. I don't mean to push all my changes to the main repository, and certainly not all at once. Any clever solutions?

create a branch form your current position. This is to not accedently loose some work

git branch safe_head

then reset this branch to the position you want. Find out which commit in your history you want to revert to and copy its hash

git reset HASH --hard

Now your local branch will be several commits behind your remote. You can override your remote with

git push --force

You now have your master wich is linked to this pull request at your desired position, Your newer work is safed in the branch safe_head, you can continue to work there....

I hope this helps a little bit

[resonant-gamedesign]

Very helpful, thank you!

[resonant-gamedesign]

I believe the conflict that Git is identifying is not really a conflict. We can just go with my version of the code, which I updated to use the parseInnatePower and parseInnatePowers functions added by the Aspect update.

But my only option is to COMMIT after I resolve the conflict. Is that OK?

[Yexo]

I believe the conflict that Git is identifying is not really a conflict. We can just go with my version of the code, which I updated to use the parseInnatePower and parseInnatePowers functions added by the Aspect update.

But my only option is to COMMIT after I resolve the conflict. Is that OK?

Yes, that's normal and expected. Git calls it a conflict because multiple branches modified the same lines (or lines very close to eachter), so git doesn't know how to automatically resolve it. A "conflict" just means you manually have to verify or update the code, the "commit" then tells git "I verified/updated the code and now it's ok".

[resonant-gamedesign]

Hey folks! I understand that this action can be reversed, so I'm going to go ahead and merge my updates. I don't think anyone is going to take the time to review them and I'm confident that it all works. There are a number of big improvements that I think benefit the project, even if minor issues are introduced (which we can resolve in future edits).

The advantage of merging this is that it allows me to continue developing and perhaps try to merge the other changes folks have proposed.