-
Notifications
You must be signed in to change notification settings - Fork 50
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Larry the Bomb Boss #100
Comments
I would like to try this change when I finish the cerr one. |
Then take a shoot on it ;-). File a PR for it (with "WIP" if it isn’t ready) and I will flag it for the 2.0.0 milestone. Vale, |
I was assuming I should finish the other thing I was working on before filing a PR, but I could file one for this if you want. I wasn't sure if the 2014-07-31 feature freeze you posted was for suggesting new features in github or for finishing the implementation of features. I seem to remember you saying we'd all discuss what's feasible once that date passes. There is a good chance I will not finish this change by July 31st. It would help to give a better impression for a milestone 2.0 release (a finale), but in reality it's not absolutely necessary. It will, however, be critical to have new levels in the main game demonstrating all of the new features for that release. |
I quote shamelessly myself from the SMC forums:
That is, what has not been merged into As a practical consequence, I will go through all open feature PRs marked with "WIP" a few days before the feature freeze and ask their respective authors if they consider their code stable enough for being merged now. If they agree, I will merge this before the feature freeze, if they don’t I won’t and the PRs will go into the next release (or whatever release when they are finished). This means, you can always file a PR. And if you want my comments on your code, you are highly recommended to do that, because I won’t follow all the commits in your own repositories. If a PR is marked "WIP" this means it is not ready to be merged; if it doesn’t it is meant to be merged as soon as possible. Vale, |
This probably won't be going in version 2.0 then. Thanks for the explanation. |
@Quintus, is ed3fdf2 a good place to look to understand what's needed for this change? We had talked about using the existing Larry image and scaling it to a larger size for now. Would you prefer to clone a copy of the svg image so that an artist can easily swap it out later, or would you rather configure the xml for this boss to link to the regular Larry image? This task will probably run pretty slow for a while. I need to focus on learning scripting / some level editing, and school is about to start in a couple weeks. |
The SVGs are here:
Rescaling is just exporting it in another size. SVG does not care about pixels, it’s a vector format. Swapping out the image can later be done always. If you want to work on the SVG itself, then yes, a new SVG for the larry boss would be required. Vale, |
You should probably just look at the implementation of Vale, |
No, I just had meant whether we wanted to create a placeholder (carbon copy image pasted through Windows/Linux) for an artist to swap it out later if and when desired. By rescale I had only meant to rescale it within the SMC application image configuration. If someone decides to edit an SVG for this boss, then they would rescale or do other things with it in Inkscape. |
Yes, that would probably be good rather than using the larry images directly. This way no code changes are necessary for graphics change later (unless of course the larry boss has more/less frames later). Vale, |
This is a task to create a Larry the Bomb Boss
Concept Discussion:
Tasks
The text was updated successfully, but these errors were encountered: