YesNoOk
avatar

Ikemen GO (Read 1807419 times)

Started by K4thos, May 26, 2018, 03:04:27 am
Share this topic:
Re: Ikemen GO Plus
#61  June 13, 2018, 04:24:45 pm
  • ***
Amidweiz, now that's what I'd like to see more - fully designed feature request with explanation how it should work internally. If you upload a sample stage that could be used for tests (with stageIntroCtrlID already set and BGCtrl coded to display something before the characters have statedef 5900 assigned and internal lifebar counter starts) I think I will be able to handle the implementation.

As for the second part I think the more flexible approach would be treating stage somewhat like a character, so that it can use CNS, AIR, SND files referenced in stage DEF file, which would open gate for proper stage interactivity:
Code:
[Files]
st      = somename.cns           ;States
anim    = somename.air           ;Animation
sound   = somename.snd           ;Sound
With this in place it would be a matter of controlling actual characters behavior via stage cns code instead of depending on fightfx air and tons of new stage parameters. For example if stage has stageIntro = 1 parameter set than characters are not forced into statedef 5900 at the start of the round - they wait for stage to control them and change their state to 5900. Should be doable with my current understanding of the engine (I hope)
Last Edit: June 13, 2018, 04:36:55 pm by K4thos
Re: Ikemen GO Plus
#62  June 14, 2018, 03:16:05 am
  • ****
  • Hey four stars, whatever that means
    • Canada
    • amidweiz.neocities.org
Amidweiz, now that's what I'd like to see more - fully designed feature request with explanation how it should work internally. If you upload a sample stage that could be used for tests (with stageIntroCtrlID already set and BGCtrl coded to display something before the characters have statedef 5900 assigned and internal lifebar counter starts) I think I will be able to handle the implementation.

As for the second part I think the more flexible approach would be treating stage somewhat like a character, so that it can use CNS, AIR, SND files referenced in stage DEF file, which would open gate for proper stage interactivity:
Code:
[Files]
st      = somename.cns           ;States
anim    = somename.air           ;Animation
sound   = somename.snd           ;Sound
With this in place it would be a matter of controlling actual characters behavior via stage cns code instead of depending on fightfx air and tons of new stage parameters. For example if stage has stageIntro = 1 parameter set than characters are not forced into statedef 5900 at the start of the round - they wait for stage to control them and change their state to 5900. Should be doable with my current understanding of the engine (I hope)

Sounds good, I'm going to send you the stage that was shown MangeX's video and the one I initially shown (CVS Pro Train stage and KOF 95 Garou stage). The Train stage for the stage intro (It's not the best example of a stage intro but it is one) and the Garou stage for the water effects and possibly the movement (as shown in the video I first showed for the request https://youtu.be/lTMwD9ybSAQ?t=9m2s ) here is the link to them two http://www.mediafire.com/file/2hj6lnnk7hpihag/stages.rar . I'll see if I can make a mock implementation for the other requests later
Re: Ikemen GO Plus
#63  June 22, 2018, 12:00:09 am
  • ***
Quote
Sounds good, I'm going to send you the stage that was shown MangeX's video and the one I initially shown (CVS Pro Train stage and KOF 95 Garou stage). The Train stage for the stage intro (It's not the best example of a stage intro but it is one) and the Garou stage for the water effects and possibly the movement (as shown in the video I first showed for the request https://youtu.be/lTMwD9ybSAQ?t=9m2s ) here is the link to them two http://www.mediafire.com/file/2hj6lnnk7hpihag/stages.rar . I'll see if I can make a mock implementation for the other requests later
thanks, I will try to implement it once I finish other things that I’m messing with.

Going back to lifebar BGdef stuff discussed here. I've just implemented trigger support for backgrounds (set via ctrldef) which can detect stuff like wintype, game mode, player's life, perfect match, round etc. When I now think about it, with this feature a single BGdef that works from the start of the match (like in stage) would be enough for lifebars considering you can just use ctrldef triggers to display stuff at any point during match, based on trigger conditions and timers (unlimited amount of triggers are allowed, equality and relational operators are supported). I think this approach will be less confusing compared to multiple bgdefs triggered at specific events.

btw. trigger support for ctrldef means that stage interactivity is greatly expanded. For example:
- you can detect if any player name matches the trigger to disable character from the background (e.g. Shao Kahn sitting on the throne in MK),
- display entirely different stage graphic on second round (e.g. from Morning to Noon a la Fatal Fury),
- adjust animation like in SF2 at the end of round (e.g. elephants animation in Dhalshim's stage) or display different crowd reaction after > x hit combo.
- create destructable objects (for example by detecting player's pos and gethit or life = 0 etc.)
etc. etc.

It also comes in handy in select screen and versus screen (after modes/characters/stage are set). For example it allows to set different bg art in different game modes or display worldmap with stage locations and display icon on the map depending on the selected stage etc.

I'm planning to expand backgrounds also with sound and text support, so there will be even more possibilities (for example announcer stuff in select screen, that can be part of the screenpack, requested here some time ago).

----------------

regarding Tag mode explained in this post. I've noticed in source code that there are TagIn and TagOut sctrls in ikemen. They do the exact same thing as in mugen (before they were removed). Not sure if current behavior is useful for anything but if someone has idea how they could be adjusted to help with common1.cns tag implementation please share it here.
Last Edit: June 23, 2018, 12:41:49 am by K4thos
Re: Ikemen GO Plus
#64  June 23, 2018, 12:21:52 am
  • ****
  • Stages & Screen Pack
  • Mugen Creator
    • USA
    • https://jusmugen.forumotion.com/
Amidweiz, now that's what I'd like to see more - fully designed feature request with explanation how it should work internally. If you upload a sample stage that could be used for tests (with stageIntroCtrlID already set and BGCtrl coded to display something before the characters have statedef 5900 assigned and internal lifebar counter starts) I think I will be able to handle the implementation.

As for the second part I think the more flexible approach would be treating stage somewhat like a character, so that it can use CNS, AIR, SND files referenced in stage DEF file, which would open gate for proper stage interactivity:
Code:
[Files]
st      = somename.cns           ;States
anim    = somename.air           ;Animation
sound   = somename.snd           ;Sound
With this in place it would be a matter of controlling actual characters behavior via stage cns code instead of depending on fightfx air and tons of new stage parameters. For example if stage has stageIntro = 1 parameter set than characters are not forced into statedef 5900 at the start of the round - they wait for stage to control them and change their state to 5900. Should be doable with my current understanding of the engine (I hope)

Sounds good, I'm going to send you the stage that was shown MangeX's video and the one I initially shown (CVS Pro Train stage and KOF 95 Garou stage). The Train stage for the stage intro (It's not the best example of a stage intro but it is one) and the Garou stage for the water effects and possibly the movement (as shown in the video I first showed for the request https://youtu.be/lTMwD9ybSAQ?t=9m2s ) here is the link to them two http://www.mediafire.com/file/2hj6lnnk7hpihag/stages.rar . I'll see if I can make a mock implementation for the other requests later
I dont what your trying to do but I got my to work for ikemen plus  only problem its the timing adjustment on the intro and timing adjustment on the lifebars rounds setting timer and fight setting timer in the fight.def and stage.def
here a demonstration what I done too it for ikemen plus v0.3



Join My JUSMUGEN Community.
https://jusmugen.forumotion.com/
Re: Ikemen GO Plus
#65  June 24, 2018, 06:24:32 pm
  • ****
  • Pixels are atom's of resolution,Low-res or Hi-res
    • Turkey
    • metekervan26@gmail.com
will sth like this be possible with statedefs? would save so much time
[StateDef 1030]
type = S
physics = N
moveType = A
ctrl = 0
anim = f1030 ;fightfx
sprPriority = 3
Re: Ikemen GO Plus
#66  June 24, 2018, 09:38:45 pm
  • ***
mete122, I can try but only if you upload a test character, fightfx.air and fightfx.sff (that's what "f" refers to?) with the above mentioned code you want to work already implemented (and description how to test it in game).

from what I see it's probably a matter of changing these lines in stateDef compiler code (and stateDef_anim portion of bytecode.go)
Code:
		if err := c.paramValue(is, sc, "anim",
stateDef_anim, VT_Int, 1, false); err != nil {
return err
}
Last Edit: June 25, 2018, 02:19:53 am by K4thos
Re: Ikemen GO Plus
#67  June 24, 2018, 10:10:53 pm
  • ****
  • Pixels are atom's of resolution,Low-res or Hi-res
    • Turkey
    • metekervan26@gmail.com
Will do send sth,but wait doesn't  any change in resolution or fight.def(lifebar) affect fightfx?
any change in this value  inside lifebars fight.def makes this impossible to use unless I resize sprites inside fightfx too,I think,
[fightFx]
scale
So In short screw it.

Can you at least make Interpolation work in fightfx.air tho?
Last Edit: June 24, 2018, 10:16:36 pm by mete122
Re: Ikemen GO Plus
#68  June 25, 2018, 02:18:12 am
  • ***
either way I'm not going to work on it, sorry. It's more difficult to implement (not a matter of using the explode code like I thought). I prefer to spend time on other tasks rather than analyzing the source code trying to make it work.
Re: Ikemen GO Plus
#69  June 27, 2018, 07:42:23 pm
  • *****
    • USA
More Arcade stuff as I wait for the SP support.
Spoiler, click to toggle visibilty
Re: Ikemen GO Plus
#70  June 30, 2018, 06:30:25 pm
  • ***
Some nice progress when it comes to expanding lifebar DEF functionality. Here is what I've already implemented (none of this is possible in mugen from within lifebar DEF):
- BG, BGDef, BGCtrlDef, BGCtrl support (expanded with triggers)
currently supported BGCtrlDef trigger list:
Spoiler, click to toggle visibilty
- optional 8 players support in [Simul Face], [Simul Name]
- new [Tag Face], [Tag Name] sections (if not present vanilla Simul sections are used instead)
- [Round] section now supports more events: Win by normal / Win by special / Win by hyper / Win by normal throw / Win by cheese / Win by time over / Win by suicide / Opponent beaten by his own teammate / Win by perfect
- [Challenger] section ("Here Comes A New Challenger" anim / bg / text, sound and config how soon players should be paused and when to end the match)
- [Simul_3P Lifebar], [Simul_4P Lifebar], [Tag Lifebar], [Tag_3P Lifebar], [Tag_4P Lifebar] - new sections for team 3p and 4p team sizes (matches with up to 8 players) for simul and tag mode, so that we can use different lifebar layout depending on team count
- [Simul Powerbar], [Simul_3P Powerbar], [Simul_4P Powerbar], [Tag Powerbar]  (more than 2 players are used only if "team power share" is disabled in options), [Turns Powerbar]
- [Powerbar] levelX.snd now supports 'pX.' prefix in order to optionally differentiate sounds among players (or to disable them for particular player if paramvalue is set to '-1, 0')
- lifebar changing color depending on health (pX.front.spr / pX.front.anim now can store additional value in the name e.g. pX.front90.spr, which is used to swap the current front spr / animation to this one if player's life matches the percentage value. There can be multiple frontX spr/anim assignments (no hard limits).

Here is an example of a simul 3p vs simul 4p match interrupted by challenger (default lifebar using optional [Simul_3P Lifebar], [Simul_4P Lifebar], [Challenger] sections. Only 2 powerbars and faces because adding more with this lifebar design would look even more silly)


There is still some work to make the lifebar DEF file flexible enough to make convoluted explode lifebars workaround obsolete. Next on the schedule are events like "First Attack", "Danger", "Reversal", "Counter", combo text, guard bar, coloring powerbars etc. It's becoming more and more troublesome to implement this stuff using current  lifebar due to missing art and sounds, so I'm thinking about porting add004 lifebar (which is coded entierly with common1.cns and fightfx - there are like 2 sprites in fight.sff) to normal fight.def file, so that all new features can be showcased (something that can be used as a reference for those interested in working with ikemen GO Plus). I will contact Shiyo Kakuge if he is ok with this.

edit: tagging @GaziraAgain:, since he requested some of these features.
Last Edit: July 02, 2018, 10:13:59 am by K4thos
Re: Ikemen GO Plus
#71  June 30, 2018, 06:38:42 pm
  • *****
    • USA
Open source, says so in post and readme.
Re: Ikemen GO Plus
#72  June 30, 2018, 06:45:02 pm
  • *
  • United Mugen Alliance
    • USA
    • sharingan2anthony@gmail.com
@K4thos: I just wonder... Can copy code from Ikemen lua file to Mugen lua file will work or not? please let me know
Re: Ikemen GO Plus
#73  June 30, 2018, 06:49:01 pm
  • ***
Mugen3Anthony, no it won't work. Either way all the things mentioned in my previous post are coded entirely in ikemen source code, not lua files.
Re: Ikemen GO Plus
#74  June 30, 2018, 06:51:13 pm
  • *
  • United Mugen Alliance
    • USA
    • sharingan2anthony@gmail.com
@K4thos: Oh I see. Thank you for informing me. :)
Re: Ikemen GO Plus
#75  June 30, 2018, 07:48:32 pm
  • *****
    • USA
It's better to do as you suggest as most, even GaziraAgain, have pasted over it with their unique assests. It was setup to be easily customize so anyone could just replace the FX with that of their own. I'm interested in messing with the 3v3 just to experiment.
Re: Ikemen GO Plus
#76  June 30, 2018, 08:48:24 pm
  • ****
    • djjosehisterico@gmail.com
Hey K4thos I read your post and it´s perfect! With all this posiblilities we can do all things present in fighting games. Thank you very much for your effort and waiting some version to test it and start to work with the engine. See you.
Re: Ikemen GO Plus
#77  June 30, 2018, 08:54:27 pm
  • *****
    • USA
I'll make some proof of concepts for you. A triple team and a quadruple team just for the lols
Re: Ikemen GO Plus
#78  June 30, 2018, 09:44:39 pm
  • ***
More Arcade stuff as I wait for the SP support.
Spoiler, click to toggle visibilty
Could you please elaborate which part of the video has those arcade stuff that you've mentioned? If it's rivals matches for arcade mode than it's already implemented. Here's the quote from the latest select.def that explains 2 new character's parameters that handles adjusting general order and match settings: (expanded compared to what was previously posted in this topic, fulfilling your older feature request)
Code:
 ; - 1, 2, 3, ... (rivals)
 ;   IKEMEN feature: The parameter alters standard arcade order system and other
 ;   default match settings, allowing to force pre-defined matches along the
 ;   way. paramname refers to arcade match number (for example 4 = 4th match).
 ;   paramvalue, enclosed in {} brackets, follows the same syntax as adding a
 ;   new character with optional stage assignment and accepts following optional
 ;   char parameters: music, musicalt, musiclife, zoom, ai, winscreen, rounds,
 ;   time, lifebar, onlyme. If 'onlyme' parameter is not set and you're playing
 ;   in team mode the referenced character becomes the opposite team leader, and
 ;   other characters follows order settings. Chars and stages referenced here,
 ;   if not already present in [Characters] and [ExtraStages] sections as
 ;   separate entries, won't be selectable in select screen.
 ;
 ; - maxmatches
 ;   IKEMEN feature: This parameter makes the character ignore default
 ;   *.maxmatches settings under [Options] section and assign different ones
 ;   instead, allowing you to set up custom maximum number of matches to fight
 ;   before game ends in arcade mode, as well as order priority. paramvalue is
 ;   used as a prefix to the original names of these settings, followed by dot,
 ;   so the new entries added under [Options] section should look like this:
 ;   'paramvalue.arcade.maxmatches', 'paramvalue.team.maxmatches'.
------------------------
If you're talking about rival conversations like in SvC than I think it's a nice idea. If you want to speed up its implementation please design exactly how it should be implemented in mugen files - see these posts for design examples:
- http://mugenguild.com/forum/msg.2408370
- http://mugenguild.com/forum/msg.2407725
- edit: http://mugenguild.com/forum/msg.2410361 (actual design for the SvC like conversations)

Same request to others. It's very possible that you guys know more about mugen than me  (for example I've figured out how lifebars works just recently), so please try to elaborate how stuff could be implemented.
Last Edit: July 04, 2018, 08:58:18 pm by K4thos
Re: Ikemen GO Plus
#79  June 30, 2018, 09:46:31 pm
  • *****
    • USA
Nope, man no requests. I'm just playing for fun. I'm just showing you that I am using the stuff you make. More as in I posted a video before, showing the arcade mode stuff you did in action. A visual for what you implement basically. The dialogue stuff can't be done like that anyway, as I want the characters to share the palette they are using, so it must be within the character. This is using the arcade mode to current point that you did.


Because its just a default mugen sp, I cut the inbetween screens and just used a manual win screen. In the other above, thats just an edited video, the fights are still using Ikemen, but in place of the default mugen sp screens I inserted the cvs3 SP just to basically say, "how cool it'd be, if this were a thing" Without a SP, which is the base of everything, nothing else can be done, so I've just been kinda bored with all of this stuff, hence the "waiting on the SP support" comment.
Last Edit: June 30, 2018, 10:03:41 pm by ;x
Re: Ikemen GO Plus
#80  June 30, 2018, 10:21:13 pm
  • ***
Quote
The dialogue stuff can't be done like that anyway, as I want the characters to share the palette they are using, so it must be within the character.
Face sprite and conversation text existing within character doesn't make the feature not viable. It's almost the exact same thing as Victory Quote mugen functionality (that I've finished implementing in Ikemen GO on engine level some time ago), just triggered during fight, right after intro. So the difference would be mostly in different text formatting (since the text should also have data regarding faces, player number). And probably lifebar would be better place for declaring fonts and backgrounds. If Ikemen GO ever becomes a new standard for mugen creators than custom portraits for conversations may become common like Victory portraits are since mugen 1.0 release.

Here is my preliminary design how it could be implemented:

1. lifebar DEF file expanded with new [RivalQuotes] section that has following parameters:
- p1.pos - position that all p1 spr / anim / text elements should start at
- p1.bg - bg sprite / animation (additional subparameters support: "offset", "facing", "layerno", "scale")
- p1.text - stuff related to text from below mentioned [Quotes] section (subparameters support: "font", "offset", "facing", "layerno", "scale")
- p1.name.text - as above but for character's name
- p1.faceX.spr - group and sprite referencing character's sff, for example 9000, 0 (additional subparameters support: "offset", "facing", "layerno", "scale"). X refers to any number which is a value that will be referenced in quote to swap the portrait.
Same for p2 side.
Also general parameters:
- tickspercharacter - specifies ticks per each text character (resulting in total displaytime, e.g. text with 100 characters, and the paramvalue set to 2 would result in displaytime = 200)
- linelength - how many characters should be rendered in the same line before the engine starts rendering the rest of text in the next line
- linespacing - defines pixel spacing between lines
- characterdelay - defines text rendering animation (if set to 0 all text is rendered at once, value > 0 represents ticks before each new character is rendered)
- transitiontime - how many ticks before switching to next text
- keeptext - 0 - P1 text is no longer rendered if P2 starts the reply and other way around. 1 - text is kept until the same player starts new text.

2. character's CNS [Quotes] section expanded with "RivalX" entries (where X is a number which below mentioned RivalQuote state sets) that should be placed alongside normal "VictoryX". The text has to be formatted since it contains information which character speaks (this swaps which pX.bg is used), and which portrait number referenced in fight.def should be displayed. So for example using syntax like this:
rivalX = "playerNo, P1PortraitRef, P2PortreitRef, {displaytext}, ... (same if there's more quotes that follows)"

3. new character's CNS state type "RivalQuote" where you decide which quote should trigger and on what conditions (works exactly the same as "VictoryQuote" state)

Example using Geese conversation from your video:
quote added to Charlie's [Quotes] section:
Code:
rival1 = "1, 1, 1, {Geese Howard. What is your connection with Shadoldo? How are you affiliated with Bison. I'm taking you in for questioning.}, 2, 1, 1, {Geese reply}"
state added to Charlie's cns, for example pre-intro
Code:
[State 190, vs Geese]
type = rivalquote
trigger1 = enemy, name = "Geese"
value = 1
Right after intro the engine would check if player has rivalquote set and start rendering stuff before the match actually starts using fonts and the art declared in lifebar DEF file (or screenpack, not sure which place is better suited for this kind of feature, when it comes to existing mugen conventions).

edit: I've revised the design a little to make the text rendering more flexible with following parameters: tickspercharacter, linelength, linespacing, characterdelay, transitiontime, keeptext. With these there wouldn't be need to specify displaytime of text and using "\n" for newlines would be optional.

The end result would be like this but with full flexibility how the conversations looks like (decided by lifebar creator): https://www.youtube.com/watch?v=4JLK9UxPozQ
Last Edit: July 02, 2018, 09:57:51 am by K4thos