YesNoOk
avatar

MFG's suggestion list for new Mugen coding features (Read 41377 times)

Started by PotS, September 24, 2009, 12:02:50 pm
Email this topic
View printable version
Share this topic:
« previous next »
Page 1 of 51 2 3 4 5 > Last →  All   Go Down

PotS

MFG's suggestion list for new Mugen coding features
#1  September 24, 2009, 12:02:50 pm
  • ******
    • Portugal
    • network.mugenguild.com/pots/
How about it?  We could compile and filter a list of our own here, then submit it to their forum all neat and tidy and saving them (some of) the trouble of seeing the same thing suggested n times.
Note that this only has to do with coding features, whatever gameplay/config suggestion you have in mind was probably already requested a dozen times at their forum (online, tag, etc).

I'll start with all I could think of right now, and will try to keep this first post updated with all suggestions.


Characters

- Stage name and authorname triggers

- RootVarAdd and RootVarSet sctrl's

- New trigger that generates a random integer/float between the range specified, to replace the usage people have developed for the Random trigger.  For instance, and calling it RandomVal here, RandomVal(-4, 8) would return a random integer between -4 and 8, and RandomVal(1.0, 5.5) a float between 1.0 and 5.5.  Note that this would not make the Random trigger obsolete

- "Unlimited" variables, and/or the possibility of naming them with strings (e.g. var(mode)) for easier reading.  If the way Mugen is set up requires characters to start out with reserved variables, then just increasing their number would be fine, there have been people struggling to keep everything in 100 variables heh.

- Make BindToTarget use the target's velocities instead of the player's.  Currently if you try to bind to a moving target it will stop moving.

- Cornerpush behaviour lifted from the standard fighting game model, i.e. P1 will be pushed back not only if P2 was hit in the corner, but also if P2 was hit into the corner.  This usage could be flagged in a new parameter flag as to not affect older characters

- Friction to apply upon getting hit should be received from a Hitdef parameter, not a constant from the character. Such parameter would default to 0.85, the KFM and by far most common friction value.

- Hitspark scale and angle parameters in Hitdefs.  You'll notice that most custom hitspark systems people have used throughout the years were made to get around these two limitations.  If rotation takes too many resources then just scaling would already be great.

- Hitspark particle effects in Hitdefs, like what you see in Capcom's PSX ports or newer games like CFJ.  This would need three parameters I think, one for the animation to use, another for how many particles to generate (capping this somehow would be nice), and another for the velocity ranges. Last parameter would probably actually need to be broken up into two or three (base velocity, velocity range and velocity multiplier).

- As an alternative to the two last points, a "sparkstate" parameter that creates a helper in the state specified upon movecontact.

- Hitsound/guardsound channel parameter

- Different handling of sparkxy, where both values are offset from P1 and the x determines the maximum distance at which the spark can appear.  Alternatively, for compatibility's sake, a new spark parameter that adds that maximum distance to sparkxy.

- A Sctrl to change the character's small portait sprite, useful for transformations or reactions when attacking/getting hit.


Stages

- Possibility of randomizing events like with characters.  In fact adding a state system to stages could tremendously expand their possibilities, or at the very least cut back on the workarounds people have found themselves forced to do

- I find myself often tiling a black square to fill some stages and preventing that mirror effect, it would be nice if Mugen simply allowed you to choose a background color to use behind all the elements.  Kinda like how debugbg adds pink.

- Vertical parallax.  I don't mean the same as the already existing yscaledelta feature, but rather something like what an x axis floor parallax rotated at 90º would look like

- On a similar note, horizontal "yscaledelta" (xscaledelta I suppose).  Having this feature and the above on both axes, instead of one for each axis, would make 3D effects a lot easier to accomplish in some cases
You can help with Ikemen GO's development by trying out the latest development build and reporting any bugs on GitHub.
My Mugen and Ikemen content can also be found here.
Last Edit: September 24, 2009, 03:00:43 pm by PotS

c001357

Re: MFG's suggestion list for new Mugen coding features
#2  September 24, 2009, 12:14:02 pm
  • *****
  • ロッキングガール
  • 「目指すはクールでロックなアイドル！」
    • twitter.com/c001357
how about a juggle system that works

RedLunchbox

Re: MFG's suggestion list for new Mugen coding features
#3  September 24, 2009, 12:40:11 pm
  • avatar
  • **
An excludefromsurvival=1 parameter in the Select.Def, to prevent some characters (such as Bonus Stages) from appearing in survival mode.

Also, if we're going to have a Sctrl that chages a character's small portrait, then we need a trigger that returns the character's small portrait, to prevent issues that could happen with KOFXI and other screenpacks that use different small portraits.

Rajaa Retired

Re: MFG's suggestion list for new Mugen coding features
#4  September 24, 2009, 12:57:50 pm
  • avatar
  • ******
    • Thailand
Characters

- Multiple re-directions triggers:  "Parent, Target, stateno = [150,159]"


The only thing I can think of now. >_>

Loona

Re: MFG's suggestion list for new Mugen coding features
#5  September 24, 2009, 02:06:00 pm
  • avatar
  • *****
  • Nothing ever ends
    • Portugal
    • www.justnopoint.com/loona
Something that allows you to create a helper that can use an opponent's states and animations, even if only from the opponent's helpers (UseTargetHelper ?...) - essentially, something to make it simpler to reflect projectiles, if current workarounds aren't completely convoluted.

PotS

Re: MFG's suggestion list for new Mugen coding features
#6  September 24, 2009, 02:29:24 pm
  • ******
    • Portugal
    • network.mugenguild.com/pots/
A few more from me to add to the first post later:
- The pixels cut from stages when changing to widescreen mode should be added to boundhigh.
- Fix defencemulset, it's not working for the first hit of a combo
- Helper sctrl parameter that makes it share the root's or parent's juggle points
- Two Hitdef parameters to handle juggling: one specifies how many points it needs to connect (can port the projectile airjuggle to characters), the other how many points to subtract when hitting
- New Hitdef parameter: air.juggletime, specifies for how long after the hit the target is jugglable (most notably present in KOF juggling). Defaults to -1, infinitely
- Allow strings like hitflag to accept ifelse expressions

GigaBowserX said, September 24, 2009, 12:40:11 pm
An excludefromsurvival=1 parameter in the Select.Def, to prevent some characters (such as Bonus Stages) from appearing in survival mode.
How about just a setting under [Options] to specify which order numbers to skip in survival? To keep things tidier I mean.

About the portrait, I probably should remove that for now, until they start adding sprite triggers.  In fact should list that one instead.

Edit: At this rate I think I'd have them end up with 200 HitDef parameters. ;P But they're the most important Sctrl afterall.
You can help with Ikemen GO's development by trying out the latest development build and reporting any bugs on GitHub.
My Mugen and Ikemen content can also be found here.
Last Edit: September 24, 2009, 02:35:01 pm by PotS

aokmaniac13

Re: MFG's suggestion list for new Mugen coding features
#7  September 24, 2009, 02:43:01 pm
  • ******
  • Just a butcher on a mission
    • www.justnopoint.com/lbends
Quote
- I find myself often tiling a black square to fill some stages and preventing that mirror effect, it would be nice if Mugen simply allowed you to choose a background color to use behind all the elements.  Kinda like how debugbg adds pink.
But debugbg also gave a performance hit to people with less than stellar computers or when used in complex stages.  Rather than drawing every frame over what's already in video memory, you're adding an extra "fill the screen with a color" step.  It's always a better idea to fix the holes yourself.  Considering how slowly mugen runs in HD for most people, any way to improve performance is worthwhile.

Quote
- Possibility of randomizing events like with characters.  In fact adding a state system to stages could tremendously expand their possibilities, or at the very least cut back on the workarounds people have found themselves forced to do
Totally agreed, the ability to spawn helpers would be especially helpful (no pun intended).

Quote
- Friction to apply upon getting hit should be received from a Hitdef parameter, not a constant from the character
Sounds good in theory but if you don't want to be using a constant velmul you'd still have to implement a custom friction system in the character getting hit, which negates the purpose.  I can't think of any games that handle friction the way mugen does.

Quote
- Stage name and authorname triggers
Screenpack detection and team mode partner names would be good, while we're at it :P

PotS

Re: MFG's suggestion list for new Mugen coding features
#8  September 24, 2009, 02:52:04 pm
  • ******
    • Portugal
    • network.mugenguild.com/pots/
Debugbg: Was hoping that such a feature, if tuned, would only replace that filling step and not be as demanding as the perhaps halfassed debugbg.  I mean, how much processing can a solid color take?

Friction: Am assuming common states would be updated with "velmul gethitvar(friction)".  And even with the custom finetuning necessary to get it as close to whatever game as possbile, it'd always be better than being stuck with 0.85 (and that's when people don't ruin that).
You can help with Ikemen GO's development by trying out the latest development build and reporting any bugs on GitHub.
My Mugen and Ikemen content can also be found here.
Last Edit: September 24, 2009, 02:55:20 pm by PotS

O Ilusionista

Re: MFG's suggestion list for new Mugen coding features
#9  September 24, 2009, 03:33:36 pm
  • ******
  • A living Mugen dinossaur :)
  • 23 years of Mugen O_o
    • Brazil
    • www.brazilmugenteam.com
String vars could be good, for sure.

but how about functions? like

function hadouken(void){
bla bla bla bla
bla bla bla
}

then you call just haodouken,withou all proj specs and avoiding making a helper for that.

- Stages having codes like chars.

Bastard Mami

Re: MFG's suggestion list for new Mugen coding features
#10  September 24, 2009, 03:38:53 pm
  • ******
  • [E]
    • Mexico
before suggesting stuff I will wait until more fix is shitted, since I am curious on what is ebyte's direction with this version of mugen.

PotS

Re: MFG's suggestion list for new Mugen coding features
#11  September 24, 2009, 03:44:34 pm
  • ******
    • Portugal
    • network.mugenguild.com/pots/
I was hoping to post such a list not so soon either, but rather when things calm down over there.  Their suggestions board is already pretty scary as is.
You can help with Ikemen GO's development by trying out the latest development build and reporting any bugs on GitHub.
My Mugen and Ikemen content can also be found here.

O Ilusionista

Re: MFG's suggestion list for new Mugen coding features
#12  September 24, 2009, 03:45:52 pm
  • ******
  • A living Mugen dinossaur :)
  • 23 years of Mugen O_o
    • Brazil
    • www.brazilmugenteam.com
explaining better my idea:

function hadouken(ID){
bla bla bla
ProjID = ID
bla bla bla
}

Then, you could call:

Quote
[state 0,0]
Type = function
Trigger1 = !Time
Value = hadouken(1000)

Bastard Mami

Re: MFG's suggestion list for new Mugen coding features
#13  September 24, 2009, 03:46:33 pm
  • ******
  • [E]
    • Mexico
what about we think about stuff that shuld be easy to add ?

O Ilusionista

Re: MFG's suggestion list for new Mugen coding features
#14  September 24, 2009, 03:49:55 pm
  • ******
  • A living Mugen dinossaur :)
  • 23 years of Mugen O_o
    • Brazil
    • www.brazilmugenteam.com
And that is difficult? I think not. Its just logic, already similiar of C#, Javascript, JAVA or whatever.

Dr. H

Re: MFG's suggestion list for new Mugen coding features
#15  September 24, 2009, 04:15:42 pm
  • ***
  • Master of Vicodin
Air:

CLSN 3 (Optional):

A clsn for throws only. You could skip that if you want by setting some parameter in "Data".

Constants:

[Data]
Dizzy = How much points of Dizzy resistance a character has. Once it reaches 0, character gets dizzed. Damage to be specified in hitdefs.
Dizzy.Recover.Time = Time in ticks that the character has to pass without getting into movetype = H to start recovering his dizzy points.
Dizzy.Recover.Rate = Time in ticks that characters will recover their dizzy points. Ex. in every 5 ticks 1 point is restored.
Dizzy.Recover.Value = How much points of dizzy will be recovered.

Guard.Crush = How much points of Guard Crush resistance a character has. Once it reaches 0, character gets their guard crushed. Damage to be specified in hitdefs.
Guard.Crush.Recover.Time = Time in ticks that the character has to pass without getting into movetype = H to start recovering his guard resistance points.
Guard.Crush.Recover.Rate = Time in ticks that characters will recover their guard resistance points. Ex. in every 5 ticks 1 point is restored.
Guard.Crush.Recover.Value = How much points of guard resistance will be recovered.


States:

P2LifeAdd

Could be used to simulate poison effects and the likes.

[State -2]
type = P2LifeAdd
trigger1 =
value =
ID =
kill =
supermove =
pausemove =
damage.time = Time in ticks that characters will be damaged. Ex. in every 5 ticks.

Notes: Some kinda of sctrl to null this ctrl should also be added, something in the same lines of removexplod.
ReversalDef

New parameters that could revert projectiles.

[State 0, ReversalDef]
type = ReversalDef
trigger1 =
reversal.attr =
pausetime =
sparkno =
hitsound =
p1stateno =
p2stateno =
ignorehitpause =
persistent =
projrevert = ;Positive number means that magic shield is on.
projrevert.velocity = ;Pretty obvious, velocities to aplly. if omitted, uses current reversed velocities.
projrevert.accel = ;Duh.
projrevert.velmul = ;Yep.

Notes: Could aswell as pair any other "Projectile" sctrl parameters to override current ones. Ex: if you add the line damage = 90, then it'll damage for 90 points no matter how much the original did.
RemapSff

A better choice than SFF swap IMO, since you only need the required sprites to be updated and that would avoid loading times issues, etc.

[State 0, RemapSff]
type = RemapSff
trigger1 =
source = 5000,0
dest = 6000,0
source2 = 5000,10
dest2 = 6000,10

AssertSpecial

More parameters, like:

NoIntroSkip: Self explanatory, the current way mugen handles it is a bit ugly.
NoWinSkip: Same.
Explods:

A new parameter:

affect.by.envshake = A positive number will make it be affected by envshakes.

Loona

Re: MFG's suggestion list for new Mugen coding features
#16  September 24, 2009, 04:17:54 pm
  • avatar
  • *****
  • Nothing ever ends
    • Portugal
    • www.justnopoint.com/loona
.(O). said, September 24, 2009, 03:45:52 pm

Then, you could call:

Quote
[state 0,0]
Type = function
Trigger1 = !Time
Value = hadouken(1000)


It'd be more useful if you could input some parameters to contemplate variations (ex: light, medium and strong versions).

PotS

Re: MFG's suggestion list for new Mugen coding features
#17  September 24, 2009, 04:22:06 pm
  • ******
    • Portugal
    • network.mugenguild.com/pots/
Stuff like guard crushing implies a lot of updating old chars or even new sprite standards (that a small minority of games even uses), I think stuff like that ReversalDef (though could be a new Reflect sctrl) and AssertSpecial parameters is what we should be suggesting.  At least anywhere in the near future.


Edit, more:
- Specify how much power should a full powerbar represent, i.e., if you set such a setting to 1000, the powerbar will fill normally until you get power=1000, then empty and restart filling until you get power=2000, and so on.  -1 would be the default and mean that it'd work as it currently does, with full bar being whatever the player's maximum power is.
- Related to the above, could have different bar animations for each of those filling stages
- In addition to the sounds that play each time a level gets filled, have an option to generate an explod on the bar when that happens.  This made keeping track of power easier in SF4
- Updated behaviour of the fall/air.fall parameter in HitDefs, where 1 makes the target always fall, 0 makes it always land on its feet (key difference here), and -1 is the default which results in no change to the HitFall parameter.
- Combo ranking (Good! Marvelous! etc). Should be easy enough.
You can help with Ikemen GO's development by trying out the latest development build and reporting any bugs on GitHub.
My Mugen and Ikemen content can also be found here.
Last Edit: September 24, 2009, 04:34:56 pm by PotS

Bastard Mami

Re: MFG's suggestion list for new Mugen coding features
#18  September 24, 2009, 04:29:07 pm
  • ******
  • [E]
    • Mexico

Keku

Re: MFG's suggestion list for new Mugen coding features
#19  September 24, 2009, 04:37:42 pm
  • *****
  • EL FUCKO GRANDE
  • I'm back, nerds
    • Canada
Lifebars

-Vertical lifebar support
-Number support for health and super gauges
-Possibility of making the gauge reach its maximum length for 1 level, and then return to its starting point (kinda like 02's gauge, for example)
-Score system support and fonts (for novelty)


General

-Changeable FightFX scales

tunglashor

Re: MFG's suggestion list for new Mugen coding features
#20  September 24, 2009, 04:38:51 pm
  • ***
  • Snake Man
    • tunglashor.webnode.com
An idea regarding AI logic:  the new aiLevel trigger is great in that it allows AI to be coded with regards to the difficulty setting.  But it still means adding this trigger to every AI move state (and ideally to every non-AI state, to prevent the AI randomly executing those states).

So how about adding a new special statedef, say StateDef -4, which is only checked for cpu-controlled players.  Then you could just put your AI states there and the AILevel trigger would only be needed for checking the difficulty, where required.
Page 1 of 51 2 3 4 5 > Last →  All   Go Up
« previous next »