-
Posts
6,420 -
Joined
-
Last visited
Everything posted by Ryon
-
nah, touhou is not my thing. I also didnt finish Reimu. Currently working on Karin from SFA3.
-
make the pausetime 1 tick longer for the helper. pausetime = 6 ,5 and make sure there is a decent value for ground.velocity. this way the will have a second to move after being hit.
-
Yup he still doing big flapjack sally. Welcome back master fu! I bet your suprised I'm still around, Since then dude i've gotten alot better so Your gonna be MORE pleased with my work. all around.
-
i've never perfected it, but i strongly believe its a helper code that pauses everything, and then a explod for the image. OR use the helper for the image. the tricky part is making it pause everything. you can summon a helper by putting in the helper code in the -1 in the CMD file.
-
yeah i mean your character has to display a error code when it crashes. change your volumescale = 100.
-
so you want him to shoot the kiblast STRAIGHT or punch straight?
-
Make Warusaki's characters EX Groove only/Remove or hide bars
Ryon replied to Artoria Alter's question in [ MUGEN CODING HELP ]
the same way we've ALWAYS done it. open the character in fighter factory 3. locate the sprites and completely move them off screen (as in move them down) to the point where they are not visible. -
is this collection strictly for the Megaman Arcade game?
-
something i do in !draw is. i would export 1 sprite from the made character, and open it in !draw once its open i would make a new image in !draw, say 500x500, !draw is a nice program because it keeps the previous image's palette. once i get the new blank image with the palette i need, I would copy and paste the new sprites into the old palette. I STRONGLY RECOMMEND USING THE DEFAULT SPRITE PALETTES, Alternate colors will most likely not work. after i put the sprites in the file. i save the file. then i start to chop the sheet up and then readd the sprites to the SFF. because they now carry the same color.
-
No Return to Standing Position from Others, Even with Required Anims.
Ryon replied to miru's question in [ MUGEN CODING HELP ]
i am assuming she is fine now? -
No Return to Standing Position from Others, Even with Required Anims.
Ryon replied to miru's question in [ MUGEN CODING HELP ]
when you press post just wait till it finishes posting, don't double click the post button. ALSO! does your character have a common1.cns file? without that your character will act funny as you have mentioned. check your def it should look like this. [Info] name = "Undead Hero By Ryon" displayname = "Undead Hero" versiondate = 09/07/2014 mugenversion = 1.0 author = "Ryon" pal.defaults = 1,2,3,4,5,6,7,8,9,10,12 localcoord = 320,240 [Files] cmd = Undead Hero.cmd cns = Undead Hero.cns st = Undead Hero.cns stcommon = common1.cns sprite = Undead Hero.sff anim = Undead Hero.air sound = Undead Hero.snd -
there is no program for that. you need to redo the pallete yourself manually and place all the colors a the bottom. Fighter Factory DOES allow you to drag and drop colors, however it WILL mess up your palette for the character (as everything shifts over)
-
Pitfall of using Remappal to simulate the "Gill Effect" in 1.0
Ryon replied to RicePigeon's topic in [ TUTORIAL LIBRARY ]
Alexei did something strangely interesting with my Demitri. he had every 2 palettes be used on demitri. so pal 1,1, and 1,2 were constantly interchanging and flashing to simulate his flashing aura. and it would only display every 2nd pal. 1,1 1,2 1,3, 1,4 1,5, 1,6 Pretty interesting I think. -
I don't do A.I often but when I do. It doesnt incorporate this. I think im gonna implement this along with seravy's on my next character. (and read it completely later to)
-
THERE IS NONE! Either read it or GTFO.
-
Seravy's A.I. guide from the Mugen Wiki Contents 1 General Information 2 AI activation 2.1 AI activation for winmugen/beta mugen 2.2 AI activation for mugen 1.0 3 Coding AI moves 4 Common/System behavior 4.1 Guarding 4.2 Jumping 4.3 Walking General Information This guide is about coding custom AI for mugen. Custom AI means the character acts the way you program it to, and ignores the default "AI" of the engine completely. This is a very important part in characters because this is the way to make characters more intelligent, making the fight more challenging and interesting. The default "AI" doesn't know what each move is for, and just executes them randomly, more often at higher difficulty and less often on low. This however, makes the character look very dumb, because they don't know such basic things as the range and area of their attacks, so pretty often, they are punching the air, or even worse, use suicide attacks when they aren't supposed to. Creating a custom AI can prevent this kind of behavior, by telling exact rules about when and how to use the attacks. An AI consists of three parts: Activation, Commands, and common/system behavior. AI activation AI activation is the part where we decide when to turn the AI on or off. AI activation for winmugen/beta mugen Pre 1.0 mugen versions don't support custom AI directly, so activating an AI is only possible using workarounds. There were several workarounds for this, each having their own strengths and weaknesses. A quick list of the possible methods were Human Impossible commands Helper method XOR method Ishometeam method Winane's AI activation code combined all four together for optimal performance, however, it is pretty complicated and hard to understand. Improper, simplified implementation of the XOR or Helper methods can have false positives, so these methods are not recommended for beginners. Detecting the difficulty level in older mugen is impossible, so the AI will always fight on a pre-set level instead of what the player selected. Most character make it possible to select this level by directly editing a configuration file of the character, but considering how many characters you usually have in your mugen, changing difficulty level this way, one-by-one for every character is completely unreasonable. This is the main reason why winmugen is outdated, and not recommended: Being able to play on the desired difficulty level is a very basic feature, and the lack of it hurts gaming experience a lot. AI activation for mugen 1.0 Mugen 1.0 and above has a new trigger: AILevel that supports custom made AI properly. By using this trigger in your AI code parts directly, you can create an AI without an activation part or variables. However, doing so is not recommended, as it reduces flexibility a lot, and makes it much harder to scale your difficulty levels, or turn the AI on/off on special conditions when necessary. Generally, you'll need two variables for your AI activation. The first variable is the AI variable itself. If it is set to 0, your AI is off, and if it is 1, it is on. Other values can be used if you want multiple AI modes, like a special boss mode for example. The second variable is the difficulty variable. This variable is responsible in determining the chance for attacking: higher values would attack more often, while lower values attack less often, making the AI's reaction time slower, and closer to a human player's. The two can be stored in one variable (0= AI off, 1-1000 =AI on with difficulty chance stored) if you want to save variable space. Example code below, it needs to be placed into one of your minus states: Numbers here correspond to the chance for attacking from 1 to 1000. Higher number means less reaction time. Lower number means more. Linear distribution of difficulty (using AILevel*10 for example) is not recommended. Numbers below 10-15 will make the character attack rarely, making the AI play weaker than a human. These values are recommended for the first two (easy) difficulty levels. Numbers around 20-50 are causing the AI to fight more like a human player, attacks will usually have a bit of a reaction time, but generally, the AI will not stay idle for too long and will fight actively. Numbers over 50-100 will reduce the reaction time of the AI significantly, and 1000 completely eliminates it. 1000 will also make the AI perform the first matching attack in each situation unless coded otherwise. These values are recommended for hard (6-8) difficulty levels only, as the reaction time is way faster than what a human player has. Using numbers above 300 is not recommended, as it doesn't make the AI any harder, but it does make it more determined/easier to predict. Average reaction time in ticks for various var(50) values, assuming a situation when only one attack is matching the triggers and is available to use (the current tick not included): 1000 - 0, always attack immediately with the first matching attack 900 - 0.11 tick 800 - 0.25 tick 700 - 0.42 tick 600 - 0.66 tick 500 - 1 tick 400 - 1.5 ticks 300 - 2.33 ticks 200 - 4 ticks 100 - 9 ticks If we consider the human reaction time to be 1/6th of a second which is 10 ticks, then it is clearly visible that any values over 100 are way too fast against a human player for normal levels. Especially as in normal cases, multiple attacks are available for the AI, further reducing the reaction time: 2 available attacks mean half reaction time on average, three means a third, and 10 means a tenth of it only, so the zone over 100 is really meant for hard to impossible difficulty levels. As visible from this, there is basically no difference between values over 500 at all, so linear scaling fails the most in that area: the attacks get 0-1 tick of delay most of the time. Below 100, the reaction time increases non-linearly: 90 - 10.1 ticks 80 - 11.5 ticks 70 - 13.2 ticks 60 - 15.6 ticks 50 - 19 ticks 40 - 24 ticks 30 - 32 ticks 20 - 49 ticks 15 - 65 ticks 10 - 99 ticks 9 - 110 ticks 8 - 124 ticks 7 - 141 ticks 6 - 166 ticks 5 - 199 ticks 4 - 249 ticks 3 - 332 ticks 2 - 499 ticks 1 - 999 ticks making it an ideal range for easy and normal difficulty levels: values below 10 have a reaction time of an entire second to many seconds, while values over 15 have 1 second or less, making it ideal for normal difficulty. Note that characters having more attacks available per situation need slightly lower var(50) values than characters with fewer ones, so in most cases, only the half/third/fourth of this reaction time applies in reality for those situations. Overall, for easy levels, take numbers from the 1-15 interval, for normal, take ones from 10-50, and for hard, take from 50-200 as a general advice. Characters with more moves or better/more versatile moves will generally need lower values like 1-10 for easy, 10-30 for normal and 30-100 for hard. Do note that "reaction time" here means time spent doing nothing before deciding what attack to use, not time spent idle after deciding to use an attack. Also note that all of these are average values: since random is used, there is always a chance for any amount of reaction time from zero to infinite, but during a whole match duration, these even themselves out. To implement an AI that has a real, human like reaction time (delay between deciding on an attack and using it), a more complicated and advanced system is necessary, where you use a timer variable and buffer the attacks that need to be executed, although I don't see much of a reason to go that far: if you want your AI to mess up and use attacks at the wrong timing, you can do that in an easier way by adding low level specific triggers to your attacks, instead of simulating a reaction time. Coding AI moves This is the part where you tell the AI when and how they are supposed to use the moves available. It works pretty much the same way as for the player, except for the conditions themselves. They are changestates that need to activate when the AI wants to use the move, and are placed in state -1. They can be placed in state -3 as well, but placing them into -1 makes more sense. These are pretty much the AI equivalent of a human player's command input. First of all, while the AI is on, we must disable all human player commands from working. The engine spams player commands (this is how the built in AI of the engine works: it simulates commands coming from the keyboard), and we don't want these to have any effect on our character. To do this, add Triggerall=var(59)>0 to all of your regular command changestates. Then, to make the AI able to use the commands, you must make a copy of that changestate, remove the conditions limited to human players (this almost always only means the command="xxx" lines), and add new ones for the AI. An example: This is a command block for a human player, it describes a super move that can be used when at 3000 or more power, and below half of maximum life while standing and having control, or as a combo after an attack coded in state 1000. The AI equivalent would be You can also merge the player and the AI command activation into a single command block, like this: If you code your AI using the same merged block for human and AI commands, updating conditions on the attack is easier. For example if you want to reduce the cost from 3000 to 2000, or update the attack so that is also works when used in the air, or want to add it as a combo after different attacks, you only need to change it in one place instead of two. This not just reduced your future work, but also eliminates a possible inconsistency: if you update one of them and forget about the other, you might end up with an attack that works under different conditions for the player than the AI unintentionally. Common/System behavior There are a few things a character do without using a move defined in the cmd, and these are: -Jumping -Guarding -Walking If we want to have control over these the way we have over normal attacks, we have to code for it. Guarding To make the AI guard properly, two steps are necessary. The first is a changestate in state -1 to enter the guard states when we want to. This one works well: Adding Trigger=!Inguarddist to AI attacks greatly helps against taking unnecessary hits, and increases chance of guarding the attack some ticks later if the guarding chance didn't trigger yet (but still fast enough against slower attacks).. Without that, the character will start to execute an attack, and end up getting hit too often, making the AI to dumb. This makes the AI behave like a player, the slower an attack is, the higher the chance that it will be guarded. Generally, you will want to have this line on all of your AI attacks except light punches or other very fast moves, or moves with invincibility. The other part of an AI guarding is keeping the AI in the guarding states long enough, and making it go to the appropriate one for each situation. You need to override all the guard states for that. If you don't want to change the conditions on which the AI changes from crouch to stand guarding or back, you can use the code below: The reverse, making the character not jump when the up button is pressed, or at least limiting how ofter that happens (default AI likes to jump way too often, which makes fights annoying) can be done by overriding state 40: Note, that if you do not want your standing animation to get restarted from frame 0, you need to change your anim=40 line into a changeanim placed below the changestate to state 0 Walking Usually, there is no need to code for walking for two reasons. If you want your AI to move closer/further, you'll use the running moves instead, as most characters have those. Walking is less optimal than running. The walking done by the default AI doesn't hurt character performance either, so there is no need to disable it usually. At least the character does something when idle for a long time at low difficulty levels instead of just standing. This guide was created by Seravy.
-
i do not understand WHAT you are asking to do. or what you want to do.
-
How to make/sprite/draw/add a winquote screen?
Ryon replied to Gaulbetti's question in [ MUGEN CODING HELP ]
ok if you can't draw in real life, it isnt gonna happen now. i recommend reusing the select screenbackground for the winner screen. ..... as per how to code it. its so simple for me to do, its super hard to explain it to others especially when they have no knowledge of coding. i recommend just looking in the system.def and scroll to the bottom you will see stuff related to the victory screen. notes as well. -
Goooooood luck!
-
Reducing the size of Portrait.
Ryon replied to Krypto 'SAM' saiyaN's question in [ MUGEN CODING HELP ]
ok WHY are you even messing with portraits like that? your screenpacks should just scale the portraits to fit. messing with the localcoord of the ENTIRE CHARACTER just for the portraits is a ridiculous idea. -
graphically it may be a mess. but other wise locate the starting state for said moves. and then look to see if its a variable that counts the time, just set it to a higher number.
-
i'd rather rip it picture by picture the old fashion way if thats the case. i would hate to go line by line. now as for palette, you should download the program !draw3, and open the image in that program if that program can read it, then you know for sure its a proper indexed image. cause you may save it as a indexed image, but how can you REALLY check if its indexed when you close it from gimp?
-
it works. but your image needs to be 256 color BEFORE hand and PNG format. BMP format images DO NOT guarantee you have a palette. the only problem I have with Alfred Unpacker is that it sorta randomizes the order of the sprites when it cuts em out. which to me is hella freaking annoying cause now i have to reorganize and find sprites.
-
Funny think you ask! I have a tutorial on making high quality big portraits from fancy pictures. HOWEVER YOU SHOULD NOTE! THIS VIDEO IS FOR GENERAL BIG PORTRAITS NOT TEMPLATED PORTRAITS. BUT THE SAME IDEA AND PRINCIPAL.
-
yeah basically you solved the second part. GOOD JOB!