YesNoOk
avatar

“Useless” constants we could make better use of? (Read 4851 times)

Started by Jesuszilla, May 31, 2018, 04:32:44 pm
Share this topic:
“Useless” constants we could make better use of?
#1  May 31, 2018, 04:32:44 pm
  • ******
  • Loyal to the Game
    • USA
    • http://jesuszilla.trinitymugen.net/
So I’ve noticed there’s a few constants we could possibly take advantage of through community standards in order to do some fun things.

For example, the number of air jumps. I doubt most people use this constant and instead just use their own variable and a state override to keep track. We could probably put this to better use for something like foot pos (for throws like Necro’s command throw). I can’t recall if this one specifically is hardcoded in the jump state, however, so it may not be possible to use this one in particular.

However, I did have a discussion with Vans and there were a couple of other constants we could make better use of IMO since I know many of us don’t use them for their intended purposes. Just wondering if anyone else thinks doing this is a good idea. It’s much better than having to keep track of system variables, especially in custom states. Plus it would pretty much be our only way to declare our own constants.
Re: “Useless” constants we could make better use of?
#2  May 31, 2018, 04:36:28 pm
  • ******
    • www.justnopoint.com/
I think it'd be pretty cool. I'm not sure how we'd use the double jump one though. Is there a way to read what it's set for in the opponent that I'm forgetting?

But yeah, pitch the ideas and let's roll it out!
Re: “Useless” constants we could make better use of?
#3  May 31, 2018, 04:41:40 pm
  • ******
  • Loyal to the Game
    • USA
    • http://jesuszilla.trinitymugen.net/
Yeah, it can be read with const(Data.AirJump.Num). Air jump height may be another good candidate, especially since if we use a large value, it could totally fix any hardcoded air jump problems if we use it for something like two Int16’s through bit shifting.

ink

Re: “Useless” constants we could make better use of?
#4  May 31, 2018, 05:28:49 pm
  • ****
  • inktrebuchet
    • USA
    • s236.photobucket.com/albums/ff271/inktrebuchet/?
I don't want to side track this topic but why not have a community standard helper?

That way you could check to see if the character uses the standard and it will allow you to use a ton of vars that could have set standards. and it wouldn't break anything.
Re: “Useless” constants we could make better use of?
#5  May 31, 2018, 05:32:31 pm
  • ******
    • www.justnopoint.com/

ink

Re: “Useless” constants we could make better use of?
#6  May 31, 2018, 05:42:28 pm
  • ****
  • inktrebuchet
    • USA
    • s236.photobucket.com/albums/ff271/inktrebuchet/?
That's true but if you can get that helpers playerid, you can then access anything you want.

I did something similar with my "Ai Detect Enemy's Helper Projectile System".
http://mugenguild.com/forum/topics/ai-detect-enemys-helper-projectile-system-179829.0.html

You just need to scan playerids for a set standard. The standard is obvious for projectiles but something like a "community standard helper" could just have a simple var(0)=(odd number that's unlikely to be used by other helpers).

Something that scans playerids could be include in a community standard helper too, since the helper code would probably be a template that is copy and pasted. That idea would only use 2 helper vars and 1 root var.

Last Edit: May 31, 2018, 07:21:22 pm by ink
Re: “Useless” constants we could make better use of?
#7  June 01, 2018, 07:46:18 am
  • ****
    • Japan
Adding to ink's idea, one possibility is to make use of one system variable.

We have 4 integer and 4 float sysvars respectively. To my knowledge only sysvar(0) and sysvar(1) are used at all within common1.cns, and the remaining two are rarely known to exist by most coders.

One possibility is to have the root store the PlayerID of said data helper during boot on state 5900. Once that is done, we can simply read the variables by retrieving the playerID from the opponent. This idea isn't too bad, a community helper would give us access to a whopping 100* standarized variables. The scary part is moderating their use.



I think it'd be pretty cool. I'm not sure how we'd use the double jump one though. Is there a way to read what it's set for in the opponent that I'm forgetting?

Yeah, you can read most of them using const (in this case const(movement.airjump.num)). The one I pitched originally was const(data.KO.echo) (lol).

The reason I pitched it is because it only uses values from 0 to 1, but it still behaves like a full integer constant.

One thing I should point out is that if some standard would be made, it should be used to detect data that can only be useful in numerical form and not boolean form. In the case of boolean form, it is much faster and efficient to detect an animation and not a number.

So just having a whole bunch of variables to indicate "yes or no" conditions would be a waste in this case.

 

One last possibility is using empty Projectiles. Projectiles are always a primitive root-owned object, so they're very fast to detect. Projectiles with no hitdef data are equally as efficient as explods in engine load, but tend to be less limited as they're very rarely used in most cases. Projectiles also let us define "windows", since they can be set to expire over a fixed amount of time.

Chizuru makes use of a dummy projectile to report that her sealing technique hit the opponent.
Last Edit: June 01, 2018, 07:58:41 am by Vans
Re: “Useless” constants we could make better use of?
#8  June 01, 2018, 08:19:23 am
  • ******
  • Loyal to the Game
    • USA
    • http://jesuszilla.trinitymugen.net/
Yeah, Felicia's Cat Ride uses sysvar(0) to store the position when not in the standard states that use it.
Code:
[State -2, Cat Ride Pos]
type = VarSet
trigger1 = Enemy, AuthorName = "Jesuszilla"
trigger1 = Enemy, Name = "Felicia" || Enemy, Name = "Felicia_LG"
trigger1 = StateNo != 132 && StateNo != 155 ; Air guard
trigger1 = StateNo != [5000,5999]           ; Gethits
sysvar(0) = (7 & 65535) | (-65 * 65536)
;            x              y
; Range for Pos X and Pos Y is [-32768,32767] (INT16)
; Pos XもPos Yの範囲は[-32768,32767]です。 (INT16)

We totally need to make better use of the sysvars, especially within helpers which get their own. That's the entire basis for Vans's reflector code.


Other good candidates:
Code:
data.sparkno: Returns value of the "sparkno" parameter. (int)
data.guard.sparkno: Returns value of the "guard.sparkno" parameter. (int)

I also think a lot of the float parameters added in 1.0 are kinda not needed, too, such as movement.down.bounce.offset.x and movement.down.bounce.offset.y. Of course common1 would need to be modified to get rid of a lot of these.


I'd also like to remind y'all that helpers can also get their own set of constants. Of particular interest are the following:
Code:
pos = off_x, off_y (int)
    Specifies the x and y offsets to create this helper at. The precise meaning of these parameters is dependent on the postype. Defaults to 0,0.
size.xscale (float)
    See below.
size.yscale (float)
    See below.
size.ground.back (int)
    See below.
size.ground.front (int)
    See below.
size.air.back (int)
    See below.
size.air.front (int)
    See below.
size.height (int)
    See below.
size.proj.doscale (int)
    See below.
size.head.pos (int,int)
    See below.
size.mid.pos (int,int)
    See below.
size.shadowoffset (int)
    These parameters have the same meaning as the corresponding parameters in the root's CNS file. You can specify one or more of these parameters to change it to a value suitable for this helper. Otherwise, they default to the values inherited from the parent.

pos is the only one that requires special processing, as it would need to be calculated at time = 0 and stored in its own variable, not making it too particularly useful. However, the head.pos and mid.pos values can be used just as well for the same purposes. Of course with helpers we won't need to standardize as much since we can make them do whatever we want for the helper's purposes.
Last Edit: June 01, 2018, 08:24:40 am by Jesuszilla

ink

Re: “Useless” constants we could make better use of?
#9  June 01, 2018, 02:10:15 pm
  • ****
  • inktrebuchet
    • USA
    • s236.photobucket.com/albums/ff271/inktrebuchet/?
The scary part is moderating their use.
I’ve been thinking about this. We could setup the helper like a config file, outlining the use of each var to ensure it’s being used the same by everyone. The playerid scaning can be coded below everything to keep it simple.

I think the hardest part for me is knowing what each var should be used for. We shouldn’t leave anything open for interpretation in my opinion.
Re: “Useless” constants we could make better use of?
#10  June 01, 2018, 02:50:15 pm
  • *****
  • Shame on you!
    • USA
I dont think that this is a terrible idea, but I'm having a hard time figuring out what exactly we cant define/find out another way.
Especially if we're finding the values at state 5900. The foot pos would just be a standard set animation, no?? Like the one character's throw would use it. Or we just define anim 5004/5014 and on.
 
Again, I'm just not sure how much use this would get. The standard animations to describe P1 barely get used. Like what color blood, what type of martial arts P1 does, n all that.

Where's @2OS: to tell us what we dont know!?!
Most of the really tough challenges I come across are in the middle of a battle during throws or custom states.


The REAL thing would be adding it into FFS as a click to add. Have descriptions commented out and such. If you could have nubs fill it out as a standard state controller in Fighter Factory I think it'd become wide spread. Especially making it easy for updating older characters.
Speaking of which, It'd need to be winmugen compatible imho.
vVv Wheat Stage Released vVv
Re: “Useless” constants we could make better use of?
#11  June 01, 2018, 03:45:34 pm
  • ******
  • Hedgehog Whisperer
  • Red Bull addict
    • Spain
    • xgargoyle.mgbr.net
wait, there are people still using winmugen???

On topic, what kind of values are you expecting to store and retrieve using the "constants"? For what purpose? And what advantages does this method bring versus the commonly use of community animations, or projectile/explods ID checks?
XGargoyle: Battle posing since 1979
http://xgargoyle.mgbr.net
http://www.pandorabots.com/pandora/talk?botid=e71c0d43fe35093a  <-- Please click that link
http://paypal.me/XGargoyle  <-- Donations welcome!

ink

Re: “Useless” constants we could make better use of?
#12  June 01, 2018, 03:53:16 pm
  • ****
  • inktrebuchet
    • USA
    • s236.photobucket.com/albums/ff271/inktrebuchet/?
I put this code together as a first draft for that community standard helper, since I had the majority of the code already together. I haven't tested it yet but not much was really changed with the playerid scanning section.

No real ideas on what all those vars could be used for though.

Another note on this one, a helper could be spawned by this helper to do calculations or whatever and use ParentVarSet to get values to the community standard helper. The triggers would just need to be changed to allow time for it. (Really only var(1) NEEDS to be !time.)

Spoiler, click to toggle visibilty


Last Edit: June 02, 2018, 05:33:34 pm by ink
Re: “Useless” constants we could make better use of?
#13  June 02, 2018, 12:32:08 am
  • ******
  • Loyal to the Game
    • USA
    • http://jesuszilla.trinitymugen.net/
Well...

1. It would prevent people from accidentally overwriting a variable, and could easily carry over into custom states.
2. It can be read instantly from the root.
Re: “Useless” constants we could make better use of?
#14  June 02, 2018, 12:47:41 am
  • ******
    • www.justnopoint.com/
Can be used as a pause detector and a var could be used to store the x and y scaling of a char so the opponent could see it
Re: “Useless” constants we could make better use of?
#15  June 02, 2018, 11:57:21 am
  • ****
    • Japan
On topic, what kind of values are you expecting to store and retrieve using the "constants"? For what purpose? And what advantages does this method bring versus the commonly use of community animations, or projectile/explods ID checks?

Well, the thing is, this is not meant to be a replacement of animations and/or projectile explod checks. Those methods will always be more efficient for detecting true or false statements. A constant would provide meaningful data (position, state number, coordinates, etc).

I can provide a reasonable use: properly defining mid.pos and head.pos. The standard set by Elecbyte ONLY allows for one fixed value of head.pos, which is usually calculated in many different ways depending on the person. Some people calculate this using a stance sprite, while others use sprites 5000,0 or 5010,0. It's a hilarious mess.

Consider Sakura's throw, for example:



Get hits vary so wildly between characters that head.pos is quite frankly not good enough for binding her properly in this throw.

One possibility would be to introduce individual gethit mid.pos and head.pos. For example, we could define head and body positions for the 5000,XX and 5010,XX series of sprites. With this we can avoid the vagueness of the original head.pos constant and actually make neck / body hold throws not look strange in more characters.
Last Edit: June 02, 2018, 12:03:44 pm by Vans
Re: “Useless” constants we could make better use of?
#16  June 02, 2018, 09:49:31 pm
  • *****
  • Shame on you!
    • USA
There's about 70 total spots for throws with the basic sprites. 23 similar pics. The 5000,5001,5002 being the same image.
It'd be best if we can figure out a system to get all 3 values into 1 reading.
The head and the waist would be with the feet on the ground. So maybe just 2 values?
Maybe a knee location for 3?
I know I do math to figure out the chest location on standing but it just gives a general X, & Y for P2 with Samus. It works pretty accurate against everybody.

I'm definitely down to do the better throw locations, but I feel like this could become a standardize animation thing too.
Like for 5004, the head pos y would be 0, and the X pos would be set to the head height.
And honestly, I think there should be a Neck positioning. So many choke moves....

----
This is basically the new 5003 head position sprite I was talking about.
Spoiler, click to toggle visibilty
vVv Wheat Stage Released vVv
Last Edit: June 02, 2018, 09:55:19 pm by Odb718
Re: “Useless” constants we could make better use of?
#17  June 02, 2018, 10:00:28 pm
  • ****
    • Japan
You don't need to calculate these numbers for 5001,5002 (etc) because those are already pre-aligned in the proper spot. It is only needed for the 5000,XX and 5010,XX ranges, which are aligned in the SFF on the feet.
Re: “Useless” constants we could make better use of?
#18  June 02, 2018, 11:07:54 pm
  • *****
  • Shame on you!
    • USA
That's basically my point.
The way I'd structure Sakura's throw would be to lock in the head position using 5002,0 and guess the Y value to put their feet on the ground. This example seems to use the 5000,0 and guesses the X & Y position to align her to their head. Which isn't working.
With the 5003,0, which doesn't exist, the feet are on the ground and the head's X position is at 0. There's only one random number that may or may not be obtainable. The head height; enemy,const(size.head.pos.y). We know people dont set this to exactly the right spot. Each hit reaction frame is almost always different. There's no real way to grab an enemy's head with their feet exactly perfect. I think the new variable system could track the 70 variations.

5000,0 is based off the feet. 5003,0 would be based off the feet and the head pos x.

----
Are you saying we'd only need to create the 28 standard hit reaction images with the new info?
vVv Wheat Stage Released vVv
Re: “Useless” constants we could make better use of?
#19  June 02, 2018, 11:17:18 pm
  • ****
    • Japan
If a standard will be set in place for head.pos and mid.pos, there is really no reason to force any additional calculations. All you need in this case is 12 numbers (for head.pos and mid.pos in the 5000,XX and 5010,XX ranges) which can be optimized to use less than 12 variables if needed.
Re: “Useless” constants we could make better use of?
#20  June 03, 2018, 12:30:39 pm
  • *****
  • Shame on you!
    • USA
I think this is a very good option. When I was thinking it up, I was pretty sure there'd be a reason to have every standard hit reaction have the new values. Right now the reason is slipping my mind, but I'm pretty positive I had a rational reasoning.
I also think having the 5020,XX sprites have the head and waist positions would be beneficial. When I find Samus's homing missile destination, when P2 is crouching I do general math. I just divide the chest height in two. It gives a rough idea. But having a set value would be best. I think a few characters have low grabs.  And if we're going to go this far, why stop short.

So I think the standard helper would be the way to work this.
It'd need to spawn at a standard spot that if you're P2 or P4, P1 & P3's helper will spawn at the same spot. Probably somewhere off screen. Maybe below?
Then it needs to hit, and it needs to BE hit.
The values would have to be filled asap.
Would it be smart to make it only hit P2/P4 if it's displaying a certain animation? This way if an accident occurs it wont occur???
If it's P1 vs P2 & P4, and 3 helpers spawn, P1 needs to be able to see all the info for the 2 chars. I was originally thinking the helper would be in attack mode asap and default to a blue clsn for the rest of the round. With P2 and P4 spawning at the same exact spot, trying to obtain the info for both chars might be a problem. Technically P3 could be hit by P1 also. Though I'm not sure if there's info you'd need from your partner.

The P2/P4 thing. Would it be better to have P2 be Var(x) and P4 be FVar(x)? This way say we need Var(5) for whatever reason, But we want both P2 and P4's values, our character would be asking for value 5. I'm only thinking about using the FVar because I'm not sure how many variables will eventually be used up. If P2 uses 0-29 then P4 would get 30-60. 30 each, but using the FVar they'd both get 40. If reading both at the same time is easy, then obviously using the Var for both would be easy and this whole problem doesn't exist.

On getting the X and Y pos. I dont know of many characters taller in pixels than my Samus. Standing she's about 375 pixels tall. Regular Capcom Ryu is about 90. I can't imagine a character would need to be over 1,000 pixels tall. I think the X and Y position should be limited to 999x999.
we could extrapolate the two values of say, Var(5) = 207132.
pos x = Floor(var(5)/1000) ;=207
pos y = var(5)-(var(59)*1000) ;=132
var(59) would be set to pos x's equation.


vVv Wheat Stage Released vVv