Beta Builds of Xion. These are builds that are not quite ready for Release, but need feedback and bug submissions in order to move it to Release Status
SLoB Wrote:i preferred the look to the knight rider moving effect on Amorbous in 82,84, dont like it in 85 now that speed is fixed lol its too jumpy/flashy where as when the speed was borked it was smooth and subtle lol
SLoB you're talking about a bug here. It was fixed as it was working incorrectly in the old version. I think you were the only one to use it like this anyway. To get the same effect just change those layers to a 50% transparency or so and it will look similar.
ALAS Wrote:well I don´t think the wrong speed was a bug, it was more a consequent error, so the system "ín itself" was ok. Just wanted to mention that my suggstion to keep the old speed system and change the sentence in the reference chart to "delay(x) Delay between each frame(1 = 50ms)" would have some advantages:
...snip...
ATM I see only 1 disadvantage of my suggestion: faster animations than the ones we used until now aren´t possible, but who of us was unhappy?
Yup, that's correct. It was never meant to be as slow as it is. I didn't really want to go through and make a delay2() though...
If each author simply keeps their skin up to date it shouldn't be too much of a change I don't think.
I also didn't want to have to introduce mandatory versioning in the skins either. That just makes the bar higher for an entry level skinner and they may wonder why their skin doesn't function correctly.
Should I have a separate function for the new delay?
lanang jagad Wrote::D Can wait to create a new skin. The new default skin is great and the size is perfect. But now something wrong with my old skin "NWD" . Its graphic that represents pause button flickers. I have checked the .psd, I guess it happens when "_over" and "indi_" are put together in one layer name.The same problem also happens to Alas's skin "lissabon2"
Thanks Lanang jagad! I've fixed this now. The problem was that the indicator states were being set on the _over and _down layer when they didn't need to be. The previous skin system would ignore this, but the new one tried to accommodate this. It now ignore indicators on _over and _down layers
SLoB Wrote:Amorbous deffo a code bug somewhere, i even have a blank stop layer on 1st layer cycle with svst on the layerset
i set the green on the lcd to be the 1st color but all the other colourable items are using green as default, with a blank stop layer and then they are cycled next go round with the color cycle button
so looks like a possible layer set issue even if using paused and svst and a blank stop layer
Your skins are extremely complicated and its proving a pain to debug this, are you able to setup a very simple skin that exhibits this bug?
SLoB Wrote:Amorbous deffo a code bug somewhere, i even have a blank stop layer on 1st layer cycle with svst on the layerset
i set the green on the lcd to be the 1st color but all the other colourable items are using green as default, with a blank stop layer and then they are cycled next go round with the color cycle button
so looks like a possible layer set issue even if using paused and svst and a blank stop layer
Your skins are extremely complicated and its proving a pain to debug this, are you able to setup a very simple skin that exhibits this bug?
Cliff
ill try doing one Cliff, I need to relook at Amorbous anyways so will work out another way to fix the issue too, altho all of those layers/sets have paused so they should not be triggered on load up, also the 1st layer also stops the animation dead in its tracks which is why I'm surprised they are cycling at all, it should only trigger the cycle once its been triggered by a button
ALAS Wrote:One thing is definitely a bug to my opinion. In contrast to earlier versions, if there is a button (play or so) above a bigger button (eg button), the button above ´shades´ the function of the one below completely, which means no over- or down-state of the button below works within the area of the button above. In earlier versions the button above had some kind of ´passthrough´ property without losing it´s own functionality. Tried the work-around: putting a passthrough to the layers of the button above. Also doesn´t work- the button loses it´s function. In earlier versions using such a stack of 2 buttons it was possible to for example define an area of the track window to show an image of the complete set of C-buttons and hide the track window (which improves some skin´s functionality much in my opinion - I use such a setting in almost all of my newer skins). An example to test that bug is Fluss.
Hmm, I see what you've done and the funny thing again is that its taking advantage of a bug that I fixed!
Basically there should only be one object with 'focus' and responding to the mouse over, etc. I will look into how I can either fake this and re-introduce the bug, or else find a work around. It's really quite interesting how you faked it to appear as though the buttons appear when you mouse over, instead of just when the window has focus!
ALAS Wrote:Another thing is the new speed of animations. Why not keep the old speed system where 10 ms were 50-100 ms (who cares) and just change the note in the reference chart? We wouldn´t have to change every skin then ) (just my thoughts)
Ok, I've now made it 1=100ms internally and all the old animations now work normally again. Maybe later I'll allow users to specify a smaller time somehow then
Cliff
Last edited by Cliff Cawley on December 4th, 2007, 7:28 pm, edited 1 time in total.
zeolyte Wrote:cool!... I'll check my old skins for this new build...
I just checked yours and there were some problems. For the most part it was simply that you had layers visible that didn't need to be and hence it made your skin appear incorrect in the new build. I've gone through both Alexis and Valiant and fixed up all the problems so that it will work in both the old and the new builds, instead of just the old.
Just download them again from this site to compare the differences to the versions you made. It was basically just that you forgot to hide all the layers to start with
zeolyte Wrote:no color control yet on psd layers? great job Cliff!
Nope, not yet, not until I can get hardware mode working
Cliff Cawley Wrote: I will look into how I can either fake this and re-introduce the bug, or else find a work around. It's really quite interesting how you faked it to appear as though the buttons appear when you mouse over, instead of just when the window has focus!
Ok, I've now made it 1=100ms internally and all the old animations now work normally again. Maybe later I'll allow users to specify a smaller time somehow then
Cliff
... a lovely bug, really worth to be re-introduced!
I have an animated layer set (animtype 0) which only has svst, so when xion first starts up it will start to run the layers within the set, the very first thing it does is to modify multiple other animation sets with the modify(x,y,z) acanplay
on each of these animated layer set (animtype 0) there is the svst paused keywords so these layer sets do not get run until triggered
the very first layer is a blank dummy layer stopping the respective layersets (colors then cycle subsequently)
what seems to be happening is that with the multiple modify call to play those layersets, the paused keyword is being ignored and also the first blank stop layer but it should honor those settings, it seems to be skipping over both acanstop on the layer within the set and paused on the set
---
oh also whenever a skin loads and you hover over the skin the eggtimer stays on for a shortwhile, then goes
--
will extract a couple of those layers into a new psd
ok tried that and the bloody thing works as intended, so something is going funny somewhere
oh btw now using CS3 after eventually getting it installed, what a pita that was lol
so Cliff, it seems as though paused and acanstop keywords are being correctly done, and there is something deeper going on which is why its probably been a pain for you
don't really want to rebuild the whole skin but it looks like i may have to so that we can get to the bottom of it, cos its peeing me off lol, not had much sleep last nite trying to install PS CS3 Extended, had the same install problems as thousands of others lol, its not good and its certainly not funny, well it is funny in a sadistic kind of way
will keep editing this post with issues found while rebuilding Amorbous, this is being rebuilt with CS3, so far no issues with CS3 psd working in Xion
on with the things found
if you accidentally have layer orders round the wrong way for a button Xion will crash, obviously I'm dragging and dropping in layers by layers with a refresh of Xion now and again to see where abouts the deeper issue for the above post is, the button layers happened to be in order down, over, normal where they should be over, normal, down, it seems Xion is not as forgiving in that area it once was, not a big deal as they were in the wrong order but it didn't used to bomb out
whoop, think i've found the issue
basically the layerset that is being treated as though paused and acanstop is not working is above the layer order from the actual calling layerset
move it below the calling layerset and it works, move above don't work
yay
which is why you have been having issues with trying to find the problem Cliff
SLoB Wrote:will keep editing this post with issues found while rebuilding Amorbous, this is being rebuilt with CS3, so far no issues with CS3 psd working in Xion
on with the things found
if you accidentally have layer orders round the wrong way for a button Xion will crash, obviously I'm dragging and dropping in layers by layers with a refresh of Xion now and again to see where abouts the deeper issue for the above post is, the button layers happened to be in order down, over, normal where they should be over, normal, down, it seems Xion is not as forgiving in that area it once was, not a big deal as they were in the wrong order but it didn't used to bomb out
whoop, think i've found the issue
basically the layerset that is being treated as though paused and acanstop is not working is above the layer order from the actual calling layerset
move it below the calling layerset and it works, move above don't work yay
which is why you have been having issues with trying to find the problem Cliff
will send u the cut down psd with steps to repro
Sweet as, nice detective work!
Just remember I have version 7, so if possible save as most compatible version ?
Will be great to see what on earth is going on!
Btw, I'll fix that crash as it shouldn't do that at all!
. Its graphic that represents pause button flickers. I have checked the .psd, I guess it happens when "_over" and "indi_" are put together in one layer name.The same problem also happens to Alas's skin "lissabon2"