Poll: What should be prioritized (multiple choices allowed)
This poll is closed.
Events 6.82% 3 6.82%
Monster Graphics 6.82% 3 6.82%
Maps (FF6LE clone) 6.82% 3 6.82%
Sprites (characters) 4.55% 2 4.55%
Monster AI 11.36% 5 11.36%
Strings / Dialogues / Names 6.82% 3 6.82%
Spell data 9.09% 4 9.09%
Item data 6.82% 3 6.82%
Monster Data 13.64% 6 13.64%
Chest data 6.82% 3 6.82%
Animations data 0% 0 0%
Tilesets / Tiles Graphics 0% 0 0%
Shop Data 4.55% 2 4.55%
Monster Formation / Packs 9.09% 4 9.09%
Other misc data (see easy stuff) 6.82% 3 6.82%
Total 44 vote(s) 100%
* You voted for this item. Show Results

Users browsing this thread: 1 Guest(s)
FF6AE

#1
Posts: 3,561
Threads: 261
Thanks Received: 636
Thanks Given: 254
Joined: Oct 2011
Reputation: 58
Status
Faith
Ok, I've officially put on hold my hack (which was already a reality for a long time now) and start back my FF6 Advance Editor (FF6AE). The version I'll be starting working on will still be .NET based but instead of an winform application it will be a WPF application (easier UI customization and data binding among other things). I'm not starting from scratch but I wasn't very proud of how I coded the previous versions. It was a first project outside school and now I know how to do better. I already got the portrait editor done for the WPF version and the GBA graphics managing functions done.

I'm planning in the long run a full editor, which the majority of what FF3usME combined with ZoneDoctor can do. It's ambitious for the least but feasible. I'm planning to add support for all three versions but I'll prioritize the European version first. I'll also try to continue my FF6EME (expanded monster) editor for the SNES version and work on updating the forum. I want to bring my two editors but they will be long term project. FF6AE will be hosted here: https://github.com/madsiur/FF6AE

However I'll be releasing betas as features are implemented but I have nothing to show for now.  Shrug

I'm still documenting and gathering infos about data formats but the ROM map is close to completed, as far as data is concerned. I'm doing a quick survey about what you guys think I should prioritize first. You can choose multiple choices and this will guide me about what to do first. I've divided different features in some categories to give a rough idea about how time consuming each will be. I'd say 95% of what is in the first two categories have been identified in the ROM. I'd say 100% of formats regarding them are known but not yet gathered in a single document / source.

So what should come first? Comments are welcome!

P.S. Poll will end in 30 days, at that time I will already have started the coding.

Easy Stuff
  • Monster Formation / Packs
  • Shop Data
  • Esper Data
  • Colosseum Battle Data
  • Natural magic lists
  • HP / MP Level Constants
  • Blitz and SwdTech skills learned by level
  • Starting Rages
  • Character Initial Statistics
  • Ragnarok Metamorphosis Packages
  • Chest data
  • Magic Data
  • Spell Data
  • Item, weapon, armors, relic.
  • Monster item stolen / dropped
  • Control / Sketch data
  • Monster stats
  • Animations data (spells yes, intro & casting not sure)
  • Portraits
  • Magic Points Earned per Monster Formation

I know what I'm doing but takes longer to code
  • Events
  • Monster AI
  • Menu backgrounds *not documented
  • Levels (FF6LE clone) *still needs some documentation
  • Characters / NPCs Sprites
  • Tilesets / Tiles Graphics
  • Strings / Dialogues / Names (in 5 languages but English first)

Dunno how FF6A manages that
  • Monster sprites
  • Animation scripts
  • World maps
  • Music Data
  • Everything involving ARM (out of scope anyway)
  • Battle events (Found data but unknown even on SNES and out of scope)

Completely different on GBA and I know nothing of them
  • Sound Samples
  • Compressed Graphics
  • Battle Backgrounds (Pipe dream)
  Find
Quote  

#2
Posts: 790
Threads: 11
Thanks Received: 47
Thanks Given: 22
Joined: Nov 2011
Reputation: 14
Status
Distill-Skill
Whoops, didn't see that Monster AI was separate from Monster Data. Tongue I would have voted for that too.


Confused Moogles FTW
Quote  

#3
Posts: 579
Threads: 33
Thanks Received: 31
Thanks Given: 21
Joined: Jan 2015
Reputation: 9
Status
Dead
Wouldn't Monster AI fall under the same issues as event editing? A little to open ended for a static editor? Really asking more than stating here, really have never even read about monster scripts, but I always thought it was, at its heart, pretty open ended as to any sort of set order to things.

On another note, just for the sake of asking more than anything, how locked down are you planning on making the code? As in open source, no source but possible to hack in simple adjustments, or are you going to throw in some voodoo curse that will instantly blind anyone that attemps to hack the program then set it to summon hungry demons on them if they keep trying? (I hear Microsoft developed this awhile back but they ran out of human sacrifies before they could get it installed. Or did they...)

Regardless, I don't see myself doing any of that, but I still think it would be a good game hack friendly feature if it had its own config menu to custom set major data pointers. Sure, wouldn't be for the general user (or maybe it would if a hack came with instructions such as "Set X pointer to C1/0074 in the settings to use the editor with this patch.") I don't see how it wouldn't however greatly expand compatability.

Just my thoughts in general, not saying any of it is a good idea though.


The only true wisdom is knowing you know nothing.
  Find
Quote  

#4
Posts: 3,561
Threads: 261
Thanks Received: 636
Thanks Given: 254
Joined: Oct 2011
Reputation: 58
Status
Faith
(02-14-2016, 12:22 PM)Catone Wrote: Wouldn't Monster AI fall under the same issues as event editing? A little to open ended for a static editor? Really asking more than stating here, really have never even read about monster scripts, but I always thought it was, at its heart, pretty open ended as to any sort of set order to things.

Monster AI are easier to deal with than events. That be said they show some similarities as being relative length entries (dialogues too). However there is less to consider when adding an extra byte in a monster script. As for events I'll have to see where ZoneDoctor is failing and find a better approach.

(02-14-2016, 12:22 PM)Catone Wrote: On another note, just for the sake of asking more than anything, how locked down are you planning on making the code?

It's going to be open-source under the GPLv3. Free to distribute and modify as long as you don't claim it your own.

(02-14-2016, 12:22 PM)Catone Wrote: I still think it would be a good game hack friendly feature if it had its own config menu to custom set major data pointers.

I can see this being done with a config file or a menu. However don't call me when you would enter wrong offsets and ask yourself why the editor output an error.
  Find
Quote  

#5
Posts: 579
Threads: 33
Thanks Received: 31
Thanks Given: 21
Joined: Jan 2015
Reputation: 9
Status
Dead
Of course a disclaimer saying to chamge at your own risk. Maybe a "set to default" button, even then you'll never account for every mistake and experiment a user can, and will attemp. The smart ones will stick to directions on a patch, or adjustments for their own work, in which case they SHOULD know if and what to change those values too.

As for the other thing, the little I've used of the event editor, it was a bit restrictive. To an extent it allowed it to guide a user to the normally propper format however.

You really can't blame anyone that once said it couldn't be done. Course, some people have used it and done things so the concept is sound. If you can make any improvements on your's, it is bound to be useful to someone. Thinking about it, maybe if it worked like my spreadsheet setup (not manual of course) where you could edit the HEX directly, or choose from menus the worded part. Basically editing/creating the disassembly in the editor.

But that's way down the road, regardless of how its done. Eitherway, should be epic to say the least.

On another note, in the usME side of things (granted not 100% on if GBA has the same format on this) but are you planning on having an option for changing the "starting spell value" for the commands that use spell rranges?

Not the code that checks IF it needs a spell list calculation, just what spell it starts at. Would allow to "edit" something such as MagiTek in a summon menu if desired. Other customizable things as well. Just a thought.


The only true wisdom is knowing you know nothing.
  Find
Quote  

#6
Posts: 3,561
Threads: 261
Thanks Received: 636
Thanks Given: 254
Joined: Oct 2011
Reputation: 58
Status
Faith
(02-14-2016, 03:05 PM)Catone Wrote: Maybe a "set to default" button, even then you'll never account for every mistake and experiment a user can, and will attemp.

That should help. I'll also load the default values in case of a vanilla ROM based on the MD5 or SHA-225 / SHA-512 value. I could also save these and other settings based on the ROM hash.

(02-14-2016, 03:05 PM)Catone Wrote: You really can't blame anyone that once said it couldn't be done. Course, some people have used it and done things so the concept is sound. If you can make any improvements on your's, it is bound to be useful to someone.   

I'd blame anyone telling it can't be done, easily done in a proper way probably not but far from impossible. I'm still thinking about it and it could be a mix of inputting the hex commands directly for the veterans or choosing from a menu for newbies with a dynamic disassembly for what you input serving as a guide. Once you save your portion of code, it either push and reorganize following code or overwrite based on the option checked. In case it pushes the code, whole disassembly is reloaded, same thing if you just remove bits of event code.

(02-14-2016, 03:05 PM)Catone Wrote: are you planning on having an option for changing the "starting spell value" for the commands that use spell rranges?

Yes, I've found all the data regarding the Magitek menu (Terra specific and default), starting Rages, Lores, natural magic tables and Blitz / SwTech learned at level up. However most of these cannot be expanded (except rages that allow technically 32) without ARM changes that I have not identified.
  Find
Quote  

#7
Posts: 579
Threads: 33
Thanks Received: 31
Thanks Given: 21
Joined: Jan 2015
Reputation: 9
Status
Dead
Yeah, as far as expanding a spell list... short of manually setting number of spells to display in the editor, no idea how that could be done, but the starting spell calulated value would be easy.

Expanding the list of commands that are calculated is easy, just a matter of space for the length of the list. Unless its changed for some reason in GBA, that's another one that could be pulled from a pointer to load the list, then check the nearby value for how long the list actually is (course it wouldn't really help much unless your already checking every command and if its a list vs a skill... yeah not much point in going that far, but starting spell number definatly.

And yeah, the ability to enter hex code directly into an event editor would without a doubt make it more appealing, would also, to an extent, help the interested newbies learn something about actual hexing events by seeing both the writen version and the hex side by side. Same concept should work for other similar things as well.


The only true wisdom is knowing you know nothing.
  Find
Quote  

#8
Posts: 3,561
Threads: 261
Thanks Received: 636
Thanks Given: 254
Joined: Oct 2011
Reputation: 58
Status
Faith
(02-14-2016, 09:21 PM)Catone Wrote: the ability to enter hex code directly into an event editor would without a doubt make it more appealing, would also, to an extent, help the interested newbies learn something about actual hexing events by seeing both the written version and the hex side by side.

It's not really possible to have a system that would be faster than hex editing directly for a very experienced event hacker. What can the editor speed up though, is serving as a real time memory refresher for the input command and easing the event revision for possible errors once completed with the help of the temporary disassembly. Otherwise hex editing will always be faster than clicking and selecting from menus for someone experienced with events.
  Find
Quote  

#9
Posts: 110
Threads: 4
Thanks Received: 13
Thanks Given: 1
Joined: Jan 2012
Reputation: 4
Status
None
Yeah the only thing event editors with experience really need is a mneumonic system and a real syntax to make readability easier.
  Find
Quote  

#10
Posts: 579
Threads: 33
Thanks Received: 31
Thanks Given: 21
Joined: Jan 2015
Reputation: 9
Status
Dead
Sure there is a method faster than direct hex typing. Phonic hex editing! Come on, how epic an event editor would be if you not only had the choices of Menus and direct hex code, but voice recognition hex input! Would also serve as great practice for the entry exam to the crazy house and those pleas of "insanity" in court. Don't know about you, but I'd have to say someone not only talking to themselves but talking to themselves in hex has at least a few screws loose.

Personally, as I said, I type out hex then the disassymbly in my notes before inporting it to them ROM, so yeah an editor that would convert the hex commands to disassymbly on the fly... yeah I see it being useful even for those with experiance. Not to mention easier to proof read afterwards.


The only true wisdom is knowing you know nothing.
  Find
Quote  



Forum Jump:

Users browsing this thread: 1 Guest(s)


Theme by Madsiur2017Custom Graphics by JamesWhite