Messages

1

FF9 Tools / Re: [PSX/PC] General editor - Hades Workshop (0.40b)

« on: 2019-06-18 01:48:35 »

[...]
3) Last but not least, what about if I want to set in a "Trance Mode at start of the battle" other characters instead only Zidane, Steiner and Vivi? It's possible?
 I know there is something that enables "Trance Mode" in the main enemy attacks, is it correct?
[...]

Prison Cage; Garnet battle does this.
It has an attack that fills the Trance meter. It may be a different name in later versions of HW, but in version 0.38 its called Transfer.
in that fight there are a few important things that happen related to the trance bar filling. I'll try to show each of the important parts of the code. You can load the battle up yourself if you want to compare.

Code: [Select]

Function Main_Init
    if ( IsBattleInitialized ) {
        CloseAllWindows(  )
        Wait( 5 )
        TerminateBattle(  )
    } else {
        set SV_EnemyTeam[ATB] =$ FirstOf(SV_EnemyTeam[MAX_ATB])
        set #( VAR_GlobUInt16_33 = ( SV_PlayerTeam[MODEL_TYPE] ==$ 0 ) )
        set #( VAR_GlobUInt16_33 |= ( SV_PlayerTeam[MODEL_TYPE] ==$ 1 ) )
    }
    return
The first check is to see if battle has ended already, that seems to be normal for most battles. Then at [else] there are some commands and one of them is setting the enemy's ATB to the MAX_ATB of the first enemy. Tirlititi will have to explain how the list assignments work because I don't fully understand them, but I know that's what's happening in that line anyway.
Next we have a variable that is looking for Zidane's dagger animation model, and one that's looking for his thief sword animation model, and setting the party slot either of them is in, to VAR_GlobUInt16_33. The code does this twice for unknown reasons, the second time fully overwriting the first one.
(if you want to change this to a random party member you can change it to this

Code: [Select]

set #( VAR_GlobUInt16_33 = RandomInTeam(SV_PlayerTeam) )now, this variable is important for later, because in that fight ONLY Zidane is supposed to start with Trance, and the game needs to know which party slot he's in, in order to target him. (the battle also tracks all the other characters this way too so there is a variable for each specific character you might want to target)

Next since we already set Prison Cage to have full ATB at the start, we have the Prison Cage ATB code (I've again removed some code not related to Trance):

Code: [Select]

Function Prison_Cage_ATB
    if ( !VAR_LocUInt8_3 ) {
        set VAR_LocUInt8_3 = 1
        set #( SV_Target = VAR_GlobUInt16_33 )
        Attack( 8 )
        return
    }
    return
VAR_LocUInt8_3 is for tracking the cutscene progression for Zidane and Steiner explaining what Trance is. To begin with, its not set, so the battle checks if it doesn't exist yet (it doesn't) and then it sets it to 1, sets the SV_Target variable to the VAR_GlobUInt16_33, which it previously set as the party slot for Zidane, so now the next attack to execute will hit Zidane. Finally, it executes Attack( 8 ) which in this battle is Transfer, which fills up a character's Trance meter completely, and then returns out of the [if] and then processes some other things I removed for brevity, and then returns again to allow the game to continue into the next cycle.

If you wanted to change the character to say, Freya, in the prison cage fight, the game locates her model and stores it in VAR_GlobUInt16_45 using this code

Code: [Select]

        set #( VAR_GlobUInt16_45 = ( SV_PlayerTeam[MODEL_TYPE] ==$ 12 ) ) just like it did for Zidane in UInt16_33
A full list of character models can be seen in the Function List, under Var Code > [DATA ACCESS]

Code: [Select]

[MODEL_TYPE]
Zidane : 0 or 1
Vivi : 2
Dagger : 3, 4, 5 or 6
Steiner : 7 or 8
Quina : 9
Eiko : 10 or 11
Freya : 12
Amarant : 13
Cinna : 14
Marcus : 15
Blank : 16 or 17
Beatrix : 18
Note, that if the character you want to target is not in the battle, the code may freeze while it looks for that character specifically, or it may skip right over the Transfer attack completely. I don't know the exact effects, but if the variables aren't set correctly in the PSX version, the battle will just stall as the game tries to attack something that doesn't exist. Tirlititi may have advice on doing other things with targetting.

Battle code is all pretty new to me, but I did just look into this last night, ironically, so I figured I'd explain what I already figured out.

2

FF9 Tools / Re: [FF9] General editor - Hades Workshop (0.38)

« on: 2017-10-20 20:57:38 »

About the ID, I'll do things like that if I think about it.

About the jump animation, they are very special: the script code "SetJumpAnimation" is the only one that doesn't check if the animation is loaded in the RAM. In case that the animation was not loaded, it bugs instead of loading it. You can use things like:

Code: [Select]

SetStandAnimation( JUMP_ANIM )
SetStandAnimation( STAND_ANIM )
SetJumpAnimation( JUMP_ANIM )This will force the jump animation to load up in the RAM so it can be used.

I see! That is helpful advice, thank you for sharing. I'll have to try that.

EDIT:
That worked perfectly, thank you so much for that tip.

3

FF9 Tools / Re: [FF9] General editor - Hades Workshop (0.38)

« on: 2017-10-20 19:59:28 »

This is an unrelated comment to my previous ones, but I have a suggestion to help with editing.

Show the ID numbers somewhere in the Strings and Fields lists so they can be easily compared with the numbered text file exports.

The Fields especially take a really long time to load in the editor when it first opens, so opening the editor to check one small detail can actually take some time
(I clocked it at about 5 minutes to load all the fields, during which time the editor was busy and couldn't be used, so I had to wait for it to finish. Also each field in the list seems to take about 2 times as long to load as the previous one, which gets quite slow after going through 817 fields twice. I'm assuming that's a limitation of how they're stored, and can't be fixed.)

Having the Field names and ID numbers export to text would be helpful, and so would being able to see the ID numbers in the editor, so the names would match up.

I often use the text dump to do a mass text search to find the code I want to inspect, but once I find the right text file in the scripts, I have to figure out which field it is in the editor by counting from the top of the list.

Simply listing ' 1 Prima Vista/Cargo Room ' instead of only ' Prima Vista/Cargo Room ' in the list box or somewhere on the editor panel would help a lot.
I'm sure the same is true with Strings, but I haven't looked far into those yet.


Back on the subject of animations, it seems like some characters Jump animations might not work in every field. I'm still trying to figure out if that's the case or if I'm just doing something wrong. This is why I started the animation tester in the first place, funny enough, if only I could get it to work haha.

4

FF9 Tools / Re: [FF9] General editor - Hades Workshop (0.38)

« on: 2017-10-16 02:38:19 »

Well, I was trying to put it all inside the Zidane_Loop function... which maybe is too much code for that and won't work...
I noticed that a lot of stuff prefers to call synchronous code inside the Loop function, instead of letting the code be inside it...

Maybe I just need to rethink everything I was doing from the ground up.

Although, I didn't know about the Ex versions of the buttons... I wonder why there are two copies.

5

FF9 Tools / Re: [FF9] General editor - Hades Workshop (0.38)

« on: 2017-10-07 10:03:26 »

Apologies. Been quite some time since I checked the thread, still haven't caught up 100%.
Looking at that DB, I can already see that some of these should be easy to name. There's a number of patterns to the strings, such as ZDN being an obvious Zidane.

I'll spend some time looking at this and see if I can't hack something together for... some of it at least.

EDIT: Ok, a lot of this looks pretty easily deciphered, but is there something specific you need from the list? Character names, super short animation names, or any specific formatting?

The animationDB strings are labeled in a {ANH, what type of object uses, what part of the game used, who specifically uses, name of animation}
Some of the generic NPC names might be annoying to decipher but it should be something that can be cross referenced with models.
I'll get to work reformatting the strings for now, but if there's a specific format you want for the names, do mention it.


EDIT2:
Ok, fair warning, this file is 472 kb, which can take a while to load in pastebin, I'm sorry for that.
But this is the only way I can see to upload it...
These names aren't fully resolved, but they should be at least understandable at now.
I can remove any data from it if you want, like the NPC/Important NPC/Main category, and the Field_V# category. I believe the Field Version is something to do with quality, as higher numbers appear to correlate with being closer to the camera in fields... that's a guess, it's probably NOT important, but I left it in just in case.
There's also a list for Battle and World animations, but I separated those out because I figured most of the usage would be for field scripts. (and they would make the file larger than I could upload.)

Second warning, it will take a while to load and may stall some browsers while it does.
https://pastebin.com/D0cMB7B1


Unreleated EDIT:
I've noticed a few scripting foibles while playing with the steam version...

the IsButton family of commands do not universally work with directions and other buttons. They seem to work fine with OK, Cancel, and Card, but other things like Select may not always work. I believe this is because the Steam game has some of those functions hard coded, rather than emulating PSX controller input.

I was trying to write an animation test script, where you'd control the animation ID with key inputs to increase or decrease... it worked to a degree, but only the OK, Cancel, and Card buttons actually registered in the field, so I've been revising it and haven't quite gotten it to work yet.

I did learn two other things while doing this.
1. It may be tempting to try to assign a new model to an object that has one already, but it results in a partial soft lock. (the Exit menu still works, but the rest of the game is frozen)
2. Animations may not look very nice when played on the wrong model, but it is safe(the game won't lock) to assign the wrong animation to a model.

6

FF9 Tools / Re: [FF9] General editor - Hades Workshop (0.38)

« on: 2017-10-07 06:55:37 »

Nice to see this is still going.
I took the liberty of aggregating some information from FFIX Steam about animations.
this file is a bit of an eyesore, but maybe it will be a bit easier for someone who wants to help organize animation information.
It is by no means well organized, but its a bit more concise than the scripts themselves.

The format here is that each line represents one Model ID as noted in the script files.
The first number is the ID of the previous SetModel command, the second is the Name of that model (from Hades_strings.h), and after that is all of the animation IDs ever assigned to that model in any script. I made note of whether it was Walk, Run, Jump, Inactive, etc. If there's just a number with no text, its an arbitrary animation that was assigned with the RunAnimation command. The end of the line should have END... as the last marker, just in case the linebreaks get messed up.

so it looks like this:

Code: [Select]

192, Freya, Stand = 2556, Walk = 2553, Run = 2558, Left = 2555, Right = 2551, Jump = 12871, Stand = 6484, 12866, Stand = 12870, 6480, Jump = 12864, Jump = 12872, Stand = 805, 837, 807, 439, END...
Note that you'll see a LOT of Stand = ... in there, because the game assigns any type of repeating animation to Stand during cutscenes.

I have obviously not hand checked these. I used a machine search through all of the scripts and took it on good faith that animations between SetModel should correspond to that model, since objects always seem to assign models in object order.

I may try to organize this more later, or I may not find the time to, but I want the file out there just in case.
https://pastebin.com/wBQdu1AL

EDIT:
I did it this way because some NPCs share animations, and some animations are specific to one scene, and occasionally the game assigns running animations to the walking or standing slot, so it was sort of hard to figure out how to label any of it, so I just compiled a list of which models (should be, untested) compatible with which animations.

7

FF9 Tools / Re: [FF9] General editor - Hades Workshop (0.33b)

« on: 2016-04-24 09:21:28 »

I don't know if it helps or is new information to you, but as the steam version is built from Unity, the Mono disassembler in Cheat Engine can crack open what appears to be the full code library in use by the game... I've yet to decipher exactly how to get at the runtime values of the variables and code I found there.

Also, the character models and world map data are stored in the streaming assets/p0data* files. Had only moderate success handling them since those files seem to be a slightly modified form of the Unity raw asset packages, rather than a normal use which could easily be unpacked and repacked at will.

It seems like the UI stuff is in the maindata, resources.assets, and sharedassets.assets files inside [x86|x64]/ff9_data folder.

All in all, once the mono code is figured out, I wouldn't be surprised if the steam version was 10x more moddable, immediately. (Since everything would be coded in one place, in assembled C# from the look of it.)

Welp. I hope that's useful. This is all just outside my normal range of modding skill, but fascinating nonetheless.

8

FF9 Tools / Re: [FF9] General editor - Hades Workshop (0.33b)

« on: 2016-04-21 07:46:50 »

Tirlititi do you have any idea how much flexibility there is in changing the size of a field script? (That is, mow many more instructions can be added to a script before it gets corrupted)

There has to be some limit in theory. Some scripts are already nightmarishly long, and I'm afraid to hazard increasing them with things like switches. (Since my goal tends toward having a choice of characters to play on a lot of different maps, that means changing the preloads on many, and adding switches in place of what would normally be init_Zidane.

I suppose there may be some clever way I could store an array of information at the start, and call up whatever the value is that way... but I'd have to know where there's free space in RAM... and probably a lot of it...
I suppose I should also ask if there's a way to find unused RAM, or a global list of known RAM positions that should never be touched or something.
Those might be useful to have.

Good luck with the Steam port.

EDIT:
Unknown weapon flag 1 (the one left of Ignore Row), is seemingly a [Melee] flag--meaning it explains whether the weapon is ranged or not. It seems to work in correlation to the [Ignore Row] flag.
I have not yet tested the effects of this. It could be damage related, statistical, pseudo-elemental (as in, this attack counts as magic, or something) or something else entirely. I can confirm though, that on disk 1 any weapon that has one flag set, does not have the other.

Still pondering the 4th flag and the two mystery values. I think the two unknown integers are likely 4 unknown bytes, just by the correlation in the ranges I'm seeing. They always tend to be greater than 0x0100, meaning the 0x01 part may be part of a different value altogether.
This is just speculation, but maybe it'll give you an idea you didn't have already. *shrug*

9

FF9 Tools / Re: [FF9] General editor - Hades Workshop (0.33)

« on: 2016-04-09 08:18:41 »

if it helps, Tirlititi, to reproduce the error, I added Beatrix and then Freya to the preload list in [Lindblum Shopping Area], and after that, even if I remove them again, the game presents an unknown opcode error immediately after starting a new game.

With only Beatrix added, the game made the player object disappear in [Lindblum Church Area]. No changed were ever made directly to [Lindblum Church Area].
Both Freya and Beatrix were loaded into [function_Zidane] index in [Lindblum Shopping Area], and the Zidane_init code was changed to Beatrix's appropriate animation and model IDs.

I don't think I changed any other data anywhere near that part of the game.

How many models can the preload list hold? I think the game supports up to 0x25 individual function calls (I read that somewhere in a hacking note related to a codebreaker code)

10

FF9 Tools / Re: [FF9] General editor - Hades Workshop (0.33)

« on: 2016-04-07 21:03:56 »

@ Satoh : I've a list of all the cluster datas and I can easily check the objects' ID. That way I know which model IDs are field-dependant and which are not. For naming them, I looked at the game's script and listed them when I could identify them (there are still a lot of unnamed model IDs btw). I don't think they have any label indeed.

It is strange that they would use the same index to refer to each model every time, when they are in different places in each field's data. It seems like there must be a master list somewhere that tells the game why [192] is Freya and [74] is Erin...

Also, there seems to be a problem with adding new preloads to a field in some cases. For example, adding a preload to the list in Lindblum Shopping Area, breaks the model loading in Lindblum Church Area. Adding two causes the game to break altogether with an error of [unknown opcode 0x3F]

Second:
I don't understand what preload list does to the data, but I suspect it may be overwriting part of the RAM or ROM data from the other field. You may want to add a size check and warning/error if this happens. Just a suggestion.

11

FF9 Tools / Re: [FF9] General editor - Hades Workshop (0.33)

« on: 2016-04-06 03:15:16 »

This brings me a significant step closer to the kind of mods I wanted to make! Awesome, Tirlititi. I didn't expect the model loading to be done so quickly.

I'm curious as to where you found the model IDs (Zidane 98, Beatrix 204). One of my end goals would be to archive all of the NPC models in the same spot as the player models. Hexediting can do that of course, but it won't mean much unless I can begin to understand how the models are organized and labeled.

The models themselves don't seem to have a label anywhere... or not one I've found.

EDIT:
I do realize adding more things to the player model archive with push other data somewhere else on the disc, meaning I'd have to modify HW to look in a new place for it too. But the question is still 'how to better understand why those models are different'

12

FF9 Tools / Re: [FF9] General editor - Hades Workshop (0.32)

« on: 2016-04-04 01:21:18 »

Yes tiff doesn't seem to have any layers when you open it up in phtoshop. Might be a problem in the future if you'll ever make it possible for people to reimport pictures. But I doubt anyone will ever do that, you can't make the backgrounds higher resolution anyway. I'm trying to recreate the pre rendered effect in another engine and I thought I'd use one of the backgrounds from ff9, if I could export a character model from the game and it's animations too. I could basically recreate a scene exactly as it is from ff9. It's not a big deal, but if you want it to work you could maybe make it work somehow.

I had every plan to reimport new backgrounds at some point. Not everyone cares about a higher resolution.
As I stated Lein, there are other programs that already export the character models and animations to usable formats.

13

FF9 Tools / Re: [FF9] General editor - Hades Workshop (0.32)

« on: 2016-03-29 08:16:07 »

I honestly don't know anything about the blender game engine. There is an addon that allows you to animate just about everything in blender, called AnimAll. Turn it on and you should be able to keyframe any property by hovering and pressing I. The property you want for the frustum will be in the Camera settings (with the camera itself selected that is, not the regular render settings) and its called "Shift" there will be one for X and one for Y. I don't know anything about object tracking. I know blender has it but I don't know if it has the features needed for FF style panning.

I honestly don't have the time to do any coding for it in either Unity or Blender though, otherwise I'd probably have shown an example... Also finally, lets not get too far off track, this is a thread for Hades Workshop.
Recreating the functional engine of FFIX would probably be best discussed in its own dedicated thread... though I've never had luck actually recruiting coders who had more experience than myself, which is probably what you'd need to do, if you don't know how to code...

Also, worth noting, FFIX for PC will be out soon enough, and may open the door for a lot more modding possibilities.

14

FF9 Tools / Re: [FF9] General editor - Hades Workshop (0.32)

« on: 2016-03-29 04:30:22 »

What I'm trying to say is, computers can render cameras "off center", which is to say, you can move the portion of what is being rendered around, without changing the focal point of the lens, only the edges what it sees. This is what FFIX does. (You'll note in a few places, the character models seem to stretch ever so slightly at different places in the map, that's because they're past the part of the camera lens that would normally be clipped off, and the perspective calculation has become unrealistically drastic....It's hard for me to describe it, but I may be able to show you with a picture.


Here we see two cameras. the pointed part on the bottom is where the camera is, and the rectangular part is 'what it can see'. On the left is a normal camera. Its focal point is directly in front of where it is in space, and what it can see is equal on the left and right of that focal point.
The right camera also has its focal point directly in front of it, but what it can see, has been shifted far off center, to the right, with anything to the left of the focal point being cut off completely, but much more being visible to the right of it.


Here we see the camera on the left, looking at a cube that is slight off center from it.


And here we see the what the camera on the right sees when looking at the cube from the same location and pointing in the same direction as the first.

Note that the cube looks exactly the same, but appears in a different region of the render area. This is because the camera's position and angle never moved. Only the edges of its periphery were changed.

You can imagine it like being able keep your eyes pointed forward, but shifting your brain's attention to the things in the corner of your eye, instead of what they're pointed at.

That's what I mean by "changing the frustum matrix"

15

FF9 Tools / Re: [FF9] General editor - Hades Workshop (0.32)

« on: 2016-03-29 00:43:52 »

When the camera pans around a scene in FFIX, the camera position does not change. Only the edges of the frustum are altered. It's easy to manipulate cameras in that way in Blender, and the same kind of matrix is used in Unity, though it does require some scripting to alter the camera matrix in that way...but its not really difficult.

The background images aren't rendered anywhere in the scene at all, they're UI elements that have a layer number, which represents a 'distance from camera', and is used to determine when the image is rendered. Closer imaged to the camera get rendered later, so they appear on top of other images and objects.

What I'm trying to say is, its not as difficult as you seem to think it is. Unity already has all the functionality you'd need to do it, probably in only a small number of lines of code, using generous amounts of Camera.ScreenToWorldPoint(...)

You're thinking about the maps as though they're 3D scenes, when really the only 3D part about them is the walkmesh and character model. Everything else is done through 2D layering the same way as menus and speech windows.

As for the camera moving around the scene, it doesn't happen, except in a select few places, and that uses prerendered video with characters dropped on top of it. Those scenes don't support objects overlapping the character models at all, and you can see them actually in front of the foreground in some of those scenes, if only for a few frames, because of that limitation.

16

FF9 Tools / Re: [FF9] General editor - Hades Workshop (0.32)

« on: 2016-03-28 18:00:58 »

Oh, I see, you want to replicate the functionality of FFIX, in another game engine?
I can respect that, I've wanted to do something similar for a while, but lack the experience to make a robust engine like FFIX.

I don't know that its exactly how FFIX does it, but the you can make a camera pan by altering the width and height and offset parameters of the frustum in any engine that lets you alter the camera matrix. This would keep the perspective vanishing point locked in one place,(in 3D) while moving the rendered image around on the screen.

Does that help?

As for the layering, unity allows for rendering layers, such that even if an object is behind another, it gets rendered later, and thus on top of everything else.
I suspect the hardest part about replicating FFIX in Unity would be the battle stuff.

As for using the models... that's a tricky subject. I have them, but because of the way they export, one model only supports one animation, so in order to use them one would need to export a duplicate of each model, for every animation. I'm strategizing how to get around that.

For now, I think the best option would be to try to work around the problems you might face in HW, as some cool things can be done with it, if not everything you might wish.

For example, beginning the game in the Festival of the Hunt (which is my pet project for HW. End goal: have a choice in playable character, more enemies and getting into scraps with the other participants.)

17

FF9 Tools / Re: [FF9] General editor - Hades Workshop (0.32)

« on: 2016-03-28 08:07:39 »

First: I in no way intended to imply that I had anything to do with developing Hades Workshop. I'm just a technically minded guy who kinda understands how the game works.

Second, the backgrounds are static images, and there's a script function that replaces some of the tiles with other tiles stored in the same field map, waits a number of frames, and then replaces them with another tile. I don't comprehend 100% how that works yet, but I am quite certain I can spot it when I see it.

You're mostly right on how the camera works, except that it can be changed and moved in the game for specific things. There are a few scenes where the camera moves during a cutscene where the video replaces the background, like in the Evil Forest just after escaping Alexandria at the start of the game.
The camera also moves when looking at different angles of the same room in a map... this happens rarely, but is first seen when Baku (in a dragon mask) jumps from the door. That door is not a new room, just a different camera angle, with a different background image applied to it.

To properly comprehend how that works, I should explain that the walls of a map are actually determined by the shape of the floor... or in other words, you can walk anywhere there is floor, and you can't walk where there is no floor. This theoretical floor is called the walkmesh, and is a 3D model.... just an invisible one. You can actually view a map's walkmesh in HW by opening the script editor and switching the tabs down in the lower left corner.

I'm not sure on the practical side of replacing images, as I said I haven't tried it, but in theory, all you need to do is make a render or painting of the area you want to replace, cut out portions of that picture that need to layer on top of the character in the foreground, and probably some stuff with chopping the image into tiles... I don't think HW handles that yet... for the same reasons it doesn't do preloading models correctly: It would involve a lot of shuffling data around in a messy complicated way.
background images are stored as a collection of 16color palettized tiles that are 32x16 and there can be... I'm not sure exactly how many palettes for a full map. Part of me wants to say 32 per tile package... and some fields have multiple tile packages... The game is kind of a mess looking at it from a 'I want to make changes' standpoint. It was all done for hardware limitations of course, and it performs admirably as a game... but its certainly not user friendly for mods. I'm honestly astonished HW has so many working features.

About character models and such, most of that can be viewed by a program called noesis. You can look that up on your own, as I'm not totally sure how Qhimm handles that topic these days. Last time I came around it was kind of a hotbutton.

As for 'how they made the backgrounds' themselves... They did it in a 3D modeling program, put in loads of detail, rendered a high quality image, then shrunk it until it was small enough to fit in the game. No big mystery really. And actually, some of the stuff you see in the scene may actually be lower in actual quality than the models you see in realtime in modern games... even as old as early PS3 games. They only look nicer most of the time because you don't see them up close. A lot of them have really terrible texturing (there are a few original high definition renders floating around the internet, but only a few), but it looks nice enough when its pixelated. Its kind of like looking at 1990's 3D cartoons... they were amazing at the time, but you look back and realize how awful they really looked up close.

For an example of how the animated tiles work, you can look at Environment Tab > Field Tab > Prima Vista/Engine Room > Edit Script > Function Code1_Loop.
In Code1_loop you should see a number of SetTileAnimationFrame(...) calls. That's where I'd look to start understanding it.
It also helps to be able to run the game with the patch automatically loaded, rather than having to actually patch a copy of the game every time you edit something. I find frequently changing, exporting a PPF patch, and using an emulator that automatically loads the patch while running the game, is an effective way to learn how code works.

18

FF9 Tools / Re: [FF9] General editor - Hades Workshop (0.32)

« on: 2016-03-27 17:50:28 »

HW doesn't truely need the option to export character models, as there are programs that do that already, and exporting them into a usable format would require a lot more effort than, say, making the preloading work.

In theory preloading would source a model and its animations from an existing field, and inject them into the archive that holds the field you're trying to change.

Which would of course be a complicated undertaking, but it wouldn't involve any format alteration. (I'm currently contemplating that issue myself)

That's not to speak for Tirlititi directly or anything. I'm just stating how I see it. There are more important features, and there's a lot of scripting opcodes which are indecipherable...

As for battle scene import, I think its likely that it doesn't work perfectly (as I said before, converting between model formats is no simple process), and possibly you may not have handled the textures correctly... I've never tried it myself. The textures the game uses are a specific 256 color palettized image format, so they can be recolored multiple times, while remaining very small on the disc. This means most images will not work, as they will be in raw 16million color formats.

Of course it's also just as likely that the feature is simply buggy, not for lack of effort, but just because PSX games are pretty strict about what they can and can't load, so any seemingly benign tweak may simply be impossible without better understanding the format.

Some games can only load vertices that fit in an area that is no more than 127 integer divisions away from 0 in any direction. Other games may go as high as 32767. It could simply be that whatever you tried to change, wasn't something the game could load, or possibly, wasn't something the conversion function could handle. There's a lot of possible points of failure with things like this.

It seems likely to me, that adding new vertices, probably won't work without first deleting an equal number from some other area in the scene, as well as counting triangles in the same way. The disc has limited space for storing these things (very very limited) The game also has specifics on what it can and can't do with UVs (some programs can't handle one vertex having multiple sets of UVs).

And as I said, you probably used the wrong kind of image.

19

FF9 Tools / Re: [FF9] General editor - Hades Workshop (0.32)

« on: 2016-03-24 18:30:24 »

I did some testing, I have an answer on the second parameter of setModel.
It determined the height adjustment for message windows, the 'player is here' pointing cursor, and probably some other 2D UI elements.

That's why the moogle's is so high, it's already a flying model.
Incidentally, you see similar things in pigeons, which fluctuate between 93 and 37, which I assume is for the ones that fly versus sitting on the ground.

It also seems to affect the head's up and down tilt for head-look operations. When I set Zidane's to 255 his speech bubbles appeared nearly at the top of the screen, and he looks up into the sky instead of straight ahead when talking to Blank, who is about the same height, right in front of him.

Hope that helps in some way.

20

FF9 Tools / Re: [FF9] General editor - Hades Workshop (0.32)

« on: 2016-03-24 03:27:29 »

Hey Tirlititi, first, brilliant work on HW so far. I've messed with it for a while, in a lurky fashion.

Second, I've done a lot of stuff with the file structure of FFIX... or at least enough to be familiar with what's where in a few cases.
That's where my question comes in:
Main character field models are stored globally on the disc... or at least separately from the models cached in the fields themselves.
With that in mind, I'm confused as to why I can't add Freya or Beatrix(characters who are in the party model folder) to the Preload list and load them up in script.
I understand with NPC models, as they're stored in the field itself.

The option to add models to the Preload list is present, but does nothing.
I guess my question most directly is "Is the preload list just a placeholder feature?"
Changing it doesn't actually do anything, except in the editor's internal memory?

Preloading an NPC from a different field, would obviously take a lot of work... but preloading a party member seemed like it should be something that works.
I'm just trying to find out if I'm misunderstanding something, or if the feature really does nothing at all yet.



On a slightly different note, do you have any theories (its listed as unknown, but I'm curious about conjecture) on what the second argument to SetModel does? the argument generally appears to be the same for party characters (that is, Zidane is usually given 93 as the second arg, and Vivi is given a different one, but its usually the same for the same character).

It occurs to me that the parameter might be a radius for the collision area, so models don't clip into each other.

21

Team Avalanche / Re: So.... whats happening?

« on: 2011-01-12 17:51:48 »

I've noticed that the resource list for bombing mission hasn't been updated with all of the models that have been done and such... Can someone list to me what still needs to be done, in terms of objects and people and such? (not ready to do any BGs...)

Or for that matter, anything that needs doing in general for wherever the project is currently moving?

22

Team Avalanche / Re: New Project: Bombing Mission!

« on: 2010-05-15 21:44:37 »

IIRC it is in the assault on midgar later in the game just before fighting Hojo... I think I recall fighting N^st Ray style enemies then...

23

Team Avalanche / Re: *Team Avalanche: WMRP(WorldMap Retexture Project)*

« on: 2010-05-09 18:53:27 »

The first computer to be proposed to use a mouse with a graphical OS was the pitched idea for the first PC that was pitched to Xerox.

It had a 3 button mouse. Xerox thought the idea was stupid, no one would need a "personal computer."

Good job, Xerox, good job.

Anyway, what's the status on the world map anyway?

24

Team Avalanche / Re: New Project: Bombing Mission!

« on: 2010-05-09 08:40:54 »

Ok, I'm considering doing something for the field models since no one has claimed many of them... but I can haz kwesschuns.

First off I need to know how much detain needs to be 3D in the face, and what parts of the face are even getting detail at all...
Also, I'm going to assume we're using fists for hands, and they should likely bleed into the elbows... like the originals.


If you all recall the original characters didn't even have mouths and most characters had ambiguous noses...

IF I decide to work on this, I'll probably be taking Jessie and the Train Guards... so put them down as... ehm... well, I guess nothing really since I haven't decided yet. But my finals are finally over, so I can chill out for a while and do my own thing... I can already feel my heart beating at a steadier rhythm...

But yeah, anyway, are we modeling full faces on the field models, or are we glossing over them and using textures only, OR even still are we just leaving the eyes and that's it? (I really don't want to make a million faces... they're so annoying...)

Wedge is lookin' good BTW.


Oh yeah, and are we able to use multilevel transparency in textures yet?

I may take a look into the MonoDrive enemy... it's so small I could redesign the whole thing and no one would notice... not that I would...
Is the monodrive a biological enemy or a mechanical one? All I can tell is that it's a pink ball with loliar--tentacles...

It looks like some sort of mutant plant, but I recall it doing things like "Scanning" and calling out other very mechanoid phrases...

Anyway, if someone could please get back to me relatively soon I'd appreciate it.



EDIT: Also, here's a great place for original concept art... might not have everything, but it has a good bit.
http://www.creativeuncut.com/art_final-fantasy-7_a.html

25

Team Avalanche / Re: Team Avalanche Main Cast Project

« on: 2010-05-01 21:50:55 »

Would it be possible to port FF8 field animation system? I mean the field models from there are like the battle models.

Not only what Covarr said, but FFVIII's battle and field models are vastly different in terms of detail. They are far from, as one might believe, identical. They don't even contain the same number of bones in FFVIII.

There's really not much separating the FFVII and FFVIII engines technically. One could be used to remake the other with few workarounds.

I just felt I should point that out.