#List of useful tools to Convert Assets (3D and 2D)
1 messages · Page 3 of 1
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
Half working ™️ 🤣
all because i was lazy and finding out if i could jump some steps to get animations working lol
I mean it looks like it should to me at least
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
some updates... LMB Animations working as intended... CMB almost there... Simulations need some more robust Math calcs...
Dart pieces are like "let's get hell out of here" and slowly running into the bottom lol...
so close
Dart official melting lol
NAILED IT
failed audition for the can't-combat disintegration anim.
why is it doing that?
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
almost there
looks good
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
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...
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
this mystery still bug me... why they put all the Vertices in those Battle Stages...
`?????????????????????????????????????????????????????????????????????????????????????????????????????
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
Look at any of the deff loading code in SC, fffxx is using something that's already loaded
well seems to be 1 = 1 in both
i can't identify what's loaded 🤣 .... since in there there is no clue of what could be... except for some CLUT references
now... how i can see the data from VRAM referenced at there? hahaha
i'm super bothering today lol
Look at the values
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
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
well sorry... are 80 quads in total...
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
of 500 frames, 70% of them are just a white screen effect.. hahahha
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 
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
after some research and looking if i found something... only can say that surely the thing loaded here is the smoke in the Lavitz feet when starting the transformation
this
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
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...
anyway... clown moment or not... this is one of the best and beautiful Dragoon Transformation of all time...

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
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
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...
interesting
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...
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?
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 🤔
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
ahhhh i thought you mean the rave music and the guys with distorted voice we find a time ago hehehe
I only remember one rave music. What's the other one? xD
distorted voice? hmm
I need to re-browse the sounds.
yeah was a Japanese guy saying something
I wish I could remember. Silly brain.
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
???
you think there's DDR files in LoD? xD
SCEI develop the mokey game, TLoD, and that pump it up
this is additions but with feet
ohhh
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...
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"
Dance pad is bae.
Beat Planet Music -> think this is the game
not PIU?
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...
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.
i know that the same team develop TLoD, work on Ape Escape and that Music game... but i can't recall the game hahaha
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)
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...
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
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
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?
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
so this function call... the function inside... is not a CMB is loading a SAF
@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
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
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.
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
I suppose.. I just find strange that there are clearly sections code that have no purpose.
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
Maybe those code snipets are like that just because they had a "default" mode to create those scripts... but without the User/Player Input much of the Functions are meaningless... since much of the DEFF actually are Linear
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...
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
No worries. I have learned a lot from your posts.
and i learn a lot from Monoxide, TFZ, Zychro and Icarus... it's kind of a wheel... a very good one...
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
haschel dragoon transformation uses a special particle type
we looked into it before
but is called inside the code and already in the code?
its mostly dragoon deffs that use these rare types
iirc theres also a particle type thats not used
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
High Five guys!
Just look at the code, that's a perfectly valid particle type
Line particle where each instance has 3 sub-instances
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
#c0c050 color hex, #c0c050 color chart,rgb,hsl,hsv color number values, html css color codes and html code samples.
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
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 😛
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
the color is set here:
call SEffe::scriptSetRelativeColour, stor[15], 0xffffffff, 0xc0, 0xc0, 0x50 ; bobjIndex1, bobjIndex2, r, g, b
@sterile lantern the SAF Animation thing is CONFIRMED
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
This might just be a language thing, but int/hex is referring to two different things, ints are a data type and hex is a way to represent numbers
20 and 0x14 are the same thing, either could be an int
This is right, and then if you look into the line particle class, it uses the lower 16 bits of the type to set the particle instance sub count
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
are Tri chips... Doritos
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
What do you mean by generating triangles on the fly?
Three points always makes a triangle
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
The line and particle renderers can only do 90 degree angles
They can only be rectangular
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
in this picture you can see the phenomena in both states... at the bottom right there is a Static Line... and the others get deformed because of the movement...
Movement doesn't deform geometry though
That's something you'd have to program it to do and it's pretty complex
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"
It still doesn't change the fact that quads/lines can't render as triangles
they don't
The script also doesn't have control over the vertices after they're created
and what moves the particle?
The particle engine
because there is an animation involved
well i will check that too
which is the ParticleEngine... the ParticleManager?
Yes, and all the associated classes
Well this leads me into the Particle Instance58
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...
Yup
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
yep... but is moving like the entire particle...
and seems to be no scale data attached to this element
It's not changing the scale, just the velocity and acceleration
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
That's a wait command
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
What array?
the one in stor[15] (which is where the Data for that particle is getting set)
stors are single values, not arrays
and where is the storage of the object really stored?
because i'm getting a little confused about that
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
inside the storage_44 is that right?
Yes but where it's stored doesn't really matter
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
Lines have two faces
ahhh are a Streched Rectangle
A lerp along the middle of what?
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
No, lerping a position doesn't change the size of something
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
this ParticleInitialTransformationMetrics10, depends also in the behaviorType
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
sorry but i don't know how to describe that sneaky movement type
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...
Wonder if SC is failing to render part of the line for some reason
maybe some data out of bounds
Note there are multiple segments in the retail pic but it doesn't look like there are in SC
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
The polybuilder for line particles is wrong
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 💪🏻
Easy fix for that
he looks more human to me, but i will admit I haven't looked at a DNA sample.
also shapeshifters
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
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...
Meru Transformation "Sorted" Script...
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
@sterile lantern you know something about this?... or some theory?
Scripts were made using templates, if the script doesn't use some of the code it won't get decompiled
Another one done... just in a few... this one is surprisingly short...
Just like everything else about Kongol
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?
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"
Eat your soup... goddammit
I would say Dart Armored Core 10.000
hahahahaha
this is the FumeArmor for Divine Dragoon Transformation
How dare you put good ideas in my head. Now I need it.
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...
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).
This i think is one of the cleanest i made until now...
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)...
It's not reading data from bents, it's getting the light directions/colours
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
little question
BattleBackgroundLightColour which is that one?
the one apply to the Skybox?
The skybox is just 2D images, no lighting
ok... but that Light Source Color what is used for... you know? 🤔
If you're talking about scriptGetBattleBackgroundLightColour, it's used for whatever effects call the methods that use BattleLightStruct64 😛
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
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
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
Finally the last of the Transformations... Who??? Dragoon
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
Yep it runs one of the refpoint methods
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
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
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
the fact that you made this much progress should still be commended
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
@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
Different Z
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
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 🤷🏻♂️
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.
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
is it possible to identify which checks are applied to all characters, and which checks are unique?
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
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!`
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.
Thanks Drew! 💪🏻
yeah... pretty sure that there is a lot of things happening to BEnt positioning too... i think that each time a BEnt need to occupies the center of Team, they had to do a lot of workarounds...
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.
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.
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
i'm trying to take this seriously
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
You’ll figure it out I believe in you
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
@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.
are you using TLoD Assets Converter?
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?
No, ruff.
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
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.
You should send the error it gives you or he won't be able to fix it
Will do when I'm back into it.
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?
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
Dunno, I don't do python
for some reason the World Map parents are not loaded correctly... hmmm
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... 
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.
@wicked gulch you should display a message if it fails to read the files for any reason
it should
well without the Database files you can see anything... because everything is written there... delete that instalation, download the zip again and unpack everything and be sure that everything is in there hehehe
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
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.
but not in the TLoD Assets Manager folder....
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
maybe if exist, then it's the possibility of Mac which cannot get the correct path to the file... which is worst... meaning that i coded that part terribly... hahahaa
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.
are you running the code version?... not the executable?
yeah... cause mac. should i not be?
i don't know but maybe you could try the executable version
if i'm correct exe files could be run on Mac
opening the exe launched my windows virtual machine. so... it worked. in windows lol
pretty sure exe wont work on mac
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"
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. 🙏
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
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.
thanks a lot for you support!...
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)
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
I think once we finish RB3 I'm gonna write some tools for making effects, cutscenes, etc
Nice!... keep me update so i will join into the quest
"""
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
--------------------------------------------------
"""
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...
@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)
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
each row have 16 pixels i'm right?
16 colors, better to think of it as
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?
4084 size
What are you doing with a tim that large?
dragoon texture
You won't be able to load that into the game
as Monoxide told... the problem could be from the engine and some calcs during the UV mapping too... since everything must be recalculated if i'm correct
It won't fit in the emulated vram
And if you're not putting it in emulated vram then it should be a PNG
hey for Lenus face fixing... why we don't do that?
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
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
Copy? I thought that was the only instance of that particular model.
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? 🤷🏻
Ah, thought we were talking about Claire
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
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
Yes but I just want to make a minor change to the existing texture to fix it
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 🟥 🟥
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
you drew Kongol too handsome... hehehe
@lime willow better place is here, just because it's the Sub-Channel for this hehehe
fair enough
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
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.
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
Ok, think im following so far
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
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
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
you need to change the CLUT Entry to get the color of that Texture Island....
But it would present good backups if i botch it
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
here is what I would do:
- create a backup of the texture files.
- use DooMMetals tool to understand where the textures are being mapped to
- 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
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.
yeah... the original cds backups are never touch except for extracting the data, at least in SC
if you delete the characters folder sc should reextract the files from your disc/bin
alright, simple enough fix 😅
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
i can't promise much... but in a few months i'm pretty sure have the Texture Creator for TLoD
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.
anyway you will be able to pick and change the same color as selected from CLUT, but also create new files from scratch
ahhh yeah sometimes CLUTs are pretty similar... but with good eye and reference images from the game you can tell which Texture Island use a CLUT
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...
Doom, the texture whisperer
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
its more preferred than being clueless, im jealous lol
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)
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.
thanks a lot... anyway always trying to get concepts simple to a better understanding of what's going on... 
btw, this recall me... don't even dare to read the glTF 2.0 official format doc... it's a hell on wheels lol
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 :
we makin the light dragoon a paladin
very good indeed!
also, hell yeah. Tommy rules
yeah.... the sword uses a little piece of the first CLUT... and then i think uses it' own
really just wish i had a live model preview so I can physically see whats being effected and how it looks in game
Those red parts aren't textured
ah, dang. Maybe I'll have to rethink the color scheme a bit, try to make it fit natural
Or figure out how to edit the vertex shading 😛
maaaan I dont even think ive figured this part out yet lol
ahhh yeah the gauntlets and some others are just 3D colored Vertices
apparently some retexture mods will require vertice edits too.
yep... indeed
well my Blender tool can handle that... but it's a little unestable...
them good ole gamer colors
looks way cooler...
thanks!
i suppose eventually i should figure out how to color the world models
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
this is proving trickier than I thought. Even Lavitz's pants are vertex
pretty much the case for almost all the models...
there are very few models that are fully textured... most of them combine
hey mate... you find out a way to see more CLUTs on that tool are you using?
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)
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.
oh... get better mate!... take care and most important... rest...
@wicked gulch can you attach your Lenus texture update to this ticket https://github.com/Legend-of-Dragoon-Modding/Severed-Chains/issues/1845
nvm just remembered you dm'd it to me
sorry mate... just sleeping but i think i had help you from the Morpheus domains hehehe
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?
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
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....
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
I see
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
what do you mean binary edit?
Edit the file by hand in a hex editor
I see
The file format is pretty simple
Actually question, are you planning on changing the size of the image? That can be tricky
I use hxd
no I don't plan on changing the size
Here's the psyq docs on the main PS1 file formats, contains a description of the TIM format
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
ok. good to know.
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
True.
Honestly that would be my preferred fix
that's on the background image, but that doesn't really matter.
Probably a one byte patch
K ill work on that then
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
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
ahhh those actually are Models inside DEFF Files (DEFF Files are used to render and show the Special Visual Effects during battle)
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
Ah alright, guessing the dragons from each dragoon's final magic is also in the DEFFs too
believe it is a little complex work to pull hehehe... i hope it was more easy 🥲
that's right!
Good to know
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...
It happens, ps1 had quite a collection of gems
indeed
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
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
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
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
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! 💪🏻
You're doing it.. for Jenkins!!!
sureeeeee!!!
@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
excellent, thank you
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...
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
So most randomest of question but does anyone know if there is a way or a place to get higher quality textures?
there are some...
https://opengameart.org/art-search-advanced?keys=&title=&field_art_tags_tid_op=or&field_art_tags_tid=&name=&field_art_type_tid[]=14&sort_by=count&sort_order=DESC&items_per_page=24&Collection= (if you are lucky and find something that fit your needs)
this is the highest quality but requires a lot of credits sometimes
Awww thanks
@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
Hi Icarus... ehmm nop.... but i could do* it in some free time... hmmmm DM what you need
actually not so necessary
ty but we'll try to grab a texture in-game now
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
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.
I'll have to ask! Thanks!
Sorry for the late answer... about Models... i have to clean the code and do some refactors i plan to release a full functional TMD tool to convert directly models from Blender into TLoD Models (Exclusive to the format used in TLoD)... about textures also i'm in develop a a tool that could produce new textures from 0, also only for TLoD
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)
I guess when you are packing a game like TLoD, you need to pack information into whatever free bytes you have. Lol
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
So like a transparency layer for the models? Or just sometimes?
Sounds... tedious to sift through.
Perfect to hyper fixate on for a week 😂
indeed...
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...
My guess is just experimenting
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...
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?
indeed
So it wouldn't be good for anything that needs fine movement
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?
SC only uses triangles
It subdivides any quads into triangles when the model is loaded
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
You're welcome
well
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
i have no idea what im watcghing but it looks cool
this tries to be the most accurate DEFF Models + Animations conversion that would be available in the very soon TLoD Assets Manager update
Oooh I’m ready for spells and additions
that would take a while... but meanwhile we can offer all the characters transformations
which i think is a fairly good start...
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
i can't promise much... but maybe i could add it before it's planned
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
Can’t wait
Yes this is a really good start
@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?
Ah far as I know
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...
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
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
No, you can just calculate the packet length based on the attributes it uses
hmmm
are you 100% sure of that?
i mean
that SC do really pass everytime the correct data into the renderer?
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
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 😆
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
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
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?
so there is two ways to do this one is the UV Painting the other is Shading
you have to...
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...
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.
... We already have a draft for this purpose. 🤦🏻
Oh wow. Back then Blender 2.8 was mandatory.
From the releases page, are you recommending 4.2.0 or 4.2.8? https://download.blender.org/release/Blender4.2/
With the advent of an all-in-one tool, will these repos be deprecated?
https://github.com/Legend-of-Dragoon-Modding/TLoD-TMD-Converter/
https://github.com/Legend-of-Dragoon-Modding/TLoD-Texture-Converter
I have given the old draft a facelift! It is unfinished, but I hope you like the progress. I need to chat with you about a few things before we can complete and publish this as a new guide.
https://legendofdragoon.org/wp-admin/post.php?post=4207&action=edit
actually the usage of the first tutorials i made were pretty much usable... except for my English pronouncement hahahah... anyway we can create a new tutorial because the most updated the better
this are "alternative" in case that the needs of the user are beyond TLoD Assets Converter workflow
4.2+ (any update is always good)
the base version would be 4.2
Okay.
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.
sure
Thanks! Send DM or tag me when you have something.
hey doom, any chance you have that unused tasman animation sitting around still?
which Tool are you using for convert the Models?
you mean this one?
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...
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
what do you mean exactly?
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
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.
glad im not the only one finding bugs lol jk love the toom DooM
Well this time it's probably user error, not a bug.
hahahaha i'm glad too no joke hehehe
your* goblin converted folder should look like this
using the TLoD TMD Converter i mean
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
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
It's a different folder
Well i wanted to wait a little bit more... but this fix must be released!... anyhow!... enjoy it!:
so what exactly got fixed in this patch
nevermind read robbie
The results speak for themselves.
so im assuming the one on the right is the new version
It is!
were there still multiple textures im assuming
Yes, you still have to texture each individual object, but the blending is obviously so much better.
yes it is
