Skeetendo

’Cause all games were better on the GBC

You are not logged in.

#1 2016-06-28 09:21:39

JudgeWargrave
Member
Registered: 2016-06-28
Post 1/18

Wargrave Tools 2.0, now on Github

Update: Version 2.0

Download 2.0, updated 2017 March 10
Github repo

---


Tools already exist for these three categories, but I wasn't able to find any I was totally satisfied with (bugs, inconvenient data entry, incompatible with GS or C, lacking features, not self-explanatory etc) so I decided to get some experience with windows forms and make my own tools. This forum has provided me with a lot of good knowledge and tools so I figure I should provide something back and post them.

Download (zip file containing all three)

Moveset Editor

http://i.imgur.com/OtMR8mP.png
http://i.imgur.com/yFGjPDN.png

29KB

Reads Pokemon and move names from ROM:
        if you edited either, the tool will respect your changes

Easily change, add, and delete moves, up to 29 per Pokemon.
Displays remaining free bytes.
        (one is very unlikely to run out of space, but just in case)
Parses a text box rather than having copious dropdown menus. This has many advantages:
-Fewer clicks
-Add or delete anywhere in the list.
        Simply enter the level number and move name with a TAB between
        If any lines are not formatted this way, or moves misspelled, it will show INVALID and not save changes
        Don't have any blank lines
-Copy and paste!

View and edit three Pokemon simultaneously
Contiguous mode (auto consecutive Pokedex order) can be toggled
Easily compare movesets within an evolutionary family
        including lines such as Slowpoke - Slowbro - Slowking, Magby - Magmar, etc
        or similar Pokemon such as Venusaur / Charizard / Blastoise, Venusaur / Meganium, etc

Change TMs and HMs learned
Copy TMs and HMs from central Pokemon, saving clicks when editing an evolutionary family

Limitations
        No move tutor or egg move editing
        I don't plan to edit these in my own project so I didn't equip the tool for them
        Unless people really want these I probably won't put these in

Move Editor

http://i.imgur.com/B4w3MW9.png

43 KB

Freely edit move names and descriptions
Detects how many free bytes remain for each
        Really only an issue in Crystal, but it definitely is an issue in Crystal.
        You can reduce Struggle and a few less distributed/useless moves like
        Bone Rush and Conversion2 to a single character to free space.
Move names are limited to 12 characters
        limitation of the game, not the tool, but the tool will warn you
Descriptions length is not checked by the tool but use your best judgment to get them to display well.
        | marks a new line

Edit all seven bytes of the data structure and toggle high crit ratio
Type, Power, PP, Accurary, Crit: self-explanatory
Effect: e.g. flinch, recoil, Hyper Beam recharge, etc
        Nearly all effects are given clear description, including a few that
        the vanilla game has but doesn't use, like +2 Special Attack
Effect probability (e.g. 9.8% on Thunderbolt for paralysis)
Animation
        This feature is fairly limited
        Can't make new animations, just reuse old ones
        e.g. Create Drain Punch in place of Poisonpowder with the Mega Punch animation
        The animation type may be displayed in the battle menu
        e.g. Normal instead of Fighting in the above example
        However the move really will be Fighting and displayed as such outside of battle
        As this changes the move ID, which some moves like Mirror Move use, this may introduce bugs
        See this thread? https://hax.iimarck.us/topic/6834/

Item Editor

http://i.imgur.com/InBrvpl.png

I'll admit I don't fully understand all the fields involved in items--being interested only in editing the cost and in-battle usability, and having not yet delved into working in assembly/pokecrystal--but I believe all relevant field are editable and given some kind of explanation as to their meaning.

28KB

Reads and edits item names and descriptions
        TM descriptions use the move descriptions and can't be edited with this tool
        use the move editor or just a simple hex editor

Edit seven bytes of the data structure and asm pointer
First two bytes are the cost
Next byte is zero except for held items
Next byte (Param) is usually zero but
        for healing items signifies amount healed
        for ethers, pp restored
        for brightpowder, king's rock etc chance of effect
Flag indicates whether the item can be
        registered with select
        given, tossed/sold, and held in quantities
        HMs can't be tossed or sold even if this flag is changed
Which pack pocket the item is held in
Use restrictions
        if the flag is 80 or C0 you may be able to use the item out of battle regardless of this setting
Asm pointer points to the routine for the item



Just click write ROM for all of these tools to save all changes at once. Remember to back up first! Although I tested these on Gold, Silver, and Crystal and nothing seemed to immediately break, there may be bugs I haven't found.

Please tell me if you find any bugs or have any suggestions.

Last edited by JudgeWargrave (2017-03-10 15:04:55)

Offline

#2 2016-10-02 06:51:43

JudgeWargrave
Member
Registered: 2016-06-28
Post 2/18

Re: Wargrave Tools 2.0, now on Github

New tool and update to the old ones! Here's a link to the zip file.

First, the update: now you can select which version of GSC you want to edit, rather than relying on version autodetection. Also offsets for Silver which differ from Gold have been corrected. You can even enter custom offsets for hacked versions! Even if someone has shifted the data all over the place, if you can find it, the tools will still work.

The code has also been modularized such that each tool extends a base class. This has resulted in a smaller overall filesize and better code. A consequence is that the applications should be kept in the same folder as the base class .exe file.

Now for the main event, the new:

Trainer Editor

http://i.imgur.com/lBR29a4.png

The editor I had been using before, and the best editor I could find, was Akwa's One GSC Trainer Editor. However, there were a few things I wanted to extend and improve. The major enhancements are:

Filesize reduction: from 7,185 KB to 63 KB! Over a hundred times smaller. This might be related to the fact that One GSC Trainer Editor takes a while to open.

Reads text directly from the ROM: Particularly important if you are changing pokemon or their movesets! This was a big problem for me because I had changed about two dozen moves, but they all still had their old names, making it quite confusing. Pokemon, move, and item names are all extracted from the ROM itself.

Change trainer class data: Trainer class names, which items they use in battle, the reward money they give, and their pokemon DVs are all editable! The tool also calculates the HP DV, hidden power, and shininess for you. It doesn't calculate gender because that depends both on Attack DV and on the species gender ratio, which can vary within a trainer class.

See pokemon default movesets, i.e. what moves they will have if you don't give them custom ones. Also shows moves the pokemon probably can't legally learn in pink for your convenience when creating custom movesets. The legality is based on level-up moves, prevo moves, and TM/HM, so it doesn't account for move tutors or egg moves currently. If you click the combo box, start at Pound, and scroll down while keeping the box "open" such that it shows many moves at once, the legal moves will clearly pop out as the white ones, which can be useful.

See how many free bytes you have remaining

Don't have to click "Change" button all the time :)

Other than those things, the basic functionality is pretty much the same: Add/remove pokemon (select "-" for a pokemon to remove it), give custom items or moves, add/remove trainers, and change their names.


Again, if you find any bugs or have any suggestions or requests, feel free to tell me, thank you!

Offline

#3 2016-10-02 10:26:35

Miksy91
Member
Registered: 2010-10-16
Post 2,295/2,339

Re: Wargrave Tools 2.0, now on Github

So is this trainer editor capable of defining where the trainer group pointer table is located? I guess so according to what you wrote about being able to define custom offsets for stuff. In this case, I'll personally find this useful with Dark Energy :)

UI looks pretty good too. Great job!

Offline

#4 2016-10-02 21:38:03

JudgeWargrave
Member
Registered: 2016-06-28
Post 3/18

Re: Wargrave Tools 2.0, now on Github

Thank you! Yep, it can change the "Trainer ptr table" in the custom offsets. It makes a few assumptions with how the data is laid out:

The table should be a contiguous list of pointers, one per class, that each point to a contiguous list of trainer data. The lists themselves don't have to be contiguous with each other to be read. However, when saving it assumes that they are contiguous, and just saves them one after another. I'll have to fix that assumption.

Now that I think about it though, violating that assumption causes a big problem if pokemon or trainers are added, or if the byte size of a trainer struct were changed via custom items/moves. If the data isn't in one big block with a single defined endpoint, how are the "free bytes" supposed to be calculated? In the case of a big block, we can avoid overwriting the other trainers by just shifting their pointers forward, but if everything is scattered there's no way to ensure not overwriting data without having an endpoint defined for each contiguous block....of course this would be no problem if the number of bytes is not increased....

I'll try making the tools that use pointer tables to work in two modes, contiguous data, which automatically repoints based on simplifying assumptions, and non-contiguous data, which won't repoint and will have to rely on the user not overwriting their own data when adding bytes. AFAIK, the relevant Gold, Silver, and Crystal data are all contiguous anyway, but hacks might not be.

I took a quick look at Dark Energy and that seems to be the case, mind telling me the offset for the ptr table if you've got it handy? I'm assuming its somewhere in the 0x0B0000 to 0x0B4000 range. It would help me out with testing this feature.

Offline

#5 2016-10-03 14:54:13

Miksy91
Member
Registered: 2010-10-16
Post 2,296/2,339

Re: Wargrave Tools 2.0, now on Github

I have practically reserved that whole rom bank for trainer data although it's really not needed. If I remember correctly, the first 0x200 bytes or so are code for fetching trainer data depending on the "Trainer Group" and "Trainer No." values in ram and it's almost immediately followed by "Trainer ptr table". That's probably at 0xB0200.

It doesn't really matter whether the editor plans to save the data continuously or not. In fact, I think it's better not to support letting user scatter data all over the place in case user himself has to make sure no useful data is overwritten during saving. If you however can make it so that each Trainer Group works the way you have made the tool treat all the trainer groups (which I personally don't see as a big obstacle to overcome), you can do it but it's almost an unneeded implementation. But only real benefit of this I can think about would be moving some other existing data from the same rom bank to a different rom bank which would lead into 2 continuous areas in the same rom bank where the hacker would have room for trainer data. But moving the whole trainer data to another rom bank like is possible as well (yet somewhat tricky without disassembly).

By the way, have you made this tool overwrite existing data to be moved with 00 bytes (on save)? I think that would be a useful functionality to not keep old copy of the data around.

Last edited by Miksy91 (2016-10-03 14:56:35)

Offline

#6 2016-10-04 10:29:37

JudgeWargrave
Member
Registered: 2016-06-28
Post 4/18

Re: Wargrave Tools 2.0, now on Github

I've mostly finished the new feature with discontiguous mode as I initially envisioned it. I also added the functionality of filling freed space with 00 when in contiguous mode like you suggested, and removed the "feature" the Moveset Editor had of overlapping learnset list null terminators and empty evo data, which would cause problems when attempting to give a non-evolving pokemon like Misdreavus an evolution, since it's "evo data" would no longer terminate Slowking's moveset to say the least!

However, when exploring Dark Energy more thoroughly, the problem of discontiguous data appears worse than it did at first...If I've misunderstood anything please correct me.

The trainer table is @0xB0220, and trainer class names are @0x1B66F0-0x1B8000. All the other relevant offsets are the same as Silver it seems, and the tool opens the file successfully. But the data is formatted unexpectedly.

1st, the trainer pointers are not strictly ascending, as they are in GSC vanilla. This is useful because if a data entry expands by N bytes, we just need to increment all subsequent pointers by N. We can do the same with reductions and make free space at the end. But this can't work for Dark Energy, or any file with ptrs that don't point to contiguous data blocks.

The raw data starts 87 44 B0 42 66 43 8F 43 D0 42...effectively 0487, 02B0, 0366, 038F, and 02D0. This already renders the data discontinuous and pointer management thorny: If the 2nd list is extended, it probably won't hit the 3rd, but it might hit the 5th. And there's no general certainty that there isn't important data in between these blocks that might get overwritten.

My solution to this was discontiguous mode: load and edit the data as usual, except don't manage the pointers, and trust the user to either know what they are doing or to not increase the byte totals.

There is a 2nd problem though: without consecutive pointers, how do we know where the end of a trainer class list is to load it correctly? There isn't any special marker, at least not in GSC vanilla. Each trainer is terminated by 0xFF, but a list of trainers isn't terminated by anything. The easiest way I can think of to end the trainer list while reading from the ROM is to check to see if we've passed the next pointer, using it as a pointer to the end of list, but this can't work if they are discontiguous, and the ROM doesn't have a separate table of endpoint pointers.

Hmm, this could still work if the data had gaps but was in order, as long as nothing in the gaps caused a problem. And the data could be sorted, or even simpler, we could compare against the "next largest" pointer value among all other pointers as the endpoint....

3rd, not only are the lists out of order, but the trainers within them are discontiguous too!

For instance, here's a text dump trainers starting @ B02B0:

Brady~($01)
($0F)($66)($5F)($5D)($49)M
($10)Z    ($4B)**   ($62)0
($12)($C0)($4B)($48)($26)0
_000000

Arnold~($01)
($11)($15)($1F)($2D)($40)($62)
($12)PK   v    ($D9)0    0
A1   -    ($11)($67)'r   0
($15)s    ($13)($3C)($6D)0
_0

Isaac~($01)
($26)($3E)($39)($3C)($5F)($05)
($29)($44)($EE)($59)($DF)0
_

Isaac~($01)
($19)($43)($05)($42)($44)($DE)
($1A)($19)($09)($1A)($19)'t
($1B)($39)($24)($45)($EE)($EE)
_0

Ritch~($01)
($0E)($6F)($18)($1E)($2B)0
($10)($1B)B      ($5B)($9F)0
_000000

Boss~0
($23)($5D)
($24)($6C)
($25)~
($26)($69)
($27)($7E)
($28)($7D)
_000000000000000000000000

etc.

All the 0s between them are the discontiguities. Here the 2nd problem is illustrated: "Boss" probably isn't in the same trainer class as "Ritch", but how does the tool determine that when loading Ritch's class?

Currently the tool also only reads Brady and Isaac's names correctly because they directly follow the previous trainer's 0xFF (_) byte. It does read their pokemon data correctly, and I can pretty easily make the tool scan past zeros when trying to read the initial name though, so the 3rd problem is minor.

TL;DR Currently the tool can't load the trainer data properly if it isn't contiguous because it doesn't know how to tell where the list of trainers for each class ends. I think that's fixable though. I'll keep working on it.

Offline

#7 2016-10-04 23:07:26

JudgeWargrave
Member
Registered: 2016-06-28
Post 5/18

Re: Wargrave Tools 2.0, now on Github

OK, it's working! Dark Energy can be loaded, edited, and saved successfully! I'll update the download in the OP.

Check discontiguous mode when loading to read the data safely. Then the data can be edited as normal. But that's not all.

By unchecking discontiguous mode, the tool will automatically "defragment" the data, making it safe to manage the pointers and extend/shrink trainers! Thus it's possible to do this:

http://i.imgur.com/ExDdZXs.png

Which could not be done without defragmenting the data because the Beauty class would overwrite the next trainer class (or vice versa, depending on their order in the fragmented pointer table). Afterward all the pointers strictly increase in value and there are no gaps in data, so next time the file is opened after being rewritten you don't have to bother with discontiguous mode at all.

Offline

#8 2016-10-05 06:00:48

Miksy91
Member
Registered: 2010-10-16
Post 2,298/2,339

Re: Wargrave Tools 2.0, now on Github

Really nice! :)
Sorry for not replying yesterday about your previous post although I indeed saw it before the second one. I'm really busy with schoolwork, part-time job, and other activities at the moment such as organizing a specific party at the start of November. I haven't even opened my hacking PC for a couple of days for trying this editor out (got another one from work which I use for programming specifically since this one has OSX and I use mainly Windows on my other PC which is not so suitable for programming tasks).

But I'll try this out the next time I do some trainer hacking (or even beforehand to just see how it works). :) But according to what you said just now, sounds like a tool that will become useful.

Last edited by Miksy91 (2016-10-05 06:02:21)

Offline

#9 2016-10-05 19:53:34

JudgeWargrave
Member
Registered: 2016-06-28
Post 6/18

Re: Wargrave Tools 2.0, now on Github

Don't sweat it, whenever you feel like testing it out is cool! BTW, I've played through most of DE now and you can add one more person interested in a full release to the list :)

Editing this in:

I've made another little update. The main thing now is instead of using a form to enter custom offsets, the tools read offsets from .txt files. I've provided files for Gold, Silver, and Crystal, and a template for what each offset is. This means another open file dialog must be traversed, but the benefit is that hack offsets don't have to be repeatedly punched in, and its impossible to mistakenly leave the offsets on the default Crystal values. This also allows for a few of the form elements to be deleted making it look a bit cleaner.

The big irregular Read and Write buttons have been replaced with a menu bar. It's now possible to use Ctrl+o and Ctrl+s to open and save. F1 opens the "help" which is actually just a link to this thread for now. Oh, and the icon in the upper left corner matches the icon in the file explorer for each tool.

Last edited by JudgeWargrave (2016-10-06 01:39:13)

Offline

#10 2016-10-09 02:57:40

JudgeWargrave
Member
Registered: 2016-06-28
Post 7/18

Re: Wargrave Tools 2.0, now on Github

1.3 is out with a new feature! Now data can be exported to & imported from .txt files, .WGSC_data.txt files to be specific to separate them out from other .txt files. Offset files are now .WGSC_offsets.txt files for the same reason, and can have descriptions following the offset value on each line to make editing them easier. Also corrected the values provided in Gold/Silver.WGSC_offsets.txt for "Item descs end" from 1C0000 to 1BC000. This caused them to allow descs to reach the next bank (technically bad, but in practice no one would make descs that long) and to overwrite that bank with 00s. In default Gold/Silver this wouldn't matter because that bank is empty, but in DE it isn't. Which is good, because that's the only reason I noticed the error!

One of the benefits of exporting is modularity: you can make changes to a Crystal ROM and quickly transfer those changes to Gold or Silver or a hacked Gen2 game. For instance, if you like a hack but it updated moves to Gen6 and you want Gen2 moves, you can load a fresh ROM, export move data, load the ROM hack, import the move data, and save. I tested this function by splicing Move and Moveset data from my own hack onto DE.

BTW Miksy, I have a question. Are the Battle Room trainers loaded in a special way? They don't appear to be correct after I edit the trainers, so maybe there is another set of pointers especially for them?

Also, if you do end up using these, I think the item descriptions are discontiguous as well. They are all in one chunk, but I think they're out of order since some are after Beat Up. This didn't affect the loading at all because descriptions, unlike trainer lists, have terminating bytes, and so don't need end-pointers, but it did screw up the export function until I realized it. In general it is probably safest to just check discontiguous data whenever loading a hack I suppose, especially if the data was edited "by hand" with a hex editor.

Offline

#11 2016-10-09 15:44:04

miremire
New member
Registered: 2016-09-10
Post 1/2

Re: Wargrave Tools 2.0, now on Github

Hi ! I am a novice in rom hacking who is editing a Crystal rom for fun, and I really like the neat tools you made. There is just one thing which bothers me with the move editor : after changing the base power of a handful of moves and starting a new game, it seemed the critical hit rate was broken, as if Tackle and Scratch now had a 1/2 or 1/3 chance of critical damage, even though I did not touch these. I am using an older version of your editor that I found somewhere on the Internet. Has this been fixed in the update ?

Last edited by miremire (2016-10-09 15:51:47)

Offline

#12 2016-10-09 16:20:49

Miksy91
Member
Registered: 2010-10-16
Post 2,299/2,339

Re: Wargrave Tools 2.0, now on Github

JudgeWargrave wrote:

1.3 is out with a new feature! Now data can be exported to & imported from .txt files, .WGSC_data.txt files to be specific to separate them out from other .txt files. Offset files are now .WGSC_offsets.txt files for the same reason, and can have descriptions following the offset value on each line to make editing them easier. Also corrected the values provided in Gold/Silver.WGSC_offsets.txt for "Item descs end" from 1C0000 to 1BC000. This caused them to allow descs to reach the next bank (technically bad, but in practice no one would make descs that long) and to overwrite that bank with 00s. In default Gold/Silver this wouldn't matter because that bank is empty, but in DE it isn't. Which is good, because that's the only reason I noticed the error!

One of the benefits of exporting is modularity: you can make changes to a Crystal ROM and quickly transfer those changes to Gold or Silver or a hacked Gen2 game. For instance, if you like a hack but it updated moves to Gen6 and you want Gen2 moves, you can load a fresh ROM, export move data, load the ROM hack, import the move data, and save. I tested this function by splicing Move and Moveset data from my own hack onto DE.

Also a useful functionality to have :)

JudgeWargrave wrote:

BTW Miksy, I have a question. Are the Battle Room trainers loaded in a special way? They don't appear to be correct after I edit the trainers, so maybe there is another set of pointers especially for them?

I think they're no way special other than the fact that the tname for each trainer of group 'Simulation' is empty (or basically just '50'). I take it you forgot to that in account because originally no trainer name is actually like that?

JudgeWargrave wrote:

Also, if you do end up using these, I think the item descriptions are discontiguous as well. They are all in one chunk, but I think they're out of order since some are after Beat Up. This didn't affect the loading at all because descriptions, unlike trainer lists, have terminating bytes, and so don't need end-pointers, but it did screw up the export function until I realized it. In general it is probably safest to just check discontiguous data whenever loading a hack I suppose, especially if the data was edited "by hand" with a hex editor.

Yeah, happened to naturally put stuff there and same happens with pretty much every in-game rom bank I have edited. Since games are themselves compiled from disassemblies of some sort the data is continuous originally, but if one changes stuff with a hex editor, it will always be like this. Not an efficient way to hack now that there is a disassembly for Crystal but I'll keep doing the 'ancient way'. :)

But yeah, when possible, it's good to take in account situations where the user could have moved stuff around with a hex editor as well.

Offline

#13 2016-10-09 17:26:31

Rangi
Member
Registered: 2016-05-09
Post 245/870

Re: Wargrave Tools 2.0, now on Github

Hey, I'm not the target audience for this tool since I'm using pokecrystal, but it looks really well-made. You have a simple, usable UI (nice update with the menu bar and key shortcuts), and it's very flexible with regard to how different hacks store data.

How are you handling types? If a hack adds a Fairy type, would it be detected?


Pokémon Polished Crystal (GitHub) — version 2.2.0 released
Pokémon Red★ and Blue★: Space World Edition (GitHub) — updated August 19!
Polished Map: pokered+pokecrystal map, tileset, and palette editor — version 3.5.1 released!

Offline

#14 2016-10-09 19:07:55

JudgeWargrave
Member
Registered: 2016-06-28
Post 8/18

Re: Wargrave Tools 2.0, now on Github

Miksy91 wrote:

I think they're no way special other than the fact that the tname for each trainer of group 'Simulation' is empty (or basically just '50'). I take it you forgot to that in account because originally no trainer name is actually like that?

Ah, I see now. I'm sure that's the reason. The function I use should be capable of returning a blank string, I'll have to debug it.

Miksy91 wrote:

Yeah, happened to naturally put stuff there and same happens with pretty much every in-game rom bank I have edited. Since games are themselves compiled from disassemblies of some sort the data is continuous originally, but if one changes stuff with a hex editor, it will always be like this. Not an efficient way to hack now that there is a disassembly for Crystal but I'll keep doing the 'ancient way'. :)

Yeah, it's actually really interesting to see the hand of a human at work rather than a compiler! And it caused me to examine a lot of my assumptions and better understand how the game really handles the data.

Rangi wrote:

Hey, I'm not the target audience for this tool since I'm using pokecrystal, but it looks really well-made. You have a simple, usable UI (nice update with the menu bar and key shortcuts), and it's very flexible with regard to how different hacks store data.

How are you handling types? If a hack adds a Fairy type, would it be detected?

Thanks Rangi! If it replaces Bird type or ??? type then it should be detected. Right now it just loads 19 type names. That's the next thing I'll generalize I think.

Looking at the preceding pointer table, there are actually 28 pointers, and the index of each pointer corresponds to the byte the game uses for each type, so this will actually be simple. It's funny to look at the quasi-logic in the list/table correspondence: the first four physical types, then jump up to 0x14 for the special types except Dragon and Dark, then back to 0x04 for the remaining physical types, then finally to 0x1B for Dragon and Dark. Oh, and just set everything between Steel and Fire to Normal, so I guess there are actually 17 "real" types, ???, BIRD, and 9 extra "NORMAL" types!

I suppose its safe to assume no one is using more than 28 types and just read type names using the pointers?

Edit:

Yep, its working, move editor now shows 28 types, each preceded by their byte code for clarity. However, while I'm ok with assuming no more than 28 types, I don't want to assume no less than 28 types, since I bet that hacks compiled from assembly would dispense with the redundant types. A quick look at the hex of polished crystal confirms a table with 19 entries. An entry in the .WGSC_offset.txt for the end of the table would be a bit excessive. I'll just put an entry with "Number of types" for now. An entry for Number of Pokemon, Items, Moves, etc would also be a good idea.

Last edited by JudgeWargrave (2016-10-09 20:46:53)

Offline

#15 2016-10-09 23:17:47

JudgeWargrave
Member
Registered: 2016-06-28
Post 9/18

Re: Wargrave Tools 2.0, now on Github

miremire wrote:

Hi ! I am a novice in rom hacking who is editing a Crystal rom for fun, and I really like the neat tools you made. There is just one thing which bothers me with the move editor : after changing the base power of a handful of moves and starting a new game, it seemed the critical hit rate was broken, as if Tackle and Scratch now had a 1/2 or 1/3 chance of critical damage, even though I did not touch these. I am using an older version of your editor that I found somewhere on the Internet. Has this been fixed in the update ?

Hi miremire, glad to hear you like them! As for the crits, actually I noticed that too but put solving it on the back burner. Thanks for reminding me, I'll look into that.

Edit:

I can't replicate this anymore, but I looked through pokecrystal\battle\effect_command.asm and the ROM with a hex editor and have an idea of what might have happened. The default list of moves with high crit ratio is 02 0D 4B 98 A3 B1 EE FF, and the list of crit chance per stage is 11 20 40 55 80 80 80, or about 1/16, 1/8, 1/4, 1/3, 1/2, 1/2, 1/2. The "11" byte contains the chance of a basic move to crit. If, in a previous version of the tool, it didn't save to a free area, the list of crit moves might have expanded to overwrite this byte since that table comes right afterward. If it were overwritten with byte "4B", for instance, that would have resulted in approximately 1/3 chance to crit. Alternatively the pointer to the crit chance table might have been corrupted, or the crit check routine itself, but I assume that would crash the game.

Anyway I tried setting the byte to FF and got all crits, 00 and got no crits, and 11 gave about 1/16 crits, so I think it's fine now.

Last edited by JudgeWargrave (2016-10-10 01:05:22)

Offline

#16 2016-10-12 05:23:05

miremire
New member
Registered: 2016-09-10
Post 2/2

Re: Wargrave Tools 2.0, now on Github

Okay. I looked in my previous "critical hit friendly" ROM and the bytes you mention are unaffected though. So I guess it is the second explanation.

I downloaded the new version of your editor and applied the same move modifications on a fresh ROM, and now it seems fine indeed. Thank you :)

Offline

#17 2016-10-12 09:17:21

JudgeWargrave
Member
Registered: 2016-06-28
Post 11/18

Re: Wargrave Tools 2.0, now on Github

Good to hear, miremire.

Update 1.4
Fixes:
-Read blank strings (trainer names) correctly: Simulations and Guardians in DE are handled properly for example.
-Load variable number of type, pokemon, move, and item names. If you added a few pokemon for instance, then it should be OK (but still assumes one byte for ID so only a few more). Set these values in the WGSC_offsets file.
-Item tool will not import ASM values from exported data because they aren't portable from version to version.
-Warns the user if names/descriptions are too long to display properly in more cases.

Improved pointer management
The old method of managing pointers and breaks in data wasn't general enough. Now you can repair breaks anywhere in the data using the "manage pointer" buttons. A break at index i means that the data for entry i doesn't start at the end of entry i-1. A break at the first index means that the first data entry does not start at the end of the pointer table. That one in particular should usually be left checked because pointer tables and their data are often separated asm rather than free bytes.

You can uncheck these and click "update pointers now" to fix them, after which the tool will repoint and calculate free bytes for you. If there is a break somewhere after index i, the free bytes for i will use that break as the endpoint. If there are no breaks after i, it will use the endpoint defined in .WGSC_offsets.txt.

If you are editing a fresh Gold, Silver, or Crystal file you won't have to worry about any of that though.

Offline

#18 2016-10-15 20:40:48

JudgeWargrave
Member
Registered: 2016-06-28
Post 12/18

Re: Wargrave Tools 2.0, now on Github

Update 1.5
Actually loads # of elements in more cases
Manage pointers in menu or with Ctrl + p
The "can't learn" indicator of the Trainer editor has been improved
Cosmetic changes

Evolution editor
i.imgur.com/JBkwUdX.png

Pretty self explanatory. Can add/remove evolutions of course. I probably could have made this in only one day if not for Tyrogue mucking everything up. Trade 255 means no item. Happiness 2 is day, 3 is night, 1 any time.

Animation editor
i.imgur.com/cbv3nkF.png

This one is pretty rudimentary, but it is functional. The potential here is much greater than just changing the animation ID with the move editor, as you can create entirely new routines! You could try splicing Thunderpunch and Hyper Fang to make Thunder Fang for example. This will also avoid the cosmetic bug with the wrong type displaying for the move in battle. Of course, you could (should) just use pokecrystal to do the same thing for Crystal, but this should work with any GenII game.

The memory management for this is the most complex yet, even worse than the trainers, as the routine for each animation can contain jumps to other routines. Don't even bother trying to manage the pointers. For now be very careful, and try to not change the number of bytes on anything....This also doesn't import/export data, as pointers in the routines would almost certainly not point to the right place in a different ROM, so programming a primarily portability motivated feature would be wasted effort.

Offline

#19 2017-03-10 15:43:33

JudgeWargrave
Member
Registered: 2016-06-28
Post 13/18

Re: Wargrave Tools 2.0, now on Github

I've put this project on Github so everyone can see and edit the source code themselves. This way if there are any bugs, more people will be able to fix it, and people can make extensions and improvements to suit their own needs.

I think this is just my new high DPI display, but the windows' widths won't let themselves shrink beyond a certain point. If anyone has a normal DPI display but the windows are too wide, let me know and I'll look into it some more. Everything should still be usable in any case.

New features:

Wild Pokemon Editor
Change the species and levels of Pokemon that appear in the wild

Adjust levels up and down for all seven Pokemon in area+time-of-day block at once

Analyze commonality of Pokemon families:
-multiplies number of areas * hours of the day * encounter frequency and lists in order so most common/rare Pokemon can be seen
-for instance, in default Crystal, Zubat, Rattata, and Tentacool have >30,000 area-hours, whereas the 4th most common, Pidgey, has 13,350. Clearly these three need to be replaced in a lot of areas for a more diverse ecosystem! Oddly, Oddish is the most rare Pokemon that can be found in Johto Land, only appearing in a few routes at night.

I haven't updated the offset files for games other than Crystal, it shouldn't be hard to make it work for G/S or hacks though. It also doesn't do anything with headbutt Pokemon or static encounters.

Updates to old tools
Icons should display properly for all tools rather than default .exe icon

Fixed some bugs with Evolution Editor

Trainer and Moveset editors analyze Pokemon and move commonality. For instance, in Crystal, the most common Pokemon enemy trainers use are Koffing, Magnemite, and Geodude. There are an astounding 16 non-legendary families that aren't used by any trainer! Replacing some Koffings would be a good starting place for any hack. The most learnable move is Hidden Power. There are a LOT of "signature" moves: MEGA KICK, JUMP KICK, TWINEEDLE, MIMIC, CLAMP, HI JUMP KICK, LOVELY KISS, SKY ATTACK, DIZZY PUNCH, PSYWAVE, SHARPEN, SUBSTITUTE, SKETCH, TRIPLE KICK, AEROBLAST, MACH PUNCH, OCTAZOOKA, MILK DRINK, PRESENT, PAIN SPLIT, SACRED FIRE, MEGAHORN, MORNING SUN, EXTREMESPEED, BEAT UP. There are yet more that are learned by two pokemon in the same family. There's even a super-exclusive move that can't be learned by any Pokemon in Crystal: Razor Wind. Not that you would want to.

Offline

#20 2017-03-16 16:40:13

Tylusnoir
Member
Registered: 2017-03-16
Post 1/13

Re: Wargrave Tools 2.0, now on Github

Hi JudgeWargrave!

An amazing software you have make it here! But I have one question about this!

I see it's only work on English version, it's possible to make it work in French version for example? If you cannot, where can I find the code to change in French version.

Thanks your answer and I give you my support for the future of this software! And sorry for my english...

Offline

#21 2017-03-17 04:50:51

JudgeWargrave
Member
Registered: 2016-06-28
Post 14/18

Re: Wargrave Tools 2.0, now on Github

Tylusnoir wrote:

Hi JudgeWargrave!

An amazing software you have make it here! But I have one question about this!

I see it's only work on English version, it's possible to make it work in French version for example? If you cannot, where can I find the code to change in French version.

Thanks your answer and I give you my support for the future of this software! And sorry for my english...

Hi Tylusnoir, thanks for using the software! Yes, it's quite simple to make work with the French version. You just need to update the Crystal.WGen2_offsets.txt so the tool knows where to find the data.

What I did was, first try opening a French rom with the evolution editor using the english offsets, which failed. Then I made a copy of Crystal.WGen2_offsets.txt called CrystalFR.WGen2_offsets.txt and replaced the Pokemon names and Moveset ptr table with the correct values. (The evolution editor requires the Pokemon names, Item names, Moveset ptr table, and Movesets end. Item names and Movesets end are the same in the English version. Pokemon names and Moveset ptr table are slightly moved.) After that, it opened properly. I tested by giving Héricendre/Cyndaquil an evolution at level 6 and it worked.

As for how I found the offsets, I used WindHex--a hex editor--and a table file that converts hex to the english letters they represent. If you don't know about using hex editors, finding a tutorial shouldn't be hard. I simply searched "BULBIZARRE" to find the Pokemon names at 053377 (not 053384) and "MASTER BALL" to find the items in the same spot. For the movesets, I just looked around the area they are in the english version and found the pointer table starts at 0425BC (not 0425B1). This step would be a bit more complicated, especially if you don't know about how GBC pointers work, but because they are still so close in memory I don't think it would be too hard.

Basically, look at the offsets in an English Crystal version, then try to find the same data in whatever other Gen2 game you want to change and record the offsets in a new file. A minor hassle, but once you get used to it you can probably finish all of them in an hour or so. If you really have trouble I can do it for you, but I prefer not to make offset files for every version of the game ;) Plus looking around the rom for the first time is a fun learning experience. With the source code for the tools, if you understand C# you can probably figure out how the data in the rom is stored too.

Once you have a French offset file, you can make a pull request on Github to add it to the repository, or you can just post it and I'll add it myself so that other French users can have it.

Offline

#22 2017-03-17 17:31:12

Tylusnoir
Member
Registered: 2017-03-16
Post 2/13

Re: Wargrave Tools 2.0, now on Github

Oh the marvelous creator of this topic answered me!!! =D

Hi JudgeWargrave! Happy to see your fast answer!

For the Evolution Editor, it's works well now! Thank you soo much!!! =)
After, I don't find a good WindHex, I have download many but when I make a search, it's a full of numbers and weird letters... And I can't find "Bulbizarre" (Bulbasaur). Did you have a website with a good download link?
I didn't find a french offsets file on internet, I must have WindHex or other software and find by myself?
And for the C#, not at all...
I'm sorry for the additional job I'm asking you.

Offline

#23 2017-03-17 22:39:53

JudgeWargrave
Member
Registered: 2016-06-28
Post 15/18

Re: Wargrave Tools 2.0, now on Github

No problem, I did say it would only take someone used to it (for example, me) an hour, so I really can't complain. I was actually quite stupid+lazy to tell you to figure it out yourself which would of course take more than an hour, it took me a lot longer than that to figure it out the first time! Well, if it were someone that had used a hex editor I probably would still tell them to figure it out themselves, lol.

French Crystal offsets

These should work. The area names will still be in English because they are hard coded into the tool as I never bothered figuring out how they were associated with the area data yet, but that shouldn't be a critical problem. Everything else should be French, although some French characters probably won't render correctly. All the tools open and display but I didn't really test them thoroughly for bugs. Tell me if you have any problems.

Offline

#24 2017-03-21 14:47:44

Tylusnoir
Member
Registered: 2017-03-16
Post 3/13

Re: Wargrave Tools 2.0, now on Github

Oh thank you soo much! I will test it later, I'm very busy for the moment. I will make a reply after testing all the editors!

Offline

#25 2017-03-24 19:22:19

Tylusnoir
Member
Registered: 2017-03-16
Post 4/13

Re: Wargrave Tools 2.0, now on Github

All Editors works now! It's very excellent!!! I can work on my version! Thank you soo much! JugdeWargrave!!!

But two more question, how the "Move Animator Editor" works? You must know the value of each attack, sounds and effects?
And how can we make a new items to remplace all the "Teru-Sama"?

Last edited by Tylusnoir (2017-03-30 15:47:00)

Offline

Board footer

Powered by FluxBB