YesNoOk
avatar

add004basic (Read 1197907 times)

Started by Shiyo Kakuge, June 18, 2014, 05:46:41 PM
Share this topic:
Re: add004basic
#1561  September 28, 2020, 09:26:24 PM
  • avatar
  • **
    • USA
Re: add004basic
#1562  September 28, 2020, 09:26:58 PM
  • avatar
  • **
    • USA
So I installed add004 to my Ikemen but there's a problem. The names doesn't show up, the P2 Portrait looks a bit off and the lifebars are looked like they are cut up. Can someone help me to fix this? Thanks!


The names appear as one more sprite ... do not use the mugen fonts the add ... you must locate in the sff with the group 9001,0 and they will appear in the ikemen





You can also use the map (def file) to use the proper states for tag system calls

[map]
a4b_sparkno=31
a4b_sparkxy=30
a4b_assist3=1000 ;; tiger Shot
a4b_assist1=1100 ;; tiger upper
a4b_assist2=1200 ;; tiger Crush
a4b_assist_hp=3100 ;; tiger Genocide
 
If anyone knows more about customization ... it would be good to share it for more info ...

Do I like find the names in the lifebars sprites or something?
Re: add004basic
#1563  September 29, 2020, 09:26:00 AM
  • avatar
  • *
  • EL LEGENDARIO CAMINANTE......
  • Después de un largo tiempo........ eh vuelto !!!!!
Do I like find the names in the lifebars sprites or something?



I don't like them, to tell the truth, but this is how the system comes, and the ikemen function still does not work properly with the desired effect in my opinion ... maybe in the future that detail can be fixed
Re: add004basic
#1564  September 30, 2020, 10:12:11 PM
  • **
  • = +...Orpheus vs. the Sirens...+ =
    • USA


Another tutorial I made on how to both fix common character patch errors and how to manually patch a character
"Make Fighting Games Great Again"
Re: add004basic
#1565  October 03, 2020, 05:07:04 AM
  • avatar
  • **
    • USA
Nice tutorial but I have one question. What if the character doesn't have Recover?
Re: add004basic
#1566  October 04, 2020, 08:54:53 PM
  • avatar
  • **
    • USA
Nice tutorial but I have one question. What if the character doesn't have Recover?

then you add it (cmd), its also default in common cns (if its not in common cns, take it from a character that has it, it should be there though)
Re: add004basic
#1567  October 20, 2020, 04:08:36 PM
  • avatar
  • *
    • Mexico
Ammm the Zatoichi Flash tutorial! Your tutorial is appreciated but it is a bit accelerated and does not show how to record and the chars of the author Violin Ken no more cannot be patched with your tutorial or with the add004basic https://www.mediafire.com/file/4l65nir7bfvc5az/Poison.7z /proceedings
Re: add004basic
#1568  October 23, 2020, 02:06:49 AM
  • avatar
  • **
    • USA
Can anyone do like a tutorial or show how to add different round and fight callout sounds to the lifebars just like 2Dee4ever did to his lifebars? For example; If you watched one of 2Dee4Ever, you'll notice that each round and fight callout sound are quite different than the CVS2 Callout sounds that Shiyo used in his lifebars.
Re: add004basic
#1569  October 23, 2020, 04:19:27 AM
  • avatar
  • **
i'm using the latest ikemen go v0.95 and latest add004 for v0.94

when in arcade tag mode 3v3 or 4v4 most of the time random characters got stuck in the edge of the screen when that happens i cannot tag or assist the character until the time runs out?

can i delete some line/s in the tag script of add004 for this to not happen?
Re: add004basic
#1570  November 10, 2020, 06:55:57 PM
  • avatar
  • **
    • USA
How do I edit the hitsparks?
Re: add004basic
#1571  December 07, 2020, 12:56:20 AM
  • avatar
  • *
First I'll warn you, there's some ikemen only sctrl's that are being used so you will have to find a workaround in mugen, so I would advise against copy pasting. But I think as long as I explain the ideas, it could properly be modified. There's ALOT happening I'll warn you first, its very oriented to fit into my custom game.

There's some very specific things (for example, it only really works good with power bar being maxed at level 3 the way its coded). It's a hybrid of a traditional tag cancel and team hyper. Usually hyper cancel will cancel the active player and they exit, in this the main player stays on until the hyper is finished and the tagged in partner lands and automatically initiates their hyper (different to pizza high fives where they just change to state 0 on land during hyper). Sample Video here of what it looks like:

[youtube]https://www.youtube.com/watch?v=aMngB7CvRzY[/youtube]

Also note, my edit is strictly 3 on 3, so if its 4 on 4, idk it might work or break....The most important things to note in the zss are:

There is a new var48 being set to 15 in state 90900 which designates a tag cancel during a hyper

Which comes to the 2nd important change, sysfvar(4) now has a value equal to 3 (it originally is just values 0-2), sysfvar(4)=3 when active player's var48 = 15, and it tells the character tagging in "hey, when I land after state 190195, I have to initiate my hyper move"

Code in question:

Spoiler, click to toggle visibilty

also you need to edit hte id search for partners to include a trigger for the new var(48)=15, in zss it looks like this

Spoiler, click to toggle visibilty
then to the next point...

In my edit, each and every character has their exceptions and hypers since all of them do have their hypers in range 3000-3999, but not al lare exactly 3000. If all of your characters have the ideal hyper you want in state 3000, you could just edit it so its global without the "name" trigger. In state 190195 in land, it has this

Spoiler, click to toggle visibilty

As you can see, again, its very specific to my game, with the power trigger and everything. But like I said, if you understand the thought process of this it should be easily modified for your own game.

Now in ikemen, there is a state -4 that ignores all kinds of pauses or super pauses so I am unsure how its coded in original mugen, its this state:

Spoiler, click to toggle visibilty
Basically,exit if you are no longer in state 3000-3999 (designated hyper states) if you called to cancel into your next partner.

Also some extras, if hyper cancel, then instead of turning blue when tag cancel, turn red and also do a superpause:

Spoiler, click to toggle visibilty

This might be it, I thought I would just explain the basics of what I did so it might be workable for a more general sense if things. Again I would not reccomend copy and pasting, the code is set up to only work wit ha very specific system.



this is perfect ive been trying to do this 4 a long time great job
Re: add004basic
#1572  December 18, 2020, 06:00:29 PM
  • avatar
  • *
does anyone know how to add more combo messages?
Re: add004basic
#1573  December 31, 2020, 11:34:16 AM
  • avatar
  • **
    • USA
NOTE: I'm using the Ikemen go version of add004, on 0.96, these might be ikemen specific but if you experience this behavior on mugen, this may help. you will have to translate it to mugen cns if you’re on the mugen version

To download a prebuilt file with example characters, use this link: https://drive.google.com/file/d/1cDHE6JHCGLpR_Ekb1rnxfa3rwNWsPEfl/view?usp=sharing

Ok so after 8 months of using add004 for ikemen and understanding the ins and outs, the current vanilla version has quite a few flaws, and hopefully my post will assist users in optimizing it for better usage. I've now basically modified it enough on my end where it responds way better and reacts as it should. If you're big into fighters like me then one of the most important things is responsiveness and timing. By default, the timing of when you can do actions (like tag in or tag out) is not that great, and tag cancel actions don't respond well at all depending on the move. Below I’ll go through some fixes that solves all this:

One has to do with the amount of time you go from state 190190 (exiting state) to state 190192(standby). The problem is, the interval (amount of time) in the main loop you can call for a character switch is shorter than your actual going to standby state. So, what happens (as I still see in some peoples’ videos and games) is if you switch and spam the switch button quick enough, your exiting partner won’t have enough time to exit and it'll force whoever is coming up to come in and "land" at the edge of the screen instead of where your partner's position was supposed to be. The run/jump out cycle is way too slow in conjunction with the tag in/out interval. So, in state 190190, to your liking, in "#;sys::partner_run-vel2" change the vel x to something higher, for me I put 12.6. But take note, you'll have to calculate everything else then and time it perfectly, these are the numbers I use. They all must be perfectly timed well.

Another problem is when the round starts, there is a small bug where if player 2 is near the edge of the side your p1 partners exited during the first seconds of the game, they will automatically turn to that edge randomly for a quick second. This is because in "#;sys::player_pos_y_outscreen1" in state 190190, your partner's presence suddenly triggers p2 to turn since they are near that position again for a few frames. This only happens at the start of a round since it SETS your partners to pos y of 0, triggering the sudden enemy p2 turn to the edge. to fix this I put "if TimeElapsed > 200" before it which avoids this all together. In Mugen you can just spawn an invisible explod for 200 or so frames and trigger it when numexplod(whatever number) equals zero.

Another problem is once you adjust the timing, it messes a bit with how player 2's ability to tag or call for an assist is in the beginning. What happens is p2 gets to call for an assist or switch in the beginning of the round quicker, to fix this I also put the same timeelapsed >200 trigger in the beginning of the #;sys::partner_goto-standby1 section, since this only happens as the round starts. Still in that section, the time it takes to go to state 190191 is 1 second, I changed mine to half a second. Instead of time?59, I put time >29.

In the section  #;sys::partner_goto-standby2 #;;<<- (158F) interval / charge-time ; I also changed "time >= 158" to "time>=29". a HUGE change, this is because the default interval when you can switch in and out or call an assist is so short, we're adjusting it accordingly so it doesn’t bug out and make your partner land on the edge of the screen (if switched quick enough).

And finally, the biggest part I changed, is how var changes happen. Making the player have to set var(48) to 11 BEFORE doing a tag cancel is counterproductive. I just separated them. There are a lot of problems with assist interval counter resetting even if it didn’t execute. Now they look like as follows:

Code:
ignorehitpause if var(48)=11 { mapset{map:"i_Assist_Interval"; value: 100} mapset{map:"time"; value: 1} }
ignorehitpause if var(48)=21 { mapset{map:"i_Assist_Interval"; value: 100} mapset{map:"cancelexit";value:1}} #ORIGINALLY 30
ignorehitpause if var(48)=12 { mapset{map:"i_Assist_Interval"; value: 120} }

if you are using my custom hyper cancel/tag code, just adjust accordingly and literally make it like the chunk of tag cancel code, but instead tirrger it when stateno = [3000,4000].

Notice how I adjusted the interval as well; this is because we’ve adjusted timing and also, I find this delay in timing personally for me works best. anywhere from 80 and above work better. Feel free to adjust lower but you WILL run into switching to the wrong character issues if switching too fast or characters ending on the edge of the screen. I have all the varsets all separate, it’s easier to keep track this way. instead of just var48 trigger and var48=12.

Again, we want the timer to run correctly and make sure that timer resets correctly if partner exits so you don't get sometimes buggy switches (which happens by default, not often, but sometimes). That’s why I have another mapset I put when var48 is set to 11 and 21. Then I added the below:

Code:
ignorehitpause if map(i_Assist_Interval)=0 { mapset{map:"time"; value: 0} }
ignorehitpause if map(time)=1 &&
(playerid(var(15)),target,incustomstate=1 ||
playerid(var(15)),target,gethitvar(isBound)=1 ||
playerid(var(15)),hitdefattr = SCA, NT ) {
mapset{map:"i_Assist_Interval"; value: 0} }

Personally, for me, if you are grappling, I don't want to just switch while they are in a grapple move, so this prevents a grapple to cancel out of.


and then it proceeds to start the next if statement. Please feel free to remove any playerid(var(15)),numtarget triggers there, because in my case I wanted characters to be able to tag cancel if they hit someone with a projectile. Move contact does not count projectiles. Numtarget is buggy if not properly managed (I haven’t posted the code here since it might be too much). Anyway......

This should prevent both those things from happening. What ends up happening is it won’t reset the interval back to 120 (at least in my case the number I set to) again. Assisting in and out should be way smoother now.

Then I made changes to the triggers of how the varsets are made because we want to separate a tagout and a tag cancel, we don’t want to have to set var48 to 11 before canceling to set 12, this just brings a slew of bugs. So I modified it to this (in #;>>sys::tag_mode_cmd_change):

Code:
#;; change [v48=11] ; 交替
#;>>sys::tag_mode_cmd_change
ignorehitpause if map(i_Assist_Interval)=0 && map(supertimer)=0 &&
roundstate=2 && numpartner && var(22)=4 && !var(48) && map(i_Assist_Interval)=0 && map(supertimer)=0 &&
(playerid(var(15)),statetype != A && (playerid(var(15)),stateno!=[45,51] || playerid(var(15)),movecontact != 0)) &&
(playerid(var(15)),movetype = I && playerid(var(15)),ctrl = 1 && playerid(var(15)),statetype != A && playerid(var(15)),movetype != A && playerid(var(15)),movetype != H ){
ignorehitpause if var(15)!=var(49) && playeridexist(var(49)) {
ignorehitpause if (playerid(var(49)),stateno=190192) && (playeridexist(var(15))) && (playerid(var(15)),stateno!=[2999,3999]) { #; if in hyper cancel, ignore p1 idle status if P3 so P3 can hyper cancel
##;;--- player-controlled ;; 操作交替
ignorehitpause if ((root,command="shift_fwd") || (root,command="shift_back")) {
ignorehitpause if var(51)<1 && var(28)>200 && (var(7)&1024) {
var(48):=11;
}}
##;;--- ai
if var(51)>0 && var(28)>200 && (var(7)&1024) {
if playerid(var(15)),sysfvar(4)<1 && (random%50=0) && playerid(var(15)),life<playerid(var(49)),life {
var(48):=11;
}}
##;;--- forced change (not-alive, stand-by) ;; 強制交替(終止、待機中)
if playeridexist(var(15)) {
if (playerid(var(15)),alive=0 && playerid(var(15)),stateno=5150) || (playerid(var(15)),stateno=[190191,190192]) {
var(48):=11;
}}
}}}

and for var48=21 (tag cancel), important note, you must add the AI code from var48=11 to this now since they are seperate and so cpu can use these functions :

Code:
#;; "Switch-Canceling"
ignorehitpause if map(i_Assist_Interval)=0 && map(supertimer)=0 && var(15)!=var(49) && playeridexist(var(49)) {
ignorehitpause if playerid(var(49)),stateno=190192 && power>=500 {
ignorehitpause if playerid(var(15)),sysfvar(4)<1 && playerid(var(15)),alive && playerid(var(15)),stateno!=[2999,3999] {
ignorehitpause if playerid(var(15)),movetype=A && playerid(var(15)),gethitvar(isbound)=0 &&
  ((playerid(var(15)),movecontact && playerid(var(15)),target,movetype=H) ||
  (playerid(var(15)),movecontact) ||
  (playerid(var(15)),numtarget>0 && playerid(var(15)),target,incustomstate=0 && playerid(var(15)),Target,StateNo != [5110,5955] && playerid(var(15)),target,movetype=H)) {
ignorehitpause if ((root,name!="BAGAN" && ((root,command="shift_fwd") || (root,command="shift_back"))) && var(51)<1 && var(28)>200 && (var(7)&1024)) ||
   (var(51)>0 && var(28)>200 && (var(7)&1024) && playerid(var(15)),sysfvar(4)<1 && (random%50=0) && playerid(var(15)),life<playerid(var(49)),life ) {
   var(48):=21;
}}}}}

Please modify to how you create your system, for example switch cancelling does not cancel on states 2999->3999 in the trigger because i have a custom hyper cancel tag I use for those statenumbers, so please look at the code and adjust accordingly before simply copy pasting.

Now this is optional, this is to FORCE cancelling partner to exit after you initiate a tag cancel, by default you may be able to do a movecontact combo with the character that is supposed to exit until they are no longer in an attack state, I prefer they exit after a cancel initiates since this messes up timing and 99% of fighting games behavior is like this, in main loop 90900 in a4b_main, I put:

Code:
ignorehitpause if map(cancelexit) > 0 { mapset{map:"cancelexit"; value: map(cancelexit) + 1} }

We already set up the map cancelexit in the above when var(48)=21. So now that it is 1, it will continue increasing by 1 each frame, we want this so in statedef -4 we can trigger a force exit with this code (put in statedef -4 to ignore superpauses):

Code:
ignorehitpause if playerid(floor(sysfvar(0))),map(cancelexit) > 5 && (stateno != [190190,190196] || prevstateno!= [190195,190196]) && movetype = A && pos y >= 0{
changestate{value:190190}
mapset{map:"cancelexit"; value: 0; RedirectID:floor(sysfvar(0))}
}

ignorehitpause if playerid(floor(sysfvar(0))),map(cancelexit) > 5 && (stateno != [190190,190196] || prevstateno!= [190195,190196]) && movetype = A && pos y < 0{
changestate{value:50;ctrl:0}
velset{x:0;}
mapset{map:"cancelexit"; value: 0; RedirectID:floor(sysfvar(0))}
}

Ok that's good, but now we must set it up so it doesnt bug out any other characters to exit, so in state 190190 && for good measure also in 190191 in a4b_tag we put:

Code:
mapset{map:"cancelexit"; value: 0; RedirectID:floor(sysfvar(0))}
We redirect the mapset to the helper90900 and set it to 0 whenit confirms the person is exiting

Then in statedef 190195 we put:
Code:
ignorehitpause if playerid(floor(sysfvar(0))),map(cancelexit) > 0 { mapset{map:"cancelexit"; value: 0; RedirectID:floor(sysfvar(0))}  }

Just so before landing in as the main character, teh cancelexit is still not running and accidently sends the character exiting.

And in statedef 190193, replace the code sections referenced below with mine here. The default does not calculate the main player's postition right in some cases which ends up making them land on the edge of the screen. This should fix that bug:

Code:
#;sys::partner-out-set2
if sysvar(0)>0 && playeridexist(sysvar(0)) {

if facing!=playerid(sysvar(0)),facing { turn{} }
posset{
x: (playerid(sysvar(0)),pos x) - ( playerid(sysvar(0)),backedgebodydist +const240p(90) )*facing;
y:-const240p(180) }

#;sys::partner-landing-pos2
if !time && !ishelper && roundstate=2 && sysfvar(4)=0 && !numhelper(909606) && sysfvar(0)>0 && playeridexist(floor(sysfvar(0))) {
if (playerid(floor(sysfvar(0))),var(0)=90900) && !(playerid(floor(sysfvar(0))),var(7)&65536) {
helper{
pos:(playerid(floor(sysfvar(0))),pos x-pos x)*facing, (playerid(floor(sysfvar(0))),pos y-pos y);
id:909606; stateno:190202 }
}}

#;sys::partner-out-vel2
velset{x:abs(pos x-playerid(floor(sysfvar(0))),pos x)*0.05; y:abs(pos y)*0.05 }
#;sys::partner-out-vel3
if (roundstate>2) {
velset{x:abs(pos x-playerid(sysvar(0)),pos x +const240p(28)*(id-sysvar(0))*facing )*0.035;
y:abs(pos y)*0.035 }
}

}

Then to prevent some weird things from happening like characters activating a switch but not actually switching (super rare), I added this when var(48) is set to 11 in state 90900:

Code:
ignorehitpause if var(48)=11 { mapset{map:"i_Assist_Interval"; value: 100} mapset{map:"time"; value: 1} mapset{map:"unsettimer"; value: 1}}

Below I also added to check if it stays stuck and no characters actually switched in, to set it back to 0:
Code:
ignorehitpause if map(i_Assist_Interval)=100 && map(time)=1 && map(unsettimer) > 2 && playerid(var(15)),stateno!=[190193,190195] { mapset{map:"i_Assist_Interval"; value: 0} mapset{map:"time"; value: 0}}

Now we remove the current #;sys::partner-landing-pos2 and replace with these two:

Code:
		#;sys::partner-landing-pos2
if timeelapsed <= 235 && !time && !ishelper && roundstate=2 && sysfvar(4)=0 && !numhelper(909606) && sysfvar(0)>0 && playeridexist(floor(sysfvar(0))) {
if (playerid(floor(sysfvar(0))),var(0)=90900) && !(playerid(floor(sysfvar(0))),var(7)&65536) {
helper{
pos:(playerid(floor(sysfvar(0))),pos x-pos x)*facing, 50+(playerid(floor(sysfvar(0))),pos y-pos y);
id:909606; stateno:190202 }
}}

#;sys::partner-landing-pos2
if timeelapsed > 235 && !time && !ishelper && roundstate=2 && sysfvar(4)=0 && !numhelper(909606) && sysfvar(0)>0 && playeridexist(floor(sysfvar(0))) {
if (playerid(floor(sysfvar(0))),var(0)=90900) && !(playerid(floor(sysfvar(0))),var(7)&65536) {
helper{
pos:(playerid(floor(sysfvar(0))),pos x-pos x)*facing, floor(playerid(sysvar(0)),pos y-pos y);
id:909606; stateno:190202 }
}}


Also its good practice to make sure noturntarget is asserted if the character you are sending out is not the main character, this is because enemies will still try to automatically turn to your standby characters if called out and are close enough, but this ruins the mechanics. This is NOT behavior in tagteam fighting games, main fighters should not be turning to standby fighters who are called in for assisting.

The combo counter system in add004 is also innacurate, compare it with the actual fight.def counter on and you'll see add004 drops some hits sometimes. I'd disable it all together and just enable native combo count system on ikemen/mugen.

Mini rant here, I personally think a lot of stuff here is over-engineered and complex for no reason (for example the explod system for messages). I don't understand the point of making every single thing a variable and writing confusing code no one can really read. I mean cmon, what is this:

Code:
var(14):= var(15)+1+(time%numpartner) -(var(15)-sysvar(0)+1+(time%numpartner)>numpartner)*(numpartner+1);
pos:var(3)*(teamside=2)+floor(5*fvar(0))*ifelse(teamside=1,1,-1) , floor((50+(var(47)%100)*8)*fvar(0));

What are we even trying to do here? Imo, some good examples of easy and clean code to read concerning tag systems are unotag and ikemen's tag system that gacel and k4thos created. I think add004 is waaaay to over complicated for no good reason, it could benefit from some refactoring. For example, why are there 2 standby states? having 2 kind of bugs everything out on default and making it be able to enter as a main player in state190191 doesn't make sense if theres 1 more standby state you have to go thorugh, why not just 1 standby state at that point then? I digress.


I think that’s pretty much the basics but this should make things way smoother and more responsive. Works way better for me this way. Again, unsure of how the mugen version is, but at least in Ikemen it was this way until I did all these modifications.


Last Edit: January 15, 2021, 10:39:55 PM by airforce111
Re: add004basic
#1574  January 01, 2021, 07:28:36 AM
  • avatar
  • *
this helped alot thanks
Re: add004basic
#1575  January 09, 2021, 09:41:33 PM
  • avatar
  • **
    • USA
https://streamable.com/wdjxpz
So I managed to adapt the tag cancel thats been written down here a page ago from airforce111,to the mugen version and it works fine,just wanted to share,probably gonna share it soon

im having trouble sending you PM's, it says you are mete123 but it doesnt appear in the list so i sent to BurningSoul but everytime I send it fails. also that error message you sent, that is really weird because timeleft is what it was called in the old version, did I accidently send the wrong files? In anycase, I have updated and made a few tweaks since then but have not been able to send pm's to you for some reason. please try this:

https://drive.google.com/file/d/1cDHE6JHCGLpR_Ekb1rnxfa3rwNWsPEfl/view

It's an entire example prebuilt. I am on ikemen 0.96. Im not sure what happened before
Re: add004basic
#1576  January 10, 2021, 03:45:42 PM
  • ****
  • Pixels are atom's of resolution,Low-res or Hi-res
    • Turkey
    • metekervan26@gmail.com

  • Online
its mete122 must have been a mistake
Re: add004basic
#1577  January 10, 2021, 08:09:29 PM
  • avatar
  • **
    • USA
its mete122 must have been a mistake
edit: is your inbox full?? that might eb the problem.

yeah it doesnt show up in my list either, its really weird, i only get to send to burningsoul but i can no longer send you PM's or even start a new conversation. i had talked to the mods. Someone else was experiencing hte same thing.
Last Edit: January 10, 2021, 08:42:01 PM by airforce111
Re: add004basic
#1578  January 27, 2021, 07:41:23 AM
    • USA
do anyone know how to change a characters dizzy state on ad0004
Re: add004basic
#1579  February 02, 2021, 10:30:21 PM
  • *
    • Argentina
    • danielcrespo1990@gmail.com
good.
is there a way to fix this error?
the problem is that some characters not all, they do not attend when I call him to defend
Spoiler, click to toggle visibilty
and I think it's the states