Thank you for the comments, everyone!
Originally posted by Iceguy- Allow events to be merged.
They can be already; just use the "Go to another event" or "Go straight to next event" actions.
Originally posted by Iceguy- You might want to add tooltips or a status strip to explain what certain things do.
Most of it is already in the readme, but yeah, putting explanations in the program itself couldn't hurt.
Originally posted by Iceguy- Add scrollbars to the generated code window.
Originally posted by Vitor Vilelagenerating a larger code a scroll bar is missing are some examples.
Will do.
Originally posted by Iceguy- Use $94-$98 for the player X/Y position.
Any particular reason? I always thought that, unless you're actually moving the player, that $D1-$D4 were the best to use.
Originally posted by Iceguy- Perhaps make things even easier to use? For example, rather than setting values for things like the P-Switch timer why not work with seconds? I think newbies would prefer something like that.
That's a good idea. I'll probably implement it for actions like that.
Originally posted by Iceguy- Sort the actions into alphabetical order.
I'm not sure that would help much, though, seeing as there's no more relevance when sorted alphabetically than when sorted categorically. As in, if they were sorted alphabetically, the list would look like a long string of "If the player's ..." followed by a long list of "Set the player's ...", and you'd still have to look around for the action you want. That's why the search bar is there.
I'm not saying "no", though. If people generally do think this is a good idea, I'll add it.
Originally posted by Iceguy- Add more things like display a message, of course.
Alright.
Originally posted by Iceguy- You might want to check
this out to see a general idea of what type of blocks people want I guess.
Most of the stuff there seems to be covered.
Originally posted by Iceguy- "If the player's coin count" only adds a BNE, not the label number.
Fixed, thank you.
Originally posted by Vitor VilelaThere are some issues though. Some windows show the X,Y position of a mouse in window title o.O
Oh, I accidentally left that in. I was using to debug the edit window, which puts its controls in different locations depending on the properties of the action it's editing.
Originally posted by Vitor VilelaAlso here a few suggestions:
- Store/add/subtract a value to RAM address(+X/Y if indexed is checked).
I'll probably add this, though it will require a bit of reworking. Right now 90% of the action editing code expects an action to only have one variable.
Originally posted by Vitor Vilela- Goto (sub)routine.
Good idea. I'm not sure why I didn't think of that one.
Originally posted by Vitor Vilela- Kill sprite (that touched).
(see previous comment)
Originally posted by WiimeiserRealy good, but needs Copy/Paste and Spawn Sprite functions.
Copy/paste, sure, why not. As for sprite spawning, if you mean like what P-switches and shells do, then I'll definitely look into it.
Originally posted by Mini_CoinWhy is it called Blockreator? I mean, I guess it's supposed to be pronounced block-creator, but it makes it look like you need to say block-reator. Or was that intentional?
It was intentional. I wanted to have the name be an awful pun, and this was the best (worst?) one I could come up with.
Originally posted by leodWhere's the "don't submit blocks that can easily be made with Blockreator" Block submission guideline?
Is it going to be there once this tool leaves beta?
That's up to the block moderators and whether nor not they deem this program to be easy enough to use to justify removing those blocks.
QuoteGeneral stuff about a sprite creator
This is a bit more difficult to answer. The thing about sprites is that they are much more "specific" than blocks. It's kind of difficult to explain, but blocks' code can get away with this kind of simplified "each action can equate to a single block of ASM", sprites much less so since they are much more dynamic. They would need more complexity than this simple system could offer. It's not out of the question, but the problem is that building a sprite that does much more than a goomba, even with a GUI like this, would still be a rather complicated, decidedly non-newbie friendly affair.
So all that being said...maybe.