YesNoOk
avatar

Character Cloning Glitch (Read 8680 times)

Started by PAVGN, June 17, 2012, 01:12:54 am
Email this topic
View printable version
Share this topic:
« previous next »
Page 1 of 11   Go Down

PAVGN

Character Cloning Glitch
#1  June 17, 2012, 01:12:54 am
  • ***
    • USA
    • stacksmash.kontek.net/
A few characters will sometimes clone themselves. A clone of itself will appear, and It'll just stand there doing nothing. Sometimes the clones can be hit. How do I keep characters from cloning themselves?

Yabuki-San

Re: Character Cloning Glitch
#2  June 17, 2012, 01:29:07 am
  • ***
  • Shingo KICK!
    • sonicstar3000.tripod.com/
Hmmm....
I seem to be getting this glitch too.




... are you STILL reading this?

DW

Re: Character Cloning Glitch
#3  June 17, 2012, 01:48:42 am
  • *****
    • USA
    • www.trinitymugen.net
This is usually a result of projectiles not having a hitoverride function. The projectile will make clones of the char if they don't have it. There are other ways, I'm not completely certain of them all, but this is the most common.
Last Edit: June 17, 2012, 02:13:57 am by DivineWolf

Yabuki-San

Re: Character Cloning Glitch
#4  June 17, 2012, 01:55:31 am
  • ***
  • Shingo KICK!
    • sonicstar3000.tripod.com/
Okay, thank you, I'll go through some of the CNS later.




... are you STILL reading this?

Seravy

Re: Character Cloning Glitch
#5  June 17, 2012, 01:05:47 pm
  • ****
    • Hungary
    • seravy.x10.mx/Wordpress
Essentially, any helper spawned is a clone of  the player. They are mostly used as projectiles, strikers or effects/hitsparks simply by displaying the appropriate non-player animation. There are three ways how they can cause a cloning bug to appear :
-If the helper changes into a player state. This means very bad coding and an incompetent creator, unless it's truly intended for cloning purposes.
-If the helper gets hit and goes to the player hit states. This is also the responsibility of the creator but it's easy to overlook an accidentally placed clsn2 on the helper animation or forget a nothitby/hitoverride in one of the many helper states, so this is the most common cause, especially if the helper rarely appears or is hard to hit, making the bug hard to find/reproduce. Wait until the character gets updated and it'll probably be fixed, or even better, report the bug to the creator. Best is to turn on debug (ctrl+d), find the clone helper, and check it's name, that way you'll know which one is the problem.
-If the helper is attacking and the attack is reversed by the opponent, they can take control of the helper. If they coded it improperly, these reversal moves can potentially treat helpers the same way as players and the result is a clone. There is no way to avoid reversals of a helper attack, so this is the responsibility of whoever coded the opponent that has the reversal move. It's generally bad practice to use reversals with custom states because once the helper is in a custom state, you won't be able to return it to normal.

2OS

Re: Character Cloning Glitch
#6  June 18, 2012, 10:59:20 pm
  • ****
  • 608 Wannabe
  • Ich schicke dich zur HOELLE!! STIRB DU FEIGLING!!
    • Egypt
that last sentence is false for player type helpers and really false in general.

there is nothing wrong with using custom states for reversing helpers. that's how projectile reflectors where the anim is retained is possible.

besides most people are smart enough to utilize them properly.


3 usual outcomes:

1. destroyself ( immediately )
2. projectile reflection
3. rootselfstate ( mostly nukes, this isnt common outside of them at all )

Seravy

Re: Character Cloning Glitch
#7  June 19, 2012, 01:08:46 am
  • ****
    • Hungary
    • seravy.x10.mx/Wordpress
Quote
1. destroyself ( immediately )
Can possibly break the opponent if the helper being destroyed is one that isn't supposed to be destroyable.
At best, it looks stupid when a huge beam or a part of the attacker's body, etc vanishes, at worst, the character can get stuck in a state permanently due to progressing its attack based on the state of the now non-existing helper, or you might remove a system helper that's necessary for the character to work in general.
Quote
2. projectile reflection
Unfortunately, as 95% of the relevant information is lost (any additional explods that are overlaid the base animation, the hitdef parameters like damage and the like, movement pattern, SCALING, drawing angle, transparency, etc), such practice is generally a very bad idea if it's not used in a full game environment. Sure, you managed to keep the animation, and reversal made sure the animation had a clsn1 on it, but that's all. You don't know how much damage it should do, what additional effects it should cause when hitting, or even how it should look like, other than the base animation which can easily be an empty animation with just a clsn1, if the actual visible part of the projectile is made up of explods. If the animation doesn't have an always active hitdef, then it might not hit. Then there is the issue of the damage. How much damage should it do? 20? Reversing a 200 damage super into a 20 damage one is lame especially if it looks like the original. 100? Reversing 30 incoming projectile that do 1 damage each into 30*100=3000 damage is crazy overkill.
What if the incoming projectile was not a helper but a projectile type? Then it won't work because those are not even affected by reversaldef, and you can't put them into custom states either.
The problem is, you can't even code it safe. Reversal will either put everything to the custom state, including players and helpers, or neither. So if you want a projectile reflection, it will affect players if the players use a hitdef with a matching (P) hitdef type, and if you want to reverse player attacks, it will affect helpers like strikers or projectiles.
Let's say you have a reversal that reverses physical attacks by throwing the opponent. A striker (or something else helper based) attacks into it. It will be put into the custom state and it cannot be avoided (neither by coding of the attacker or the reverser) and then what? Destroyself? The striker will disappear into thin air for no apparent reason which looks bad. Selfstate? See below.
I hold my opinion that reversaldef with p2stateno is bad and has to be avoided at all costs, and same for targetstate after reversal. The safe way to code such moves is using hitoverride to intercept the hit and then hitdef with p2stateno or targetstate to hit. That way, it won't affect helpers that are supposed to be invincible. You can even read the original damage and return it, although it's best to consider that the original one's damage dampening will not be applied, which can be an issue when reflecting a 30 hit laser beam super.
Quote
3. rootselfstate
Umm what? Root is a redirection and selfstate is an sctrl, they have nothing to do with each other. If you mean using selfstate to put the projectile back to it's last state using prevstateno, that can potentially break the coding (as it will restart time but not the animation and variables, resulting in normally impossible conditions). If you mean selfstate to any other state, that causes cloning.

As for player type helpers....they are deprecated and cause problems in the coding of the enemy when used (they confuse coding based on P2 triggers and enemynear redirections because they do count into P2 triggers and are ignored by enemy/enemynear. So you can end up with having 1 enemy (the player) that's different from the object P2 triggers reference (the helper), in short you'll end up in a situation where P2stateno!=enemynear,stateno and numenemy=1, which is otherwise impossible). Using them is bad. I know because I used them for a few years and in the end I decided to remove them even at the cost of having to recode a lot of stuff and limit what the player type helper (an actual clone of the player) can do. If you want minus state access for your helper, use keyctrl and state -1 instead of player type. It works. The problem is, when reversing, you can't tell apart normal and "player type" or "clone" helpers. The reversal will treat them the same way, meaning both a striker/clone and an actual projectile will end up being reflected or destroyed.

Quote
besides most people are smart enough to utilize them properly.
Properly as in a full game environment only? Because otherwise it won't be safe, see above. I do believe if something cannot be done in a fail-safe way (and reflecting while keeping the anim is one of those), then it's better not to do it at all.

Anyway, this topic was about cloning bugs, not about reversals, so maybe we should stop this here and talk about it elsewhere if you still disagree after all of that.

Rajaa Retired

Re: Character Cloning Glitch
#8  June 19, 2012, 02:47:06 am
  • avatar
  • ******
    • Thailand
Holy shit.

For purposes outside of a full game, just destroy the helper and all of its explodes immediately, then summon a new helper to emulate reflection.

People should know that they should have fail safe codes for code that depends on the existence of helpers. Mainly because helpers can get destroyed if the limit is reached.

Seravy

Re: Character Cloning Glitch
#9  June 19, 2012, 12:31:44 pm
  • ****
    • Hungary
    • seravy.x10.mx/Wordpress
Quote
Mainly because helpers can get destroyed if the limit is reached.
No, they cannot. New ones fail to get created if the limit is reached. I have never seen any get destroyed, and I use helpers to store important data/display bars or card systems, so I would see them disappearing.
To be honest, in that situation, it's already disruptive enough to the gameplay not to care what happens after. You are unable to use helper based moves and if you do try any, it will fail, you'll lose any costs, and be wide open to attacks. I really use a lot of helpers and the 56 limit is not a problem, when it is then the enemy is badly coded and doesn't destroy his helpers after they leave the screen, or has moves that use far too many at a time.
I can see it being a problem in simul, but I don't code my characters to be compatible with simul in the first place. Simul is broken in so many ways we could fill multiple threads with it, it's best to ignore it altogether.

Coding fail-safe is a good thing but that doesn't solve the problem.
The destroyed helper might have contained important data, which is then lost. Even if you code fail-safe and make sure to re-create the helper (which wasn't supposed to be possible to destroy in the first place, so 99% of the time people won't code this), it will not reappear in the same position, state and containing the data of the old one.
Besides, making everyone else code that much more just to be able to delete their helpers is not reasonable.
I don't understand how people could think it's fine to delete data from the opposing character, and removing helpers is exactly that. If you don't overwrite opposing variables in custom states, then why do you think it's ok to erase helpers? They have variables, too...if you delete a helper, those variables are gone.
And then there is still the issue that the helper is visually gone which can look really stupid.

Rajaa Retired

Re: Character Cloning Glitch
#10  June 19, 2012, 05:09:59 pm
  • avatar
  • ******
    • Thailand
I was pretty sure they got destroyed, but if you say they aren't because you tested it, then I guess you're right.

You fill your posts with too much text. :ninja:

DW

Re: Character Cloning Glitch
#11  June 19, 2012, 08:16:25 pm
  • *****
    • USA
    • www.trinitymugen.net

2OS

Re: Character Cloning Glitch
#12  June 19, 2012, 08:44:32 pm
  • ****
  • 608 Wannabe
  • Ich schicke dich zur HOELLE!! STIRB DU FEIGLING!!
    • Egypt
rootselfstate is just a label.

a helper can be manipulated to make the root selfstate. that's how Omega Tom Hanks and F1 is killed.

Seravy

Re: Character Cloning Glitch
#13  June 19, 2012, 11:14:50 pm
  • ****
    • Hungary
    • seravy.x10.mx/Wordpress
Quote
rootselfstate is just a label.

a helper can be manipulated to make the root selfstate. that's how Omega Tom Hanks and F1 is killed.
To do what? If you are manipulating the helper not the root, the root is still in its own states, only the helper is in a custom state. Maybe you mean to put the root into the custom state as well? There should be no way for a helper to change the state of its root directly in any normal way.
If you refer to that mysterious coding of instant-win characters that makes the enemy lose without ever doing anything to them, it's obviously a bug in the engine and not something to be used. You are supposed to report these kinds of things to Elecbyte and have it fixed, not abuse them. I would have done it myself but I have no idea how it works. If you know how it works, I'd like some explanation about it...or maybe you should post that into "bug reports" at Elecbyte directly...if they even care.

Quote
You fill your posts with too much text.
At elecbyte.com this topic filled about 4 whole pages...
If you want a very short, compressed version : Using custom states on reversals is bad because it cannot be prevented by any reasonable way on helpers that should be immune to it, there is no way to avoid it affecting non-intended types of targets, and there is no way to restore the unintentionally affected targets to their original condition once it happened, outside of a full-game environment.

2OS

Re: Character Cloning Glitch
#14  June 20, 2012, 12:14:51 am
  • ****
  • 608 Wannabe
  • Ich schicke dich zur HOELLE!! STIRB DU FEIGLING!!
    • Egypt

Seravy

Re: Character Cloning Glitch
#15  June 20, 2012, 02:21:08 pm
  • ****
    • Hungary
    • seravy.x10.mx/Wordpress
Quote
type=projectile
Come on, explain it normally please. We are talking about an undocumented feature/bug here, there is no way I can just guess it from that...

2OS

Re: Character Cloning Glitch
#16  June 20, 2012, 05:40:25 pm
  • ****
  • 608 Wannabe
  • Ich schicke dich zur HOELLE!! STIRB DU FEIGLING!!
    • Egypt
what im hinting at actually IS documented and that's exactly why i didn't explain it.

Docs said:
All projectiles created by helpers immediately become owned by the root.

so p1stateno on them will . . . . .


Spoiler: Omega Tom Hanks Killer (click to see content)

Spoiler: F1 Killer (click to see content)

Seravy

Re: Character Cloning Glitch
#17  June 20, 2012, 06:09:33 pm
  • ****
    • Hungary
    • seravy.x10.mx/Wordpress
Quote
so p1stateno on them will . . . . .
...have no effect because projectiles don't have a state number to change. P1stateno is supposed to change your own state number, not P1's. A helper using P1stateno will change it's own state, a partner using P1stateno will change its own state and a player using it will change its own state. So a projectile using it is also supposed to change its own state, which doesn't exist so P1state is meaningless for projectiles. If this is indeed working the way you say, it is either a bug, or a design flaw. I think Elecbyte just forgot to remove the P1stateno parameter from projectiles, it doesn't belong there.

Will test this.
Edit : indeed, P1stateno on projectiles does affect the player instead. That's definitely unexpected. Well I guess they didn't care because they plan to deprecate projectiles altogether.

by the way
Quote
All projectiles created by helpers immediately become owned by the root.
Is in the known bugs section. So yes, it is also abusing a bug, although a known and documented one.
Last Edit: June 20, 2012, 06:21:31 pm by Seravy

2OS

Re: Character Cloning Glitch
#18  June 20, 2012, 06:58:07 pm
  • ****
  • 608 Wannabe
  • Ich schicke dich zur HOELLE!! STIRB DU FEIGLING!!
    • Egypt
it says ""notes"" in the docs, not ""bugs"".


also there is overloading the engine with nulls to kill any character and/or destroyself roots. i don't know much about it myself because even i think killing things before roundstate 2 is stupid.

all i know is that the root and 56 helpers trigger a bunch of nulls but that it definitely isn't that simple.

Seravy

Re: Character Cloning Glitch
#19  June 20, 2012, 09:57:25 pm
  • ****
    • Hungary
    • seravy.x10.mx/Wordpress
2OS said, June 20, 2012, 06:58:07 pm
it says ""notes"" in the docs, not ""bugs"".
True, it seems to have been moved in 1.0 docs. It was in the "VII. Known Issues / Notes" section in older versions which was replaced by a forum link in 1.0 docs.
I guess when they decided not fix it for compatibility (and because projectiles will be deprecated anyway), they moved it there. It was never an intended feature though, we just ended up stuck with it.
Page 1 of 11   Go Up
« previous next »