char(1).warping, char(1).blinking and char(1).curframe

Description: Have any suggestions or new ideas for SMBX-38A? This is a place for you. Good suggestions may appear in future versions of SMBX-38A.
Moderators: Yoshi021, Lx Xzit, 5438A38A, Semi-moderatos, Moderators

Lx Xzit M
Topic author, Moderator
Moderator
Avatar
Lx Xzit M
Topic author, Moderator
Moderator
Reputation: 272
Posts: 619
Joined: 9 Nov 2015
Website

Post #1by Lx Xzit » 2 Sep 2019, 0:25

char(1).warping (Read Only) [ADDED PATCH 21]
I know there's an auto-run event to check whenever the player entered a warp, however it still requires some setup to know when the player has ended warping. It's not the same entering a door than entering a pipe, and it's not the same entering an pipe horizontally than vertically, (and not to mention the transitions effects). To differentiate between these three things, it would require us to three events, and trigger them on every warp in order to know exactly when the player is warping and the type of warp it's in.
It's important to know when the player is warping in case you want to lock certain custom actions while warping.

That's why I suggest a variable that turns 1 (or any other value greater than 0) whevener the player is warping, and turns 0 when the player is able to move again. This is not needed for instant/loop warps. In the case of pipe warps being projectiles, this property could take the value of 2 until the player is ascending, and turn 0 when the player is able to move again (it isn't completely necessary, it's just a small suggestion).

char(1).blinking (Read Only)
A variable that turns 1 everytime the player is invisible when blinking (when got hurt or when got a power-up). For example:
Spoiler
Image

The reason why I'm suggesting this to be a property instead of manually setting up it is because.
a. It requires a complex setup. The player blinks differently depending if got hurt, got a power-up and the type of power-up it is (either "special" or not).
b. The blinking effect is random so no matter what you do, you won't be able to perfectly sync the script with the player.
c. It is important that the script be accurately syncronized with the player, if you're doing for example a custom vehicle or anything that attachs the player (e.g a custom Spiny Hat or the Cape Feather).

Even after this setup the system is still not reliable. All this process can be a lot simplified by just making it a property If for example someone was working with a custom playable that's being drawn through a bitmap, and want it to blink as the player would do, he could only do this:

Code: Select all

bitmap().hide = char(1).blinking


(Additionally, this value can turn -1 when the player got a power-up/got hurt and while cannot move, but this isn't as important as what I said above)

char(1).curframe (Read Only)
Similar to npc's curframe, it would store a value indicating the current player's animation.
It doesn't have to be writable, being read only would be more than enough. This would be very useful for doing effects that syncs with the player (e.g a Starman effects that leaves flashy effects, or a custom accesory like a Spiny Hat from SMM or the Cape Feather, taking the previous examples).

I made this sheet to show how it would work:
Spoiler
Image

This way, the difference between facing left and right it's just a sign (I assume that's how the frames are programmed)
VISIT MY YOUTUBE CHANNEL! LX XZIT
Join our 38A Discord server!

Image

Victor ManuelMR
Good citizen
Good citizen
Avatar
Victor ManuelMR
Good citizen
Good citizen
Reputation: 17
Posts: 33
Joined: 7 Feb 2018

Post #2by Victor ManuelMR » 3 Sep 2019, 0:47

Spoiler
Lx Xzit wrote:char(1).warping (Read Only)
I know there's an auto-run event to check whenever the player entered a warp, however it still requires some setup to know when the player has ended warping. It's not the same entering a door than entering a pipe, and it's not the same entering an pipe horizontally than vertically, (and not to mention the transitions effects). To differentiate between these three things, it would require us to three events, and trigger them on every warp in order to know exactly when the player is warping and the type of warp it's in.
It's important to know when the player is warping in case you want to lock certain custom actions while warping.

That's why I suggest a variable that turns 1 (or any other value greater than 0) whevener the player is warping, and turns 0 when the player is able to move again. This is not needed for instant/loop warps. In the case of pipe warps being projectiles, this property could take the value of 2 until the player is ascending, and turn 0 when the player is able to move again (it isn't completely necessary, it's just a small suggestion).

char(1).blinking (Read Only)
A variable that turns 1 everytime the player is invisible when blinking (when got hurt or when got a power-up). For example:
Spoiler
Image

The reason why I'm suggesting this to be a property instead of manually setting up it is because.
a. It requires a complex setup. The player blinks differently depending if got hurt, got a power-up and the type of power-up it is (either "special" or not).
b. The blinking effect is random so no matter what you do, you won't be able to perfectly sync the script with the player.
c. It is important that the script be accurately syncronized with the player, if you're doing for example a custom vehicle or anything that attachs the player (e.g a custom Spiny Hat or the Cape Feather).

Even after this setup the system is still not reliable. All this process can be a lot simplified by just making it a property If for example someone was working with a custom playable that's being drawn through a bitmap, and want it to blink as the player would do, he could only do this:

Code: Select all

bitmap().hide = char(1).blinking


(Additionally, this value can turn -1 when the player got a power-up/got hurt and while cannot move, but this isn't as important as what I said above)

char(1).curframe (Read Only)
Similar to npc's curframe, it would store a value indicating the current player's animation.
It doesn't have to be writable, being read only would be more than enough. This would be very useful for doing effects that syncs with the player (e.g a Starman effects that leaves flashy effects, or a custom accesory like a Spiny Hat from SMM or the Cape Feather, taking the previous examples).

I made this sheet to show how it would work:
Spoiler
Image

This way, the difference between facing left and right it's just a sign (I assume that's how the frames are programmed)

This could open a door of possibilities and could even recreate the gameplay of Mario Classic (SMB1) within SMBX using only Script
:biggrin:

Eri7 M
Viscount
Viscount
Avatar
Eri7 M
Viscount
Viscount
Age: 18
Reputation: 83
Posts: 331
Joined: 19 Dec 2016
Location: Germany , Bonn

Post #3by Eri7 » 3 Sep 2019, 18:47

In my opinion we should be able to change char(1).curframe as it would benefit us way more than just being able to detect it!
Join the discord server about Nova Projects.
Image

Image

Tricolor BombDX
Our friend
Our friend
Avatar
Tricolor BombDX
Our friend
Our friend
Age: 15
Reputation: 8
Posts: 65
Joined: 8 May 2018
Location: Brazil

Post #4by Tricolor BombDX » 3 Sep 2019, 19:58

Eri7 wrote:In my opinion we should be able to change char(1).curframe as it would benefit us way more than just being able to detect it!
I agree with this
I support these projects:
[list]MARIO & LUIGI - The Great Quest
Super Mario - Rainbow Road
Super Mario Bros.: The Great Adventure
Adventures in 2DU
[/list]

Lx Xzit M
Topic author, Moderator
Moderator
Avatar
Lx Xzit M
Topic author, Moderator
Moderator
Reputation: 272
Posts: 619
Joined: 9 Nov 2015
Website

Post #5by Lx Xzit » 3 Sep 2019, 20:42

Eri7 wrote:In my opinion we should be able to change char(1).curframe as it would benefit us way more than just being able to detect it!
You're right, but after thinking on it, I came to the conclusion that it's already very helpful just knowing the current frame of the player. Remember that you can already draw your custom animations by making the player invisible, and it would be even easier if .curframe was a property. I also remember have heard that 38a had plans of adding curframe in the past, but for some reason he didn't (probably it's inclusion ended up being problematic somehow). If 38a adds this function, he can later decide on wheter this should be writable or not (like what happened with some few system variables).
VISIT MY YOUTUBE CHANNEL! LX XZIT
Join our 38A Discord server!

Image

NESTED ERNEST M
Duke
Duke
Avatar
NESTED ERNEST M
Duke
Duke
Reputation: 14
Posts: 133
Joined: 23 Sep 2017
Location: Perú, Lima
Website

Post #6by NESTED ERNEST » 3 Sep 2019, 22:12

Although we indirectly obtain "char (1) .curframe" with the properties of stand, climbing, sjumping; and if 38A add properties like sliding, grabbing, pulling, inwater it would be good, which seems to confirm this link written by yourself that if you can't char (x) .curframe.
Programming NPCs in SMBX-38A is fun:

ROCKMAN GIF IN SMBX 38A

Image

Lx Xzit M
Topic author, Moderator
Moderator
Avatar
Lx Xzit M
Topic author, Moderator
Moderator
Reputation: 272
Posts: 619
Joined: 9 Nov 2015
Website

Post #7by Lx Xzit » 3 Sep 2019, 22:34

The purpose of .curframe wasn't detect the action of the player but it's current frame. For example, doing a running cycle exactly as the player does is quite complex.

pulling
Not needed. You can already check the direction the player is facing, the direction it's going and if it's stand or not

inwater
Not needed at all. You can already use iterators to detect water.
VISIT MY YOUTUBE CHANNEL! LX XZIT
Join our 38A Discord server!

Image

NESTED ERNEST M
Duke
Duke
Avatar
NESTED ERNEST M
Duke
Duke
Reputation: 14
Posts: 133
Joined: 23 Sep 2017
Location: Perú, Lima
Website

Post #8by NESTED ERNEST » 3 Sep 2019, 22:56

Lx Xzit wrote:The purpose of .curframe wasn't detect the action of the player but it's current frame. For example, doing a running cycle exactly as the player does is quite complex.

pulling
Not needed. You can already check the direction the player is facing, the direction it's going and if it's stand or not

inwater
Not needed at all. You can already use iterators to detect water.

Pulling: is when the player do this:
Image

Inwater: I know this can be done with iterators, but it’s best to have .inwater,
When the developer writes the moment when the images are put when the player swims, he could put .inwater=1; why do an iteration, it is not that it is not possible, it is only game optimization and it would also be faster.
Programming NPCs in SMBX-38A is fun:

ROCKMAN GIF IN SMBX 38A

Image

EXEcutor-The-Bat M
Bat
Bat
Avatar
EXEcutor-The-Bat M
Bat
Bat
Age: 17
Reputation: 28
Posts: 178
Joined: 18 Apr 2014
Location: Somewhere...
Website

Post #9by EXEcutor-The-Bat » 15 Oct 2019, 5:54

Curframe needs to be a thing. I think it should be read and write, though.
If you need help with anything related to SMBX38A (that isn’t TeaScript) come ask me. I know quite a bit about how expanded NPC text codes and other stuff works.

sweep a leaf sweep away a troubles
While you're looking at whatever has this signature attached to it, why not check out my DeviantArt page?

hey look a Discord server

"If you look deep into each message, you will be sent on a path to enlightenment..." -Abridged Tails

(If you wanna know what it seems like I'm online all the time, it's because I usually don't log out.)


Return to “Ideas & Suggestions”

Who is online (over the past 5 minutes)

Users browsing this forum: 5 guests