Kadish Sparkly

Announcements and discussion regarding any projects related to Cyan Worlds' Plasma Engine including (but not limited to) CyanWorlds.com Engine, Drizzle, OfflineKI, PyPRP, and libHSPlasma.

Re: Kadish Sparkly

Postby Sirius » Sat Jan 01, 2011 4:53 am

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

D'Lanor wrote: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.
User avatar
Sirius
 
Posts: 1506
Joined: Mon Jul 26, 2010 4:46 am
Location: France

Re: Kadish Sparkly

Postby D'Lanor » Sat Jan 01, 2011 6:17 am

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
"It is in self-limitation that a master first shows himself." - Goethe
User avatar
D'Lanor
 
Posts: 1980
Joined: Sat Sep 29, 2007 4:24 am

Re: Kadish Sparkly

Postby diafero » Sat Jan 01, 2011 9:58 am

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?
I prefer e-mails to "diafero arcor de" (after adding the at and the dot) over PMs.

"Many people's horizon is a circle with a radius of zero. They call it their point of view."

Deep Island Shard | Offline KI
diafero
Deep Island Admin
 
Posts: 2966
Joined: Mon May 05, 2008 5:50 am
Location: Germany

Re: Kadish Sparkly

Postby D'Lanor » Sat Jan 01, 2011 10:15 am

diafero wrote: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.
"It is in self-limitation that a master first shows himself." - Goethe
User avatar
D'Lanor
 
Posts: 1980
Joined: Sat Sep 29, 2007 4:24 am

Re: Kadish Sparkly

Postby diafero » Mon Jan 31, 2011 7:04 am

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)
I prefer e-mails to "diafero arcor de" (after adding the at and the dot) over PMs.

"Many people's horizon is a circle with a radius of zero. They call it their point of view."

Deep Island Shard | Offline KI
diafero
Deep Island Admin
 
Posts: 2966
Joined: Mon May 05, 2008 5:50 am
Location: Germany

Re: Kadish Sparkly

Postby Sirius » Tue Feb 01, 2011 11:23 am

That's interesting !

I guess you used Python ? I couldn't get it working with PRPs, the symbol is still invisible :( .
User avatar
Sirius
 
Posts: 1506
Joined: Mon Jul 26, 2010 4:46 am
Location: France

Re: Kadish Sparkly

Postby diafero » Wed Feb 02, 2011 4:52 am

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.
I prefer e-mails to "diafero arcor de" (after adding the at and the dot) over PMs.

"Many people's horizon is a circle with a radius of zero. They call it their point of view."

Deep Island Shard | Offline KI
diafero
Deep Island Admin
 
Posts: 2966
Joined: Mon May 05, 2008 5:50 am
Location: Germany

Re: Kadish Sparkly

Postby Sirius » Wed Feb 02, 2011 6:02 am

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.
User avatar
Sirius
 
Posts: 1506
Joined: Mon Jul 26, 2010 4:46 am
Location: France

Re: Kadish Sparkly

Postby diafero » Wed Feb 02, 2011 1:14 pm

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.
I prefer e-mails to "diafero arcor de" (after adding the at and the dot) over PMs.

"Many people's horizon is a circle with a radius of zero. They call it their point of view."

Deep Island Shard | Offline KI
diafero
Deep Island Admin
 
Posts: 2966
Joined: Mon May 05, 2008 5:50 am
Location: Germany

Previous

Return to Plasma Development

Who is online

Users browsing this forum: No registered users and 0 guests