Xion Community

The CLI command produces a different result depending on the size(or maybe scale) of the current player when it is moved, skin changed, and re-scaled.

It's not relative, it'll be a combination of skin and scaling.

I'd suggest changing the skin first, THEN moving it.

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.

deema Wrote: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.

When you call set position it should definitely be setting the absolute position.

When a skin is loaded, it'll reposition itself to remain centered from whatever the last skin was. Normally this feature can be disabled in skins using the dontreposition keyword.

Perhaps that's what you're seeing is simply a race like condition.

Try to delay for 100ms instead of just 10ms and see if it makes a difference.

What I think is happening, is that you're telling Xion to load a skin, then while it's still loading that skin, you tell it to move to 800x300, then Xion finishes loading the skin and applies centering the the current position (800x300). And then it's no longer in the correct position.

I can add a way to disable this repositioning feature, which should fix any race condition issues.

Also, some tips.

Instead of calling just C:\Users\%USERNAME%\Documents\Xion\Interfaces\station.xsf you should pass that to Xion as a command line, because if the file association is broken, it won't work.

So:

splinter delay 10
C:\Program Files (x86)\r2 Studios\Xion\Xion.exe "C:\Users\%USERNAME%\Documents\Xion\Interfaces\station.xsf"
splinter delay 10

Make sure you surround the path in quotes, otherwise spaces in the path won't work.

I will add a new CLI option to disable the repositioning.

In the mean time, I think if you increase the delay just after where you load a .xsf, it will work for you.

Cliff

Cliff Cawley Wrote:

deema Wrote: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.

When you call set position it should definitely be setting the absolute position.

When a skin is loaded, it'll reposition itself to remain centered from whatever the last skin was. Normally this feature can be disabled in skins using the dontreposition keyword.

Perhaps that's what you're seeing is simply a race like condition.

Try to delay for 100ms instead of just 10ms and see if it makes a difference.

What I think is happening, is that you're telling Xion to load a skin, then while it's still loading that skin, you tell it to move to 800x300, then Xion finishes loading the skin and applies centering the the current position (800x300). And then it's no longer in the correct position.

I can add a way to disable this repositioning feature, which should fix any race condition issues.

Also, some tips.

Instead of calling just C:\Users\%USERNAME%\Documents\Xion\Interfaces\station.xsf you should pass that to Xion as a command line, because if the file association is broken, it won't work.

So:

splinter delay 10
C:\Program Files (x86)\r2 Studios\Xion\Xion.exe "C:\Users\%USERNAME%\Documents\Xion\Interfaces\station.xsf"
splinter delay 10

Make sure you surround the path in quotes, otherwise spaces in the path won't work.

I will add a new CLI option to disable the repositioning.

In the mean time, I think if you increase the delay just after where you load a .xsf, it will work for you.

Cliff

What I think is happening, is that you're telling Xion to load a skin, then while it's still loading that skin, you tell it to move to 800x300, then Xion finishes loading the skin and applies centering the the current position (800x300). And then it's no longer in the correct position.

Yes, okay, that sounds likely. I will delay for longer, will try when done with this post. Thanks.

splinter delay 10
C:\Program Files (x86)\r2 Studios\Xion\Xion.exe "C:\Users\%USERNAME%\Documents\Xion\Interfaces\station.xsf"
splinter delay 10

Great suggestion, thank you, this could have been an issue later with end users. Okay, I am stoked again. I shall test it shortly. -----ahhhhhh, you know what,. I think you are right about it still being in the process by the time the next command is run. Cause the "new skin" always appears in one place initially and then moves right at the end. That would perfectly explain that (which i forgot to mention earlier).

On this whole subject, and way down the road, but if things work out with these two guys I think that a more in depth integration could be beneficial. For example, Splinter has a 'functionality" called "immersion mode", where one splicon, on every page, is allowed to be linked with one other splicon, on every other page. This is meant for seamless transitioning in splinterfaces where the wallpapers have various angles of the same scene. So that if a car door is opened in one angle, when you flip to another page with a different angle, the same car door is opened, giving the 2d environment a cohesive 3d effect. It is basically making the CLI implements that you are doing now for this splinterface, permanent and with far less overhead. Just the checking of a box for the player on each page would handle all of the "workarounds" that you and I are currently implementing. Irrelevant now, just sayin. But I have always planned on developing a sort of Splinter SDK, anyway, for varous modular / plugin type additions. Xion seems that it will be the clear candidate for many initial integration type implements.

Thanks again, will report back how she blows, how it goes....

Sorry, Cliff, I am having an unrelated issue with Splinter, at the moment. I'm not even sure if it is Splinter, or me, I am at about that 2 and a half day mark without sleep. Jello mush brain.

But I ran the commands separately and the player parked itself in the right spot, each time. So, the "race" as you called it was almost certainly what was happening. Thanks, I will get more in depth tomorrow and send you a sample of how it is working.

Gotta tell ya, though, for ME, my personal and professional uses, Xion is hands down the best player, regardless of "whatever' features the other "big three" have....

side note- the integration potentials between the two are becoming more and more "obvious" and substantial, to me. For example, the CLI implement of mainplayerscale has a rather limited use as just that, a cli function. However, as triggers(one type of icon in Splinter, the ones that have internal scripting abilties) can be set to run any command, I simply added four triggers and gave the first a command of "..... /SetMainPlayerScale=10', the second /SetMainPlayerScale=25, third, /SetMainPlayerScale=50, fourth /SetMainPlayerScale=100, then added a trigger that is set to toggle "show a,b,c,d triggers" and hide a,b,c,d trigger. This toggle trigger can just be hidden and the toggle occur with a keyboard shortcut. So in "two" minutes I added the new hotkey functionality to Xion to pop up four buttons that will scale the player to those sizes(Im not a huge fan of sliders unless mouse wheel capable).

Now this is a very basic and unspectacular function addition but it is actually kind of a big deal, as it dawned on me that every cli parameter can "instantly" be made into some type of button(s) or switch(es), without any more coding needed in Xion for that aspect, and generally no more than a line of "dos" -like commands in Splinter. Pretty cool.

.

SWEET. Here is the structure that works best. Works flawlessly, no out of place imagery at all.

C:\Splinter\EXE\Xion.lnk /SetMainPlayerPos=2000,1200
splinter delay 10
C:\Splinter\EXE\Xion.lnk /SetMainPlayerScale=1
splinter goto 16
splinter delay 100
C:\Splinter\EXE\Xion.lnk P:\Users\%USERNAME%\Documents\Xion\Interfaces\station.xsf
splinter delay 100
C:\Splinter\EXE\Xion.lnk /SetMainPlayerScale=100
splinter delay 100
C:\Splinter\EXE\Xion.lnk /SetMainPlayerPos=800,300

Well, you may experience problems on slower machines though where the race condition will rear it's head again. ( http://en.wikipedia.org/wiki/Race_condition )

I'll need to update my command line processor to allow multiple commands from the same call.

I.e.
C:\Splinter\EXE\Xion.lnk /SetMainPlayerScale=100 "P:\Users\%USERNAME%\Documents\Xion\Interfaces\station.xsf" /SetMainPlayerPos=800,300

Should be okay for your first release though

Cliff Cawley Wrote:
Should be okay for your first release though

? Splinter has been public for two years and I have released over 15 splinterfaces to the public. (remember how hard I said I knew it was changing (mis)perceptions)...

Anyway, aside from that, going along with the scenario, why would it be okay for the "first release" and not later ones? Confused. Has to be right every time, not just some. Anyway, I can and will increase the delay to up to 1000 or more, if I have to. Or no, I will just tell the end users to do it. All they have to do is right click the trigger, select the script tab, and change the delay. Anyone can handle that.

Also, it isn't as big a deal now, for the ploayer to not immediately be in position on screen cause it can be off screen for the scale changes. I just didnt want it to be ON screen and in a jacked up place. And anyway, I can, and will, I just realized, put a splicon image of the player in the spot so that it is immediately there when flipping pages and then when the player is positioned, just kill the splicon. End user will never know that any of it is happening, will look like nothing more than the wallpaper the entire time, nothing moving or out of place. Always a way to do ANYTHING with Splinter.

Sh!t, now I fogot what I logged on to say...................... Oh, would really recommend a shortcut key and/or mouse button combo for skin flipping, similar to what I have implemented in Splinter for wallpaper flipping. It takes a good 10+ seconds to right click, window load, contents in window load, select skin, load skin and close window. Now, this can be a big deal if you have 100+ skins and are going through each to try to find the right one for you desktop. I could flip through a skin a second, literally at least ten times faster, if was able to instantly see and switch the skin. It will not just be me doing what I am currently doing, soon, I think. Right now there are roughly 400K end users for Splinter. But I think that 99% of them are just that, END users, not designers. When I start pulling more and more designers away from Rainmeter and SCANDALOUS SUBVERSIVE UNETHICAL STARDOCK, then functionality that streamlines the creative process will be key. And designers are going to choose the software that integrates with Splinter, the most efficiently and effectively. Just sayin... Use logic and rational thought and come up with a scenario that doesn't have Splinter/"clones" of Splinter as THE way the desktop is interacted with, by 'all", in the future.

Hi. Is there an "exaggerated" number you can give me for a race to not occur, an d I will just increase that by one and use that as the delay? I would rather not set tool long if not necessary, though it isn't the biggest deal, either way. But less work is better at this point. I am way deep up in this breezy and my mind is hittin way too many places that have variables that may or may not require alternative solutions and each one of those I can check off drops my scatterbrain level several notches. Thanks.

But in general, Xion is a 100% effectively used and functioning entity within the splinterface. I will not "require" any more implementations in order for it to work, so that is a big weight, lifted. Of course it can always be improved, but of course so can splinter. So I can say with certainty that Xion will be the only dynamic audio player ( I am still using a few stock flash players, in areas, because of the spectrum analyzers that come with them, that I have not seen Xion capable of reproducing(i am sure it CAN, just havent seen it)

deema Wrote:Hi. Is there an "exaggerated" number you can give me for a race to not occur, an d I will just increase that by one and use that as the delay?

Depends on the machine specs and how bogged down the machine is while executing commands. If you're happy to have your users editing the delays, then just go with 500ms or something. Maybe get some feedback from users?

Cliff Cawley Wrote:

deema Wrote:Hi. Is there an "exaggerated" number you can give me for a race to not occur, an d I will just increase that by one and use that as the delay?

Depends on the machine specs and how bogged down the machine is while executing commands. If you're happy to have your users editing the delays, then just go with 500ms or something. Maybe get some feedback from users?

If you're happy to have your users editing the delays---
'
All splinterfaces can always be edited in any way by any one.... And all good, I don't even know why i asked this question, not important