Toy Scaling

[EJAX]

So, I'm just trying to get my head around this... I think what you're saying is there are positions defined in the room script that aren't available to the Pose Editor as starting positions. And that if I were to change an existing pose to use one of these undeclared positions, it would cause the chair to appear? Is that right, or am I way off?

[Marburg]

Quote

." WHERE IS THAT LINE?", is my question. You say "There isn't one"

I said no such thing. There clearly has to be some extra code / data in the pose

 

And I hate to repeat myself but OUR Pose Editor cant do that and THEIR pose maker can.

Not all poses are created equal.

 

 

Quote

I think what you're saying is there are positions defined in the room script that aren't available to the Pose Editor as starting positions.

 

That's not what i said. I haven't checked but i'm pretty sure the exact same location is also declared in another position group to accept generic (and user) poses. But the particular Posing01:position01 is only "visible" to the Posing group of poses.

Again: the same location can be re-used in another group

 

Quote

if I were to change an existing pose to use one of these undeclared positions, it would cause the chair to appear? Is that right, or am I way off?

Way off I'm afraid. The pose would have to be part of the right group (Posing) AND have the "initialize the chair" code or nothing special would happen at all. And as far as I know, we can't put user poses in any of the standard groups.

Like you said: it's convoluted

 

 

 

 

 

 

 

[EJAX]

1 hour ago, Marburg said:

And I hate to repeat myself but OUR Pose Editor cant do that and THEIR pose maker can.

 

And I hate to repeat MYSELF... Regardless of what made it, there is a line of code somewhere that THIS engine can read. It stands to reason that we should ALSO be able to read it (IF we can ever find it). I would love to look at Posing04.pes, but I cannot find such a thing. My guess is it's buried in one of those dlls.

[Marburg]

No, not in the DLL's. I think they are part of the executable file.
At any rate: they are not scripted or human-readable.

 

my guesstimate is that the category is probably encoded by just one binary value in the pose data.
You would have to know not only the relative location of that byte but also the possible values.
Not even mentioning the fact that we don't know where and how the pose data is stored.
I'm fairly certain it does not use the PES format as read and produced by "our" pose editor.

 

So yes, if we know where and how the data is stored and the byte we should look at for an as yet unknown value, we will be able to read it too.

You win

 

 

 

[EJAX]

I think the key is right here (from random pose file):

 

{
    "$Format":    "BSB6",
    "$Syntax":    3,
    "$Root":    {
        "Class":    {
            "$ID":    "PoseEdit",
            "I32":    201,
            "Text":    "EditablePose0001_Situation",
            "Text":    "Dance 4",
            "Text":    "FLOOR"
        },

 

Find the values for whatever created "poser", and it should work. So far, I haven't had any luck.

 

Again, I could be dead wrong (usually am).

[Marburg]

You could be dead right but it's only half the answer at best.
what $Syntax does an "internal" pose use? we dont know.

the "PoseEdit" $ID proves that not all poses are created equal and who knows whats in that field for non-PoseEdit poses

An internal standard pose could even have a different data bock layout... perhaps the $Syntax variable says "next data block is of type XXX"?
that's a common technique used in binary files.

 

without the actual Posing 4 pose data, i think it will be hard to reverse-engineer the process.

Trial and error won't get you far in this case I'm afraid but you never know. I have certainly been wrong before!