Kadish Sparkly

[Sirius]

I think Dustin already melted some PRPs to use a PythonFileMod for the Relto fog because of the calendar pinnacle. So, it should work...

And if modifying the native Uru:CC file Kadish_District_kdshPillars.prp is against Drizzle's principles there is always the less elegant Python method...

It can be put in PotS conversion, but using a Python file would be better to avoid problems if you don't have MOULa converted.

[D'Lanor]

True. I never bothered to convert MOUL(a) offline. In that case the Python code needs a safety catch as well:

kdshPillarRoom.py

Code: Select all

    def OnServerInitComplete(self):
        #do this before anything else
        try:
            objDecal = PtFindSceneobject('CalendarStarDecal', PtGetAgeName())
            objPillar = PtFindSceneobject('pillar03', PtGetAgeName())
            PtAttachObject(objDecal.getKey(), objPillar.getKey())
        except:
            pass
        #continue here with existing code

[diafero]

The issue is, as you noticed, caused by the pillar not being a parent of the sparkly. Back when this was added, there was no good way to edit original Cyan files in Drizzle. Nowadays this could be done was part of the POTS modifications - unless, of course, Uru has an issue with parents referring to child objects that do not exist (for people that did not convert MOUL).

For your Python method D'Lanor - won't that cause issues if the offset of those objects is wrong at the beginning? As in, we have to somehow assure that the pillar is all the way up when attaching the two?

[D'Lanor]

For your Python method D'Lanor - won't that cause issues if the offset of those objects is wrong at the beginning? As in, we have to somehow assure that the pillar is all the way up when attaching the two?

Since the coordinates are the same as in the MOUL file I assume that they are already positioned correctly. That is why the Python code has to run before anything else in that file which moves the pillars based on their SDL state. Cyan always takes care not to save the actual animation states in the age sav file (unlike most fan ages) so the objects should load in their default positions.

[diafero]

I finally got the chance to try this out, and it's working and will be in the next Offline KI (it's already installed on DI)

[Sirius]

That's interesting !

I guess you used Python ? I couldn't get it working with PRPs, the symbol is still invisible .

[diafero]

Yes, I did it all in Python. It can't be done by Drizzle alone anyway (as the existing prp with the pillar03 object would have to be modified), so I just made it work with the file Drizzle creates (which contains some now needless workarounds - but they don't to any harm, either, so that's okay ).
I guess the reason why you do not see the symbol anymore is that that you have to properly set the parent to local and local to parent matrices in the coordinate interface - for objects without parent, they are equal to world to local and local to world, so that's how Drizzle makes it. But after re-parenting, you got to change that.

[Sirius]

I first tested before with LocalToParent and ParentToLocal (they bear identity="True" in MOUL and some coordinates in PotS), but it didn't work.

You're right, in world to local and local to world, the coordinates are not the same (I guess that's the "now needless workarounds" ?).

Unfortunately... It doesn't work. I tested with MOUL's coordinates for WorldToLocal and LocalToWorld, with identity="True" or the original coordinates in LocalToParent and ParentToLocal, I made sure the coordinates of the pillar were the same in CC and MOUL... but nothing. So either there is something not working I can't find, either my graphic card can't render it for some reason . Parenting should be possible across PRPs, right ?

Of course I can use Python, but I prefer everything to be located in the PRP.

[diafero]

Sure, it should be possible. But I'm not a prp expert, sorry

You're right, in world to local and local to world, the coordinates are not the same

Those two are never the same! At least, that's how I remember it: They are matrices to transform world coordinates into local object coordinates and vice versa. So, those two should always be the inverse of each other. They are only the same if the matrix is the identity matrix, and the object is at the world coordinates (0,0,0) aligned with the world axes. The parent to local and local to parent matrices however do the same for the coordinate system of the parent object. So, the work-around is that during conversion, parent to local is set to world to local, and local to parent is set to local to world. This is what you somehow need to to properly when re-parenting. But for the details, someone else will have to help out, sorry.