Sambo wrote:1)Make it so you can place more than one of any item in a box, and decide if they come out one at a time or all at once when you hit the block.
This also suggested by Kevsoft long time ago (also he shown me a video where someone builds map in some RPG game, and where user selects multiple tiles and then places this mosaic to the map as it's alone tile), but still good idea, so, that will be kept in a mind until I will finish main sort of optimizations (QGraphicsScene sucks on maps with a big number of elements, therefore to resolve this I must implement interactive scene with items, multi-selction, dragging and moving, etc. That must not be hard, but requires time, experiments and then converting everything which implemented over QGraphicsScene into new-implemented editing scene)
Sambo wrote:There could be an "infinite number" option as well, and a "randomizer" option. This option would allow you to make a random NPC of your choice come out. With this, you could limit the number of block hits so the player can't get everything that's in it.
Since lua-API is presented, there is already possible to have programmable randomizers-NPC (like random power-ups, random vegetables, etc.)
Sambo wrote:2)This would sort of go with the other suggestion, but could be implemented in the current editor. There should be a counter shown in the editor for how many coins are in the block. This would appear on the bottom of the coin graphic that appears when coins are in the block.
...draw that number like WarpID drawn on every warp point, so, I'll add that, good idea
h2643 wrote:maybe it would be better to finally move SMB2 pass-through block from SMB3 block section to SMB2 one? Block-289 is the block I'm talking about. Redigit put it in SMB3 section by a mistake an accident originally.
Okay, you right (even a proof
h2643 wrote:remove PGE testing from the editor for now, and only leave SMBX testing (with testing settings too)
That is totally unneeded. Instead I added a warning message box about in-development state of engine part. Also SMBX-Test plugged to F5 key by default in the SMBX Integration configuration package, because SMBX-Test is impossible without SMBX Integration package (except in-editor test while SMBX Editor is running in background). I working hard on engine and now it takes huge changes since february 2016: it finally took player API for lua and I finally can write lua-scripts to implement power-ups, ability to cure health, do some attacks without "chucknorris" cheat (until this, every big level is in "hardcore" difficulty, so, let bossedit8 try to play one of "The Invasion 1/2" levels in hard mode (no ability to restore health!
)), it finally takes moving layers support, so, unbeatable in past levels are finally beatable now. (Anyway, if too much elements in a moving layer, because iterating of every element plugged in the moving layer, engine is going to lag while that layer in move. Examples are water-based levels with rising/downing water where lots of BGO's are plugged as moving layer. I think that in SMBX instead of every element iteration are modifiers variables which are defining offset of elements which are plugged plugged into moving layer. Anyway this way results some bugs known in SMBX, example is wrong offset of layers after level restart in some cases, etc. But this algorithm allows any number of plugged elements without CPU overloading).