YesNoOk

Show content

This section allows you to browse the content for this member. Note that you can only see content for which you have sufficient viewing permissions.

*
Ziddia is Offline
Contact Ziddia:

Ziddia

User

Messages by Ziddia

Page 1 of 11
    

Re: Helper (SCTRL) 1.0 + 1.1b

 June 28, 2022, 10:27:36 pm View in topic context
avatar  Posted by Ziddia  in Helper (SCTRL) 1.0 + 1.1b (Started by Odb718 October 13, 2015, 09:00:46 pm
 Board: MUGEN Class
Helpers and Projectiles in 1.1 support an undocumented postype of `none`. With postype set to `none`, the Helper or Projectile will be spawned offset from the stage center.

This postype option was documented for Explods, but was missed in the documentation for Helpers and Projectiles, despite being functional.

This is also the only postype option which breaks this rule from the post: "In all cases, off_y is relative to the position of the player". In the case of `postype = none`, off_y is relative to y = 0 (i.e. the floor of the stage).
    

Re: MUGEN Crashes Compilation

 March 04, 2022, 11:38:28 pm View in topic context
avatar  Posted by Ziddia  in MUGEN Crashes Compilation (Started by Noctis February 22, 2016, 08:08:27 pm
 Board: MUGEN Class
Couple of interesting ones -

`PlayerSCtrlApplyElem not recognised` - 1.1 only
Code: 
[State ]
type=Tag
trigger1=roundstate=2

This one crashes with a 'rare' error message, I think this is the only way to hit it normally across all versions. Cause of the issue is use of the `Tag` sctrl, which MUGEN 1.1 can parse, but not run. Therefore, the character can load with this sctrl, but as soon as it triggers, the game will crash.

%%n
Code: 
[State ]
type=displaytoclipboard
trigger1=roundstate=2
text="%%n"

This one crashes with no error message. Cause of the issue is, of course, the %%n - complicated issue, but basically this will try to apply as a normal %n, causing the OS to close the application silently.

Of course these aren't realistic to hit in a character, just kind of novelties.
    

Re: Winmugen crashes when selecting character

 May 26, 2021, 02:34:05 am View in topic context
avatar  Posted by Ziddia  in Winmugen crashes when selecting character  (Started by shotx May 23, 2021, 01:45:45 am
 Board: M.U.G.E.N Configuration Help
dsrugal is a supernull, most likely it’s an incompatibility with your OS, especially if you’re on windows 10
    

Re: spark helper displayed too many times

 May 23, 2021, 05:24:56 am View in topic context
avatar  Posted by Ziddia  in spark helper displayed too many times (Started by Momotaro May 22, 2021, 10:57:23 pm
 Board: M.U.G.E.N Development Help
The issue is probably ‘trigger1 = movecontact = 1’, movecontact and similar triggers don’t increase while you have hitpausetime, so this trigger will be true for the duration of your hitpause (1 Helper on initial contact + 2 during your 2-tick hitpause = 3 helpers)

You probably want to add either ‘triggerall = !numhelper(8000)’ or maybe ‘triggerall = HitPauseTime = 2’ to make sure it only triggers once
    

Re: How to move during pause or super pause

 May 11, 2021, 02:03:19 pm View in topic context
avatar  Posted by Ziddia  in How to move during pause or super pause (Started by Boxuu May 11, 2021, 11:04:35 am
 Board: M.U.G.E.N Development Help
Your movetime and time should match, as is you have time=300/movetime=2 so the character only moves for the first 2 frames of the pause and then freezes.
    

Re: Regarding ChangeAnim (instead of animation, MUGEN seems to use sprites)

 May 04, 2021, 03:32:13 am View in topic context
avatar  Posted by Ziddia  in Regarding ChangeAnim (instead of animation, MUGEN seems to use sprites) (Started by ice00monster May 03, 2021, 10:18:32 pm
 Board: M.U.G.E.N Development Help
Please share the code + relevant portion of the air file, it’s hard to debug an issue like this without seeing at least the code for the custom state
    

Re: Poison Glitch Implementation Problems

 May 03, 2021, 02:02:27 pm View in topic context
avatar  Posted by Ziddia  in Poison Glitch Implementation Problems (Started by CoffeeFlavoredMilk May 02, 2021, 10:10:22 pm
 Board: M.U.G.E.N Development Help
The point of the ReversalDef is to persist a target, normally targets are dropped when the targeted player leaves the hit state but running ReversalDef allows the target to continue to be held. In this code the player running state 1051 (I assume some helper) is getting the initial target with HitDef, but then you spawn a new helper into 1052 to run the ReversalDef... the 1052 helper doesn’t have any target to begin with so the ReversalDef can’t persist anything. You need to run the ReversalDef on whatever player already holds a target.

You could just merge these two together and use the same helper for both...

[State 1051, HitDef]
type = HitDef
trigger1 = !NumTarget ;; <— only until target obtained

[State 1051, ReversalDef]
type = ReversalDef
trigger1 = NumTarget ;; <— retain target after obtained

Then move all the posset, targetlifeadd, etc up to 1051 and trigger them on NumTarget as well... and adjust the DestroySelf triggers
    

Re: ChangeAnim2 Doesn't Use My Animations...

 February 09, 2021, 05:49:15 pm View in topic context
avatar  Posted by Ziddia  in ChangeAnim2 Doesn't Use My Animations... (Started by George777 February 08, 2021, 08:05:56 pm
 Board: M.U.G.E.N Development Help
Unfortunately you can’t get the opponent to use both your sprites + anims at all, just anims via CA2. If you need to use your sprites, a Helper or Explod with the opponent Invisible+NoShadow is your best bet
    

Re: ChangeAnim and ChangeAnim2 (SCTRL)

 February 09, 2021, 02:15:21 pm View in topic context
avatar  Posted by Ziddia  in ChangeAnim and ChangeAnim2 (SCTRL) (Started by Ricepigeon October 20, 2015, 04:35:15 pm
 Board: MUGEN Class
There’s a bug in the way ChangeAnim/ChangeAnim2 are handled for custom states, fortunately it’s not very likely to come up so long as appropriate SelfAnimExist checks are used

Internally to MUGEN, a character’s animation is stored as the index of that animation in the AIR file (ie first anim in the AIR is index 0, second is index 1, ...)

When ChangeAnim2 is successfully executed, the matching index from the AIR file of the custom stator is used (ex, I custom state the opponent and CA2 to 5155, which is index 50 in my AIR file; anim number for the opponent internally is updated to 50), and a flag is set to indicate whose AIR data to use

If ChangeAnim is then executed within the same custom state, and the ChangeAnim has an invalid animation number specified, the flag for whose AIR data to use is cleared, but the index remains at whatever it was after the ChangeAnim2 (for the above example, 50). This is because ChangeAnim will refuse to change to an invalid anim, but the AIR data flag is cleared without this check. So in this example, the custom stated opponent jumps from my 50th animation to their 50th animation. This can cause obvious visual errors (since the opponent’s ‘n’th animation is unlikely to be what I want to show), or even hard crashes (if the opponent’s AIR file has less than ‘n’ animations, random junk data will get loaded from memory as the current anim and will very likely crash with no error)

This shouldn’t ever come up in a normal character, since you should use SelfAnimExist to avoid ChangeAnim to an invalid value. But here’s an example of how it could go wrong with a missing SelfAnimExist guard on a ChangeAnim. In this case, if the CA2 activates, we know 5060 does not exist, so the subsequent ChangeAnim will trigger the bug.

Code: 
[State 1234, CA2]
type = ChangeAnim2
trigger1 = Time = 0
trigger1 = !SelfAnimExist(5060)
value = 2050

[State 1234, CA]
type = ChangeAnim
trigger1 = Time = 0
value = 5060
    

Re: ChangeAnim2 Doesn't Use My Animations...

 February 09, 2021, 01:55:52 pm View in topic context
avatar  Posted by Ziddia  in ChangeAnim2 Doesn't Use My Animations... (Started by George777 February 08, 2021, 08:05:56 pm
 Board: M.U.G.E.N Development Help
Post contents of your action 4000? In case there’s any confusion, CA2 will change to your character’s anim data (ie definition from the AIR file) but will still use the target’s sprite data, which sounds like the behaviour you’re describing in the last paragraph

It’s probably also a good idea to pause and stepframe when the opponent reaches your custom state so you can confirm the anim number in debug info

Is the state you posted in the OP the entirety of it? There’s some sort of uncommon bugs that can come up if you use changeanim2 and changeanim both in the custom state

    

Re: Swiss Army Knife for Win, 1.0, 1.1

 November 10, 2020, 08:42:49 pm View in topic context
avatar  Posted by Ziddia  in Swiss Army Knife for Win, 1.0, 1.1 (Started by Ziddia October 10, 2020, 10:00:35 pm
 Board: Your Releases, 1.0+
EgyLynx said, November 10, 2020, 06:46:01 pm
Ziddia said, November 10, 2020, 05:08:48 am
Alivated said, November 09, 2020, 07:55:50 pm
Great work!

I just want to report that the display is bugged when starting a mugen that has fullscreen enabled. Also, is there a way to enlarge the mugen window? It looks limited to 640x480 or something.
Thanks for the report, I'll look into it.

Being stuck to 640x480 is a limitation of the original program to make sure it fits in with the other debugging windows, but I'll take a look through it and see if there's a way to scale it up.
Original rogram?

Like I mentioned in the OP, I just updated this tool to 1.1 and added/fixed a few features, the original program was made by a Japanese developer and translated by Vans :)
    

Re: Swiss Army Knife for Win, 1.0, 1.1

 November 10, 2020, 05:08:48 am View in topic context
avatar  Posted by Ziddia  in Swiss Army Knife for Win, 1.0, 1.1 (Started by Ziddia October 10, 2020, 10:00:35 pm
 Board: Your Releases, 1.0+
Alivated said, November 09, 2020, 07:55:50 pm
Great work!

I just want to report that the display is bugged when starting a mugen that has fullscreen enabled. Also, is there a way to enlarge the mugen window? It looks limited to 640x480 or something.
Thanks for the report, I'll look into it.

Being stuck to 640x480 is a limitation of the original program to make sure it fits in with the other debugging windows, but I'll take a look through it and see if there's a way to scale it up.
    

Re: GetHitVar(*) (Triggers)

 November 10, 2020, 05:03:00 am View in topic context
avatar  Posted by Ziddia  in GetHitVar(*) (Triggers) (Started by JustNoPoint October 09, 2015, 05:04:46 am
 Board: MUGEN Class
XGargoyle said, November 25, 2018, 06:17:53 pm
Gethitvar(isbound) will bug if P2 performs the move with the TargetBind controllers AND the movetype is set to I.
Under this instance, P1 will see Gethitvar(isbound)=0 and eventually go back to his owns SelfState if using a trigger like !Gethitvar(isbound).
In the same scenario, if P1 performs the same move instead, P2 will see Gethitvar(isbound)=1 and still be under P1's custom state, hence the bug with the internal engine

In this scenario, TargetBind is working fine and positioning the player in the corresponding screen position, but since the movetype is set to I (no attack), P1 gets a different gethitvar(isbound) data than P2.

The "fix" to this bug is to ensure that any state with TargetBind controllers are set as movetype=A, otherwise it will work only for P1 but not for P2

More details here:
http://mugenguild.com/forum/topics/p1-not-bound-if-p2-initiates-hold-possible-bug-gethitvarisbound-185393.0.html


Big necro, but I noticed this and I want to clarify why this isn't a bug. It comes down to player processing order, and the duration of TargetBind.

Sorry for long post OTL

In MUGEN, in general, players 'move' (or process their states) in player slot order: P1->P2->(P3->P4->)Helper1->Helper2->...->Helper56. However, players and helpers with MoveType = A always move before players and helpers with MoveType != A. I think this is to help with making sure attacks land consistently.

Therefore, P1 will always move before P2 in a frame, with the single exception of P2 having MT=A and P1 having MT!=A (e.g. MoveType=I). In addition, the default time value for TargetBind is 1, so it lasts for a single frame (since no time parameter was set on the TargetBind stecons in the linked post) - I believe that setting the time parameter to something other than 1 would solve the linked issue, but I didn't bother to check whether IsBound resets to 0 every frame independent of the time parameter or not.

Knowing this, we can deconstruct the details of the linked scenario:

Case 1 - Player 1 MT=I, Player 2 MT=H, Player 1 has thrown Player 2 and Player 2 wants to check GetHitVar(IsBound). This is the case where it was working.

Since both Player 1 and Player 2 have MT != A, they move in player slot order: P1->P2. Now this happens in the span of one frame:
- Player 1 performs TargetBind, this sets Player2,GetHitVar(IsBound) = 1
- Player 2 reads GetHitVar(IsBound), it evaluates to 1
- Player 2 remains bound
- IsBound becomes 0 at the end of the frame.

Obviously, it works as expected.

Case 2 - Player 1 MT=H, Player 2 MT=I, Player 2 has thrown Player 1 and Player 1 wants to check GetHitVar(IsBound). This is the case where it failed.

Again, both Player 1 and Player 2 have MT != A, so they move in slot order:
- Player 1 reads GetHitVar(IsBound), it evaluates to 0
- Player 2 performs TargetBind, this sets Player1,GetHitVar(IsBound) = 1
- IsBound becomes 0 at the end of the frame.

...as you can see, there is never a chance for P1 to read GetHitVar(IsBound) while it's set to 1. Player 2 moves second, and it gets unset at the end of the frame. Therefore, it fails.

Case 3 - Player 1 MT=H, Player 2 MT=A, Player 2 has thrown Player 1 and Player 1 wants to check GetHitVar(IsBound). This is the described workaround.

In this case, since Player 2 has MT=A, it will move before all players and helpers with MT != A, including Player 1:
- Player 2 performs TargetBind, this sets Player1,GetHitVar(IsBound) = 1
- Player 1 reads GetHitVar(IsBound), it evaluates to 1
- Player 1 remains bound
- IsBound becomes 0 at the end of the frame

...all this to say, if you want an effect that's active for only 1 frame to be readable by any other player or helper, you should make sure to set MT=A!
    

Re: Swiss Army Knife for Win, 1.0, 1.1

 November 08, 2020, 07:11:10 pm View in topic context
avatar  Posted by Ziddia  in Swiss Army Knife for Win, 1.0, 1.1 (Started by Ziddia October 10, 2020, 10:00:35 pm
 Board: Your Releases, 1.0+
Updated:
- enabled trigger-checking breakpoints for all MUGEN versions
- relabeled to 'Trigger breakpoint status' to be explicit that it will pause the process
Bugfixes:
- fixed functionality of 'Bring other windows to front' button
- fixed a bug where MUGEN would report as frozen when it really wasn't (related to wrong GameTime offset)
- fixed some issues related to MUGEN scaling (but not all)

Tutorial for the breakpoint system is on https://ziddia.blog.fc2.com/blog-entry-46.html. But basically it's in the Triggers tab, and it's just a method for automatically pausing MUGEN when conditions are true so that you can inspect the character. Pretty useful for debugging very frame-tight issues.

edit: updated with new link, added an alternative breakpoint method since certain antiviruses don't like the use of hardware breakpoints. If you have issues with regular breakpoints, please set `Enable Experimental Breakpoints` to ON in the Profile config.
    

Swiss Army Knife for Win, 1.0, 1.1

 October 10, 2020, 10:00:35 pm View in topic context
avatar  Posted by Ziddia  in Swiss Army Knife for Win, 1.0, 1.1 (Started by Ziddia October 10, 2020, 10:00:35 pm
 Board: Your Releases, 1.0+
This is basically https://mugenguild.com/forum/topics/swiss-army-knife-winmugen-english-version--178952.0.html compatible with 1.1a4 and 1.1b1. Includes some additions I made (localcoord checking, full AssertSpecial list).

The tool lists all characters/helpers, explods, projectiles currently in play, supports frame-by-frame stepping, and lists all vars and other info about players/helpers. I only updated this to work with 1.1, most of the work is credit to an unknown Japanese developer and translation is credited to Vans (post is linked above).

Feel free to report bugs/request missing features.

Download: https://ux.getuploader.com/ZiddiaMUGEN/download/15 (2020/11/08 v2 version)

Example:





    

Re: HitDef (SCTRLs)

 October 07, 2020, 03:29:51 am View in topic context
avatar  Posted by Ziddia  in HitDef (SCTRLs) (Started by Odb718 September 30, 2015, 12:13:58 pm
 Board: MUGEN Class
Yep - need to use a combo of p1stateno/chainID and a permanent target to perform the actual damage, which is super inconvenient. It’s mostly just a gimmick in the end.
    

Re: HitDef (SCTRLs)

 October 07, 2020, 03:04:54 am View in topic context
avatar  Posted by Ziddia  in HitDef (SCTRLs) (Started by Odb718 September 30, 2015, 12:13:58 pm
 Board: MUGEN Class
Nep Heart said, October 07, 2020, 02:55:26 am

 This is technically incorrect since it still does make hitdefs interrupt targets, but they just end up with no hittime and no hitshaketime to the point it's unnoticeable.

This is an interesting result, because we did verify that this worked the way I described, where the opponent never enters a hit state/leaves its current state using ground.type=None. You can see this in https://youtu.be/BVUuS0Znzxs - the characters continue to move/attack and Time continues to advance without being interrupted while these HitDefs are used. If there was even an instant of interruption, Time would be reset to 0 or the character would change state. I’m interested in how your test was set up to see what might be different.

    

Re: HitDef (SCTRLs)

 October 07, 2020, 02:43:37 am View in topic context
avatar  Posted by Ziddia  in HitDef (SCTRLs) (Started by Odb718 September 30, 2015, 12:13:58 pm
 Board: MUGEN Class
Some properties or engine quirks of HitDefs that aren’t really well documented.

- HitDefs with ground.type=None are non-interrupting, deal no damage, don’t force the target into a hit state, etc. They also don’t grant targets or set MoveHit, MoveContact. But properties p1stateno, p2stateno, chainID will all work on these HitDefs, so it’s possible to use p1stateno or chainID to detect when a non-interrupting hit connects and then deal damage via a permanent target bug instead. Kind of has a niche use for attacks which you don’t want to interrupt the enemy with (it almost appears visually as if the opponent has armor, even though they don’t).
- P2stateno=-1 on a ground.type=None HitDef puts the target into your statefiles without resetting Time to 0, so landing the hit on an opponent with StateNo=200, Time=15 will put them into your StateNo=200 with Time still =15. I can’t think of a use for this for a normal char though.
- A HitDef with a throwing type attribute (any NT,ST,HT,AT) makes the target completely unhittable for the duration of p1’s pausetime, with a minimum of 1 frame, so if you set e.g. pausetime = 15,0 the target will be unhittable for 15 frames. This also supersedes all NotHitBy/HitBy, it will strictly last until the pausetime ends. I can’t think of any way this will apply for normal chars, outside of knowing it exists to explain simul issues/issues with helper hits.
- Someone mentioned earlier that omitting the statetype portion of the HitDef makes it non-reversible (e.g. using attr=,NA). This is true, but Mugen engine automatically updates the HitDef to take on the statetype of the character applying the HitDef after it hits (e.g. my statetype=S, the HitDef before becomes S,NA). So as soon as the HitDef hits once, it becomes reversible again. To avoid this, you can make use of hitonce, or else continue to re-apply the HitDef on every frame so the attr is constantly updated as not having a statetype, at which point it’s truly irreversible for most (non-cheap) purposes.
Page 1 of 11