[PSX/PC] General editor - Hades Workshop (0.50b)

  • Thread starter Thread starter Tirlititi
  • Start date Start date
Status
Not open for further replies.
Hi. Long time no see.
Version 0.19 out, more to reassure you that I'm not dead than to be an useful update...  :P
- You can import models for Battle Scenes (geometry only, not texture yet),
- Exporting quads is fixed now (at least Blender can read them with most gfx cards),
- You may also change the colors a bit, as well as reorder textures, in Battle Scenes,
- You may now choose not to load texts (names, helps, etc...) when loading mods,
- Added 2 spell effects (Absorb Strength and Absorb Magic).

The bad point :
the size limit... You have between 0 and 2048 free bytes, which is really poor when it comes to models.

The good point :
textures should be importable soon (I guess it'll take much less time than geometry). I hope it will allow a decent way to get more space by optimizing the textures.

Note : the model's format must be .obj (the importer doesn't read the related .mtl file). Each faces be either a triangle or a quad and must have a texture and an UV mapping associated to it. If the program can't interpret some features of the model, it will display a warning and ignore them. Once a model is successfully imported, you must link textures ID from the imported model to the texture list available in the Final Fantasy file (Blender, in particular, tends to un-sort them).

Pfiou, it was really hard for me to make that importer. And I'm so busy with my studies these times... :'(

Thanks for the thx, demeterf, by the way !

@ R51 : posting when I update ^^' speak of a coincidence.
About enemies, there are several things.
- Enemies are often duplicated : I think there is 1 instance for each different battleground (or battle scene) they may appear in. I'm not 100% sure that's the only difference but, for instance, the Big Dragon in the Mist Continent's mountain and the Big Dragon in the Forgotten Continent's plains are separated.
- Additionaly, there are enemy groups (or enemy formations) : they are variations of the same battle, with more or less enemies in it or different enemy types (eg. : Carve Spider or Carve Spider + Axe Beak). The Frequences are the probability you fall on each formation given you have already fallen on that battle. Frequency of 255 is same as 100, actually.

There is a help (F2), which I should update but still gives some useful informations (it strangely lags a bit though...). Don't hesitate to read it if that's not done yet ^^
Also, I tried to answer a lot of questions in this thread, so you may also read it if you have time to spare :P

Thanks for the feedback.
 
Last edited:
Thanks for the update. Im always checking this. Awesome job on the whole import models work you are putting into this program.
 
Ah this program is awesome!

Is there anychance it might be able to export the models/textures of the world map at any point?
 
Thanks. To answer you, it might be possible, but I think Zidane_2 (him again !) made a program to see the world map already. I don't remember how it worked (if you could export the models or only see it) but I may try to add this feature in the future.

However, for now, my short-term plan is :
- add a battle scene texture importation,
- add a charmap texture importation (not really advanced : I think you won't be able to see the changes for the texts in the program, only in-game),
- add a section for the party's stats.
 
Tirlititi: don't forget my request, please. the change and defend editing, remember i wanted to change "change" into any choice movelist?
 
Thanks. To answer you, it might be possible, but I think Zidane_2 (him again !) made a program to see the world map already. I don't remember how it worked (if you could export the models or only see it) but I may try to add this feature in the future.
Click to expand...
Aye, Zidane_2 made a bunch of software written in Blitz3D for FFIX, I've put the sourcode here (he gave it to me a while ago) so you can grab it if you like, it just sits in there all the time anyway.

Here: https://www.dropbox.com/sh/azf19y7homu8qnj/u-JOQibN1q

Unfortunately you couldn't export from his viewer, it was only that, a viewer, it was pretty good though.
I actually have the sourcecodes to everything he ever did for FFIX, I'd be happy to share it with you, I've got his permission to share it so its not a problem, might help you a little. It's all written in Blitz3D though, so you'll probably have to get the trial version of that.

A guy on the Xentax Forums managed to make a little progress in figuring out the format so I can always provide that info too.

Eitherway this program is awesome and your aforementioned updates sound great, IX doesn't get enough love honestly, I'd love to be able to go in and HD the game with higherquality textures (and perhaps a more painterly art style Ala Bravely Default) some time.

EDIT: In the end I just threw in all the sourcecodes for all the Zidane software he gave me (basically everything he put on the forums plus a few more things he never shared because they were incomplete.
 
Last edited:
Wow, great !
The Blitz3D script seems exploitable at first glance. It'll be useful anyway :D

Itoikenza, I didn't forget your request nor the fact that the "Commands" section is bad for now, but I can't guarantee any result in this since I don't know where (and how) those datas are stored. I'll try to figure it out when I'll go on Party's stats, but I can only cross the fingers for that :/
 
Wow, this is a wonderful tool! I was testing it, 'cause I plan to use this for my future projects with FF9. I have a question, Tirlititi: can this tool hack the equipment/item/key item/location names?
 
Last edited:
No, not for now. It's on my to-do list though. Good luck with your project :)

About location names, you may edit them (they are world map texts, even if you would need to change them in all the dialogs too) but it's not working so well as I need to implement text opcode editing.
 
Ah, cool. I'll be waiting for the next update. ;D

Oh yeah, I forgot to mention the Card names. I edited the monster names with Hades Workshop, but the Card names are still the same. Guess they're stored somewhere else.
 
It seems that the program can't edit some eidolon attacks yet. These are the ones I didn't find:

  • Atomos' G-Force 199
  • Carbuncle's Ruby Light
  • Fenrir's Terrestrial Rage & Millennial Decay
 
I don't know if you already have info regarding items and equipment text so i'll just tell you what i've found.
Items/Key Items/equipment/card names are are located into the SLES/SLUS file in ff9 text format. Pointers for equipment and item names are right above the names, in blocks long 18 byes each, with the first two being the actual pointer. Key item pointers are located after the names instead, but not directly after (there are 386 bytes between the end of the block of the names and the first pointer to key item names in the italian SLES file) in blocks 7 bytes long, with the first two being the actual pointer. I'll try editing card names next so tell me if you need infos about them too. I hope to have saved you some time, keep up the good work!  ;-)
 
Thanks :D It will save me some time indeed.

@ Kikoutei : You mean they are not in the spell section list? :O
I have them... They are named "Atomos", "Carbuncle" (4 of them, including Ruby-light) and "Fenrir".
Or maybe you speak about the animations or about the effects? Eidolons' effects are quiet weird and you can't change the "ores powerup" effect on them, I guess.
 
@ Kikoutei : You mean they are not in the spell section list? :O
I have them... They are named "Atomos", "Carbuncle" (4 of them, including Ruby-light) and "Fenrir".
Or maybe you speak about the animations or about the effects? Eidolons' effects are quiet weird and you can't change the "ores powerup" effect on them, I guess.
Click to expand...
Their names and attacks are not in the same place, believe me. Just like "Rebirth Flame" and "Phoenix". "Phoenix" is shown in the Summon list, while "Rebirth Flame" is shown in the attack/skill message box. Yes, some Eidolon attacks are located somewhere else, I found them using a hex editor.

FF912_zps7a4e7d6d.png
 
Last edited:
Thanks :lol: It will save me some time indeed.
Click to expand...
Glad to have helped. I'm really looking forward for the time when every single string of the game will be editable with your tool.
Ah, and when everything is finished you should consider adding a search function and/or an export/import function to allow easier editing of multiple strings.
 
I haven't really looked at this application, but I thought I'd chip in with a few suggestions.

The first one is to try and avoid storing player modifications as binary files. Seriously. This was a major mistake with the FFVII tools and I really do think it has harmed serious efforts to create large scale modding projects for years. Player changes should be saved first as text files that represent the state of the model (not binary changes). This is really, really important, because it makes mods portable, it lets modders use source control and it makes it feasible to update the implementation of a particular effect etc. without forcing modders to rewrite their projects. This won't always be possible in all circumstances, like model or texture assets, but it's an absolute must for mechanics / stats patches.

The reason is that with 'abstracted' user files, it suddenly becomes trivial for a modder to immediately port a project to multiple international releases. They can store their projects in subversion and branch / merge features as they see fit (branching binaries is arduous; merging them is practically impossible). Updates to tools are no longer as risky, as if a tool's compile / save to PPF messes up a project, you can always wait for the next release and compile again (unlike with some of the FFVII tools, which occasionally lose data on save and force some very time-intensive regression testing). Faulty implementations are bound to tools, not project files, so modders can continue working on stuff whilst tools get fixed.

The other big thing is that abstracted project records can expose implicit global variables in the binary - like duplicate enemy records - without much trouble. In fact, the model doesn't have to represent the binary file at all - if you want to give users the ability to create monster attribute inheritance chains that don't exist explicitly in the binary, you can do so without (much) trouble.

I'm being a bit prejudiced here - I haven't seen your code, I'm just assuming it looks like a lot of the projects I've seen round here before - so possibly you've already considered this. But as it sounds like your project is growing steadily, you might want to think about these things as they'll have architectural implications (because they'll force you to separate out your model).
 
Last edited:
So, first thing first, I've updated the program :
- It can now kind of import textures for the Battle scenes models.
- The help is improved a bit.
- I think the dll are not required anymore (it turns out they were only debugging dll ^^').
- Some few bug fixes.

I didn't test the model importation thoroughly but it seems to work, more or less (exporting a model + re-importing it elsewhere works at least).

I'm not really satisfied with the way I handle it because :
1) you have to manually import textures and models separately and make the link after.
2) The texture you can import must not be larger than 768x256 (3 times a 256x256 texture, which is what most of the default scenes use).
3) There are 2 opposite needs concerning textures and UV mapping : the UV mapping in the model must refer to a 256x256 part of the full picture (called "Painting" in the program) but the importation process creates a palette, which is quiet complicated by itself, and would better require the textures to be splitted into smaller parts to have a better resolution (a palette is limited to 256 colors). I really don't know how to make it nice...

Tell me if I made a mistake and the dll are still needed (I don't think that's the case, but who knows...).

@ Kikoutei-sama : Ah, their names... Yes, that is somewhere else, in a more general text block. I'll try to give access to it.

@ Caledor : There is already an exporting feature, but I know that's not that convenient. I'll think about it (a search feature, I guess) but it would be a waste of time to make it before I find a definite way of managing the charmap (if I want the program to be able to write texts in, let's say, chinese, I have to re-write the way the texts are handled by the program).

@ Bosola : I'm not sure to fully understand you. First, models are not the only thing Hades Workshop can edit. Second, I don't know how the FF7 tools you're refering to are coded, but I tried to make the binary saves (the "Save Mod" feature, if that's indeed what you're talking about) looking alike the binary data in the FFIX disc : this way, a program reading a FFIX disc should have little problem reading my files.
Actually, the differences is that
1) there is an header in my file and each data blocks begin with one or several identifiers (which are, if I can do it, also using FFIX's standart : I use the chunk type list and the object's identifiers, for instance).
2) there is no "offset constraint", so the data blocks can be however large or in whichever order they want.

Of course, my system is far from being perfect. I think the last time I looked about it, I told myself that I should have add more "Version bytes" to make the format a bit more flexible (for spells, for instance, I think I'll add to write datas related to Kikoutei-sama's issue in a separated data block instead of just writting them next to the other spell datas).

Tell me if I missed the point or if I'm not clear ^^ That's likely to have happened.
 
Hurray for my dumberness !
banane.gif

I didn't test it properly then... They're back.
 
@ Bosola : I'm not sure to fully understand you. First, models are not the only thing Hades Workshop can edit. Second, I don't know how the FF7 tools you're refering to are coded, but I tried to make the binary saves (the "Save Mod" feature, if that's indeed what you're talking about) looking alike the binary data in the FFIX disc : this way, a program reading a FFIX disc should have little problem reading my files.
Click to expand...
This is a good practice, as it promotes interoperability, but I don't think it goes far enough. You shouldn't just be saving to binary - for 'gameplay' data, I'd propose you should really be saving a model that may or may not be directly tied to the binary, then provide a compile step.

I can think of quite a few benefits:

  • It makes supporting multiple releases with the same mod codebase trivial. Someone wants support for the UK version? Just open the source and tell the compiler to target PAL/EU
  • It forces you to separate your model from your binary view in the app itself, which is probably a good architectural practice anyway
  • It lets you create an interface with a more advanced model than a simple binary editor provides, e.g. inheritance chains between monsters, re-use of global variables
  • It allows you to swap out your binary save implementation if it needs to be refactored
  • It allows you to save data in a non-binary representation, which may be more effective (e.g. plaintext, which can be subject to version control)
  • It allows players to distribute mods without copyright issues
  • If the model save uses a familiar plaintext format (XML, JSON, etc.), players can hack their own mods
  • Broken editor versions can't mess up mods as easily, and any issues are visible and recoverable if broken files are in plaintext (because you can just eyeball your mod source files and SVN->revert)
  • It's probably a good opportunity to practice an MVC design, which is something you'll need to get to grips with at some point if you intend to become a software engineer
If I were writing this tool, that's the approach that I'd take.
 
Last edited:
Status
Not open for further replies.
Back
Top