platform interaction

[XGargoyle]

I haven't coded anything for the last 5 years and I suddenly realized my skills have deteriorated to n00b level .

Ok, so I just got the new mugen for the first time, checked about its features and updates and told to myself: "Yeah, with this I can finally make my dream project"

What I have done, so far:

I tried coding a platform that can be used by both P1 and P2, in that way:
- P1 creates a helper and he is able to stand on it and fall from it when walking off the edge.
- The helper spawns a projectile when P2 is over it, so that P2 is put into a custom state and then placed on state 0 (the idea is that P2 can walk over the platform.

What is not working:
- P2 gets to state 0 and 1 tick after it goes automatically to state 50 (jump) and falls to the ground, preventing it from "floating" over the platform

Any idea what should I do to fix it?

[Shamrock]

An ugly way would be a custom ghetto ass walking state but as you know, not everyone has the same amount of sprites so it would be ugly.

The only other idea is to make the platform have a red clsn slightly above that prevents state 50 and puts player two in the walk state, when touching. But I am not sure if that is actually do able as I never tried. Also how would he jump off the platform?

[Cobra Caddie]

The problem is in any character that has "in the air" detection to prevent floating state 0s. I think I'm guilty of this. I was going to say it's impossible because of that but Bane managed to pull it off. I'd recommend checking out his stuff to see how he did it(the Contra mini game).

Since you mentioned "dream project", is this in a full game?

[Shamrock]

Might be better to move the floor instead. Optical illusion of the background and custom boxes of helpers over the empty space beside the platform that is actually on the floor. Someone touches the boxes of the floor/platform, a projectile sends both into a custom fall that is actually a float up as the optical illusion of the background moves making the real floor the floor again and gets rid of the custom box/helper.

[Cyanide]

Actually, this is a common1.cns thing right now. Elecbyte added a "Am I Floating" fix in there. If you're doing a full game, simply null this value. Pretty sure it's that, i don't have the default files on me right now to check.

[Cobra Caddie]

Ah, didn't know that Elecbyte added coding for it.

To be a bit more direct what's causing it is a character having their statetype being set to A.

[Sam]

it's only in early versions of mugen 1.0 (the release candidates). the official release doesn't have that floating stuff in common1. but maybe your problem is because p2 didn't set the right statetype and physic. you may wanna try to set a var to detect when they're on the plataform and then set a -2 statetypeset to fix it

[Cobra Caddie]

it's only in early versions of mugen 1.0 (the release candidates). the official release doesn't have that floating stuff in common1. but maybe your problem is because p2 didn't set the right statetype and physic. you may wanna try to set a var to detect when they're on the plataform and then set a -2 statetypeset to fix it

Not possible unless it's a fullgame. If he's talking about having it effect any opponent in Mugen, you can't change p2's statetype outside of custom states.

[Sam]

I know, but it's not impossible. just tell in the readme that you have to paste a little code in -2 statedef and create another .st to the major codes. In the worst case, I should say

[Cobra Caddie]

No one would want to do that

[Shamrock]

To bad there is no -2 in common. Would solve so many issues.

[Cobra Caddie]

...Alright, after that comment and the so many things wrong with it, I'm done with this topic. Good luck, Garg.

Everyone else, please lay off of the sauce. Especially you, Shamrock.

[Sam]

lol you could release your common1 with -2 and -3, but everybody would override it anyway xD In my char I'm overriding the entire common, so it wont solve that issue ;~

the other way would be sending p2 to a custom state the whole time he is on the plataform, ther's no issue with sprite number anyway, but this will fail if someone put the walk anim with something like 15 instead 20. and believe me, I saw xD

BUT if it's a fullgame (you didn't specify that) you can just code the same helper in different positions depending of your teamside or facing at the very beginning of the round. it will solve the issue

[Shamrock]

I will have you know caddie that I have been sober for a while now.

[Cyanide]

...................................

If it's a full game all well and good. Whatever. However you cannot do things like that to p2 unless you want him unable to do anything while he's on these platforms which is a bad plan. Being able to attack and the like is important.

Therefore this is an issue in the common1.cns. Either he has an older version without the fix removed, or his test character has said fix in place via a custom common1.cns or a manual fix.

Try it on something old with a custom common1.

[Shamrock]

Hey sober guys. What about this http://elecbyte.com/wiki/index.php/PosAdd. Can it be applied? My last thing and then I will let the big boys play. Or even PosSet.

[Riptide]

But what if mugen thinks P2 is floating. I've never actually seen mugen correct floating 0's. I'm surprised that this problem has come up.

[Cobra Caddie]

Hey sober guys. What about this http://elecbyte.com/wiki/index.php/PosAdd. Can it be applied? My last thing and then I will let the big boys play. Or even PosSet.

You can not set a constant posadd or posset to the opponent without hitting them. And even if you could, they would just keep falling anyway.

[XGargoyle]

Ok guys, got it working. FYI, it's not an issue related to common1.cns (otherwise Bane's coding wouldn't work), it wasn't a physics related issue either.

Actually it was about P2 believing that P1's helper was his own helper.

My original code had P1 creating a platform helper that allowed P1 to "float". The same platform used a projectile to put P2 into state 0 as soon as it gets on top of the platform.

Problem was that I was testing same char Vs. same char, and with it, P2 believed that the P1's platform helper was actually spawned by P2 himself. this resulted in the code for P1 being on the platform was executed at the same time that the code for placing P2 in a custom state, resulting in a collision of codes for poor P2.

Apparently, helpers that share the same ID can be in someway "seen" by all players.

The issue didn't happened when fighting against different chars, because in that case P2 didn't have a helper with the same ID. This is how I realized what was wrong about my original code.

I solved the issue by adding a trigger that checks the owner of the helper to avoid P2 interacting with P1's coding:

Code Select Expand


[State -3, platform OFF]   
type = ChangeState 
triggerall = helper(10000), IsHelper(10000) ; check that P2 doesn't think P1helper is his own
triggerall = vel y = 0
triggerall = pos y < 0
triggerall = stateno != [40,52]
trigger1 = helper(10000),rootdist y > -41
trigger2 = helper(10000),rootdist y < -51
trigger3 = helper(10000),rootdist x > 11
trigger4 = helper(10000),rootdist x < -11
value = 50
   

(ignore the shitty coding, just testing functionality at this time)

Anyways, thanks for your comments