The Mugen Fighters Guild

M.U.G.E.N Central => M.U.G.E.N Discussion => Development => Topic started by: Jesuszilla on May 31, 2018, 04:32:44 pm

Title: “Useless” constants we could make better use of?
Post by: Jesuszilla on May 31, 2018, 04:32:44 pm
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.
Title: Re: “Useless” constants we could make better use of?
Post by: JustNoPoint on May 31, 2018, 04:36:28 pm
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!
Title: Re: “Useless” constants we could make better use of?
Post by: Jesuszilla on May 31, 2018, 04:41:40 pm
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.
Title: Re: “Useless” constants we could make better use of?
Post by: inktrebuchet on May 31, 2018, 05:28:49 pm
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.
Title: Re: “Useless” constants we could make better use of?
Post by: JustNoPoint on May 31, 2018, 05:32:31 pm
Because no double redirects! Weeee MUGEN

You can't see enemy, helper, anim or enemy, helper, var etc

I did set some explod standards though

http://mugenguild.com/forum/topics/various-states-poison-power-drain-palfx-custom-states-standards-183112.0.html
Title: Re: “Useless” constants we could make better use of?
Post by: inktrebuchet on May 31, 2018, 05:42:28 pm
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.

Title: Re: “Useless” constants we could make better use of?
Post by: Vans on June 01, 2018, 07:46:18 am
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.
Title: Re: “Useless” constants we could make better use of?
Post by: Jesuszilla on June 01, 2018, 08:19:23 am
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.
Title: Re: “Useless” constants we could make better use of?
Post by: inktrebuchet on June 01, 2018, 02:10:15 pm
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.
Title: Re: “Useless” constants we could make better use of?
Post by: Odb718 on June 01, 2018, 02:50:15 pm
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.
Title: Re: “Useless” constants we could make better use of?
Post by: XGargoyle on June 01, 2018, 03:45:34 pm
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?
Title: Re: “Useless” constants we could make better use of?
Post by: inktrebuchet on June 01, 2018, 03:53:16 pm
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


Title: Re: “Useless” constants we could make better use of?
Post by: Jesuszilla on June 02, 2018, 12:32:08 am
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.
Title: Re: “Useless” constants we could make better use of?
Post by: JustNoPoint on June 02, 2018, 12:47:41 am
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
Title: Re: “Useless” constants we could make better use of?
Post by: Vans on June 02, 2018, 11:57:21 am
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:

(https://i.imgur.com/ylO4zg6.png) (https://i.imgur.com/CdT36rc.png) (https://i.imgur.com/nKxpTHd.png)

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.
Title: Re: “Useless” constants we could make better use of?
Post by: Odb718 on June 02, 2018, 09:49:31 pm
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
Title: Re: “Useless” constants we could make better use of?
Post by: Vans on June 02, 2018, 10:00:28 pm
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.
Title: Re: “Useless” constants we could make better use of?
Post by: Odb718 on June 02, 2018, 11:07:54 pm
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?
Title: Re: “Useless” constants we could make better use of?
Post by: Vans on June 02, 2018, 11:17:18 pm
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.
Title: Re: “Useless” constants we could make better use of?
Post by: Odb718 on June 03, 2018, 12:30:39 pm
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.


Title: Re: “Useless” constants we could make better use of?
Post by: Vans on June 03, 2018, 01:57:46 pm
Then it needs to hit, and it needs to BE hit.

You don't need to do this at all. All you need to do is read its playerID.
Title: Re: “Useless” constants we could make better use of?
Post by: inktrebuchet on June 03, 2018, 02:15:34 pm
I forgot about team battles. The code I posted yesterday only handles one enemy. It could be modified to switch playerids using enemynear or target I guess.

-edit-
Vans, I just realized why you wanted to use sysvars! Passing the helpers ID to a sysvar would be much easier, assuming they aren't being used already.
Title: Re: “Useless” constants we could make better use of?
Post by: Vans on June 03, 2018, 05:17:15 pm
Indeed!

As far as I know sysvar(3) is completely unused by 99% of all (if not every) MUGEN creation out there. Simply because it was undocumented Pre-1.0 and still rarely touched upon,
Title: Re: “Useless” constants we could make better use of?
Post by: Odb718 on June 04, 2018, 01:06:18 am
You don't need to do this at all. All you need to do is read its playerID.
So how are we going to know which playerID is what? Some characters spawn with helpers. A copy/paste job may not work with a random helper number because it could be used, right?
Title: Re: “Useless” constants we could make better use of?
Post by: Vans on June 04, 2018, 07:26:36 am
So how are we going to know which playerID is what? Some characters spawn with helpers. A copy/paste job may not work with a random helper number because it could be used, right?

http://www.elecbyte.com/mugendocs/cns.html#triggers

Quote
playerID(ID)

n should be a well-formed expression that evaluates to a non- negative integer. The trigger is redirected to the player with unique ID equal to ID. See the "ID" and "PlayerExistID" triggers in the trigger documentation.

http://www.elecbyte.com/mugendocs/trigger.html#id

Quote
Any helper that is created during this time will also receive its own unique ID number. 

The number will be saved to a sysvar, which is always fixed.

Upon entering state 5900 it is enough to ask the helper to report its ID and store it in a sysvar, say, sysvar(3). Once it is saved we can retrieve the number using enemynear(n), sysvar(3).

We could also theoretically detect it by looping once through the whole list of players using a combination of PlayerIDExist and PlayerID(XX), var(YY) = ZZ. Where said variable and number are values properly chosen to identify this specific helper. I fear for this method since I have no idea if it would break if an opponent has too many helpers at once.
Title: Re: “Useless” constants we could make better use of?
Post by: inktrebuchet on June 05, 2018, 02:49:20 am
This could also be great for characters that have transformations. It could be a way to check for alt animations during custom states so the character doesn’t have to switch back.

That one might be a stretch though.
Title: Re: “Useless” constants we could make better use of?
Post by: Odb718 on June 05, 2018, 09:14:21 am
Ink I was thinking the same thing. But P1 & P2 would have to be coded together to make things work. P2 would have to switch to the custom animation.

We could also theoretically detect it by looping once through the whole list of players using a combination of PlayerIDExist and PlayerID(XX), var(YY) = ZZ. Where said variable and number are values properly chosen to identify this specific helper. I fear for this method since I have no idea if it would break if an opponent has too many helpers at once.

I think if the helper spawns and put's it's own ID as sysvar(3) and you crosscheck that it'd be improbable a dev accidentally set it.

EnemyNear only works horizontally right? So if we spawn the helpers below the map and triggerall a bodydist Y it should also severely limit the chance of getting a misfire.
Title: Re: “Useless” constants we could make better use of?
Post by: Vans on June 05, 2018, 11:11:50 am
I think if the helper spawns and put's it's own ID as sysvar(3) and you crosscheck that it'd be improbable a dev accidentally set it.

You don't need to do this, the actual number used for the helper can be checked using IsHelper(XXX). The sysvar being used is from the root, also.

This could also be great for characters that have transformations. It could be a way to check for alt animations during custom states so the character doesn’t have to switch back.

That one might be a stretch though.

It's bit tough if the controller used is ChangeAnim2, since we would need the transformed character to already have the animations in their .AIR.
Title: Re: “Useless” constants we could make better use of?
Post by: Jesuszilla on June 05, 2018, 12:53:18 pm
SelfAnimExist?
Title: Re: “Useless” constants we could make better use of?
Post by: Vans on June 05, 2018, 01:10:40 pm
SelfAnimExist?

I mean, that's true, but! That would mean the character already has the gethit animation for that throw in their .AIR. Think of it this way, the character that is getting hit is defining which animation they should be using from their own files.

This would mean that all those special gethits would need to already be define in their files and not in the files of the attacker. If this was (for example) a double-sided character, that would mean that the double-sided character has animations for getting hit by all sorts of throws in the .AIR. That's not very optimized. :P
Title: Re: “Useless” constants we could make better use of?
Post by: Jesuszilla on June 12, 2018, 12:32:24 am
OK so here's my idea since I'm making Necro:

We use sparkno for front foot pos and guard.sparkno for right foot pos. They're both Int32's, so we should be able to split the Pos X and Pos Y into two bitwise fields, each of 16 bits.

So to calculate the positions, you'd do Pos X | (Pos Y << 16). In other words, Pos Y is multiplied by 65536.


So for a pos of -16, 1, you'd do:

(65535&-16) | (65536 * 1) = 65520 | 65536 = 131056.

And to retrieve the position for front foot, you'd do:
Code:
[State x, TargetBind]
type = TargetBind
trigger1 = AnimElem = 6
pos = ceil(((Target,Const(Data.SparkNo)&65535) | ifElse(Target,Const(Data.SparkNo)&32768,-65536,0)) * Target,Const(Size.XScale)), ceil((Target,Const(Data.SparkNo)/65536) * target,Const(Size.YScale)), Foot


Make sense?
Title: Re: “Useless” constants we could make better use of?
Post by: Bastard Mami on June 12, 2018, 09:01:58 pm
I see that and I feel like having mugen compatibility/import