#List of useful tools to Convert Assets (3D and 2D)

1 messages · Page 3 of 1

wicked gulch
#

not only not using the TLoD Orientation, even is not using the 3D Software Orientation...

wicked gulch
#

sorry if i'm a little lost lately... but between RL and the glTF format i have barely time to do stuff... this format is so freaking random hahaha

wicked gulch
#

all because i was lazy and finding out if i could jump some steps to get animations working lol

true apex
#

I mean it looks like it should to me at least

wicked gulch
#

Resetting the code status to "start" since found that was i was doing something* was not glTF 2.0 100% compliant behavior... so here i am... starting again lol

#

sorry but i cannot leave this problems staying until the end of the days... i want a good usable code that will do the trick as supposed to do...

#

something very funny is "the trick" is done... but animations get scrambled because the behavior for an Animation timeline expects that every object are part of the same "mesh" and don't support each object independent animation... Blender Importer and glTF 2.0 Schema... are a THING...

#

another thing found... i think no i know why models and animations are some kind of rotated with TLoD Assets Manager... seems to be something related to Quaternion Management i do during the last steps of conversion.... i want to solve that too to keep the original In-Game position/rotation of objects... but maybe will take a while... since Quaternion conversion is something that i'm not familiar to, so i need to fully understand what's going on there

wicked gulch
#

some updates... LMB Animations working as intended... CMB almost there... Simulations need some more robust Math calcs...

wicked gulch
wicked gulch
junior mantle
#

so close

wicked gulch
#

Dart official melting lol

sterile lantern
#

NAILED IT

vestal halo
true apex
#

why is it doing that?

wicked gulch
#

for various reasons... most of them that have to do that i'm a bad coder and even a worst Java code interpreter lol

#

find out that i was doing buffoonery, since i forgot to set the Vectors used into Signed values... one is that... the other i how i update the values that i'm looking right now hehehe

wicked gulch
#

DONE!

true apex
#

looks good

wicked gulch
#

thanks!... anyhow i think i might need some tweaks in the future if i want to dump a single file animated with all the objects inside... atm the tool is doing the trick so that would be for 0.3/4 hahaha

#

so underline i'm saying... right now the tool will dump each object (animated/static) in a single file... each file must be imported if want to do the full scene

#

because i will need test the 400 (or more) DEFF to know if i will be able to do a full set of them

wicked gulch
#

and try my first attempt giving me a 15mb gltf File... with 500Mb of pure buffers... something that i don't want to happen to anyone... still loaded into Blender...

wicked gulch
#

for some reason the particle positioning get totally broken... don't know why ¯_(ツ)_/¯... but i will leave that for a very loooong future... since is the only thing i cannot replicate 100% as intended

#

sorry for a little spam... but now coding properly

wicked gulch
#

this mystery still bug me... why they put all the Vertices in those Battle Stages...

wicked gulch
#

`?????????????????????????????????????????????????????????????????????????????????????????????????????
call SEffe::scriptAllocateParticleEffect, stor[16], 0xffffffff, 0xfff03, 0x28, 0x1f4, 0x1, 0x0, 0xc230000, 0xb ; effectIndex, parentIndex, type, count, p4, p5, p6, p7, behaviourType
call SEffe::scriptSetGenericEffectValue, stor[16], 0x0, 0x10 ; effectIndex, genericIndex, value
call SEffe::scriptSetRelativeColour, stor[16], 0xffffffff, 0x0, 0x0, 0x0 ; bobjIndex1, bobjIndex2, r, g, b
call SEffe::scriptSetRelativeScale, stor[16], 0xffffffff, 0x400, 0x400, 0x400 ; bobjIndex1, bobjIndex2, x, y, z
call SEffe::scriptSetRelativePosition, stor[16], stor[8], 0x0, 0x0, 0xfffffe0c ; bobjIndex1, bobjIndex2, x, y, z
call SEffe::scriptAddConstantColourScalerAttachment, stor[16], 0xffffffff, 0x12, 0x80, 0x70, 0x60 ; effectIndex, parentIndex, ticks, destR, destG, destB

call SEffe::scriptAllocateParticleEffect, stor[22], 0xffffffff, 0xfff03, 0x28, 0x3e8, 0x1, 0x20, 0xc230000, 0xb ; effectIndex, parentIndex, type, count, p4, p5, p6, p7, behaviourType
call SEffe::scriptSetGenericEffectValue, stor[22], 0x0, 0x10 ; effectIndex, genericIndex, value
call SEffe::scriptSetRelativeColour, stor[22], 0xffffffff, 0x0, 0x0, 0x0 ; bobjIndex1, bobjIndex2, r, g, b
call SEffe::scriptSetRelativeScale, stor[22], 0xffffffff, 0x400, 0x400, 0x400 ; bobjIndex1, bobjIndex2, x, y, z
call SEffe::scriptSetRelativePosition, stor[22], stor[8], 0x0, 0x0, 0xfffffe0c ; bobjIndex1, bobjIndex2, x, y, z
call SEffe::scriptAddConstantColourScalerAttachment, stor[22], 0xffffffff, 0x12, 0x80, 0x70, 0x60 ; effectIndex, parentIndex, ticks, destR, destG, destB
call SEffe::scriptAddLifespanAttachment, stor[22], 0x23 ; effectIndex, ticks
?????????????????????????????????????????????????????????????????????????????????????????????????????Well this a little weird... normally all thescriptAllocateParticleEffectdepends on a ParticleFile (formerly known as VRAM Particle Data), this particle files normally have theirtypewritten on the file header... and there is no0xfff03` on file headers

#

at this point i have the "sequencial" data already clean up... so this is loaded just after Lavitz start to get Animated and before the Rising Leaves start to appear

#

also this:
for some reason Lavitz Dragoon Transform had two pairs of Rising Leaves in the start of the animation... both are the same, except that the second loaded have some lifespan data loaded scriptAddLifespanAttachment... maybe one is persistent while the other don't... but is weird since i can only see one of them in the animation (meaning that both are overlapping)

#

so the first steps of Lavitz Dragoon Transform DEFF are pretty much no sense hahaha

#

if someone ask me the strange particle loaded are "loaded" but invisible...

#

i wonder if using Retroarch in wireframe mode show that particles...

#

other particles are shown... but some invisible maybe don't, because need vertex color or being textured to be seen

sterile lantern
#

Look at any of the deff loading code in SC, fffxx is using something that's already loaded

wicked gulch
wicked gulch
sterile lantern
wicked gulch
#

now... how i can see the data from VRAM referenced at there? hahaha

#

i'm super bothering today lol

sterile lantern
#

Look at the values

wicked gulch
#

already did

#

U->936 V->64
CLUT-> 0x7D7B -> 32123

#

and have 32x32 pixels W/H

#

it's telling me from where the texture is get... but anything more... like the shape hehehee

#

except that are 50 quads

#

sorry 40

#

countParticleInstance_50 == 40

#

call SEffe::scriptAllocateParticleEffect, stor[16], 0xffffffff, 0xfff03, 0x28, 0x1f4, 0x1, 0x0, 0xc230000, 0xb ; effectIndex, parentIndex, type, count, p4, p5, p6, particleInnerStuff, behaviourType which make a lot of sense to this

#

also... p7 is the particleInnerStuff

sterile lantern
#

The type tells you what shape it is

#

It's a quad

wicked gulch
#

yeah are 40 quads... but what's the meaning?... hehehe

#

because this quads are not the leaves

#

and the smoke from the floor i think is a staticTmd that get animated

#

also are grey quads hahaha

#

call SEffe::scriptAllocateParticleEffect, stor[15], 0xffffffff, 0x3400, 0x32, 0x1f4, 0x1b, 0x100, 0x1a0000, 0xb ; effectIndex, parentIndex, type, count, p4, p5, p6, p7, behaviourType this are the leaves

wicked gulch
#

because after that call another one is done with the exact same data the only difference is... at the end made the same as the leaves... give this property scriptAddLifespanAttachment

#

i think i found it

#

but is weird

#

normally a Tmd get allocated and put all the properties on them.... this case is backwards... are first setting all and after everything they allocate the tmd in that storage

#

but only one of the two storages

wicked gulch
#

of 500 frames, 70% of them are just a white screen effect.. hahahha

wicked gulch
#

Found an unused piece of Model in the Lavitz Dragoon Transform

#

wow this a total reveal... the mouth movement for Lavitz when finishing transform it's passed through as a ParticleFile lol

#

weird that is not referenced in any part of the Decompiled Script...

#

but if i recall clearly can be seen Lavitz moving his mouth at the end of the animation

#

certainly... Lavitz it's moving his mouth at the end of the Animation... in SC also works... but for some reason is not referenced at any part of the Script to do that... which i think it's weird... maybe we have some uncompiled code... or a fork very forked ruff

#

how the hell this is working...

#

look for animatedSprite or something like that in SC but is for SubMaps... i don't know where is the one used in-Battle CutScenes (which are actually a DEFF loading a lot of stuff)

#

well anyhow this will not interrupt at all the conversion of files hehehe

#

but wonder how this still working if not referenced hehehe

wicked gulch
#

is the only thing listed in there

#

which i think is a real waste of resources... because creating 100 quads for that, instead of using a half hose which rotate in the position would be more efficient

#

could explain why they use the resource already loaded from game... since that texture is the same used whenever a character runs to an enemy

#

i cannot explain why particle simulation is broken again in my tool... i will have to check all out again... anyhow also i'm adding more support to values found in Scripts...

#

which put the simulation closer to the original...

#

but EVEN ORIGINAL/RETAIL had some randomness

#

check this

#

`# HERE IS LOADING SOME TMD BULLSHIT OUT OF THE MAIN FUNCTION (????!!!!) # I think is the gust at the end of the animation
; FORK JMP
LABEL_55:
63 (0x3f) / 2 (0x2) while -> repeat LABEL_56:
LABEL_56:
call Battle::scriptRand, stor[18], 0x0, 0x1000 ; value, min, max
call Battle::scriptRand, stor[19], 0xfffffc00, 0x0 ; value, min, max

call SEffe::allocateDeffTmd, stor[17], 0x3603 ; effectIndex, flags
call SEffe::scriptSetRelativeRotation, stor[17], 0xffffffff, 0x0, stor[18], 0x0 ; bobjIndex1, bobjIndex2, x, y, z
call SEffe::scriptSetRelativePosition, stor[17], stor[9], 0x0, stor[19], 0x0 ; bobjIndex1, bobjIndex2, x, y, z
call SEffe::scriptAddScaleScalerMultiplicativeAttachmentTicks, stor[17], 0xffffffff, 0xa, 0x0, 0x0, 0x0 ; effectIndex, parentIndex, ticks, x, y, z
sub 0x400, stor[18] ; amount, operand
call SEffe::scriptAddRotationScalerAttachmentTicks, stor[17], 0xffffffff, 0xa, 0x0, stor[18], 0x0 ; effectIndex, parentIndex, ticks, x, y, z
call SEffe::scriptAddConstantColourScalerAttachment, stor[17], 0xffffffff, 0xa, 0x0, 0x0, 0x0 ; effectIndex, parentIndex, ticks, destR, destG, destB
call SEffe::scriptAddLifespanAttachment, stor[17], 0xa ; effectIndex, ticks
yield
yield
while stor[8], inl[:LABEL_56] ; counter, addr
rewind`

#

and yes... is a gust and some smoke that is total random position/rotation depending on the values...

#

and that values are set in a while loop... so we get some little numbers... but still random

#

so... a DEFF 100% as retail at this point is totally discarded... since randomness could be in other parts... i love to get an approach even before getting stuff like this... i waste -10% time because of that

wicked gulch
#

as far i can tell... Rose Transformation script is a Clown Fiesta

#

they had LMB format that support Scaling... instead of using that format to do the Animation of object which need scale, they did a very complex Scaler, des-Scaler, Re-Scaler, des-Scaler 2 (the return, this is personal) type of code lol

#

also some stuff that need rotation is done there... with complex calculations... also solved with formats like SAF or CMB

#

make -1 sense everything i see there hahaha

#

only thing i can tell is... maybe some of the problems and frame rate issues (in Retail playing) while in Special Visual Effects (DEFF) must be part of this nonsense going on. I'm not telling that Rose Transformation have that issue... but other effects... could be...

wicked gulch
#

anyway... clown moment or not... this is one of the best and beautiful Dragoon Transformation of all time... s6Rose special

#

my least favorite (not because of the characters, but the quality) is Lavitz/Albert Transform... are just some gusts here and there... and that's it... even Kongol had a better Transform... sorry Lavitz/Albert Dragoon enjoyers xD

wicked gulch
#

Well after digging in the most deep part of Rose Dark Dragoon... i find something funny

#

there is a Model that isn't used at all... as two textures (which supposedly have to be used by that model)

#

here it is

#

(Techninal Data?):
NOT USED: 0xCA00 (File 11) and Textures (15 and 16) which are used in it, is a StaticTMD Model
Is a kind of Multicolor Startburst surely used before getting the Startburst Effect Working, Textures are a kind of Animated glowing/stars

vestal halo
#

an effect for the "engine" area?

wicked gulch
# vestal halo an effect for the "engine" area?

could be... also by the natural placement of the Model i think is more for when Rose finished her Transformation, she had some Rainbow Starburst at her back... maybe was replaced by it...

vestal halo
#

interesting

wicked gulch
#

and the Starburst it's complex... so i'm a little confident that they use that model as a placeholder maybe... or they find out that the Starburst effect was more nice

#

they goods of be in the Script Mines...

vestal halo
#

It's quite unlikely, since it's pretty well-mapped now, but I hope against hope that your tool finds another unused song. Even just a short beat, like that rave bit.

#

do you remember it?

wicked gulch
#

yeah i recall that... i think that was some of the devs working on this Music game... i can't recall the name

#

probably that game used the same script engine to interact with the user... for some reason i believe that 🤔

vestal halo
#

Music game?

#

for me, it sounded a little bit like Battle 2 (the first few seconds with the weird sounds, before the main loop)

#

the wrr wrr wrr sound

wicked gulch
#

ahhhh i thought you mean the rave music and the guys with distorted voice we find a time ago hehehe

vestal halo
#

I only remember one rave music. What's the other one? xD

#

distorted voice? hmm

#

I need to re-browse the sounds.

wicked gulch
#

yeah was a Japanese guy saying something

vestal halo
#

I wish I could remember. Silly brain.

wicked gulch
#

hmmm... well that music+that voice recalls me this kind of game like "pump it up" in which you have some rave music and a guy saying "perfect" when you do the steps in the correct moment

#

and behind scenes the game input works like TLoD Additions

vestal halo
#

???

wicked gulch
#

in which you have three states "Bad" "Good" "Perfect"

#

this kind of games

vestal halo
#

you think there's DDR files in LoD? xD

wicked gulch
#

SCEI develop the mokey game, TLoD, and that pump it up

vestal halo
#

ohhh

wicked gulch
#

funny that we are more precise with our feet and legs, than the hands and fingers lol

#

the concept of additions and pump it up are the same...

vestal halo
#

just timings

#

Okay, so we check the song list of PIU? xD

wicked gulch
#

you need to press the "button" at the right time to get the "Perfect" if not, you hit in "Bad" which give 0 points or just discontinue additions and "good" enough to give some point or continue addition

#

that's why the day you showed using the pump it up carpet to do additions in my mind said "hey! that's a good idea"

vestal halo
#

Dance pad is bae.

wicked gulch
#

Beat Planet Music -> think this is the game

vestal halo
#

not PIU?

wicked gulch
#

hmmm nop... i think PIU was developed by SEGA... if i'm correct

#

let me check

#

Andamiro... a Korean Developer lol

#

Dance Dance Revolution by Konami

#

i think was that Beat Planet Music...

vestal halo
#

Oh, we should've checked. PIU is a separate South-Korean dev.

#

PIU is the game where the Beethoven Virus remix debuted, however, and is the subject of one of my LoD remix attempts.

wicked gulch
#

i know that the same team develop TLoD, work on Ape Escape and that Music game... but i can't recall the game hahaha

vestal halo
#

Only JP.. hmm.

#

Yeah the whole brand started with, in part, a music team.

#

would you like to datamine the JP rom? xD

#

(not serious)

wicked gulch
#

have to be honest... i tried over Ape Escape.... to see if find some clues about the Script Engine...

#

nothing... but at least i say this team was pretty busy in that time...

#

almost 4 games in 1 or 2 years

#

insane... even today is insane hahaha

#

most of game devs today take 3 or 4 years to release something with half of the work already done (UE4/5, Unity, CryEngine, etc...)

#

in that time they coded almost all the engines from 0

#

in favor... today is more important the visual appearance than the playability...

#

and try to pull some new idea when most of the mechanics are already exploited...

wicked gulch
#

While Rose Transform were a Clown Fiesta... Haschel Transform is a Demons Party lol

#

the quantity of self jumps to set a script that do a move of data during processing is something unseen for me hahahaha

wicked gulch
#

wow... this took 2 days of mining... well i kind of manage to "sort" the Script for Haschel Transformation... at the moment a hell on wheels.... anyhow you'll find interesting that some code from the decompiled script seems to be not used at all in any time... but are a few things not much

#

i will need the help of some of the experienced Script Miners... since i could be wrong about the not used code

wicked gulch
#

call Battle::scriptLoadCmbAnimation, stor[10], 0x18d00 ; effectIndex, flags ---> This is wrong... i expect the flags to be 0x8D01 or 0x8D00 hmmm i need to research this flags how are they get... also... the haschel Animation there... is well played? 🤔

#

anyhow that Animation is not a CMB it's a SAF

#

Omg... the first time they didn't use another model... they used the same model as loaded in the BEnt Index...

#

i mean... usually each DEFF have a duplicated model of the Character in a "Normal" form...

#

but this case they use a cloning of model to pull that...

#

why they do it for Haschel and not for Rose, Shana, Lavitz and Dart so far?

wicked gulch
#

maybe i'm saying nonsense... but the Haschel "moment" in which he start to lag his body is because is not a CMB animation but a SAF Animation

#

i will run a test with my tools... if the case or not we will know in a few moments

#

AHAHAHAHAHAHAHHAA

#

first of all

#

there are two models of Haschel Dragoon Duplicated... which are doing the same animation

#

second the Animation is a SAF

wicked gulch
#

@sterile lantern i will log this into the issue

#

logged

#

btw the @ScriptParam(direction = ScriptParam.Direction.IN, type = ScriptParam.Type.INT, name = "flags", description = "The DEFF flags, mostly unknown") is the ID+FLAG at the very header of the file

#

now i can say that i'm more or less prepared to help... took me 3 years...

#

but now i get the basics of whatthehellisgoingon

wicked gulch
#

also i need to check visually step for step very closely this Script

#

seems to be loading a lot of Data... BUT A LOT.... when more or less in much of DEFFs transforms atm are half or a quarter of Data loaded

forest saddle
#

The dragon transformations script are weird. The Rose, Meru, and divine Dart transformation all will get, set, and store the xyz coordinates using memcpy for each party member. There is no reason to do this. I patched in a returnso they no longer use the coordinates and the scripts still work without any issues.

wicked gulch
#

well the first time we see one of the Scripts i said to Monoxide "HEY THAT'S A SCRIPT FILE" said me "that's not a Script"... with the time goes by finally came up to the conclusion that DEFF used Scripts... but the "format" is very very different from the used in SubMaps...

#

and it's understandable for two main reasons

#

1.- SubMaps are the most Interactive with player stuff going on in the game

#

2.- DEFF are loaded specifically when a Special Visual Effect is cast in Battle

#

so... some returns maybe make sense since the way that TLoD Engine interacts in the original hardware is pretty much different on how it do in SC, because Monoxide rewrote partially if not fully the Script Engine to be more "friendly" for coders like me xD

#

those returns surely are replacing the data in RAM in that address by the data obtained from the calcs

forest saddle
#

I suppose.. I just find strange that there are clearly sections code that have no purpose.

wicked gulch
#

also exists the chance of a buggy stage of the Dev Tool... keep in mind that this game experiment a lot in various things...

#

even i cannot tell why they didn't use the same "blueprint" for the DEFF Scripts... and instead each Script is very very specifically build for each character

#

also i think one of the biggest bugs Original Devs found were when working with Haschel DEFF... i'm pretty sure that this DEFF is Broken... but works because Soa is gentle and good hahaha

wicked gulch
#

because Script Engine is part of the Interface between TLoD Engine and the Player...

#

so we can say that this technical wall is understandable... because they need to use the same Script Engine for two very different purpose... in today programming this would be a bad practice... but in that time and with the PSX hardware they made magic...

wicked gulch
#

sorry if i do a little spam... but this matter is so exciting for me that i can't hide my emotions... i was so into getting the data from the DEFF all this time that now i'm a little accelerated hahaha

forest saddle
wicked gulch
#

and i learn a lot from Monoxide, TFZ, Zychro and Icarus... it's kind of a wheel... a very good one...

wicked gulch
#

Monoxide, TFZ and Icarus.... i think Haschel Dragoon Transformation Script is not only Retail Bugged, but actually totally broken... one of the tips on this is the size... which is x3 larger than other complex DEFF Scripts... but here's a thing... i find a very first glance of this...
{ ---> Allocate Particle call SEffe::scriptAllocateParticleEffect, stor[15], 0xffffffff, 0x200003, 0xc8, 0x7d0, 0xa, 0x180, 0x4180000, 0x3a ; effectIndex, parentIndex, type, count, p4, p5, p6, p7, behaviourType call SEffe::scriptSetRelativeColour, stor[15], 0xffffffff, 0xc0, 0xc0, 0x50 ; bobjIndex1, bobjIndex2, r, g, b call SEffe::scriptSetGenericEffectValue, stor[15], 0x0, 0x1 ; effectIndex, genericIndex, value call SEffe::scriptSetRelativePosition, stor[15], stor[8], 0x0, 0xfffffe0c, 0x0 ; bobjIndex1, bobjIndex2, x, y, z mov 0x1e, stor[stor[stor[0], 15], 8] ; source, dest call SEffe::scriptSetScriptScript, stor[15], 0xffffffff, 0x1 ; scriptIndex, deffScriptIndex, entrypoint {ENTRYPOINT_1} } ---> This Particle is Retail Bugged?
There is no file with 0x200003 Type... and tbh i see a lot of Particle Generatation and Loading from this Script... i will continue with this one... but i can say that at least i found the very first retail bug from it

#

this also could explain some strange behaviour Monoxide had with this specific DEFF (which was filling memory with garbage) and Zychronix with his Mod before SC

#

and this is JUST the start

restive carbon
#

haschel dragoon transformation uses a special particle type

#

we looked into it before

wicked gulch
#

but is called inside the code and already in the code?

restive carbon
#

its mostly dragoon deffs that use these rare types

#

iirc theres also a particle type thats not used

wicked gulch
#

must be this one

#

since there are no Type with more of two bytes (Short)

#

since the Type is written in the Header of the file as part of the FLAG+ID

#

most of the DEFF have a unique FLAG+ID... are very little which are kind of "repeated"

#

but the first short of the header (will be at the left in the hex viewer tool) is this Type...

#

that's how i know which file is loading...

#

i search for that value at the very start of the files in the current DEFF

#

also... this type is used to identify is AnimatedTMD{SAF, CMB, LMB}, StaticTMD or Particle...

#

i had 100% success with this method... except for this file only...

#

also that's how i know if a Texture or a Model/ParticleFile is used or not in the DEFF

#

if not used is not referenced in all the Script Decompiled code...

#

there is a type which start with 0xffNN those are using stuff load in the Main Battle DEFF

#

i'm aware of those

#

because part of the Battle HUD is a DEFF... actually DEFFs are inside DEFFs... DEFFception

wicked gulch
#

High Five guys!

sterile lantern
#

Line particle where each instance has 3 sub-instances

wicked gulch
#

so there are 3 sub-instances for flags and are lines?

#

hmmmm

#

this is a very big problem

#

this is a hard drawback for me... i ever think about that posibility... but... i think i could reproduce them on glTF 2.0 format

#

how can i be so blind

#

i'm a sucker

#

look those little lines...

#

are those

#

anyway... after seeing the previous scripts that used just a short to define the Type... this Script Engine always do the exactly opposite of what i ever expected

#

they bake the ingredients before getting any cake shape XD

#

but i cannot retreat.... that would be something that "old" DooM will do...

#

anyhow i can use a simple "trick"... anything that is not written in FLAG+ID surely is a Line or some shenanigan like that

#

oh freaking shiet!

#

read the docs glTF supports Line types with any effort

#

but the problem is... i don't know if Blender support importing lines from glTF 2.0

#

Yep is a line Particle...

#

YEAAAHAHAHHAHAHAHAHAHAA

#

sorry i lost it for a sec

#

Confluent Yellow Lines i got a name for them

sterile lantern
#

Those aren't line particles

#

They're textured

#

And none of the particles use a short type

#

Again just look at the code and do what it does 😛

wicked gulch
#

the previous i show... was the color... and the color is the same as the lines....

#

call SEffe::scriptAllocateParticleEffect, stor[15], 0xffffffff, 0x200003, 0xc8, 0x7d0, 0xa, 0x180, 0x4180000, 0x3a ; effectIndex, parentIndex, type, count, p4, p5, p6, p7, behaviourType
i look for the code and take the type,
the type final int renderType = particleTypeId >> 20;
0x200003 >> 0x14 (because Script dump it as a Hex representation, while the code is using an int, instead of the hex representation)

#

2

#
    final ParticleEffectData98 particle = switch(renderType) {
      case 0 -> new QuadParticle(this, parentBobj, new ParticleEffectData98Inner24((short)_10, (short)_14, (short)_18 / (float)0x100, innerStuff, behaviourType), renderType, particleCount);
      case 1 -> new TmdParticle(this, parentBobj, new ParticleEffectData98Inner24((short)_10, (short)_14, (short)_18 / (float)0x100, innerStuff, behaviourType), renderType, particleCount);
      case 2 -> new LineParticle(this, parentBobj, new ParticleEffectData98Inner24((short)_10, (short)_14, (short)_18 / (float)0x100, innerStuff, behaviourType), renderType, particleCount);
      case 3 -> new PixelParticle(this, parentBobj, new ParticleEffectData98Inner24((short)_10, (short)_14, (short)_18 / (float)0x100, innerStuff, behaviourType), renderType, particleCount);
      case 4 -> new JkNotActuallyALineParticle(this, parentBobj, new ParticleEffectData98Inner24((short)_10, (short)_14, (short)_18 / (float)0x100, innerStuff, behaviourType), renderType, particleCount);
      case 5 -> new WhyIsThereANoParticle(this, parentBobj, new ParticleEffectData98Inner24((short)_10, (short)_14, (short)_18 / (float)0x100, innerStuff, behaviourType), renderType, particleCount);
      default -> throw new RuntimeException("Invalid particle type");
    };```
Case 2 == Line
wicked gulch
#

@sterile lantern the SAF Animation thing is CONFIRMED

sterile lantern
#

Line particles can't taper like that

#

The line renderer can't do that

#

See how they're triangular

#

Change the line particle's colour to ff00ff and see if it changes those particles

sterile lantern
#

20 and 0x14 are the same thing, either could be an int

sterile lantern
#

I'm not sure what kind of particle those would be

#

They don't look textured

#

But line/quad both have 90 degree angles

#

They obviously aren't pixels and 4/5 have no renderers

#

That leaves tmd but that seems insane

wicked gulch
#

are Tri chips... Doritos

wicked gulch
#

i will look into it closely... but i had the "idea" of being Triangles Generated at the fly

#

Three points, and since the color start to get compact because one line is just near to the other generate that Triangle looking shape

sterile lantern
#

What do you mean by generating triangles on the fly?

#

Three points always makes a triangle

wicked gulch
#

yep... that's why... don't result strange for you there are a lot of shapes in the case selector

#

but the most important is missing?

#

Triangle is a base shape...

#

so my theory is... since they find out that they miss the triangles... they made it that way

#

just doing that nonsense xD

sterile lantern
#

The line and particle renderers can only do 90 degree angles

#

They can only be rectangular

wicked gulch
#

hahahahaa

#

i think i know what's happening

#

i put in a simple draw to better understanding of my idea

#

in the static mode also will fill the gap between point A to point B with color Data...

#

becase are triangular... but always the base is pointing to the Center

wicked gulch
sterile lantern
#

Movement doesn't deform geometry though

#

That's something you'd have to program it to do and it's pretty complex

wicked gulch
#

they are stretching the points

#

that's a movement

#

also is the same to VDF

#

they move the vertices to kind of moving the 3D Object to make it "flexible"

sterile lantern
#

It still doesn't change the fact that quads/lines can't render as triangles

wicked gulch
#

they don't

sterile lantern
#

The script also doesn't have control over the vertices after they're created

wicked gulch
#

and what moves the particle?

sterile lantern
#

The particle engine

wicked gulch
#

because there is an animation involved

#

well i will check that too

#

which is the ParticleEngine... the ParticleManager?

sterile lantern
#

Yes, and all the associated classes

wicked gulch
#

and in that instance

#

i see a three point animation

#
  protected void beforeRender(final EffectManagerData6c<EffectManagerParams.ParticleType> manager) {
    this._1a += this._14;
    this._1c += this._16;
    this._1e += this._18;
    this.particleVelocity_58.x = this._1a / (float)0x100;
    this.particleVelocity_58.y = this._1c / (float)0x100;
    this.particleVelocity_58.z = this._1e / (float)0x100;
  }
}```
#
  @Method(0x80100c18L)
  @Override
  protected void initType() {
    this._14 = (short)(-this.particlePosition_50.x / 2.0f * this.particle.effectInner_08._18);
    this._16 = (short)(-this.particlePosition_50.y / 2.0f * this.particle.effectInner_08._18);
    this._18 = (short)(-this.particlePosition_50.z / 2.0f * this.particle.effectInner_08._18);
    this._1a = 0;
    this._1c = 0;
    this._1e = 0;
  }```
From this Initializer Particle...
sterile lantern
#

Yup

wicked gulch
#

why? xD

#

we are with lines

#

maybe this is a retail bug? xD

sterile lantern
#

It doesn't matter if it's a line, it still has to have a position

#

Unless you're rendering something in 2D you need to have xyz

wicked gulch
#

yep... but is moving like the entire particle...

#

and seems to be no scale data attached to this element

sterile lantern
#

It's not changing the scale, just the velocity and acceleration

wicked gulch
#

ENTRYPOINT_1: ---> Move Storage from a point to Another (related to Frames) mov stor[stor[stor[0], 0], 8], stor[stor[stor[0], 0], 23] ; source, dest wait stor[stor[stor[0], 0], 23] ; frames deallocate
maybe this is?

#

no... too much

#

well that entrypoint is called at the end of the allocating

sterile lantern
#

That's a wait command

wicked gulch
#

yep... but is moving data from the same Particle Index

#

---> Allocate Confluent Yellow Lines call SEffe::scriptAllocateParticleEffect, stor[15], 0xffffffff, 0x200003, 0xc8, 0x7d0, 0xa, 0x180, 0x4180000, 0x3a ; effectIndex, parentIndex, type, count, p4, p5, p6, p7, behaviourType call SEffe::scriptSetRelativeColour, stor[15], 0xffffffff, 0xc0, 0xc0, 0x50 ; bobjIndex1, bobjIndex2, r, g, b call SEffe::scriptSetGenericEffectValue, stor[15], 0x0, 0x1 ; effectIndex, genericIndex, value call SEffe::scriptSetRelativePosition, stor[15], stor[8], 0x0, 0xfffffe0c, 0x0 ; bobjIndex1, bobjIndex2, x, y, z mov 0x1e, stor[stor[stor[0], 15], 8] ; source, dest call SEffe::scriptSetScriptScript, stor[15], 0xffffffff, 0x1 ; scriptIndex, deffScriptIndex, entrypoint

#

at the scriptSetScriptScript

#

is moving '30' to that nested storage...

#

yeah is moving 30 to this ThisParticle[15][0] (the Storage is 15 and the position inside that array is 0)

#

is very specific

sterile lantern
#

What array?

wicked gulch
#

the one in stor[15] (which is where the Data for that particle is getting set)

sterile lantern
#

stors are single values, not arrays

wicked gulch
#

and where is the storage of the object really stored?

#

because i'm getting a little confused about that

sterile lantern
#

In the script state

#

s15 is just the script state index for the particle

#

If the particle got loaded into script state 20 then s15 would be 20

wicked gulch
#

inside the storage_44 is that right?

sterile lantern
#

Yes but where it's stored doesn't really matter

wicked gulch
#

yeah you are right because is just changing the number inside the stor[15] to be set as stor[15] == 30

#

what will happen if we put Lerp in the middle?... assuming that the original state of a two lines 90° get filled with color in the "face" part

#

i know that a line have no face

#

but let's assume that

sterile lantern
#

Lines have two faces

wicked gulch
#

ahhh are a Streched Rectangle

sterile lantern
#

A lerp along the middle of what?

wicked gulch
#

of moving animation

#

will stretch the object?

#

i recall that video that shown me... about Lerp....

#

and cannot stop thinking on that "smooth" movement... but also kind of strecht the object during rendering

sterile lantern
#

No, lerping a position doesn't change the size of something

wicked gulch
#

excellent... so the object must be totally solid no flexing..

#

new ParticleInitialTransformationMetrics10(4, 12, 12, false, false, 0, 0), this is the transformation Metrics

#

what do the 4 thing

#

} else if(metrics.initialPositionMode_00 == 4) { //LAB_801019e4 final int angle1 = seed_800fa754.nextInt(4097); final int angle2 = seed_800fa754.nextInt(2049); this.particlePosition_50.x = (rcos(angle1) * rsin(angle2) >> metrics.initialTranslationMagnitudeReductionFactor1_02) * effectInner._10 >> metrics.initialTranslationMagnitudeReductionFactor2_04; this.particlePosition_50.y = rcos(angle2) * effectInner._10 >> metrics.initialTranslationMagnitudeReductionFactor2_04; this.particlePosition_50.z = (rsin(angle1) * rsin(angle2) >> metrics.initialTranslationMagnitudeReductionFactor1_02) * effectInner._10 >> metrics.initialTranslationMagnitudeReductionFactor2_04; }
is changing the angles

wicked gulch
#

also is changing the position of the object based on the effectInner._10 value

#

so it's kind of changing the shape of the object...

#

ohhhhhhhhh

#

in TLoD are

#

lines

#

with "sperm" kind of moment

#

look at this

#

maybe SC is not showing the Lines as intended, and actually are rendering Triangles because can't get the correct data

wicked gulch
#

now looking the Radial Gradient and the Lines travelling inside i think the Devs wanted to point a very specific idea xD

#

since positioning is random... some of the lines are overlapping (near Haschel head)

#

which looks like a Triangle... but is not...

#

for solving this i use the normalized positioning of objects around of an sphere... if not... the positioning is not equally to all the Sphere surface...

sterile lantern
#

Wonder if SC is failing to render part of the line for some reason

wicked gulch
#

maybe some data out of bounds

sterile lantern
#

Note there are multiple segments in the retail pic but it doesn't look like there are in SC

wicked gulch
#

that's the thing... in SC we got this

#

when should be something like this

sterile lantern
#

Nah it should be several quads

wicked gulch
#

ahhh that's true

#

but we have a good idea right now on what is happening

#

still paint is the most useful tool for any coder or engineer hahahaha

sterile lantern
#

The polybuilder for line particles is wrong

wicked gulch
#

oki doki... well at least we find something because of how much i'm into the rabbit hole hehehe

#

How i love this kind of discussions Monoxide ❤️ thanks a lot mate... you made my brain get into work 💪🏻

sterile lantern
#

Easy fix for that

wicked gulch
#

NICE!!!!!

#

you are a beast mate!

vestal halo
#

he looks more human to me, but i will admit I haven't looked at a DNA sample.

#

also shapeshifters

wicked gulch
#

wow, this is interesting indeed... the Quantity of Electricity bolts generated for Haschel Transformation in all the calls is random*...

#

between 1 and 2

#

but hey! it's random... as their placement

wicked gulch
#

i'm pretty convinced that most of the time this particle is called:
call SEffe::scriptAllocateParticleEffect, stor[15], 0xffffffff, 0xfff1e, 0x32, 0xfa, 0x0, 0x200, 0x4140000, 0x15 ; effectIndex, parentIndex, type, count, p4, p5, p6, p7, behaviourType
is the dust effect over floor... since this Dust is the only thing i cannot find inside DEFF files... and also the particle generation is way bigger to do not notice another particle... also it's loading something from Battle Main DEFF already loaded...

wicked gulch
#

The more i see this files the more i convinced that we have something miss here... in some cases there is a lot of Data after some deallocating of Scripts...

#

also see a kind of a pattern... in the mapping of the data inside Transformation DEFF Scripts... the "place" for LABEL_5 to LABEL_8 have all Data Tables

#

specially for BEnt Shadow

wicked gulch
sterile lantern
#

Scripts were made using templates, if the script doesn't use some of the code it won't get decompiled

wicked gulch
sterile lantern
#

Just like everything else about Kongol

wicked gulch
#

ENTRYPOINT_0: gosub inl[:LABEL_81] ; addr ---> The most pointless thing i ever seen
---->
; SUBROUTINE LABEL_81: return data 0x49

And that's all hahaha... for some reason Devs decided to jump to an Address to made a return and then continue... Why?... the question here is Why not?

wicked gulch
#

as a little update... just started with Dart Divine Dragoon Transformation... at the moment i can say that is the MOST complex DEFF Script I've seen... because seems to be checking if THIS is the very first Transformation of Dart, not only at the "Start" of the Script... but in several parts of the "First Time"

wicked gulch
#

after 6 hours

wicked gulch
#

Eat your soup... goddammit

vestal halo
#

Opposite of soup nazi?

#

Is it Kongol II?

wicked gulch
#

I would say Dart Armored Core 10.000

#

hahahahaha

#

this is the FumeArmor for Divine Dragoon Transformation

vestal halo
#

How dare you put good ideas in my head. Now I need it.

wicked gulch
#

well a crossover of this two games maybe make sense hehehe

#

this DEFF is not only complex... they do a lot of things that in other DEFF did the same but with different Functions hahaha

#

so... i have a theory

#

well two....

#

or the Effects department was very split in very specific Effects and each one develop their unique approach to do the same

#

or for some reason at middle of development they change some stuff because get game buggy or unstable... but keep the things that already worked

#

also... there is one theory more... but i don't think it's the case... anyhow i will listed...
the Allocators for Models/Particles were programmed by Hierarchy instead of Type...

#

what i mean? well instead of creating the Functions based on the type of Object to be processed (as i do in my tool) they do it in backwards... taking in account the hierarchy in the DEFF Scene

#

doing this way produces more code... since by type, the only thing i need to do is a recap of relative transformations and colors and applying that to the child objects... instead... doing by hierachy you must code everything from Model/Particle/GeneratedParticle ---> ChildModel/ChildParticle/ChildGeneratedParticle

#

this third theory make more or less sense because some models used almost all the header flag (specially the Main models)

#

while "Child" models are using half of the header flag

#

as fourth theory we can say that the three theories before are TRUE... and they took some decisions that made coding and DEFF get a very convoluted develop...

wicked gulch
#

From DDD:
NOT USED CONTENT:
Seems to be a Single ParticleFile: File 22 Texture: EXTRA:14. Whichs is a Rose/RedishGlow.
Texture: 9 from 4130. (Is a Simple Glow... surely from the LensFlare but not used at all).

wicked gulch
#

Albert Transform

#

A little note about "Data Manipulation"... maybe if you already read some of them i put that... well actually is setting, re-setting, copy and do a lot of stuff specially with Battle Game Vars and Storage... so i'm not trying to find all the explanations... but make sense some stuff need to change... this things specially happening at the very start of a Transformation Dragoon DEFF or at the very end of them...

#

BEnts that need to be hidden or shown, Run through the List of BEnts to "know" IDs or getting the Status from them... that stuff always happens at the very start and very end...

#

Also i found funny that there are various Values that controls Light Direction and Light Colors, which makle me think that each BEnt have a unique value for them in the Scene

#

instead of all BEnts sharing the same Light Direction and Light Colors

#

---> Get Battle Stage Direction And Color call Battle::scriptGetLightDirection, 0x0, stor[stor[stor[0], 26], 8], stor[stor[stor[0], 26], 9], stor[stor[stor[0], 26], 10] ; lightIndex, x, y, z call Battle::scriptGetLightDirection, 0x1, stor[stor[stor[0], 26], 11], stor[stor[stor[0], 26], 12], stor[stor[stor[0], 26], 13] ; lightIndex, x, y, z call Battle::scriptGetLightDirection, 0x2, stor[stor[stor[0], 26], 14], stor[stor[stor[0], 26], 15], stor[stor[stor[0], 26], 16] ; lightIndex, x, y, z call Battle::scriptGetBattleLightColour, 0x0, stor[stor[stor[0], 26], 17], stor[stor[stor[0], 26], 18], stor[stor[stor[0], 26], 19] ; lightIndex, r, g, b call Battle::scriptGetBattleLightColour, 0x1, stor[stor[stor[0], 26], 20], stor[stor[stor[0], 26], 21], stor[stor[stor[0], 26], 22] ; lightIndex, r, g, b call Battle::scriptGetBattleLightColour, 0x2, stor[stor[stor[0], 26], 23], stor[stor[stor[0], 26], 24], stor[stor[stor[0], 26], 25] ; lightIndex, r, g, b call Battle::scriptGetBattleBackgroundLightColour, stor[stor[stor[0], 26], 26], stor[stor[stor[0], 26], 27], stor[stor[stor[0], 26], 28] ; r, g, b
This and Example

#

The only one that seems to be shared is the last one... but for the previous i can tell that is taking 3 light Directions + Colors which is a little weird to me... anyhow i don't know the internals of this... but is very likely that always had that type of setting...

#

Also Camera Movement Functions seems to be defining the type and the angle... like "If Full Body, you have 2 types, Far Away, A Closer one" (just example, not a real example)...

sterile lantern
#

It's not reading data from bents, it's getting the light directions/colours

wicked gulch
#

but i think* is used to calculate each Light Source over This BEnt... it's difficult to say what i mean

#

because i cannot find the correct words and expressions

#

but the Engine is not calculating a general light and apply that to every model... instead each Model have it's own light source attached to it

#

or using 3 lamps in the Scene?

#

if the case we can do some tricks to know where are placed

sterile lantern
#

There are no spot lights

#

The psyq libs use 3 directional lights, that's it

wicked gulch
#

little question

#

BattleBackgroundLightColour which is that one?

#

the one apply to the Skybox?

sterile lantern
#

The skybox is just 2D images, no lighting

wicked gulch
#

ok... but that Light Source Color what is used for... you know? 🤔

sterile lantern
#

If you're talking about scriptGetBattleBackgroundLightColour, it's used for whatever effects call the methods that use BattleLightStruct64 😛

wicked gulch
#

It's funny that ?-Dragoon Transformation as in Shana Dragoon Transformation, wait a specific value of Y-axis to start a Rotation... if this condition is not met, will never Rotate lol

#

in most of the case Devs did just a "wait of frames" and then pull the transformation to be animated... this is at least a little unexpected to me hahaha

wicked gulch
#

Another crazy move... If Miranda not Scus94491BpeSegment_8006.battleState_8006e398.combatantBentIndex_1a8 the Script code will softlock hahaha

#

The Script expect that var[10] will be 0xff to Increment the execution table + 1 Index

#

the only time when this var is set is when the Script is executed for first time... but this var[10] is written by what ever it does... (not the Script)... this means that if this var[10] is not 0xff the Code will loop indefinitely until hardware get exhausted or broken lol

#

and maybe you will say "DooM, this is a very good safe check"... well i gotta say that is the first time i found they do this kind of check to continue the Increment of Index Table from all the Dragoon Transformations hahaha

wicked gulch
#

Nice... they have two "numbers" to store frame numbers

#

; FORK JMP LABEL_0: ---> Wait Frames At stor[8] wait stor[8] ; frames ---> Start Joypad RumbleMode call Scus94491BpeSegment::scriptStartRumbleMode, 0x0, stor[9] ; joypadIndex, p1 ---> Wait Frames At stor[10] wait stor[10] ; frames ---> Start Joypad RumbleMode call Scus94491BpeSegment::scriptStartRumbleMode, 0x0, 0x0 ; joypadIndex, p1 deallocate [LABEL_0_Data.txt] ---> Data At The Rear Of LABEL_0

#

sorry we have three:
---> Move And Wait Frames mov 0x6, stor[28] ; source, dest wait stor[28] ; frames

wicked gulch
wicked gulch
#

Well Finished All the Playable Characters Dragoon Transformation DB at least in this very first attemp

#

Now, I think i will do some nonsense in each of the "New Scripts" to make a totally Generic format...

#

Some of the Models use some special Functions and others don't... maybe it's better to do a generic template... since atm my tool organize the models to convert as a Type of Model:
AnimatedTMD-(SAF-CMB-LMB), StaticTMD (This Models are Animated through Function calls or using VDF Technique), GeneratedParticle (Generic Particles which use stuff already loaded into the Battle), ParticleFile (Files which have the Texture to be loaded, but also have the functions that call to behave like Particles), LensFlare (A Special Type), I don't know if i forget something more...
But are some cases that i need to Add stuff like lifespan or counts for StaticTMD Specially, are not "Particles" but Actually are treated like "Particles" well you know this weird decisions they made 🤷🏻‍♂️

#

Btw FUN_800db034(){}---> This Method Seems to be a Viewpoint Setter... what i mean?... Camera will focus whatever is tell to focus through this

#

As an idea Monoxide... we can call it as scriptSetCameraFocus

sterile lantern
#

Yep it runs one of the refpoint methods

wicked gulch
#

now i will take some time on the meanings of some Camera related movement

#

at the moment i think they are setting some waypoints

#

those waypoints are also turning camera depending on angles...

#

when Camera is pointing to a BObj i think is using degrees because of the 360 turn around

#

orbiting

#

while the rest don't use that because is turning the Camera not keeping align to a center

wicked gulch
#

Time to find out if glTF->Blender supports scaling of Colors

#

i need to know if i can animate the color property from the color shader i setup for the object

#

Certainly you can animate the color in Blender... the problem is to import that Color Animation

#

that's something that happens in DEFF often... to change color from Objects specially from ParticleTMD

wicked gulch
#

Definitely is NOT supported

#

what a waste of time

#

seems that i have to create an addon to do this

#

and a export format to take the converted data and make it work into Blender...

#

well the Scaling of Colors in DEFF would be the latest addition for Assets Converter in this next update cycle

true apex
#

the fact that you made this much progress should still be commended

wicked gulch
#

yeah atm is a very long way... since I wasn't glad with the results I had... because i'm trying to get close to the original DEFF output... i know that's something more or less impossible for me right now... but i want to get the closer as i can

wicked gulch
#

@sterile lantern Sorry for bothering and bring you here but i don't want to spam Main with questions... scriptSetEffectZ() this method set the effect to a new Z value... now the question... why they don't directly set that value from the start when the call for Relative Position is done?, any idea?

#

also... i found the "method" which "Animate" the Scale of objects during some effects... actually is scriptAddScaleScalerMultiplicativeAttachmentTicks, maybe you are a little surprised that took me so long to figure out... but what this do is changing the Scale during each tick rendering, making the objects Grow or Shrink, depending if Scale is positive or negative... so there is not an exact method, but actually they change the size of objects during each rendering tick

sterile lantern
#

Different Z

wicked gulch
# wicked gulch also... i found the "method" which "Animate" the Scale of objects during some ef...

Is using directly this method addScaleScalerAttachmentTicks on Mode 1, which means this:
else if mode == 1: scale.mul(parent.getScale()); scale.sub(manager.getScale());
They set the rest of values inside that method
but the important thing happens that this is done tick by tick
scaler.ticksRemaining_32 = ticks; scaler.value_0c.set(manager.params_10.scale_16)
so each tick cycle the value change... making the engine render the Effect Object bigger or smaller... i don't know if i'm clear on what i'm trying to tell hehehe

#

btw i remade the DB format for DEFF since my old format (the very alpha) was not parentness compliant as Script Methods could be... so now i have this structure:
"Main DB" which have the General Scene Data and Animation length. "Object DB" which is the description of each object and the Calls it made during it's processing...

#

this help me to write the data i need to make Models and Particles behave "in paper" as in Retail

#

also yeah... some Script Methods... specifically the Relative Transforms, could take various "Relative to" to transform the object... initially i thought every object resolved this using a single parent (the Main Object, or some Model) but no, could be taking for position a Model, for color Main Object, for Scale another Particle, etc

wicked gulch
#

Finished the Lavitz Script sorting again, because i was adding some new sorting rules... well for some reason this time i came up to the conclusion that actually Lavitz Transform is the most complex looking for hiding/showing and setup BEnts... the reason?... who knows... anyway have several checks that are not present in other Transformations 🤷🏻‍♂️

vestal halo
#

unlike other chars, he needs a "am I dead?" check, because it changes his battle model.

#

idk if this is related, haha. Just being funny.

wicked gulch
#

maybe?... hahaha sounds crazy not crazy.... but i think compared to other characters

#

and having the second character develop to be Dragoon

#

ehmm

#

maybe, MAYBE, the idea of more dragoons on battle field was something in the early development.

#

it's a theory

#

more than anything because unlike other Transformation DEFF they did 3 to 4 BEnt checks...

#

Dart do not need any check because

#

is the only hardcoded character that always the data must be in the same spot over and over through all the game

#

After Shana Transformation the BEnt checking is more "linear" and with very less code

#

even... half of the code to Lavitz Transform is only for check BEnt and make them appear/disappear during the DEFF Animation

#

Since Albert had a Copy'N'Paste Script had the same peculiar way of doing things

#

Shana had only 3 checks lol

#

Lavitz had... 7 + some more that are nested lol

vestal halo
#

is it possible to identify which checks are applied to all characters, and which checks are unique?

wicked gulch
#

hmmm since they call an specific Function we can trace easily when they want to show or hide a BEnt

#

the problem is... you need to run this code to know exactly in which cases the conditions are met or not

#

In Lavitz case could run through the whole RAM until deallocate what it needs and allocate the new things...

#

the good news is... the checks are done over hardcoded values in the ScriptFile vs BattleVars in hardcoded Indices...

#

a little example:

#

`; SUBROUTINE
LABEL_24: ---> Seems To Be Hiding BEnts
---> If 0x0 != inl[:LABEL_44] Jump Complete To LABEL_31 ---> "If This First Check Fails, Try This"
jmp_cmp !=, 0x0, inl[:LABEL_44], inl[:LABEL_31] ; operand, left, right, addr

LABEL_25:
---> Allocate Empty Effect Child At stor[23]
call Battle::scriptAllocateEmptyEffectManagerChild, stor[23] ; effectIndex

---> Move stor[18] To Nested stor[...]
mov stor[18], stor[stor[stor[0], 23], 18] ; source, dest

---> Move var[35] To stor[18]
mov var[35], stor[18] ; source, dest

---> Decrement stor[18] - 1
decr stor[18] ; operand

LABEL_26:
---> Move Nested var[...] To Nested stor[...]
mov var[34][stor[18]], stor[stor[stor[0], 23], 9] ; source, dest

---> Show This BEnt OFF
call Battle::FUN_800cb618, stor[stor[stor[0], 23], 9], 0x0 ; bentIndex, set

---> Decrement stor[18] - 1
decr stor[18] ; operand

---> If 0xffffffff != stor[18] Repeat LABEL_26
jmp_cmp !=, 0xffffffff, stor[18], inl[:LABEL_26] ; operand, left, right, addr

---> Move Nested stor[...] To stor[18]
mov stor[stor[stor[0], 23], 18], stor[18] ; source, dest

---> Deallocate Object At stor[23]
deallocate_other stor[23] ; index
return
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
LABEL_44:
[LABEL_44_Data] ---> Data Tables At LABEL_44
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
LABEL_31: ---> "If This First Check Fails, Try This"
---> Allocate Empty Effect Child
call Battle::scriptAllocateEmptyEffectManagerChild, stor[23] ; effectIndex

---> Move stor[18] To Nested stor[...]
mov stor[18], stor[stor[stor[0], 23], 18] ; source, dest

---> Move var[53] To stor[18]
mov var[53], stor[18] ; source, dest

---> If 0x0 != stor[18] Jump Complete To LABEL_32
jmp_cmp !=, 0x0, stor[18], inl[:LABEL_32] ; operand, left, right, addr
return

LABEL_32:
---> Decrement stor[18] - 1
decr stor[18] ; operand

LABEL_33:
---> Move Nested var[...] To Nested stor[...]
mov var[52][stor[18]], stor[stor[stor[0], 23], 9] ; source, dest

---> Show This BEnt OFF
call Battle::FUN_800cb618, stor[stor[stor[0], 23], 9], 0x0 ; bentIndex, set

---> Decrement stor[18] - 1
decr stor[18] ; operand

---> If 0xffffffff != stor[18] Repeat LABEL_33
jmp_cmp !=, 0xffffffff, stor[18], inl[:LABEL_33] ; operand, left, right, addr

---> Move Nested stor[...] To stor[18]
mov stor[stor[stor[0], 23], 18], stor[18] ; source, dest

---> Deallocate Object At stor[23]
deallocate_other stor[23] ; index
return
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!`

forest saddle
# wicked gulch

label 45 from the divine dragoon transformation script looks a lot like label 117 from the meru rainbow breath script (drgn0\4190\1). LABEL_117: mov var[35], stor[23] mov 0x0, stor[24] LABEL_118: decr stor[23] mov var[34][stor[23]], stor[25] jmp_cmp ==, stor[25], stor[8], inl[:LABEL_119] call 138, stor[25], 0x1 jmp_cmp ==, stor[24], 0x0, inl[:LABEL_120] jmp inl[:LABEL_121] LABEL_119: jmp_cmp !=, 0x0, stor[23], inl[:LABEL_118] return LABEL_120: call 148, stor[25], stor[8], 0x1, 0xfffff800, 0x898, 0x400 incr stor[24] jmp inl[:LABEL_119] LABEL_121: call 148, stor[25], stor[8], 0x1, 0xfffff800, 0x898, 0xfffffc00 incr stor[24] jmp inl[:LABEL_119]

#

call 148 is a function that sets bent position.

wicked gulch
#

Thanks Drew! 💪🏻

wicked gulch
forest saddle
#

I think there are 2 separate workarounds they used. The way they store bent position in the rose (4216), meru (4224), and divine dart (4232) transformation position is different from the other transformation scripts.

forest saddle
#

I also think there is not good reason to store the position of all player bents in the transformation scripts. I patched the three dragoon transformation scripts to prevent getting and setting of all player bent positions and they worked the same. Most of the melbu generations transformation scripts also store player bents in the same way. Just like in dragoon transformation scripts, if the player bent position stuff is patched out the scripts still work fine.

wicked gulch
#

an update

#

it's somehow funny that did almost the same way as TLoD Devs without noticing... anyhow there are some points in the code that i didn't take in account so i prefer to rewrite the code and getting it in well shape before any releasing

wicked gulch
#

i'm trying to take this seriously

wicked gulch
#

here it is

#

now i will do the same for each of Object Types from Scene...

#

yeah sounds crazy but i had to do this because i'm kind of getting lost in my own code right now xD

true apex
#

You’ll figure it out I believe in you

junior mantle
#

prototyping, eh?

#

maybe you should throw one of these guys in

#

glad to see you're in the spirit of doing something insane by trying to export entire deffs

rich quest
#

@wicked gulch Hey, just wondering if your tool has been tested on mac at all. I'm getting a lot of crashes and I'm not sure if it's just cause I have no idea what I'm doing, or if it's cause there are some bugs running it on mac. Just trying to export the world map files.

wicked gulch
#

supposedly in Mac had compatibility but i can't test because i have no Mac to test

#

hehehee

#

which kind of crashes are you getting?

#

Ruff, what you can say about me?

mild masonBOT
wicked gulch
#

hzhahahahayhavhasvbgasvbds

#

sorry for the divertion... well if you can tell me more about your crashes maybe i can help...

#

if you have more information, like the tool you were using... if was an specific world map you get the error... and more...

#

at this time the only compatible tool "in theory" with Mac is TLoD Assets Converter

rich quest
#

Ahh, I'll try the assets conversion at some point. I was using the latest version of the assets manager. I got everything up and running, the gui launches fine (with a few visual bugs, like text not fitting in the buttons) But when I go to click on the world map button, it just instantly crashes.

Anyways. It's not really an issue, I ended up just stealing my wifes windows laptop for a few minutes to get the models I needed. Thank you for taking the time to answer though.

#

I can't stand mac... but unfortunately I'm stuck with it for work.

sterile lantern
#

You should send the error it gives you or he won't be able to fix it

rich quest
#

Will do when I'm back into it.

wicked gulch
#

As Monoxide told i need to be fed with the errors you have, anyway it's good to know that you find a way to get the models... anyhow the most errors i know, the most possible it's to me fix it

#

btw Monoxide... Mac users need some special compiled version of tools?

rich quest
#
libs/debugpy/adapter/../../debugpy/launcher 51201 -- /Users/ryan/Downloads/TLoD-Assets-Manager-beta-v0.1.1.hotfix/main_gui.py 
Traceback (most recent call last):
  File "/Users/ryan/Downloads/TLoD-Assets-Manager-beta-v0.1.1.hotfix/main_gui.py", line 317, in worldmap_conversion_window
    submap_conversion_window = WorldMapConversionMainWindow(self, icon=self.icon, assets_database=self.assets_database, sc_folder=sc_folder_get, deploy_folder=deploy_folder )
                               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/ryan/Downloads/TLoD-Assets-Manager-beta-v0.1.1.hotfix/worldmap_conversion_window.py", line 36, in __init__
    self.initializate_window()
  File "/Users/ryan/Downloads/TLoD-Assets-Manager-beta-v0.1.1.hotfix/worldmap_conversion_window.py", line 41, in initializate_window
    self.generate_window()
  File "/Users/ryan/Downloads/TLoD-Assets-Manager-beta-v0.1.1.hotfix/worldmap_conversion_window.py", line 52, in generate_window
    self.create_treeview()
  File "/Users/ryan/Downloads/TLoD-Assets-Manager-beta-v0.1.1.hotfix/worldmap_conversion_window.py", line 86, in create_treeview
    self.create_treeview_data()
  File "/Users/ryan/Downloads/TLoD-Assets-Manager-beta-v0.1.1.hotfix/worldmap_conversion_window.py", line 115, in create_treeview_data
    self.treeview.setExpanded(this_parent.index(), True)
                              ^^^^^^^^^^^
UnboundLocalError: cannot access local variable 'this_parent' where it is not associated with a value
ryan@Ryans-Mac-mini TLoD-Assets-Manager-beta-v0.1.1.hotfix %```

This is what I get when I try to click on the "Convert WorldMap Mode" button
No idea if this is because of something I dont have set up properly or what
sterile lantern
wicked gulch
#

please Yuncha... check if you have this folders and file: Database (Folder)-> World_Map (Folder) -> World_Map.csv (File)

#

have to be in the same as the Exe

#

like this

#

hmmm seems to be working just fine for me

#

only happening with the World Map or is happening with the other Conversions too?

#

UnboundLocalError: cannot access local variable 'this_parent' where it is not associated with a value this happens because the csv file is passing empty data... or even is not working which is worst hahaha

#

well seems to be related on how Mac get and use the relative/current path...

#

hmmmm

#

at least they don't measure things in socks per second...

#

welll i need to pull a new changes for this... i will do whenever i got some free time... ruff

rich quest
#

huh.... okay, this may very well be something that I'm doing wrong. the TLoD assets manager folder is completely empty. dont even have a databases folder to check.

#

and yes, it happens with other conversions too. but for the other ones, i can click the button on the main screen that brings me to the list. but then the list of models just doesnt populate. Like I can see characters and cutscenes on the side panel. but if i click on characters for example, the list in the middle remains empty.

sterile lantern
#

@wicked gulch you should display a message if it fails to read the files for any reason

wicked gulch
#

i have an error written specifically to "if not the hardcoded is loaded, will crash"

#

shoot is not working

#

i will rewrite that part of the code lol

rich quest
#

Ah, jeeze. I'm an idiot. sorry. There is a database folder. I was looking in the exports folder.. thats my bad.

So yes. world_map.csv does exist.

wicked gulch
#

if it would... the tool have to work normally

#

thanks to you i find out that the part of the code that is in charge of checking the databases is failing... 💪🏻

#

also... maybe the file exists... but for some reason is passing "empty data"... which is leading to the crash

#

that means that i have to check if not empty data

#

so this is good to know... that bug seems to be living in the code from the very start... what a shame hahahaha

wicked gulch
rich quest
#

wish I knew enough about programming to actually be of some help with debugging. The folder exists, and it's in the same folder as main_gui.py which is what I'm running. I have all the dependencies installed I think..
But for all I know, I could be making some huge mistakes on my end. Honestly I have no clue what I'm doing.

wicked gulch
#

are you running the code version?... not the executable?

rich quest
#

yeah... cause mac. should i not be?

wicked gulch
#

i don't know but maybe you could try the executable version

#

if i'm correct exe files could be run on Mac

rich quest
#

opening the exe launched my windows virtual machine. so... it worked. in windows lol

pretty sure exe wont work on mac

wicked gulch
#

so my theory was right... is passing empty data, because Mac cannot find the Database file, because on how Mac read "relative to this place" and "actual place inside the disk"

rich quest
#

good old mac, making everything a pain in the ass. I honestly run into situations daily where basic things I want to do just simply aren't possible on mac... I miss my windows pc... 😦

on a side note though. Just wanted to say thank you so much for this incredible tool. It works flawlessly on windows and I have come to rely on it so much for my project. I've used it a tonne, and I owe you a lot for making this possible. 🙏

wicked gulch
#

no worries mate! since i promise it would be working in any platform is very good to know this type of issues... if not i'm lying as coder hahahaha

#

thanks to you to sending your report and i will continue improving the tool

rich quest
#

I bet I'm the only mac user out there that's into nerding out about old ps1 lod models, so... you're not lying as a coder if no one ever finds out. I'll keep it a secret 🤫 😅
in all seriousness though, thank you for your continued work on this. I'm always excited to see the new developments.

wicked gulch
#

thanks a lot for you support!...

wicked gulch
#

a little update... since is complex to set on an exact place, Logo model conversion will be deprecated, the most complex is putting it into a specific category (parent) and also model itself is not so much a thing (a bunch of planes with colors and reassemble very little from the TLoD Logo)... also i don't think is one of the most crucial models in all the game 🤷🏻‍♂️

#

today it's better take the original logo, do some shenanigans on Blender and you will get it even better... (as i did for some of my presentations hehehe)

wicked gulch
#

also i will leave the childish dream of compose the DEFF Scenario at once... and being realistic and adult... for now my tool will do the conversion which can do... step by step... when i figure out a better way to solve the issues for particles i will do it... if not... the next update will be in two years at this rhythm hahaha

sterile lantern
#

I think once we finish RB3 I'm gonna write some tools for making effects, cutscenes, etc

wicked gulch
#

Nice!... keep me update so i will join into the quest

wicked gulch
#
"""
        Rebuild DEFF Sequence:\n
        Pretty much as the name says, rebuilds a DEFF Sequence, based on CSV files,\n
        which acts as a kind of script file, but human readable.\n
        Since much of this files are written by hand could contain some errors.
        """
        
        """
        First understanding that getting Data from the Script files is not an easy task, even people like Monoxide, TheFlyingZamboni, Zychronix, Icarus, struggles a lot
        to simply follow up whats going on (and seriously i'm not even closer to their understand about this files), 
        this because the Script Files are not necessarily 'linear'. So getting the exact frame in which an effect start is very complex at best (impossible in other words).
        What i do in this files is comparing some timing/frame data from the Scripts Versus a 15~20~24 FPS Recording (in which i dump each frame into images) and checking
        frame by frame when a effect start to appear or end (disappear).
        For the rest of Data I just follow what file is loading.
        For sake of easy reading and maintainance I opted to split the "Script" into two concepts.
        First Concept is "Sequecence File", Sequence file is a csv which contains:
        --------------------------------------------------
        DEFF Fantasy Name | DEFF Objects Folder | DEFF Texture Folder | Total Frames | Extra Texture Folder
        0_DEFFObject0
        1_DEFFObject1
        n_DEFFObjectn
        --------------------------------------------------
        Second concept is "DEFF Object Properties File", DEFF Object Properties File have the same name as referred in Sequence File, 
        So for example we say the last DEFFObject is the n_DEFFObjectn, and the name of the file would be "n_DEFFObjectn.csv"
        This files contains the properties of the Object itself (Objects could be AnimatedTMD, StaticTMD, Particles).
        Structure of file is:
        --------------------------------------------------
        FILE (File Real Name) | FILETYPE | TEXTURES | ANIM FILES | PARENT | FRAME START | FRAME END | PARTICLE TYPE | COUNT | SIMULATION TYPE | LIFESPAN
        After the previous row starts the Script Properties, this are properties normally used for scripting Position, Rotation, Scale, Relative Color, 
        Scale Factor, Script Animation, etc.
        Since This last properties are dynamic, in other words could change during DEFF Animation, we can list even more than one in the same Object. Each of this Properties, 
        are listed as:
        Property Name | RelativeToParent | Values | Frames if Needed
        --------------------------------------------------
        """
wicked gulch
#

again some changes... tbh this changes are necessary, since i want to my code running as fast as possible... the main reason is... in a future when i get more or less every DEFF to be convert, we are talking about 400 files that each file have very specific treatment, this way I can be sure to modify/add/remove things that we need easily...

wicked gulch
#

@junior mantle @sterile lantern i need this information.... maybe are you familiar with it... need to know the "standard" size for PXL files... since Character TIM files are always 256[64 VRAM]*256

#

for my tool i will put 3 standard modes... MiniModel Texture Creation, Battle Model Texture Creation and Free Texture Creation (for SubMaps and other Bit modes which are not 4 or 8)

junior mantle
#

the individual texture size is 64x128 pixels. As far as I recall, there are 1x1, 4x1, and 4x2 variants, so 64x128, 256x128, and 256x256

#

All of them are at 4bpp

#

And don't forget that there is no CLUT section of a PXL file. All of the CLUTs are embedded into the image data

#

So the actual size of each texture is really 64x112, because the last 16 rows of pixels are the CLUTs

wicked gulch
junior mantle
#

16 colors, better to think of it as

restive carbon
#

@wicked gulch is there any way to rescale tims

#

I need to resize 4084 by 8x

sterile lantern
#

It wouldn't be that hard to write a script for it, but why do you need to resize it?

#

Also 4084 isn't a texture?

restive carbon
#

4084 size

sterile lantern
#

What are you doing with a tim that large?

restive carbon
#

dragoon texture

sterile lantern
#

You won't be able to load that into the game

wicked gulch
sterile lantern
#

It won't fit in the emulated vram

#

And if you're not putting it in emulated vram then it should be a PNG

restive carbon
#

Thats pixel count

#

It was 256x256, and I already did it

wicked gulch
#

i can merge all the textures into a single one...

#

or you want a direct retail file fixing?

#

the only problem is... i don't know a thing about how to implement into code... my last try into modify my sc local code almost end into melting my pc and github you know xD

sterile lantern
#

I don't have time to add a new model renderer that can do texture overrides when literally all we have to do is copy a model

vestal halo
#

Copy? I thought that was the only instance of that particular model.

sterile lantern
#

No, the other model is fine

#

It's only broken in one cutscene

vestal halo
#

Let me rephrase: I thought it was only used in one cutscene.

#

Her Dragoon model is shown just before battle, but after battle she is already gone.

#

disintegrated? 🤷🏻

sterile lantern
#

Ah, thought we were talking about Claire

wicked gulch
#

nop Lenus

#

and Lenus Dragoon have a single apparition in all the game

#

anyway.... if you need to do a lot of turnarounds for implementing i prefer just doing an original file creator hahaha

#

i thought was simply "here's the texture, replace this one" or something like that

sterile lantern
#

Negative

#

It's a whole thing

wicked gulch
#

now... time for technical questions Monoxide...

#

Emulated VRAM in SC works as the Retail VRAM from PSX?

#

same size

#

same placement for images/textures/display-render area?

#

same TPage numeration and order, etc?

#

or there is something different that i should to know

sterile lantern
#

Yes but I just want to make a minor change to the existing texture to fix it

wicked gulch
#

yeah no problem... the fixing will be only to the face feature

#

nothing more nothing less

#

the main problem came that for doing that i need a tool that seems to do not exist for some reason

#

and everyone in this world code the same old tool which depends on several ultra-deprecated tools 🤷🏻‍♂️

#

instead of doing everything in ONE-CLICK... they do the classic nerdy approach of "you need several tools to pull this out, first install Windows 95" (duh)

#

this is very red flag to me 🟥 🟥

wicked gulch
#

not the best draw of all time... but we have an official brush for the tool lol

#

for some reason the cursor can't be seen *in the screenshot, in my tool it's captioned perfectly lol

restive carbon
#

finally, i am gonna 1v1 painter in bale

#

thank you doom

wicked gulch
#

you drew Kongol too handsome... hehehe

wicked gulch
#

@lime willow better place is here, just because it's the Sub-Channel for this hehehe

lime willow
#

fair enough

wicked gulch
#

well i will go in a little explain on how the textures in TLoD Works...
each model is composed by several objects, each texture object (actually each one of the faces) in their data point to a Texture CLUT... ok?, but there is a little more, some Textures had more than one CLUT.
In TLoD each CLUT is used to define a color in one of the "Texture Islands" that a texture had

#

for example

#

marked in green Texture Islands examples

#

so to get a totally new model texture with changed colors, you might want to change each CLUT involved in that color change...

#

be aware that the maximum number of CLUTs for Battle Model Textures is 16 CLUTs

forest saddle
#

The CLUT is a basically a palette that is applied to a monochromatic image to create a colored image. The PS1 uses this to save space.

wicked gulch
#

Also that... CLUT cames from Color Look-Up Table... in other words... the CLUT is the Palette and the "Texture" actually are Pixel Data in Monochromatic fashion

lime willow
#

Ok, think im following so far

wicked gulch
#

i think that's the most important... hehehe

#

there are old tools to create textures for TLoD...

#

but i'm in a quest to write one for todays OS and PCs

forest saddle
#

the part that was difficult for me to understand is that when you open a texture in Tim2Vim there are multiple palettes that are each applied to different parts of monochromatic image.

#

that is why the in preview of CLUT 1/16 every looks really red

lime willow
#

alright, so then next question : Is there anything for tim2view to convert a png to the tim file? for example the texture converter saves it all to png, but the program doesnt seem to wanna mess with those

wicked gulch
#

you need to change the CLUT Entry to get the color of that Texture Island....

lime willow
#

But it would present good backups if i botch it

wicked gulch
#

yeah

#

use my tool

#

you can convert each CLUT into it's own Texture so for example in Dart had 11 CLUTs, will create 11 Textures, the problem came that i have to way to put them into the Original format... not at the moment

#

i'm developing a tool for crating or even editing existing textures

forest saddle
#

here is what I would do:

  1. create a backup of the texture files.
  2. use DooMMetals tool to understand where the textures are being mapped to
  3. change the CLUT with Tim2View (i think it will autosave the changes you make)
#

you don't need to use Tim2View to extract any png files

lime willow
#

It certainly does autosave the changes and I failed to make a backup first lol

#

on the plus side, i had to download the newest update anyway so I can just replace the files

#

...i hope.

wicked gulch
#

yeah... the original cds backups are never touch except for extracting the data, at least in SC

forest saddle
#

if you delete the characters folder sc should reextract the files from your disc/bin

wicked gulch
#

that's also true

#

SC can detect if some file is missing and will re-extract them

lime willow
#

alright, simple enough fix 😅

sterile lantern
#

It only detects root files from the ISO being missing, if you want to reset you'll have to delete the files folder itself and SC will extract them again next time you run it

wicked gulch
#

i can't promise much... but in a few months i'm pretty sure have the Texture Creator for TLoD

lime willow
#

alright, so im not sure I can process how to tell the difference between what one clut has control of or not. It seems like everythings just there for all of them only in different shadings.

wicked gulch
#

anyway you will be able to pick and change the same color as selected from CLUT, but also create new files from scratch

wicked gulch
#

tbh... i'm so used to look PS1 Textures, that yesterday was looking into a Medievil Texture format and i told "hey this are Packed PS1 Textures", a person told me that "are not, is not PSX Textures format", the only difference was that each block of Pixel Data (the image itself) referred to a CLUT based in a value with a shifting...

sterile lantern
#

Doom, the texture whisperer

wicked gulch
#

ending changing a little of my code to support 15-bit Direct color conversion (plus the previous i had) and voila xD

#

i can tell the type of CLUT just looking at binary

#

i'm getting odd lol

lime willow
#

its more preferred than being clueless, im jealous lol

wicked gulch
#

sometimes it's frustrating... because some stuff now looks way simple that i thought initially... but also i had this communication barrier that i cannot express like i do in my language... making me difficult to explain some stuff...

#

in Argentina we say "pasame el coso, al lado del cosito, arriba del coso grande" (give me the thing, next to the thingy, up to the bigger thing)

forest saddle
#

Doom, I still would not understand what a CLUT is if it was not your posts and the documents you wrote in the SC google drive.

wicked gulch
#

thanks a lot... anyway always trying to get concepts simple to a better understanding of what's going on... i93PowerUp

#

btw, this recall me... don't even dare to read the glTF 2.0 official format doc... it's a hell on wheels lol

lime willow
#

i still legitimately cant tell which CLUT effects what, gonna have to fix up that sword, and the angles where it gets the underside of the armor are still red, so i gotta figure that out but :

lime willow
#

we makin the light dragoon a paladin

wicked gulch
#

very good indeed!

lime willow
#

also, hell yeah. Tommy rules

wicked gulch
#

yeah.... the sword uses a little piece of the first CLUT... and then i think uses it' own

lime willow
#

really just wish i had a live model preview so I can physically see whats being effected and how it looks in game

junior mantle
lime willow
#

ah, dang. Maybe I'll have to rethink the color scheme a bit, try to make it fit natural

junior mantle
#

Or figure out how to edit the vertex shading 😛

lime willow
#

maaaan I dont even think ive figured this part out yet lol

wicked gulch
wicked gulch
# lime willow

ahhh yeah the gauntlets and some others are just 3D colored Vertices

vestal halo
#

apparently some retexture mods will require vertice edits too.

wicked gulch
#

yep... indeed

#

well my Blender tool can handle that... but it's a little unestable...

lime willow
#

ok, so maybe not paladin, but deathknight?

lime willow
#

them good ole gamer colors

wicked gulch
lime willow
#

thanks!

lime willow
#

i suppose eventually i should figure out how to color the world models

wicked gulch
#

you mean the Mini Models?

#

ahhh if you talk about them are a little more complex... since the palette is drawn in the same image...

#

so the only way is painting each of the pixels in the palette to a different color

#

except that could be done using the textures from SC

#

i can't recall but if uses TIM (instead of the original format) could be possible do something like that

lime willow
#

this is proving trickier than I thought. Even Lavitz's pants are vertex

wicked gulch
#

pretty much the case for almost all the models...

#

there are very few models that are fully textured... most of them combine

wicked gulch
#

i promess that once i finish the Medievil 3D format checking i will continue writing the Texture creator...

#

the biggest problem i found is... for some reason PyQt doesn't support very well doing zoom to Canvas (and Canvas need to be placed inside another Widget, that also doesn't like to be zoomed... i'm trying to generate a workaround in my mind... because the maximum supported size for Battle Stage models is 256*256)

lime willow
#

honestly I havent really looked into it much. Been pretty sick the last couple days and I'm praying for the sweet release of unconsciousness today.

wicked gulch
#

oh... get better mate!... take care and most important... rest...

sterile lantern
sterile lantern
#

nvm just remembered you dm'd it to me

wicked gulch
#

sorry mate... just sleeping but i think i had help you from the Morpheus domains hehehe

lost flower
#

I'm trying to learn stuff about SC and maybe fix an issue while i'm at it. So I started looking into the green lines at the bottom of submap 111
https://github.com/orgs/Legend-of-Dragoon-Modding/projects/7/views/1?pane=issue&itemId=92546304&issue=Legend-of-Dragoon-Modding|Severed-Chains|1201

It's caused because the foreground doesn't cover the background in that spot.
Severed-Chains\files\SECT\DRGN21.BIN\337\8 - foregound
Severed-Chains\files\SECT\DRGN21.BIN\337\6 - background

How would I go about editing the foreground image in a way that I can re-load it back into the game? Can this even be done right now? Or is there a totally different solution I should be thinking about?

sterile lantern
#

We don't really have a great way to do that, easiest would be to extract the image, edit it, and ship that, but we can't ship assets

#

For retail assets, we typically ship binary patches, which is doable if the image can be edited in a reasonable way that changes the file minimially

lost flower
#

I extracted it and have the foreground image in .tim and .png formats, but I don't know how to edit a .tim and don't know how to get the game to load a .png.

The foreground only needs like 5 pixles added. So a binary patch could probably be done. Is that one of the .diff files in patches/scripts/DRGNX....

sterile lantern
#

Those are text-based unix diff patches for the scripts specifically

#

For asset patches, people generally send the modified file to me and I generate the patch

lost flower
#

I see

sterile lantern
#

Converting to PNG isn't useful unless you write a tool to convert back to TIM that does so in such a way to maintain exact colours and palette layout

#

You'd either need to use a TIM editor if you can find one that actually works, or do a binary edit to the file

lost flower
#

what do you mean binary edit?

sterile lantern
#

Edit the file by hand in a hex editor

lost flower
#

I see

sterile lantern
#

The file format is pretty simple

lost flower
#

I could probably do that

#

Do you know of a good hex editor off the top of your head?

sterile lantern
#

Actually question, are you planning on changing the size of the image? That can be tricky

#

I use hxd

lost flower
#

no I don't plan on changing the size

sterile lantern
#

But you may be better off looking at the Tim class in SC

#

Pixel format used by those textures is indexed 4bpp

#

So each byte of pixel data is two palette (CLUT) indices

#

i.e. aaaabbbb

lost flower
#

ok. good to know.

sterile lantern
#

And since the palette indices are 4 bits, the CLUTs are 16 colours (2^4)

#

@lost flower note - you might just be able to set the neon green in that palette to black and call it a day

lost flower
#

True.

sterile lantern
#

Honestly that would be my preferred fix

lost flower
#

that's on the background image, but that doesn't really matter.

sterile lantern
#

Probably a one byte patch

lost flower
#

K ill work on that then

sterile lantern
#

Sounds good, let me know if you have any questions

#

Oh one more note - the pallettes are 15bpp, and the 16th bit is a control bit that enables or disables translucency in the engine

lost flower
#

so... don't change bit 16

#

?

sterile lantern
#

mbbbbbgggggrrrrr so palettes are 16 colours x 2 bytes each

#

Right

boreal solstice
#

So not all models can be access yet correct? I was going through looking at all was shown and 2 things i wanted to find was the Moon Gem for its textures and the stolen Dragoon Spirit to see if it was just a red glowing orb or if it actually had textures to it but couldnt find either one

wicked gulch
#

atm i'm working into get those files working as intended

#

since are 400 DEFFs (and each DEFF had at least 4 models), and i need to read and decompile certain information from game to get the Timestamp for certain animations... is taking me a little time to pull

#

but i will be updating the tool in a very near future with the Dragoon Transformations already supported

boreal solstice
#

Ah alright, guessing the dragons from each dragoon's final magic is also in the DEFFs too

wicked gulch
#

believe it is a little complex work to pull hehehe... i hope it was more easy 🥲

boreal solstice
#

Good to know

wicked gulch
#

i think, in March i will be releasing the first DEFF Support packages...

#

i was waiting a little bit because of some things going on hehehe

#

also and tbh i get a little divert into converting other games Assets that i like... ehem.... Medievil...

boreal solstice
#

It happens, ps1 had quite a collection of gems

wicked gulch
#

indeed

wicked gulch
# boreal solstice Ah alright, guessing the dragons from each dragoon's final magic is also in the ...

i forgot to tell because i was tired -sorry- hehehe... but alternatively you can use my TLoD TMD Converter, in the Advanced Conversion Mode, and using the File Mappings a and a good Hex Editor to look for the Model headers, you can convert one by one... anyway i do not recommend this way, because you have to be familiar with the 3D Format of Models, Animation Formats and some stuff more to make it work... that's why i deprecated that function in my newest tool

boreal solstice
#

I did use that tool and was tryimg out the advanced conversion but had no idea really how it worked but imma wait for the next big tool update for the DEFFs

wicked gulch
#

i don't want to sound lazy or disrespectful, but this can take a while... since i have to decompile code that game need to run the DEFFs, the main problem is each DEFF have it's own code, which controls the quantity of Objects to be shown in the final render, timings and apparition order, some of those codes are near to be 5k lines... and i have to sort them and follow up the sequence and make some guesses... that's why i start with something i knew very well... after that i will going character by character and their Dragoon Magics... maybe to June i will have Dart Dragoon Magics with support too... all will depend on the time i have to spent in this hehehe

boreal solstice
#

Nah i get it, i follow quite a few game projects that try figuring out things and understand there are things that is complex. You good

wicked gulch
#

thanks a lot mate!... i really appreciate people who encourage me to continue, since sometimes i get a little tired (of the repetition) or lazy... but with this message i recall that i'm not doing this for myself... but for the community! 💪🏻

vestal halo
#

You're doing it.. for Jenkins!!!

vestal halo
#

Oh I mean a different Jenkins hehe.

wicked gulch
#

any Jenkins is a good Jenkins! xD

#

cannot watch it 🥲 blocked in my country... lol

vestal halo
#

Ouch. aYaaaaa

#

Do it for him anyway!

wicked gulch
#

sureeeeee!!!

wicked gulch
#

@sterile lantern i'm again in this dumb question... and sorry for this... but how the game knows in which FPS must run a DEFF rendering... how the calculation is done?... which are the parameters i should be looking at... because the matching frame-by-frame is seriously running down this project hahaha

#

and tbh it's ruining my efforts second by second...

#

i want to match the near as possible as retail but the most i think on it... it's draining my mental health

sterile lantern
#

var[25] is the vsync divider

#

Frame rate is 60 / var[25]

wicked gulch
#

excellent, thank you

wicked gulch
#

atm i will keep the methods and values like AddConstantColourScalerAttachment, this kind of methods are not easy if not possible to animate inside glTF format...

wicked gulch
#

i've change some internal logics in my algorithm, right now, there are two types of properties attached to a Object which is inside a DEFF*

#

General Properties and Scripted Animation Properties

#

General properties are fixed and won't change in any time of the DEFF processing/rendering

#

while Scripted Animation Properties are the properties which change or could change during DEFF processing/rendering

#

changing this logic, my code would be more flexible in case i found the same Object changing relative position/relative rotation/relative scale

#

i found some of those properties that i believed to be fixed, that actually are changed for this object in some moments

true apex
#

So most randomest of question but does anyone know if there is a way or a place to get higher quality textures?

true apex
#

Awww thanks

restive carbon
#

@wicked gulch do you have any renders of monsters with transparent film

#

eevee

#

cycles is fine too but considering lod assets i doubt you would render with that lol

wicked gulch
restive carbon
dreamy cobalt
#

im looking through some of the tutorials and videos, a lot of them use the TMD converter to load animations and models and put them back into a file that can get loaded.
Im not sure I can find that same functionality on the new Asset Manager. I think maybe thats just part of the Advanced Conversion thats not supported.

Mostly i just want to try and see if i can import a texture into the game for kicks and giggles. Though it seems like there are some limitations to that due to the size of the files needing to be the same. Seems like Tim2View is the way to go?

#

though that didnt seem to open the texture from Assests Manager

vestal halo
#

Textures can be modded. It's not a formal part of the modding API yet, but in the meantime you can try a hacky implementation. That's how the #1341465691265568880 experiment is starting. I'm not sure exactly what Emerald's process is, but there is solid progress and Grey Mad helped access more things to recolor.

dreamy cobalt
#

I'll have to ask! Thanks!

wicked gulch
#

since TLoD in some cases have some extra Data and some other functionalities over Models and Textures, even if are TMD (Models) or TIM (Textures)

dreamy cobalt
#

I guess when you are packing a game like TLoD, you need to pack information into whatever free bytes you have. Lol

wicked gulch
#

more or less the case

#

in the case TLoD models uses an "extra header" before the TMD Header

#

in that header they write some information related to Visibility of model, textures and/or Animations

dreamy cobalt
#

So like a transparency layer for the models? Or just sometimes?
Sounds... tedious to sift through.

#

Perfect to hyper fixate on for a week 😂

wicked gulch
#

well i've returned after some weeks somehow out...

#

IRL got wild because of my work... but now we get to normal operations...

#

so...

#

the first thing i want to say is...

#

LMB Type 2 make no sense... if you want to write to stop some of the transformations in certain point of Animation... why would you set a flag for it?... why you didn't keep the last value to be repeated and that's all you need xD

#

and they do almost all the time in SAF and CMB

#

even in LMB Type 0 if i'm correct

#

also... why they use it only in one single animation across all the Animations in game?... what made that animation so special?

#

clearly i can copy'n'paste what SC do... but i want the logical meaning for that difference...

#

it's like... why you want a Ferrari instead of a classic Ford of this year?... because of speed?, because of status?, because the design?... that kind of logical questions made me think more that i wanted... but i want those answer to properly manage that type of file...

sterile lantern
#

My guess is just experimenting

wicked gulch
#

maybe they thought that LMB Type could replace SAF and CMB, because had the scale (which is not used ever i think hehehe), but they keep the already work done?

#

they idea behind packing values is not bad actually, because it's a kind of "compression" for long Animation files...

sterile lantern
#

Hard to say, probably not worth it to compress most of the animations

#

The LMB compression is lossy since it's literally just truncating the values isn't it?

wicked gulch
#

indeed

sterile lantern
#

So it wouldn't be good for anything that needs fine movement

wicked gulch
#

yeah... will present the object moving more clunky that the desired output... specially for moves like additions that used body capture techniques...

#

also i had a question Monoxide... since i will focus into get a stable version of Blender to TLoD Models

#

will do some weird side effect only using triangles into models for SC?

sterile lantern
#

SC only uses triangles

#

It subdivides any quads into triangles when the model is loaded

wicked gulch
#

which is a totally green light then... the only limitation will be the number of total Vertices/Normals/Primitives that TMD files could handle

#

thanks a lot Monoxide

sterile lantern
#

You're welcome

wicked gulch
#

is not 100% accurate... because some of the magic is done via the waiting frames... that's something that i cannot handle directly in my tool i think

#

specially at the end when Dart it's waiting the Dragoon Flame Armor to appear

#

that's gone to be on the user hands 🥲 // SORRY

#

the good new is... i think this way is at least 80% more accurate that my previous DEFF TMD+Animations calcs

#

anyway... timing adjustments could be done simply editing the Database of the files... and changing the Frame Start / Frame End values

#

Also... textures will be converted for each DEFF (this means that you'll have duplicates of Textures from the same model, so i recommend using DEFF Conversion with caution and discretion, in other words... do not go wild... the quantity of nesting+files could be a surprise for some users..)

#

why?... well i cannot tell if there are differences between model-texture correlation... i keep as developers did... until we find out if from model to model texture and UV placements do not change

restive carbon
#

i have no idea what im watcghing but it looks cool

wicked gulch
#

this tries to be the most accurate DEFF Models + Animations conversion that would be available in the very soon TLoD Assets Manager update

true apex
#

Oooh I’m ready for spells and additions

wicked gulch
#

that would take a while... but meanwhile we can offer all the characters transformations

#

which i think is a fairly good start...

boreal solstice
#

Having just gotten through the Grand Jewel boss, I notice i now need textures from the Dragon Block Staff of the still images of the dragons used for its magic 😅 ..... im aware got to wait for that

wicked gulch
#

i can't promise much... but maybe i could add it before it's planned

boreal solstice
#

Do what you need to, i just noticed the images of the dragons in the Grand Jewel's magic effect is the same images in one of the JP Guidebooks... so kinda wanted to assess those textures lol

true apex
#

Can’t wait

true apex
wicked gulch
#

@sterile lantern hmmm i found something very weird in the Rose Transformation, in the white model that should be appearing during her transformation... it's present?, have no bug?

sterile lantern
#

Ah far as I know

wicked gulch
#

well the primitive packets for the Triangles are wrong 🤔 at least in the ILEN number

#

the packets are fine but... instead of 0x05, must be 0x04

#

11 05 00 30 -> {0x05}, represent the total rows of 4 bytes below... if the number is 5 means that should have 5 rows of 4 bytes below.. in this case all had 4
EB EB EB 30
8E 00 AD 00
CB 00 C6 00
9B 00 AF 00

#

DD 05 00 38
EB EB EB 38
00 00 29 00
01 00 28 00
02 00 54 00
03 00 53 00
{This is a correct ILEN number}

#

idk if SC relies on this... on my tool i will write a very hacky solution... but is not recommendable using any number, except the correct in there...

sterile lantern
#

We've talked about this a few times, ilen and olen don't matter

#

They aren't even read

#

The models are optimized when loaded and those values are completely overwritten without even looking at them

wicked gulch
#

ahhh forgot that... shoot...

#

the main problem is... TLoD have a very hardcoded way to handle models and process them... if i want to be flexible with a single code... that number really matters

sterile lantern
#

No, you can just calculate the packet length based on the attributes it uses

wicked gulch
#

hmmm

#

are you 100% sure of that?

#

i mean

#

that SC do really pass everytime the correct data into the renderer?

sterile lantern
#

Yes

#

This isn't an SC thing

#

The standard library does this

wicked gulch
#

well i must check that calculation... for some reason i kept that goddamit number as the calculation for the next primitive packet

#

i don't know if i'm dumb

#

or i missed something in the middle

sterile lantern
#

It's redundant, there is only one valid size for each packet configuration

#

So either it's set to a value you already know, or it's set to a different value and it's wrong 😆

wicked gulch
#

hahahahaha

#

yeah for some reason i think i replace the code when i sum the current packet size and change it... 🤷🏻‍♂️ ... so i'm dumb

wicked gulch
#

which Ilen i should put? lol.. i'm not only dumb... but stupid at universal levels xD

#

i don't need any calculation... my self code is pointing to say which is the Ilen number for the next primitive

#

since i'm selecting the primitive types as Monoxide did in SC

#

and the best... i sort the data in the same row count as in seen in the binary file

#

so i learn... the stupid decisions are all made while 1: i was drunk; 2: i was tired xD

vestal halo
#

Hey DooM, I'm unclear how to load a model's textures onto said model. D-Wrecks is having the same issue. We both ticked the checkbox for textures. We imported some gltf-format models, and Blender seems to have not picked up the textures in the neighboring subfolder. I take it we have to apply the textures manually? Or?

true apex
#

so there is two ways to do this one is the UV Painting the other is Shading

wicked gulch
#

sorry for the the late answer, but i was a little busy

#

i do not write the texture auto-loading

#

because is not the best way to work on Blender

#

to say it properly

#

is not the efficient workflow

#

imagine that you want to change the texture from one to another you have to check if it's going well and it's planned in your mod...

#

well change textures and materials in Blender it's sometimes tricky, specially for people with not much knowledge on Blender and "how to do" {example, me hahahaha}

#

also if i add the material directly... i will be kind of hardcoding the materials to the model... and the only hardcoded materials are colors...

#

i know that is possible to do it?... yeah... it's efficient for the purpose of the tool and the general idea behind the tool?... no

#

sorry for boring all of you with this text i will send but will understand what's going on... for a long time i was using improper Normal calculation during conversion; plus, i didn't know every difference between models that seems to be repeated from time to time, since that time i do not use the shaders and all the possible configurations because i didn't knew how to set them in Collada... now in glTF 2.0 i can do it... but will bring another downside... i must hardcode much of the primitives configuration percentages at the glTF Writer Module which is not good from my point of view (some people like some surface more glossy/lit/metallic,etc more than the real adjustment or so)... also Blender and TLoD have a very different way to handle light calculations depending on the Render engine you are using, making models propense to cast shadows in situations that it shouldn't... and also because i will be limiting the final user to "this is what tool do, take it or leave it" (i really hate that kind of situations). So in this way i can be sure the final user will do the adjustments to it's like and expectations....

#

in conslusion... more work to final user? == Yes {which is bad from a point of view}, more creativity and configuration possibility for the final user? == Yes {which is very good to setup different scenes to be render if needed}...

#

even... i was planning something more complex... since some people would like to setup models for creating it's own animations... well in Blender you need all the objects from the model collapsed, which is done when you have no animation selected in my old tools... right now Assets Manager don't do that, because every model have an animation, so i want to change that to also have a "still" animation of the objects collapsed on gizmo...

vestal halo
#

Thank you for the detailed explanation. I think the solution is to create a basic "usage" tutorial for all users. I can do the first part as soon as I get back to the house, about 30 minutes.

vestal halo
#

... We already have a draft for this purpose. 🤦🏻

#

Oh wow. Back then Blender 2.8 was mandatory.

vestal halo
vestal halo
wicked gulch
wicked gulch
wicked gulch
#

the base version would be 4.2

vestal halo
#

Okay.

vestal halo
#

Hey DooM. D-Wrecks, a new editor on our wiki team, is trying to apply textures to LoD models. He made a little headway but needs help so we can use these images on the wiki. I'm wondering if you'd be okay with expediting a 1-2-3 step dirty guide specifically for applying the textures to the models.

wicked gulch
#

sure

vestal halo
#

Thanks! Send DM or tag me when you have something.

lime willow
#

hey doom, any chance you have that unused tasman animation sitting around still?

wicked gulch
#

yeah... actually is Converted by the tool if i'm correct 🤔

#

is not?

wicked gulch
#

with TLoD Assets Manager all the Animations are stored in the NLA Track (Non-Linear Animation Track)... and you'll find all of them one after another in descending order...

wicked gulch
#

An advice to all the TLoD Assets Manager Users:
Recently D-Wrecks found a very weird bug, in which some of the Normals are calculated wrong... making the tool behaving not as expected in terms of generating the conversion of Normals... this will lead into a heavy update of the Normal Calculation algorithm... sorry but will take some time to fix it

true apex
#

what do you mean exactly?

wicked gulch
#

well some of the faces (surfaces of meshes) could be not receiving the proper color calculation in the 3D Software that you use... making renders/view incorrect to the retail one...

#

Normals are Vectors which tells to Blender, Maya, etc, how to calculate light impact over the surface/vertex... if a number is wrong, the result is a wrong coloring/shading of the object

cursive junco
#

All right, @wicked gulch, I already have some feedback for you.

#

First of all, upon importing the .dae file into Blender, it places all objects at the origin point inside of each other instead of arranging the parts in the shape of, you know, the enemy's body.

#

However, when I sift through it for the goblin's face and apply the textures, it just works.

wicked gulch
#

move your timeline to coincide

#

with the 1st frame

cursive junco
#

All animation frames are the same.

#

Maybe I dumped it wrong?

wicked gulch
#

hmmm

#

show me the timeline

cursive junco
wicked gulch
#

that's weird lol

#

how many files have you in the goblin folder?

true apex
#

glad im not the only one finding bugs lol jk love the toom DooM

cursive junco
#

Well this time it's probably user error, not a bug.

wicked gulch
#

hahahaha i'm glad too no joke hehehe

#

your* goblin converted folder should look like this

#

using the TLoD TMD Converter i mean

cursive junco
#

So what I did was launch your tool, point to the SC files folder, picked a dump folder, clicked Convert Battle Models, checked "Convert All", clicked Convert Models, Start

#

My output folder for Goblin does look like that

wicked gulch
#

hmmm you sure that you dump the files in a different folder which is no the same as the Assets Manager?

#

if not will be a mess of files lol

cursive junco
#

It's a different folder

wicked gulch
#

oki doki

#

can you go a little into the Voice chat?

wicked gulch
#

Well i wanted to wait a little bit more... but this fix must be released!... anyhow!... enjoy it!:

true apex
#

so what exactly got fixed in this patch

true apex
#

nevermind read robbie

cursive junco
#

The results speak for themselves.

true apex
#

so im assuming the one on the right is the new version

cursive junco
#

It is!

true apex
#

were there still multiple textures im assuming

cursive junco
#

Yes, you still have to texture each individual object, but the blending is obviously so much better.

true apex
#

yes it is