Hi.I have opened a new section on my site where I will be sharing notes of several things I have studied over the years. The first article is about cornerpush and how commercial games compare to the way MUGEN handles them.It is a nice read and hopefully it'll help to improve understanding how cornerpush works in fighting games.My site.If you have any suggestions, questions or whatever just post it here. I will keep you guys updated when I post something new.
Mugen's cornerpush has something else that bugs me. Namely it will ONLY kick in if p2 has his back to the wall when hit. Basically something that would normally only be capable of hitting twice is now able to hit 3 times. I dunno if it's me, but in commercial games it generally applies a lesser velocity to you if p2 is pushed into the wall as well. Like if the whole gap should be 24 pixels, you both move 12, your 12 occuring once p2 hits the back wall.Is that correct? I might be seeing things.
Yeah, that's another thing MUGEN doesn't do correctly. The game basically starts applying the same velocity player 2 after he touched the corner, keeping the same exact calculations and everything. Let's say that if Ryu hits Ken with a fierce punch and Ken is supposed to be 110 pixels away from Ryu at the very end of the hit. If Ryu's attack connects while Ken is almost at the corner then Ken will cover a small distance which is subtracted from the total (110 pixels), after that it's Ryu's turn to cover the rest of the distance via the cornerpush.
So, I might have some free time in the next couple of weeks, so I'll try to write a couple of tutorials during this time.My plan was to write about:- On learning: why it's better to fail than to ask.- Thought process for hacking with artmoney- On coding technique and etiquette.- An introduction on how to code MUGEN systems to deal with complex tasks....In order of priority from top to bottom. I've seen a lot of interest in artmoney as of late, and I think it's about time someone writes a proper text on how to actually use the damn thing. JNP's tutorial is outdated, confusing and it only serves as an example on how to use his tables for ripping.The second to last article is mainly geared towards beginner and intermediate coders, I've seen many coders skip over some very important steps in the learning process of CNS. I plan to cover some of the most general and advanced "tricks" and why you should be looking out for ways to optimize your code.The final article will deal with complex CNS coding and going beyond the regular limits of MUGEN. This is geared towards experienced coders.I will try to outline what the best way to design a system for MUGEN is, as well as the way it should be laid out and documented.This last article will include one of my code-heavy CvS:CC systems as an example. Any suggestions as to what else to cover in any of these articles? (or if I should write about something specific?; maybe another article?)
I like the first one. Too many people have the idea that their code should work first time with no bugs ever. It is far better to have something break and work through the troubleshooting process.
Oh, those are great. I didn't even know that existed.I will make sure to link back to those in my site as well.
A small update: I have finished writing the articles in-between classes, and I will be posting them after I'm done transferring them (I had to write these on paper).Hopefully the first one will be up this Sunday.
I will be uploading my artmoney tutorial in a couple of hours, please wait for it!Also, I would like to open up a new section in my site called "Free Q&A". In this section, I will answer your development questions regarding code etiquette, techniques or even just understanding my code (I know a lot of my stuff might be a little overwhelming).You may send me an e-mail too if you don't have an account here, just check the details on my notes page.You may use this topic to ask me anything, once I answer a question it'll be posted on the site. Please, feel free to ask anything that is on your mind, I will try to answer as best possible.
Alright everyone, double post and all, but it's an update.My ArtMoney notes are now up in my blog. You may find them under Notes => An Introduction to Memory Hacking with ArtMoney.If there's any questions, please feel free to ask.
I can't stress enough some stuff that every Artmoney should have, but few mention.For experienced Artmoney users this is a given, but newbies may have some hard time getting their downloaded tables to work.First of all, some emulators use dynamic memory addresses. This results in loading a table in Artmoney and then values don't match the game. In order to get the table working, it is required to calculate the offset difference and apply it to the rest of address. I usually use an easy-to-find value such as score, credits or character choice. Search this value and then apply the offset to all the rest. This is the first step you must when loading a new table.Tip #2: Some addresses use non-volatile addresses, but others are in fact volatile. What does it mean? It means that your Pos X value will always work, but perhaps the life value that was working yesterday, will no longer work the day after. This is due that the life value you had found was a volatile one. In other words, it will always change every time the game is running. What can you do to solve it? You have to find the real life address, a non-volatile one. With some experience, you will realize that volatile addresses are outside the region of the rest of addresses. For example, good addresses will be in the range of 0E280000, but a volatile address will be in the 0D1D0000. Anytime you find a value outside the main region, you can bet it's a volatile one.Still volatile values have some use though. They provide information about the game internal engine and may provide details on how data is structured. But in practical terms, you can't use them.Tip #3: Artmoney lets you scan all memory addresses from the game, so basically, whatever the game can do, you can find it on Artmoney. Think outside the box!!!! Don't limit yourself to just finding the life values and the position of your character.My Artmoney tables usually have about 300 or 400 addresses. I have found values that range from background layer disabling, collision box information, debug modes enabled, animation/action/sound test player, text displayed on screen, RGB components, Explods removal... you name it. Arrange your data by description and assign different groups for easy filteringTip #4: Rely on other sources!!! MAME Cheats are a good complement for it. Use existing cheat codes to help on your Artmoney findings. Most popular games have tons of codes that will save you the work from finding them on Artmoney. Also, sometimes it's easier to do the reverse. Values that you have found in Artmoney can be compiled into a MAME cheat file which will facilitate things. For example, background removal in a particular game consisted in removing each sprite from screen, about 40 addresses in Artmoney that I had to modify one by one. For me it was easier to create a MAME cheat with all these changes and applying it was as fast as a one click operation (think of it as a macro). You may need to calculate the offset difference between MAME and Artmoney though for this trick to work.Tip #5: Research. Do a in-deep research on the game, the emulator and the system. Are there debug rooms or hidden gems in this game that may be helpful? Can I get the sprites directly from a Sprite test mode, or do I have to rip them in-game? Is there a Sound test mode, or do I have to record the clips in the middle of the round? Can I get the data using external tools directly from the game files? Would it be better to hack/mod the game files and then run them on the emulator? Are there any FAQ or gamesave with additional content unlocked?
Vans said, April 21, 2012, 05:26:38 amI know a lot of my stuff might be a little overwhelmingI took some stuff from you, and everything was very well documented and labeled correctly.But hey, if people still don't understand, it's cool you'll explain then.
You think?It's just that I keep reading my code is uses a whole bunch of "useless" calculations and variables for something so "simple", and it's really starting to bum me out. I don't want people to have the wrong impression before reading my code.The very most I've used is 38 int variables and 8 flt variables. And this is counting helper bound variables, and I use a whole bunch of those.Whenever I write something I have two goals in mind:1. I want it to be transferable. I always try to make code that can be easily copy-pasted without much modification.2. I want it to be compact and self-contained. I don't like having code all over the place, so I try to have it all together in one place so it can be read.Even when I was coding systems for CC I always kept in mind someone else might need to use my coding, so I made those even easier to use.So I dunno, I'm puzzled.My code wouldn't be good reference for anybody if it can't be read, so this worries me quite a bit.
Vans said, March 05, 2011, 02:10:59 amHi.I have opened a new section on my site where I will be sharing notes of several things I have studied over the years. The first article is about cornerpush and how commercial games compare to the way MUGEN handles them.It is a nice read and hopefully it'll help to improve understanding how cornerpush works in fighting games.My site.If you have any suggestions, questions or whatever just post it here. I will keep you guys updated when I post something new.What happen to your site? I can't access...
