Cliff Cawley Wrote:It's not relative, it'll be a combination of skin and scaling.
I'd suggest changing the skin first, THEN moving it.
This makes it relative, then, perhaps we are on different pages. The skin the it is being changed TO has to have parameters set relative to the skin it is being changed FROM. This is not going to work for my purposes. Cause it means that EACH of the 30+ skins would potentially have to have a script created for EACH of the other 30+ skins.
The skin that the user is going TO "should not" have anything to do with where it is coming from, cause then it is always a one to one configuration that must occur. And instead of just 30 scripts needed could, in theory, need 900 scripts for this to work. No way that is happening.
Is this not what you understood that I meant? Cause this is the very definition of relative so we must have been talking about different things. I may have not explained it right.
And changing the skin first and then moving it is how I have been doing it. There is just one addition prior to that. The way I am doing it, the only way I am willing to do it is that when I am about to move to another wallpaper, I shrink the size of the player to "1x1" pixel, then flip wallpapers, then switch skins while it is still shrunk, then set scale and location. This is the ONLY way that it is seamless. There is no out of place imagery in any of it, which is mandatory with splinterfaces, or the overall effect is ruined. (unless there is a"hide player' and "show player" cli parameter that can handle the "new skin" function while still hidden and then only "show player' after it has the new skin and scale and pixel coordinates set...not the biggest deal, can use flash players for some, others for some, Xion for some, not stressin on it. But see that is how big a deal the seamless cohesiveness is. I am willing to spend more time implementing while getting fewer skin choices and more hassle designing with a way that never "shows the card up the magicians sleeve", if you will, than a way that may give the best look when "set", but must first break the fluidity and cohesiveness every time new page is flipped to).
This is the scripting structure I am using. The spli-scripting is irrelevant to this problem, I am just including it for a fuller understanding of steps.
C:\Program Files (x86)\r2 Studios\Xion\Xion.exe /SetMainPlayerScale=1
splinter goto 16
splinter delay 10
C:\Users\%USERNAME%\Documents\Xion\Interfaces\station.xsf
splinter delay 10
C:\Program Files (x86)\r2 Studios\Xion\Xion.exe /SetMainPlayerPos=800,300
splinter delay 10
C:\Program Files (x86)\r2 Studios\Xion\Xion.exe /SetMainPlayerScale=50
The 10ms delays are just for good measure so that the commands are run in the proper order
If I am using "x" skin initially, the station.xsf skin will end up "here" and "this" size. If I am using "y" skin initially, this script makes the station.xsf skin appear "there" and "that" size, and so on. See what I mean? They should be set with absolute positions, otherwise the parameter numbers for setmainplypos and setplyrscale are pointless, cause there is no way to calculate an x and y setting that you have to factor in scale and position of the previous skin. Would take as long to configure one skin this way as it would all skins with absolutes.