Ideas & Suggestions for future versions of PGE

Description: Report bugs and ask questions regarding PGE here.
Forum rules: Here you can ask any question related to PGE Project components:


Any questions related to LunaLUA project please ask HERE (LunaLUA subsection)
Any questions related to SMBX-38A (1.4.x) Chinese project please ask HERE (SMBX-38A subsection)
Moderator: Moderators

What do you think of these suggestions?

They are perfect addition for this Engine.
31
Wohlstand, CaptainSwag101, John Leagsdurg, IngeniousPlatformer, Squishy Rex, Veudekato, the_end_of_WORLD, ImperatoreXx, CreatorForce, sky2, DatDude, Love Bodhi, hacheipe399, Fennor, Sambo, itskadenhere, Yoshimoto, Tux-Prowess, Pilzinsel64, Yoshi021, Jayce 777, Bonnies, Caketaco, KesterTank, TheCreator520, Stickman01, Jackson455, Glitchy, LuigiCraft, Greendan, the GaMERDoG
67%
They are not bad, could think of some others.
13
nexiana, Natsu, h2643, EXEcutor, Alucard, Josh16, ellingtonisland, lighthouse64, Saronin, Edward Elric, SamuelNM2, Sammzy, Coolio__
28%
I disagree with some of them (specify).
2
tb1024, Infobox
4%
I don't like them at all (specify).
0
No votes
 
Total voters: 46
Dato24
Passerby
Passerby
Dato24
Passerby
Passerby
Reputation: 0
Posts: 2
Joined: 24 Jan 2016

Post #321by Dato24 » 26 Jan 2016, 2:16

I don't have enough time to read all the posts on this topic, so I write my suggestions directly.
  • Background movement: in level editor of SMBX, when you move around the level, the background have a slower movement than blocks and other things, and this create a particular profondity effect. In PGE Editor this there isn't.
  • Auto-align: in SMBX's editor if is checked the checkbox "auto align", when you go over the editor window, the white hand have a free movement as you move your mouse, but the block/npc/bgo etc. will be already positioned in the "invisible grid" of the level. In PGE editor you can choose a function like auto-align, but in both cases (checked or not checked) the block have a free movement and only when you place a block it will be aligned with the grid, and it is a bit annoying.
  • The grid: I don't remember well if this is already implemented, but in case of no, I think is a lot useful have a visible grid in the level window.
    These are my suggestions :) sorry for my weird english
~~~ :tux: ~~~

Yoshimoto
Passerby
Passerby
Yoshimoto
Passerby
Passerby
Reputation: 0
Posts: 3
Joined: 3 Jan 2015

Post #322by Yoshimoto » 29 Jan 2016, 4:26

You can add this functions:
Add more custom npcs, blocks, bgos, tiles, backgrounds, scenes, levels, players and paths than original
Resize tiles, levels, paths, scenes and bgos
Custom functions and time limit without LunaLua and LunaDll
Custom sounds
Autoscroll
Teleport area definition.

Wohlstand M
Lead Developer
Lead Developer
Avatar
Wohlstand M
Lead Developer
Lead Developer
Age: 25
Reputation: 317
Posts: 1292
Joined: 15 Feb 2014
Location: Moscow, Russia
Website Skype YouTube

Post #323by Wohlstand » 29 Jan 2016, 9:43

Yoshimoto wrote:Resize tiles, levels, paths, scenes and bgos
PGE already supports those things of any size: just put any image ad CGFX and enjoy ;-)
Yoshimoto wrote:Custom functions and time limit without LunaLua and LunaDll
Every new thing works in PGE Engine natively
Yoshimoto wrote:Autoscroll
Already improved:
- you can toggle autoscroll in same section just witb block hiting
- you can set another section to be autoscrollable and then enter into it to begin you wall with scrolling screen
- you can return to scrollable section and stay scrollwalk again without level restating
Yoshimoto wrote:Add more custom npcs, blocks, bgos, tiles, backgrounds, scenes, levels, players and paths
Any "universe" questions are going for config pack, but not for engine core which interprets config pack and animating your universe. PGE already supports abiloty to declare any number of elements in the INI files (configs/<pack name!>/*.ini)
Yoshimoto wrote:Teleport area definition.
Instant warps? Is planned to have "wide entrances" to don't spam with warp points to make a long teleport area

sken130 M
Citizen
Citizen
sken130 M
Citizen
Citizen
Reputation: 1
Posts: 5
Joined: 18 Aug 2015
Location: Hong Kong

Config pack for SMW behaviours

Post #324by sken130 » 30 Jan 2016, 16:29

I wonder if it's possible to include an additional configuration pack which implements SMW game-play physics and behaviours instead of replicating all standards of SMBX.

I know it may be difficult to implement, because not only the data (graphics, blocks, power-ups (SMB3 feather vs SMW feather) will be different, but also the programming logics (e.g acceleration physics, flying physics, swimming physics) will be different from SMBX.

The following behaviour differences between SMBX and SMW are far from complete, but can serve as the examples:

  1. In SMBX, while running, Mario's speed is accelerated constantly towards the maximum. While in SMW, Mario's horizontal speed accelerates from 0 to 36, and stay in 36 for 1-2 seconds, and jumps (not accelerates smoothly) from 36 to 48 finally. Remarks: Mario's normal walking speed on land is 20.
  2. This's for swimming physics. In SMBX, pressing the jump button has the same effect as pressing the jump+up button. But in SMW, pressing jump+up button will swim upwards much faster than pressing only the jump button, and pressing jump+down button will swim only slightly upwards. Also, in SMW, while carrying items (Koopa shells, P-Switches, Spring-boxes, etc.), Mario's swimming horizontal speed increases from 16 to 32. Mario's walking speed under water is 8.
  3. Remarks: The address for Mario's speed is 7E007B, and you can use Snes9x with LUA to monitor it.
  4. For flying physics, it's obvious that SMBX's is different from SMW's, if you have played SMW.
  5. In SMBX, we cannot carry items (Koopa shells, P-Switches, Spring-boxes, etc.) through pipes, which greatly limits the possibility of many puzzle levels. In SMW, we can carry items through pipes. Though, this behaviour can be implemented as a episode-wide config instead of different config packs.
  6. Of course, we don't need to implement the glitches of SMW, such as the double yoshi glitch, wall jump glitch, etc. You may find the glitches in various Mario Must Die TAS.
  7. We know Blue Beach Koopa (Blue Koopa without its shell) kicks any shell on its way, in both SMBX and SMW. But the different is, in SMBX, it kicks the shell immediately after encountering it, while in SMW, it stops and waits around 0.5 seconds before kicking the shell
  8. We know there are animations when Mario is shrinking (after getting hit), when Mario is growing up (after eating a mushroom), when Yoshi is growing up (after its egg hatches). In SMW, during such animations, all other NPCs (and moving platforms) to freeze. But in SMBX, all other NPCs do not freeze during those animations.
  9. Mario's acceleration is higher SMW than in SMBX, making Mario more agile in SMW than in SMBX. I prefer "difficulty due to strong enemies" (which is more interesting since Mario rocks in this way) rather than "difficulty due to slow Mario" (which is a fake difficulty and Mario sucks in this way).

    For reference, you can feel Mario's agility in the extremely hard final boss fight of Kaizo Mario 3 (https://www.youtube.com/watch?v=oYHlznTM2zo), where the Japanese player R.Kiba lost around 110 lives there, and at 7:30 Mario's agility is fully shown. As a comparison, one would expect the final boss of SMBX's Princess Cliche 2 would be much easier (even without the bullet bill gun nor the hammer suit) because in Princess Cliche 2 Bowser doesn't throw 5 hammers, doesn't spit 3 fire balls, doesn't jump quickly, and doesn't have Magikoopa and Thwomp as allies. But still it's not easy to fight, and I lost more than 150 lives in the final boss of Princess Cliche 2 simply because Mario in SMBX doesn't have enough acceleration and agility (even if Mario has enough max speed) to dodge the flying koopas. Mario also has a bigger hit box in SMBX than in SMW. To summarize, SMBX physics won't allow agile Mario movements similar to Kaizo 3 boss fight 7:30.

    With SMW physics, the final boss of SMBX's Princess Cliche 2 would be a piece of cake, and we can make it harder by putting more enemies or obstacles.

You may ask why implement SMW behaviours in PGE again while we can just play SMW rom hacks in emulators?
It's obvious, because I want to get rid of all those awful limitations in SNES. We know SMW in SNES will lag heavily when there're just 10 NPCs in one screen. We know SMW uses the location to determine whether the question block is a blue-switch or grey-switch. We know SMW will glitch if there are more than 5 spinning blocks spinning at the same time. All these limitations are awful.

mariofan 64
Honourable citizen
Honourable citizen
Avatar
mariofan 64
Honourable citizen
Honourable citizen
Reputation: 3
Posts: 39
Joined: 22 Oct 2015

Post #325by mariofan 64 » 1 Feb 2016, 11:27

sken130 wrote:
Spoiler
I wonder if it's possible to include an additional configuration pack which implements SMW game-play physics and behaviours instead of replicating all standards of SMBX.

I know it may be difficult to implement, because not only the data (graphics, blocks, power-ups (SMB3 feather vs SMW feather) will be different, but also the programming logics (e.g acceleration physics, flying physics, swimming physics) will be different from SMBX.

The following behaviour differences between SMBX and SMW are far from complete, but can serve as the examples:

  1. In SMBX, while running, Mario's speed is accelerated constantly towards the maximum. While in SMW, Mario's horizontal speed accelerates from 0 to 36, and stay in 36 for 1-2 seconds, and jumps (not accelerates smoothly) from 36 to 48 finally. Remarks: Mario's normal walking speed on land is 20.
  2. This's for swimming physics. In SMBX, pressing the jump button has the same effect as pressing the jump+up button. But in SMW, pressing jump+up button will swim upwards much faster than pressing only the jump button, and pressing jump+down button will swim only slightly upwards. Also, in SMW, while carrying items (Koopa shells, P-Switches, Spring-boxes, etc.), Mario's swimming horizontal speed increases from 16 to 32. Mario's walking speed under water is 8.
  3. Remarks: The address for Mario's speed is 7E007B, and you can use Snes9x with LUA to monitor it.
  4. For flying physics, it's obvious that SMBX's is different from SMW's, if you have played SMW.
  5. In SMBX, we cannot carry items (Koopa shells, P-Switches, Spring-boxes, etc.) through pipes, which greatly limits the possibility of many puzzle levels. In SMW, we can carry items through pipes. Though, this behaviour can be implemented as a episode-wide config instead of different config packs.
  6. Of course, we don't need to implement the glitches of SMW, such as the double yoshi glitch, wall jump glitch, etc. You may find the glitches in various Mario Must Die TAS.
  7. We know Blue Beach Koopa (Blue Koopa without its shell) kicks any shell on its way, in both SMBX and SMW. But the different is, in SMBX, it kicks the shell immediately after encountering it, while in SMW, it stops and waits around 0.5 seconds before kicking the shell
  8. We know there are animations when Mario is shrinking (after getting hit), when Mario is growing up (after eating a mushroom), when Yoshi is growing up (after its egg hatches). In SMW, during such animations, all other NPCs (and moving platforms) to freeze. But in SMBX, all other NPCs do not freeze during those animations.
  9. Mario's acceleration is higher SMW than in SMBX, making Mario more agile in SMW than in SMBX. I prefer "difficulty due to strong enemies" (which is more interesting since Mario rocks in this way) rather than "difficulty due to slow Mario" (which is a fake difficulty and Mario sucks in this way).

    For reference, you can feel Mario's agility in the extremely hard final boss fight of Kaizo Mario 3 (https://www.youtube.com/watch?v=oYHlznTM2zo), where the Japanese player R.Kiba lost around 110 lives there, and at 7:30 Mario's agility is fully shown. As a comparison, one would expect the final boss of SMBX's Princess Cliche 2 would be much easier (even without the bullet bill gun nor the hammer suit) because in Princess Cliche 2 Bowser doesn't throw 5 hammers, doesn't spit 3 fire balls, doesn't jump quickly, and doesn't have Magikoopa and Thwomp as allies. But still it's not easy to fight, and I lost more than 150 lives in the final boss of Princess Cliche 2 simply because Mario in SMBX doesn't have enough acceleration and agility (even if Mario has enough max speed) to dodge the flying koopas. Mario also has a bigger hit box in SMBX than in SMW. To summarize, SMBX physics won't allow agile Mario movements similar to Kaizo 3 boss fight 7:30.

    With SMW physics, the final boss of SMBX's Princess Cliche 2 would be a piece of cake, and we can make it harder by putting more enemies or obstacles.

You may ask why implement SMW behaviours in PGE again while we can just play SMW rom hacks in emulators?
It's obvious, because I want to get rid of all those awful limitations in SNES. We know SMW in SNES will lag heavily when there're just 10 NPCs in one screen. We know SMW uses the location to determine whether the question block is a blue-switch or grey-switch. We know SMW will glitch if there are more than 5 spinning blocks spinning at the same time. All these limitations are awful.
Sounds like a massive idea for SMB Xtended, tbh. It can be done if you know what you're doing, but until then, just wait and it may sooner or later happen.
As for swimming, already like that in SMBX (you gotta try, man. it works already) and iirc, you can set warp options to allow carryable NPCs through the warp with you, even rides like Yoshi, but I haven't looked in a while, but I know for a fact that the swimming surely does work, just not in PGE yet, I think, but it does in SMBX.
One last thing...why add glitches? smh
Current Projects: (Infinite Mario Bros: 0.16%)
(Super-Project Completion: 0.001% Complete. pls don't ask about it)
Youtube Status: MIA

Squishy Rex M
Advanced Moderator
Advanced Moderator
Avatar
Squishy Rex M
Advanced Moderator
Advanced Moderator
Age: 22
Reputation: 114
Posts: 254
Joined: 24 Feb 2014
Location: Australia

Post #326by Squishy Rex » 7 Feb 2016, 11:26

mariofan 64 wrote:One last thing...why add glitches? smh

I have two reasons why:

1. Glitches can be exploited to create some pretty unique gimmicks and interactions.

2. There are a decent amount of levels that already exist which use and exploit the use of glitches. If not carried over, playing these levels in a "glitch" free game, effectively renders those levels unplayable. That said, I am not considering the "wall-jump glitch" or the "slide-through-the-wall glitch" in this as they have been shown to be not glitches, but purposely added. Wohlstand showed this a while back.
Squishy Rex's CGFX Pack v1.7
Image
To show your support add any of these Userbars to your Signature!
Image

SgwySpeedrcr
Good citizen
Good citizen
SgwySpeedrcr
Good citizen
Good citizen
Reputation: 2
Posts: 29
Joined: 4 Dec 2015

Post #327by SgwySpeedrcr » 16 Feb 2016, 23:00

I have been lurking for a very long time in the mario modding scene. I have edited many games into full mods. Long story short, I can tell that PGE is a very, very promising engine and I want to throw my full support into helping you all succeed. I am certain that PGE will be a powerful and successful platforming engine once officially released.

I hope that I can be of use to the development team. I am afraid that I am not a programmer so I cannot help in the most critical forms of development. I will examine the support thread thoroughly for ways I can contribute.


I apologize if this has been stated previously. I am excited that the AIs are to be edited.

Can the Hammer Bros AI be edited to match the behavior of the actual games? The current 1.3.0.1 and 1.4.1 do not interact with blocks in such a way that they can jump onto them. Also the Hammer throwing behavior is vastly different.

Wohlstand M
Lead Developer
Lead Developer
Avatar
Wohlstand M
Lead Developer
Lead Developer
Age: 25
Reputation: 317
Posts: 1292
Joined: 15 Feb 2014
Location: Moscow, Russia
Website Skype YouTube

Post #328by Wohlstand » 17 Feb 2016, 3:58

SgwySpeedrcr wrote:I have been lurking for a very long time in the mario modding scene. I have edited many games into full mods. Long story short, I can tell that PGE is a very, very promising engine and I want to throw my full support into helping you all succeed. I am certain that PGE will be a powerful and successful platforming engine once officially released.

I hope that I can be of use to the development team. I am afraid that I am not a programmer so I cannot help in the most critical forms of development. I will examine the support thread thoroughly for ways I can contribute.
Thanks for support of us ;-)

SgwySpeedrcr wrote:I apologize if this has been stated previously. I am excited that the AIs are to be edited.

Can the Hammer Bros AI be edited to match the behavior of the actual games? The current 1.3.0.1 and 1.4.1 do not interact with blocks in such a way that they can jump onto them. Also the Hammer throwing behavior is vastly different.
Because PGE Engine designed to have NPC-AI's as Lua-Scripts, you can edit them freely, also you can make new algorithm from scratch to customize it (NPC.txt's "script" field)

SgwySpeedrcr
Good citizen
Good citizen
SgwySpeedrcr
Good citizen
Good citizen
Reputation: 2
Posts: 29
Joined: 4 Dec 2015

Post #329by SgwySpeedrcr » 18 Feb 2016, 4:16

I see I have a lot to learn about the project with regards to NPC scripts.

Wohlstand wrote:Thanks for support of us ;-)

I am reading up on the project through your wiki. As I am reading through, would you like it if I were to make slight English grammar revisions to it for clarity? You are a very proficient English speaker... there's no way I could ever speak Russian :biggrin:

I have career experience with formatting and tweaking the wording for proprietary documents. It is an enjoyable task, and I believe I will gain a greater understanding of your project as I am doing so.

Saronin
Passerby
Passerby
Saronin
Passerby
Passerby
Reputation: 0
Posts: 1
Joined: 19 Feb 2016

Post #330by Saronin » 19 Feb 2016, 12:40

Make it easier to add custom graphics. For example Tools>Palettes and Tilesets>Import Tileset(s). Then choose the directory your images, and .ini are located.
No longer replacing, but instead expanding your graphics options.

Added after 6 minutes 43 seconds:
Thanks for all of ya's hard work


Could I please have a link to all the classes that are used by NPC AIs.
Lua seems to be a simpler, more platformer specific version of java, so having a look at the base classes, and those accessible by AI scripts.
Something similar to this: https://docs.oracle.com/javase/7/docs/api/
Last edited by Saronin on 19 Feb 2016, 23:47, edited 1 time in total.

h2643 M
Contributor
Contributor
h2643 M
Contributor
Contributor
Reputation: 82
Posts: 327
Joined: 15 Feb 2014
Location: Ukraine
Skype YouTube VK

Post #331by h2643 » 19 Feb 2016, 16:48

SgwySpeedrcr wrote:As I am reading through, would you like it if I were to make slight English grammar revisions to it for clarity?..
I will say yes, go for it if you want to. We will appreciate your work since there are... quite a lot of pages that need to be fixed. I also fix myself some of the pages, but I can't do much because I'm not a native english-speaker. I do what I can do.

If you want to help though, just log in in the wiki by using your forum's username and password :)
<Knux> h2643 the super computer

Sambo M
Count
Count
Avatar
Sambo M
Count
Count
Age: 19
Reputation: 13
Posts: 264
Joined: 27 Jun 2014

Post #332by Sambo » 26 Mar 2016, 4:41

I have a couple of minor suggestions:

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. 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.

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.
Image
Current Project:
Image

h2643 M
Contributor
Contributor
h2643 M
Contributor
Contributor
Reputation: 82
Posts: 327
Joined: 15 Feb 2014
Location: Ukraine
Skype YouTube VK

Post #333by h2643 » 26 Mar 2016, 20:25

My suggestions are minor and only for editor too :) So, since there's a SMBX 2.0 version of PGE Editor and the legacy SMBX editor will be disabled by default, 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 an accident originally.

And another suggestion, maybe remove PGE testing from the editor for now, and only leave SMBX testing (with testing settings too)? I've seen a lot of people getting confused as of why when they tested their stages the engine just wasn't working correctly, since they had no idea they were doing PGE testing instead of SMBX testing.
<Knux> h2643 the super computer

Wohlstand M
Lead Developer
Lead Developer
Avatar
Wohlstand M
Lead Developer
Lead Developer
Age: 25
Reputation: 317
Posts: 1292
Joined: 15 Feb 2014
Location: Moscow, Russia
Website Skype YouTube

Post #334by Wohlstand » 26 Mar 2016, 21:10

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! :devil:)), 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).

h2643 M
Contributor
Contributor
h2643 M
Contributor
Contributor
Reputation: 82
Posts: 327
Joined: 15 Feb 2014
Location: Ukraine
Skype YouTube VK

Post #335by h2643 » 26 Mar 2016, 23:09

Wohlstand wrote:
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.
Oh, that's great!
<Knux> h2643 the super computer

Pilzinsel64
Count
Count
Pilzinsel64
Count
Count
Reputation: 27
Posts: 219
Joined: 24 Jan 2016

Post #336by Pilzinsel64 » 27 Mar 2016, 21:19

I would say it needs a way to change blocksize like in smbx-38A.

Wohlstand M
Lead Developer
Lead Developer
Avatar
Wohlstand M
Lead Developer
Lead Developer
Age: 25
Reputation: 317
Posts: 1292
Joined: 15 Feb 2014
Location: Moscow, Russia
Website Skype YouTube

Post #337by Wohlstand » 27 Mar 2016, 21:25

Pilzinsel64 wrote:I would say it needs a way to change blocksize like in smbx-38A.
Are you mean setting absolute value sizes?
Okay, I'll add a mini-dialog from context menu of resizing box where you can modify absolute geometry of block (and even section or screenshot zone selection box) (X/Y/Width/Height).
Or better: Item properties box will have editable Width/Height fields on already-placed block (in-placing disallows pre-defined sizes because new block will be drawn with dynamical size definition (from rectangle drawn by you) )

Pilzinsel64
Count
Count
Pilzinsel64
Count
Count
Reputation: 27
Posts: 219
Joined: 24 Jan 2016

Post #338by Pilzinsel64 » 27 Mar 2016, 21:43

Wohlstand wrote:
Pilzinsel64 wrote:I would say it needs a way to change blocksize like in smbx-38A.
Are you mean setting absolute value sizes?
Okay, I'll add a mini-dialog from context menu of resizing box where you can modify absolute geometry of block (and even section or screenshot zone selection box) (X/Y/Width/Height).
Or better: Item properties box will have editable Width/Height fields on already-placed block (in-placing disallows pre-defined sizes because new block will be drawn with dynamical size definition (from rectangle drawn by you) )

Okay, thanks!

Squishy Rex M
Advanced Moderator
Advanced Moderator
Avatar
Squishy Rex M
Advanced Moderator
Advanced Moderator
Age: 22
Reputation: 114
Posts: 254
Joined: 24 Feb 2014
Location: Australia

Post #339by Squishy Rex » 4 Apr 2016, 11:54

Here's an idea, perfect for the miscellaneous category on NPCs. What about adding the Mighty Eagle from Angry Birds, as a power-up to PGE. Say you hit a block and out pops the Sardine Can. You throw it, it hits the ground and in swoops the Mighty Eagle, which in turn defeats all enemies upon contact, destroys certain blocks/objects and kills all enemies on screen upon touching the ground, causing a POW Block explosion of sorts to simulate the earthquake he causes in Angry Birds.

- The Sardine Can only activates the Mighty Eagle upon hitting the ground after being thrown, like how the SMB2 Bomb explodes only after being thrown. Putting the Can down by dropping it at your feet would make it not activate. It would also disappear upon activation or after the Mighty Eagle passes so it cannot be used more than once.

- The Mighty Eagle swoops in from the top left, hits the ground, causes the earthquake and exits to the top right.

- The Mighty Eagle would be a one-time only item due to its power and can only be used upon finding another Sardine Can. Also cannot harm the player.

- Defeats all enemies on-screen upon contact, or by causing an earthquake. Destroys ? Blocks, Bricks and Turn Blocks.
Squishy Rex's CGFX Pack v1.7
Image
To show your support add any of these Userbars to your Signature!
Image

Pilzinsel64
Count
Count
Pilzinsel64
Count
Count
Reputation: 27
Posts: 219
Joined: 24 Jan 2016

Post #340by Pilzinsel64 » 6 Apr 2016, 15:31

Wohlstand wrote:
Pilzinsel64 wrote:I would say it needs a way to change blocksize like in smbx-38A.
Are you mean setting absolute value sizes?
Okay, I'll add a mini-dialog from context menu of resizing box where you can modify absolute geometry of block (and even section or screenshot zone selection box) (X/Y/Width/Height).
Or better: Item properties box will have editable Width/Height fields on already-placed block (in-placing disallows pre-defined sizes because new block will be drawn with dynamical size definition (from rectangle drawn by you) )

I mea like this:
Image


Return to “Troubleshooting”

Who is online (over the past 5 minutes)

Users browsing this forum: 1 guest