YesNoOk
avatar

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

Started by Jesuszilla, May 31, 2018, 04:32:44 pm
Share this topic:
Re: “Useless” constants we could make better use of?
#21  June 03, 2018, 01:57:46 pm
  • ****
    • Japan

ink

Re: “Useless” constants we could make better use of?
#22  June 03, 2018, 02:15:34 pm
  • ****
  • inktrebuchet
    • USA
    • s236.photobucket.com/albums/ff271/inktrebuchet/?
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.
Last Edit: June 03, 2018, 05:07:38 pm by ink
Re: “Useless” constants we could make better use of?
#23  June 03, 2018, 05:17:15 pm
  • ****
    • Japan
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,
Re: “Useless” constants we could make better use of?
#24  June 04, 2018, 01:06:18 am
  • *****
  • Shame on you!
    • USA
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?
vVv Wheat Stage Released vVv
Re: “Useless” constants we could make better use of?
#25  June 04, 2018, 07:26:36 am
  • ****
    • Japan
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.
Last Edit: June 04, 2018, 07:50:20 am by Vans

ink

Re: “Useless” constants we could make better use of?
#26  June 05, 2018, 02:49:20 am
  • ****
  • inktrebuchet
    • USA
    • s236.photobucket.com/albums/ff271/inktrebuchet/?
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.
Re: “Useless” constants we could make better use of?
#27  June 05, 2018, 09:14:21 am
  • *****
  • Shame on you!
    • USA
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.
vVv Wheat Stage Released vVv
Re: “Useless” constants we could make better use of?
#28  June 05, 2018, 11:11:50 am
  • ****
    • Japan
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.
Last Edit: June 05, 2018, 11:32:24 am by Vans
Re: “Useless” constants we could make better use of?
#29  June 05, 2018, 12:53:18 pm
  • ******
  • Loyal to the Game
    • USA
    • http://jesuszilla.trinitymugen.net/
SelfAnimExist?
Re: “Useless” constants we could make better use of?
#30  June 05, 2018, 01:10:40 pm
  • ****
    • Japan
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
Re: “Useless” constants we could make better use of?
#31  June 12, 2018, 12:32:24 am
  • ******
  • Loyal to the Game
    • USA
    • http://jesuszilla.trinitymugen.net/
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?
Re: “Useless” constants we could make better use of?
#32  June 12, 2018, 09:01:58 pm
  • ******
  • [E]
    • Mexico

  • Online
I see that and I feel like having mugen compatibility/import