Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Tirlititi

Pages: [1] 2 3 ... 19
@Tedrainbow: Hum ok, it's been a while since you asked and I thought you did that already.
So, apparently, what I described before only allows your stat growth to break the limit, but the limit still applies for equipment stat boost.
So, you need to also change the method "ff9play::FF9_GetSkill". Near the 4/5 of the method, you'll find lines like these:
Code: [Select]
ldfld 0x40008AD // FF9PLAY_SKILL::Base
ldloc.s 6
ble IL_0328
ldfld 0x40008AD // FF9PLAY_SKILL::Base
Just replace the line "ble IL_0328" by "br IL_0328" and it should remove the limit totally.
It is not easy to choose the limit yourself by CIL code editing because the limit is stored in an unreachable array ("<PrivateImplementationDetails>::$$field-545").
In practice, it will then be that the base stats are limited (by whatever limit you want) and the equipment stat boosts can still increase that limit a bit.

@Tedrainbow: Maybe you import the atlas file in a RGB format (Alpha channel, ie. transparency is not imported). In the Unity Assets Viewer's image options, you can choose the "RGBA" compression method to be sure to import the image without compression and with its transparency. If I remember correctly, the DXT5 compression method can use about 4 shades of transparency.

MIPS is the assembly language of the PSX. It doesn't exist anymore in the Steam version and is replaced by CIL code.
It is possible to move other characters than Zidane (actually, you just need to use the script code "DefinePlayerCharacter()" in another entry than Zidane's entry) but you'd need to script all the animations that come with that. Zidane can have an interaction with a lot of stuff through the game and sometimes has specific animations for these interactions that other characters just don't have.
This has nothing to do with MIPS but with Field scripts, by the way.

@ToraCarol: Albeoris's Memoria tool is able to change the text font of the game easily, but it's incompatible with HW right now.
But apparently, the tool dnSpy allows to edit the Assembly-CSharp.dll by changing the C# code, which is just as great. You can change the font by replacing the declaration of the variable "defaultFont", in the "EncryptFontManager" class, by this:
Code: [Select]
public static Font defaultFont = Font.CreateDynamicFontFromOSFont( "Arial" , 16 );"Arial" is the font name and "16" is the font size (you can change them to your convenience).
Here's a list of fonts you can use.

@Tedrainbow: I don't really understand.
First of all, this red light is not part of your problem, right?
Then, changing the primary stats bonuses in the "Items" panel should be enough ; there's nothing else to do to mod the items primary stat boosts (the only thing is that they use "Stat Sets" and modding the stats boosts of 1 equipment can have an impact on other equipments if you're not careful).
It was working fine a couple of HW versions ago, and I didn't touch that part of the tool, so I guess you're doing it wrong. But if you can't fix it, I'll have a look.

About CIL code, I'm not planning to add nor to fix anything from these panels. I know that they are useful for plenty of things that people generally want to mod, but these panels were added more like a precarious feature waiting for something more convenient.
As said, it looks like dnSpy should be a better solution right now (I didn't test it yet but I'm definitelly interested in that).

Ok, so lot's of things there :/

1) The problem lies somewhere else. Modifying the script should have no impact on what happens after the SquareEnix logo. Script modifications are in the file "p0data7.bin" and, if you get an "Assembly-CSharp.dll", that means you're modifying something else.
I don't know what could cause this bug with the latest version of HW. You may try to update your FF9 game by going to your Steam's game library -> right-click on FF9 -> Properties -> Check the integrity of local files. It will update the game to the latest Steam release and replace the modded files (it won't remove the .hws files and it's always better to have your mod in that format as well ("File -> Save Mod" in HW)).

2) So, if I understand correctly, nothing happens in-game if you do that? No bug, but nothing changed?
If so, it may be because of:
- Either your "Blank_Init" function is wrong ; since your "Blank_SpeakBTN" is correct, I feel that you did the other one just fine,
- Or you forgot to add a line "InitObject" in the "Main_Init" function: you should have a look at it and see a bunch of those "InitObject" lines, each corresponding to some 3D model on the field,
- Or you made the mod in one language and play the game in another one (the default language is "English (US)" in HW, you can change that in the "Files -> Preferences"). Scripts are language-dependant.
- Or, as Incinerator said, you copy the files in the "x86" folder of the game while playing in "x64" mode. If you copy the modded files in both folders, you're sure to be good in that regard.

3) It's a bit complicated: Blank uses the same slot as Amarant, so you can't have them both in the team at the same moment. Since Amarant is already there (as a party member) in the Pandemonium scripts, the best is to consider Blank as a NPC if you want to add him in cutscenes.
There is only one feature that is different between playable characters and NPCs in the scripts: it's the possibility to refer to an entry (in that case, a 3D object) that corresponds to the characters in your party. In the "InitObject" line, for instance, one can use "InitObject( 251, 0 )" to refer to the 1st character in the party, instead of doing things like:
Code: [Select]
if (IsInParty(0)) { // If Zidane is in the party
    InitObject( 10, 0 ) // Init the 3D object and functions corresponding to Zidane
if (IsInParty(1)) { // If Vivi is in the party
    InitObject( 11, 0 ) // Init the 3D object and functions corresponding to Vivi
// etc...
Except for that feature, NPCs and PCs are handled the same way.

4) That picture is in the "sharedassets2" archive (like most of this kind of pictures).
When you "right-click -> Export selection", it exports the file in the folder "HadesWorkshopAssets" (in the game's directory) as you saw. You may edit the file from there (if you have the option "Automatically convert images to PNG", as I recommand, you should be able to edit the file with any image editing tool). In order to re-import the modded file in the archive, you must be sure that this modded file is in the "HadesWorkshopAssets" folder at the same place and with the same name as when exported (in this case, there should be no ".png" extension because the file doesn't have an extension in his name in the archive). Then just "right-click -> Import Selection" should popup a message, either saying it was successfully imported or saying that it failed.
The general politic is that the Unity Assets Viewer expect the re-imported file to be in the same format as the exported file, ie. it expects a PNG image if you have the "Automatically convert images to PNG" enabled.
And to complete, the archives are indeed duplicated (except for the "Streaming Assets" archives) in two folders, "x64" and "x86" and only one of them is used by the game. You may switch folders in the Unity Assets Viewer in its options, or you may indeed copy-paste the modded archive to the other folder as well.

It's the field that is loaded when hitting the "New Game" button. It basically launches the opening cinematic and move to Prima Vista/Cargo Room.
It used to work fine. I guess that it crashes because it has no background or walkmesh ; I'll fix it.

Variables of type "General" (Var_Gen...) are the ones saved in saved games. It doesn't matter whether it's an auto-save or a moogle save.
I'm not really sure what you're doing that for. If you want to have a "New Game +" feature, setting a flag before an auto-save is not the way to go because auto-saves make sure that both executions are ran with the same setup (you can't distinguish between the 1st execution and the execution after the player hits the "Continue" button).

So, I'm working on something else right now and I can't test about these bugs you mentioned, Incinerator, but I'll eventually take a look at them.
About 3D environment, it would be possible to change the engine to make it possible ; I don't even think that would be such a huge amount of work (the environment is already mostly 3D, engine-wise). It would be way more difficult to recreate the scenes themselves in 3D, and I don't think they would look as great as prerendered backgrounds (not to mention that a lot of things are working visually because of static backgrounds: look at Alexandria's bell tower, its size from outside and its camera for inside).

The foot sfx datas are indeed stored in the walkmesh (well, more precisely, the walkmesh says which kind of ground each triangle is ; then the script says which footstep sound is played on each kind of ground). It is not possible to replace the walkmesh data now because there's no tool to edit the walkmesh itself.

@jmp434: You have the 3D OBJ files describing the walkmesh geometry two posts above yours. The cameras of the fields are a bit weirdly stored and, last time I tried, I couldn't have them properly readed.

I don't exactly know what you're preparing us, but that sounds very neat :D
Here are the walkmeshes:

I don't think that I'll add an option to export them in HW as I am pretty sure that there will never be an importer of walkmeshes in OBJ format. Adding an exporter may make people think that walkmeshes are just a bunch of triangles. I'll just let the walkmeshes here.

PS: I double-faced the triangles because apparently the orientation of triangles is not relevant for walkmeshes.

It is possible, yes. You just need to empty the party reserve and then setup the characters' data: with the "Update level" option, it usually sets the character's level to the average level of the party reserve, but it sets the level back to 1 for an empty party reserve.
Code: [Select]
    SetPartyReserve( 0 )
    SetCharacterData( character_id, 1, 255, 255, 255 )  // By using 255 in the other arguments, you don't change the value
    SetPartyReserve( 255 ) // May be different if you don't want the 8 regular characters to be available

Yes he was modded (both the usual and the friendly yans).
It was also proven that, contrary to the non-modded fight, you can defeat a Friendly Yan at lvl 1.

Look at Black Waltz 3's AI script (the battle on the Cargo Ship). He starts the battle by casting trance on Vivi.
Basically, you need to "set SV_FunctionEnemy[ATB] =$ SV_FunctionEnemy[MAX_ATB]" and use a flag for the first attack of the enemy.

Ok yes, this is AI script.

So actually, the default AI scripts are usually quite complex. One thing you should do before editing AI scripts is import the local variable informations ("LocalVariableSettings_v1.hws" that is included with the tool). It makes the scripts a bit more readable.
But writing a simple AI script like what you say can be done quite easily. Here is how the "ATB" function would look like:
Code: [Select]
Function Enemy_ATB
    if (turn_counter == 0) {
        // Turn 1
        if (GetRandom % 2) {
            set SV_Target = RandomInTeam( SV_PlayerTeam )
            Attack( Poison ) // It is not "Poison" that should be in the real thing but the attack ID instead
        } else {
            // You may avoid Silencing someone who's already silenced using this kind of lines
            set SV_Target = RandomInTeam( NotMatching(SV_PlayerTeam[STATUS_CURRENT_A], 265) & NotMatching(SV_PlayerTeam[STATUS_CURRENT_B], 64) )
            if (SV_Target == 0) { // Everyone is either dead or silenced already...
                set SV_Target = RandomInTeam( SV_PlayerTeam )
            Attack( Silence )
    if ((turn_counter == 1) || (turn_counter == 3)) {
        // Turn 2 and 4
        set SV_Target = RandomInTeam( SV_PlayerTeam )
        Attack( Physical Attack )
    if (turn_counter == 2) {
        // Turn 3
        set rnd_num = GetRandom % 100
        if (rnd_num < 50) {
            set SV_Target = RandomInTeam( SV_PlayerTeam )
            Attack( Flare )
        } else {
            if (rnd_num < 90) {
                set SV_Target = RandomInTeam( SV_PlayerTeam )
                Attack( Stop )
            } else {
                set SV_Target = SV_PlayerTeam | SV_EnemyTeam
                Attack( Doomsday )
    set turn_counter = ((turn_counter + 1) % 4)
And declare the local variables "turn_counter" and "rnd_num" in the local variable panel:
Code: [Select]
local uint8 turn_counter
local uint8 rnd_num

For the counter-attack, I suggest that you take a look at Gizamaluke's AI and mimic it.

@aidolu12: Yes, it's extremely difficult to do CIL changes by only looking at the CIL code. It's way better to look at the C# code to at least understand how the engine works before guessing how you can tweak it (it requires reading C# but that's always better than CIL).
You can see the C# code in Memoria's Github page, or using a tool like dnSpy or dotPeek.

For your particular question, it's not particulary easy in CIL, but you might change the method "BattleHUD::GoToBattleResult" and add this kind of lines:
Code: [Select]
call 0x6000F5D // FF9StateSystem::get_Battle
ldfld 0x4002267 // BattleState::FF9Battle
ldfld 0x4002230 // FF9StateBattleSystem::btl_list
ldfld 0x4000226 // BTL_DATA::next
ldfld 0x400022A // BTL_DATA::cur
ldfld 0x4000809 // POINTS::hp
call 0x6000F5D // FF9StateSystem::get_Battle
ldfld 0x4002267 // BattleState::FF9Battle
ldfld 0x4002230 // FF9StateBattleSystem::btl_list
ldfld 0x4000226 // BTL_DATA::next
ldfld 0x4000229 // BTL_DATA::max
ldfld 0x4000809 // POINTS::hp
call 0x6000F5D // FF9StateSystem::get_Battle
ldfld 0x4002267 // BattleState::FF9Battle
ldfld 0x4002230 // FF9StateBattleSystem::btl_list
ldfld 0x4000226 // BTL_DATA::next
ldfld 0x400022A // BTL_DATA::cur
stfld 0x4000809 // POINTS::hp
This only restores 25% of max HP of the 1st character only (and doesn't even check if it goes over the max HP limit)...
Best is to use Memoria for that and add these lines instead, since you can surely use local variables when replacing C# code:
Code: [Select]
for (BTL_DATA next =; next != null; next =
if ( != 0 && next.cur.hp>0)
next.cur.hp = min(next.cur.hp + next.max.hp / 4, next.max.hp);
Much simpler indeed ^^'

@Gordo98: What you want to do is not related to AI but to the battle system, so CIL code or C# again :/
And increasing the duration of status effects is not possible with HW, as explained here. The best you can do is to change the tick for poison/venom/regen.

Don't say that! It is still possible to annoy me many many more times :p
Here's an updated link.

However, Italian is actually a language for which there already is a translation (of the current version of AF). TheFF8Fan was able to translate everything all by himself, and even added a couple of scripted sequences. (Check out his profile for the parts after this.)

About the "Spells" panel: yes, the Magic Swords are in there as well, but they are spread around. Most of them are next to Dagger's summons and Flare/Doomsday are at the end of the list.

About the "Localization" field, yes I noticed that. As strange as it appears, it's not a bug from HW but that's how the latest Steam version texts are (they were correctly set in the previous Steam versions). Don't bother.

Thanks usb :)
Yeah, I thought that they fixed that bug, but apparently not. It doesn't concern only Italian but also French and Spanish. The bug lies in the CIL method "BattleHUD::SetBattleCommandTitle" but it's a bit tricky to fix it there with HW.

What you can do though is bypass the bug: go to the "Interface" panel, select the "Battle Spell Naming" field and add 13 entries to it (right-click -> Add), then write the proper full names ("Colpo Fire" etc...). Finally, go to the "Party -> Spells" panel and change the casting names of the magic swords spells to the entries that you just added.
It's a bit dirty as a fix, but it works. You should also translate the names in the "Interface" panel if you want it to work for all the languages (I think the game would crash in non-italian language otherwise).

For info, you can have up to 62 custom spell names in that interface field.

You're supposed to select the corresponding Texture2D file.
That is, however, very weird that your texture is named "98.fbx"...

Huh, I didn't see your post until now Trostboot. That's a shame :/

I updated the tool to v0.39b:
- Fixed a bug in Model Importer when the texture files were auto-detected,
- Allow to use UV, normals and tangents in "ByPolygonVertex" mode for importing models,
- Improved the "Edit Similar Enemies" option: it now applies to the enemies' attacks as well,
- Added a few editable datas to the enemies, related to how they look and sound in-game, as well as which model animations they use,
- Allow to input the model ID of an enemy so you can choose an imported model ID or a model that is normally not used for battles.

This last feature needs a bit of engine modification to work though. When you use an imported model, you need to add it to the engine's database like any other model, but even if you use a standard field model, you'll need to modify 3 CIL methods.
Indeed, there are 2 model databases:
1) "FF9BattleDB::Animation", containing the battle models (enemies, characters and weapons),
2) "FF9DBAll::AnimationDB", containing all the models (including the battle models).
You must make it so the "FF9DBAll::AnimationDB" is used anyway instead of looking in the "FF9BattleDB::Animation" table.
Additionally, you must tell the engine to load all the animations in the RAM for the models used in battles. The policy is indeed that:
1) For Fields, only the animations listed in "Preloading" are initally loaded in the RAM. Other animations are automatically loaded everytime if you use them in the Field script (with a "RunAnimation" call for example). The only exception to this rule is the "Jump" Animation that isn't automatically loaded by the related call so must be loaded another way (either have it in "Preloading", or use a "RunAnimation" or "SetStandAnimation" call on the "Jump" animation beforehand).
2) For World Maps and Battles, all the animations that can be found are loaded in the RAM along with the model.
Whichever option is chosen doesn't depend on the game's state unfortunatly, but on the model's string ID (if it contains something like "_B0_" or "_W0_", it is considered as a Battle/World Map model). So the wrong policy is used if you select a Field model for an enemy.

In practice, do these changes in the CIL Code if you want to use a Field model for an enemy:
- In the method "btl_init::SetMonsterParameter", you should have a line "ldsfld 0x40004B6   // FF9BattleDB::Animation" near the middle of the method. Change it to "ldsfld 0x40012A4   // FF9DBAll::AnimationDB" (the hexadecimal IDs are the ones from the latest Steam release).
- Same in the method "btlseq::SeqExecAnim". Change the "FF9BattleDB::Animation" line to the "FF9DBAll::AnimationDB" line.
- In the method "AnimationFactory::AddAnimToGameObject", search for these lines:
Code: [Select]
ldstr 0x7003CA77 // "_B0_"
callvirt 0xA0001A7 // bool System.String::Contains( string )
brtrue IL_0098
Replace them by these:
Code: [Select]
call 0xA0000BB // !0 PersistenSingleton`1<class EventEngine>::get_Instance()
ldfld 0x40019E6 // EventEngine::gMode
beq IL_0098
It may have an inconvenient bug though: sometimes models will be messed up in the first screen you see after launching the game. Going to the menu -> Title Screen -> Continue, it will be fixed back, but it is annoying.

And, of course, you must setup the datas in the enemy's resources (at least setup the animations it uses ; the other datas won't make the game crash if they are at 0).

Another problem though is that the animation speed are slowed by a factor of 0.5 in battles, so the field models will have slower movements...
Hopefully, these troubles will find a convenient fix in the future.

@Trostboot: I will fix that bug for the PSX version for the next release, but you can use an older version of HW in which there is not this bug. The version 0.37c doesn't seem to have that bug. Also, most recent features are for the Steam version mainly so you don't miss a lot. Sorry about that.

About the SFX identifier, it is indeed dependant on the character only (the "serial_no" number). The method "btl_vfx::SelectCommandVfx" defines which Spell Animation is used depending on the command: most of the time, the Spell Animation used is the one given by the Spell, but for some special cases, like the Attack or Throw or a few others, it is handled by the engine.
The Spell Animation used by the Attack command should be around the position IL_0091 and it's "100 + btl_util.getSerialNumber(regist)".
For Zidane, the serial number is 0 or 1 depending on his weapon, for Vivi, the serial number is 2, etc...
There are only the 19 slots of Spell Animations used by the characters between 100 and 118 included. There are also 64 slots of Spell Animations used by the enemies for their physical attacks, ranging from 313 to 376, but the game won't allow a character to use one of these like an attack (it only displays the strike, without the animations of the characters running to the enemy).

For the save spot, the Fields are loaded and initialized after a loaded game just like after entering the Field normally.
What they do is that they set the variable "VAR_GenBool_184 = 1" right before saving. Since that variable is saved in the memory card/Steam save, the script knows when a field is entered by a loaded game, and generally, it then sets the variable "General_FieldEntrance" to the special value 10000. You can see the position where Zidane is created after loading a save in "Zidane_Init" functions.
In the World Map, the character's exact position is also saved in the variables "VAR_GenInt24_64" (X), "VAR_GenInt16_67" (Z), "VAR_GenInt24_69" (Y) and "VAR_GenUInt8_72" (angle) ; you can use them for the field's position as well with something like that:
Code: [Select]
set VAR_GenInt24_64 = GetEntryPosX(255)
set VAR_GenInt16_67 = GetEntryPosZ(255)
set VAR_GenInt24_69 = GetEntryPosY(255)
set VAR_GenUInt8_72 = GetEntryAngle(255)
set VAR_GenBool_184 = 1
Menu( 4, 0 )
set VAR_GenBool_184 = 0
And then something like this in the character's "Init" function:
Code: [Select]
if ( General_FieldEntrance==10000 ) {
    MoveInstantXZY( VAR_GenInt24_64, VAR_GenInt16_67, VAR_GenInt24_69 )
    TurnInstant( VAR_GenUInt8_72 )
I think that the lines "if ( VAR_GenBool_184 == 1 ) { set General_FieldEntrance = 10000 }" are present in all the Fields of the game so you don't have to care about adding them.

Ah yes indeed.... I'm sure he posted other videos, showing gameplay, in the past. But they don't seem here anymore (maybe he removed them or made them private... he tends to do that a lot). Nevermind, sorry.

"The Zodiac Addition" seems to be a continuation (or prequel) of "Evil Mist Rebirth" that is another mod of the same author.
Unless I'm mistaken, the videos about "Evil Mist Rebirth" give you a fine glimpse of what to expect from "The Zodiac Addition".

It's the name of the flag from the engine's source code, but it doesn't seem to be used at all (I couldn't find anything that checks if this flag is on in the engine's code). It is most likely a flag dummied out during the game's development.

@Incinerator: Ok, I found a bug and it was, as usual, a pretty stupid one. I will make a fix update but I'll use the occasion to also add a couple of things. You can bypass the bug with the current version though: rename the texture dependancies in the FBX model to something else. The bug occurs when the model importer automatically catches the texture (more precisely, when another file as the same internal name as the texture, such as a material).
So you have to make sure that the program asks you what are the textures linked to the model.

With this, at least exported/reimported models work. I'll try to add compatibility with the UV indices by Polygon Vertex for the fix as well.

Not related, but I found where the "3 enemy types / 18 attacks" limit is: go to the CIL Code "FF9StateBattleSystem::.ctor", the limit is there.
Find the following lines and increase the numbers to whatever you need:
Code: [Select]
newarr 0x2000062 // ENEMY_TYPE
ldc.i4.s 18
newarr 0x2000050 // AA_DATA
You may then ignore the warning that popups when adding too many enemy types or attacks in a battle.
There are other limits in that CIL method, but none of them can be modified as easily as just changing a number there.

These lines in the Yan's script are present in most of the enemies' Counter function. They precisely say to not counter to Zidane's What's That?!. Indeed, "return" means something like "skip everything's left". So actually, Yans counters to anything as long as it's not that single skill.

To give you ideas, you can also look the AI of Gizamaluke, who counters differently depending on a magical or a physical attack, and the AI of Soulcage, whose counter depends on the element of the attack (more complicated).

You can declare new local variables, yes. For AI, you should first import the "LocalVariables" .hws file that comes along with the tool: it declares all the used variables of the enemy scripts. If you import it, you'll see a few lines in the "Local Variable Panel" when editing an AI. These lines declare the used variables. You can add yours like this:
1) Select the function to which you want to add a local variable (or at least a function of the right enemy),
2) In the local variable panel, add a line like "local uint8 isBexecuted",
3) Use that variable in the function: when you parse, it will recognize the declared variable,
4) Most likely, you will still have a warning, like "Need to allocate more": change the "allocate N" line accordingly and parse again if that happens.

In the help (F2), you have some informations about variables (which types can be used, what is the difference between local, global and general, etc...).

Note that when you declare local variables in Field or World Map scripts, the local variables already used are not listed at all and you can overlap an existing variable if you're not careful. In order to be sure not to overlap an existing variable, you can write this kind of line instead for 2):
"local uint8 myVariable Loc_UInt8_[N]" where [N] is replaced by the number in front of "allocate".
You'll then need to increase the "allocate" number for sure.

Yeah, it should, Kaldarasha, minus the problems that importing a model seems to bug most of the time :/

So, I've tried to extract/reimport Zidane and it indeed crashes in-game. It's the meshes/materials that are causing the bug for some reason (the animations seem to be better done since Zidane's 401 animations were exported/reimported correctly).
Also tried with the Grimlock with the same result: it doesn't work anymore for me either... Since it worked previously, I can hope to find what I changed since I tested it.

Yes, the moogle book is the book you see when saving. That's the model 133, the first of the list when sorted, which is why I usually tested things on it.

I'll make a fix, but I'm busy this week, sorry.

So, @Incinerator:
You can't just replace the Mapping Information Type by another ; each type means that the datas are sorted differently (and usually not at the same place in the file). I'm also worried about that Zidane export/reimport as it shouldn't bug in-game. I'll test that today.
What I'm sure of, is that exporting/reimporting the moogle's book works perfectly, as well as the Grimmlock enemy model. Can you try one of these? If that doesn't work, then your archive must be corrupted somehow. If I can't export/reimport Zidane, I'll have something to work with and I can catch where the problem comes from.

Normals are good as they are in your screenshot. That's many polygons but there shouldn't be any data size restriction on the new model.
For the scale, the game expects models of size ~100. It's the same unit as the position in Fields, for instance. So a 100 radius scaled model is quite small, but still visible. For human-sized models, you'd take a height of ~700.

@ste459: Glad to hear that this works at least ^^
There shouldn't be any bug with changing this formula, as long as the frequency is positive. And these lines are only for the Regen frequency.

Yeah, that's the problem (at least that's A problem). I don't know how to change that setting in Metasequoia. That's not on the window you're displaying.
Do you have the free version or the licensed version of Metasequoia? I may look at it.

Maybe it's because the UV are refered by Polygon Vertex?
Search in your .FBX the lines "MappingInformationType". What do they say? (ByVertice, ByPolygonVertex, ByPolygon...)

Pages: [1] 2 3 ... 19