[PSX/PC] Battle editor - Proud Clod (1.5.0/FINAL)

  • Thread starter Thread starter nfitc1
  • Start date Start date
Status
Not open for further replies.
I second what Destro said. Stellar program. If I had to address a critic now, it would only be the fact that, as a full-fledged Scene.bin editor, it is somewhat less accessible than Hojo. What I mean is, when you select a particular scene (for example scene 10, with Devil Ride, Kalm Fang & Prowler), you don't instantly see the enemies' stats, drops and the like. You have to click on Enemy Management, then Enemy stats before you can alter those. For this reason, if I wanted to edit something Hojo can modify, chances are I'll still open Hojo (quicker access to what I need to be changed, and I can easily compare each enemy's stats).

So, I really think the "Enemy stats" window should be the main one, while the attack editor should be an option. The best thing though, would be to have both (or all features ?) in the main window. I'm not a big fan of tab-browsing - the more info you can squeeze into the main window, the better IMO. I admit though, that it's nitpicking on a high level. Two clicks won't kill me (but I've been using Team-Viewer a lot lately, to control my home PC with my ipod when I'm not at home, and two clicks mean something in Team-Viewer).

Anyways thank you again, this made my day  :D
Click to expand...
I've intended to make this a suite since adding the AI editing. I don't have the skills to do that yet, but that IS the next bullet point on my TODO list. I'm not crazy about the organization of it all, but as soon as I figure out how to change it to something more accessible I will.
 
Ha I understand, thanks for the reply. I'm beyond happy with 1.5.0.α_3 as it is anyways ^_^
Well, time for me to go back to modding :-)

EDIT:

The same problem still occurs : in any given scene, nothing regarding the third enemy's drops/morph/allowed statuses/... can be saved. I don't know if I should laugh or cry.
At this rate, the not-saving bug will truly be "Fix'd" in 1.5.0.α_10.
Small tip : if you have trouble testing things by yourself and need someone to do it before publicly releasing a new version, I'm right here (you should have my email address).

It really looks like you can't try your own program by yourself and only use our feedback to fix things. If that's the case it's no problem (perhaps you don't develop PrC on a computer where FF7 is installed / where a scene.bin is available ?), but please tell us. So instead of typing "many enemy stats aren't saved", we'll list them all so you can fix them once and for all.
 
Last edited:
The same problem still occurs : in any given scene, nothing regarding the third enemy's drops/morph/allowed statuses/... can be saved. I don't know if I should laugh or cry.
At this rate, the not-saving bug will truly be "Fix'd" in 1.5.0.α_10.
Small tip : if you have trouble testing things by yourself and need someone to do it before publicly releasing a new version, I'm right here (you should have my email address).

It really looks like you can't try your own program by yourself and only use our feedback to fix things. If that's the case it's no problem (perhaps you don't develop PrC on a computer where FF7 is installed / where a scene.bin is available ?), but please tell us. So instead of typing "many enemy stats aren't saved", we'll list them all so you can fix them once and for all.
Click to expand...
The third enemy? That's oddly specific. I'll take a look. It's likely the index didn't get set properly. Then if it's not throwing an error it might be overwriting another enemy's data.

EDIT:
Fixed it. See blog for more details.
 
Last edited:
Wow, that was fast !  :o

Downloading Alpha 4 now. Thanks so much for being so reactive :)
 
It hit me as I was fixing this that I want to make it more like the tool Square was likely using to create the scene.bin in the first place. What I envision is there are entries for enemies, attacks, and scenes. Specifically, a list of each and a form for each. During saving, the tool would combine them all based on the formation data entries.

Enemy Data:
There would be spaces for 397 enemies (Models AADA - OFDA) that would each have their own stats, animations, required attacks, and AI assigned to them. This will be crucial for keeping enemies "synchronous" between scenes.

Attack Data:
Ranging from index 100h - 7FFFh for the same reason. They would each have attack values like the standard attacks.

Scene Data:
Between 00h - FFh and contain formation data, formation AI, camera placement, and which enemies would be contained within.

All this would be presented in an MDI format (individual windows, not tabbed) and can be used to compare enemies and attacks with each other. If you're familiar with either Morrowind's or Oblivion's Construction Set you know what I mean. Optionally, it would also allow importing of KERNEL.BIN attack data, attack names (both of which trump scene.bin attack data), and item names for consistency's sake. Optimistically, it would also allow importing the char.lgp to actually view the animations (currently this is WAY out of my league).
That's where I'd like this project to ultimately go. That would require a rather substantial re-write of the interface and I'd probably start from scratch on that. Theoretically, this envisioned tool could create a scene.bin file FROM SCRATCH!

Question: Is that what YOU, the end-user, wants?
 
It hit me as I was fixing this that I want to make it more like the tool Square was likely using to create the scene.bin in the first place. What I envision is there are entries for enemies, attacks, and scenes. Specifically, a list of each and a form for each. During saving, the tool would combine them all based on the formation data entries.
Click to expand...
WANT
 
Nice. I'm glad that got a good response. I figured it would. I'd like to apologize for the visual atrocity that PrC has become. Since it was originally just an attack editor it made sense to just keep adding little piece by little piece on to it.

I've been working on the interface for about an hour and I like the direction it's going already. Most of the code is written already (which is good) so it's really copy-pasting and a few days work to get it all together. Don't fool yourselves into thinking it'll be done in a few days, that's just the cumulative amount of time it'll take to finish it.....when I get the time.

Now what I need is some artistry. I'd like to add a little more pizazz to this redesign. What I'd like are 32x32 pixel icons for enemies, attacks, and scenes. I'm thinking something like http://www.finalfantasykingdom.net/dissidia/bomb.gif for enemies, maybe the buster sword for attacks http://geekskillz.com:50000/images/buster_sword.gif, and a basic blue squares vs red triangles for scenes. Any other ideas?

EDIT:
The more I play with this idea, the more I abso-freakin'-lutely LOVE IT!! This is going to be cool, but potentially memory demanding. I didn't ever retain more than the scene.bin's size plus two times the size of the uncompressed scene being worked on (just over 271K). Now this new interface is holding data for each unique attack, enemy, and scene. That's a LOT more data to hold onto, but it's SO much more organized and easier to keep up with what's changed.
 
Last edited:
If you require assistance on the UI design front, I'm happy to give advice. My experience is more in laying out web service pages, but I've practical experience in the field PC deals with.
 
I think you might get dependance on the kernel (already discussed I think) and battle.lgp so that we see potentially new names, models and all. Also, you might want to allow us to open any .BIN file instead of a one naming scene.bin so that it is easier for modders. Also, let us choose which kernel.bin to check data in, instead of the one in the kernel folder. Also, make all windows resizable and all, even is just diagonaly (because I sometimes want to open 2 scene.bin simultaneously and my screen isn't big enough).
 
I think you might get dependance on the kernel (already discussed I think) and battle.lgp so that we see potentially new names, models and all. Also, you might want to allow us to open any .BIN file instead of a one naming scene.bin so that it is easier for modders. Also, let us choose which kernel.bin to check data in, instead of the one in the kernel folder. Also, make all windows resizable and all, even is just diagonaly (because I sometimes want to open 2 scene.bin simultaneously and my screen isn't big enough).
Click to expand...
Dependence on the KERNEL.BIN? No. Highly suggested encouragement of it's inclusion? Definitely. Like I said earlier, I want this to have the ability to create a scene.bin from scratch. I've already got that in place. I'm convinced I can create one from scratch based on the way I'm going with it.

Less restrictive file naming convention? You got it! That was easy. :)

Resizable? You got it! Now that this will be an MDI interface, I can restrict the size of the individual attack panels and still give you the ability to resize the overall container window. All those annoying focus-related issues will go away too! You can have multiple attacks or multiple enemies (even multiple windows PER enemy if you desire) viewable at the same time, be able to switch between them, and have the ability to save changes whenever!


Another epiphany:
Attack data will tend to look the way it used to, but I'm still going to have some tabbed browsing for enemies and formations.

Enemies will be divided into the following tabs: Stats; Animations (including allowed attacks, modelid, and berserk/manip attacks); AI. This way I can still make prime use of real-estate. The Animations tab will allow you to use ANY attack rather than just the thirty-two in the scene already so it might take a while to load. I'm going to see if I can do some sort of data-binding to reduce this lag.

Scenes will have the following tabs: Formations (including flags, background, enemy placement data in a similar format to what it was before); AI. I'd also love to keep the Preview button, but it'll likely be a while before I include the battle.lgp (not the char.lgp that I mentioned earlier) for model importing. I'm still not good at the animations and stuff.
 
What about to let us choose which kernel to patch? Can you make it that the dumped scenes are text files? If I understand correctly, we can have dozens of windows and be able to switch between them all? Awaiting badly for the true release of 1.5.0!
 
It hit me as I was fixing this that I want to make it more like the tool Square was likely using to create the scene.bin in the first place. What I envision is there are entries for enemies, attacks, and scenes. Specifically, a list of each and a form for each. During saving, the tool would combine them all based on the formation data entries.
Click to expand...
I've been reflecting on this. What 'development' tool did Square use? More importantly, what general 'development' tool best fits our requirements as modders?

My thinking is this: rather than even talking about separate KERNEL.BIN, SCENE.BIN, LIMTMENU.MNU etc. editors, what about, as an ultimate ambition, a 'general' FF7 mod IDE? Think an application that can work in an open-standard project file format, handling notes, flags, revision histories and user-defined groups, that can take the contents of an FF7 ISO and output a new, modified disc / patch file. An IDE that can automatically handle YAMADA.BIN (file table) modification and insert 'global' AI scripts (common AI scripts used to hack functionality, like our Poison=Disease script). An IDE that needn't be rewritten when new files are researched / alternative files are written, thanks to an extensible XML-based resource directory.

Would be a massive undertaking, though. Might have to park it until, ooh, 2016.
 
Last edited:
...
Would be a massive undertaking, though. Might have to park it until, ooh, 2016.
Click to expand...
Yeah, you get right on that, let me know how it goes. :)

Kidding aside, I doubt there was one great "omni-tool" that was used for every piece of the game. It would be likely that there would be one great battle-related tool that would end up creating all the resources like menus, stats and attacks for both player and enemy-related data. Perhaps some day I, or someone else, will combine the functionality of PrC and WM with some form of menu editor.

As an update to my current progress things are looking positive. I was able to sucessfully open at least thirty attack windows and manipulate them all. However, in order to do that most efficiently, I made the attack sat a window to be tabbed. This seems to be a good thing because I can make some labels be more descriptive. For instance "No re-target" got changed to "Will not re-target if target is disabled" and "One Row" got changed to "Cursor cannot switch between enemies and allies" and stuff like that. I was going to make a fraps of it and post it on YouTube, but I'll probably wait until it has more features ready
 
Optionally, it would also allow importing of KERNEL.BIN attack data, attack names (both of which trump scene.bin attack data), and item names for consistency's sake.
Click to expand...
Yep, you need the item/materia (can enemies drop materia?) names, Hojo couldn't do that and it really made things difficult.
Question: Is that what YOU, the end-user, wants?
Click to expand...
Well, I want to basically completely modify the game, so yes.
 
Yep, you need the item/materia (can enemies drop materia?) names, Hojo couldn't do that and it really made things difficult.
Click to expand...
When Hojo was developed KERNEL.BIN hacking wasn't happening. Since text of items wasn't changing there wasn't much point to allow a different set of item names. This new PrC will accept either KERNEL.BIN or kernel2.bin attack/item names (no, enemies never carry materia either dropped or stolen. You either find it or buy it).
I also realized as I was digging through the asm of attack indexes listed in the scenes that the attack data for KERNEL.BIN based attacks DOES INDEED need to be in the scene for only one function: determining MP cost. It looks like if the command index is 20h (from the 92 command) then this function will look through the attack data from the scene and pull MP data of the attack from that. If I'm reading the rest of the code right (including that) then that's really the only place that the game cares if KERNEL.BIN attacks are in the scene.
 
Small bug report : the camera override doesn't save for -at least- the first enemy.
 
Small bug report : the camera override doesn't save for -at least- the first enemy.
Click to expand...
Can you clarify that? I don't know what you mean by "camera override".

I did find a pretty glaring error while looking through this. The actual formation data, the stuff on the "Formation" tab, will be saved to the scene data as you edit it. Even if you hit cancel those changes will still be made.   :-[ That is, obviously, not a good thing. I'll fix this after Armorvil tells me what he meant.
 
Yeah, the "done" button doesn't do a thing, and "cancel" closes and saves the changes. Still, it's no big deal.

What I meant by camera override is : camera override. This is what it's called, and this is what it does :P
But this is just me being annoying. If you need more precisions, this is in the Animations/Formations window, in an enemy's tab. At the right of each attack, you can assign an animation. Then, at the right of the animations, you have a field called Camera Override. Basically, this forces a new camera data for this particular attack. Since my modifications sometimes turn a single-target attack into a multi-target attack, I need to change those values (so the camera doesn't zoom on the middle character when said attack hits the whole team). In previous versions of Proud Clod, the data in those fields was always saved - but not in PrC 1.5.0.α_4!  :'(

If you change a camera override value, close the animations/formations window, then open it again, you'll see your modifications - implying it will save. But alas, if you save your scene.bin, the data reverts to its previous state.

Oh yeah, and now that I'm at it, there is another bug - regarding AI editing this time. When you create a new line and type the 93 opcode, the program instantly displays an error message. And once, after I added many different 93 opcodes, the program would start to automatically add lines consisting of 00s below them (opcode being 00, argument being 00 00). And everytime I'd delete those unwanted lines, they would keep coming back after closing and opening the AI window again -__-

So I had to use Proud Clod 1.2.0.0 to do my AI editing, since it looks like it handles AI editing with more stability somehow.
 
Last edited:
Status
Not open for further replies.
Back
Top