xPerT -- PervTalk plugin for Xlobby

[abobader]

Hi P3rv3rt,

Thanks for the update info, I better wait then, any est. time before Xtalk be ready?

My best.

[P3rv3rt B3ar]

Hi P3rv3rt,

Thanks for the update info, I better wait then, any est. time before Xtalk be ready?

My best.

Actually XTalk (PervHub) is ready, but i only have released it for alpha testers of kXd. Reason for this is that ZPd (zoom player device) is not ready. I wanna release those together to general public for beta testing, cause giving PervHub out without devices to connect it wouldnt make much sense. (i released xPerT earlier cause its other function is XL-toolkit with wide selection of conviniency features)

ZPd has been pretty good readyness state for a long while... but problem has been bug in xPerT which i havent been able to fix totally yet and which has been foiling development of ZPd. Bottomline is if i can complete new version of xPerT in these 10 days (bug fixes & features) then i can continue with finishing implementation of ZPd, that could mean release of XTalk (xPerT, PervHub, ZPd) about as soon as months time. On the other hand if im unable to finish xPerT within these ten days, ill no more have access to C#, and this will delay release unknown period of time.

BTW i was today working on new implementation of random variables and it seems to be successful increasing speed greatly, so if u try current version and it seems too slow... there is improvement on the way.

[P3rv3rt B3ar]

Theres bug in 0.91 and experimental version for BFauska, which affects processing of deepcats. Flatcat processing works normally. So if u r currently using 0.9 version, u better off with it, do not upgrade to 0.91 version unless uniqueness requirement of parameter field is showstopper for u.

[abobader]

Hi P3rv3rt,

In the download link, only ver 0.91, where I can get ver 0.90? (I am sure I d/l before, but can not find it now).

My best.

[P3rv3rt B3ar]

In the download link, only ver 0.91, where I can get ver 0.90? (I am sure I d/l before, but can not find it now).

I think this should be it.

Also there is bug in call command in all released versions. So instead of using xPerTs call-command rather use new event launch feature included in core XLobby by Steven. Allthough bug will only manifest it self in rather complex situations like calling call inside call...

Anyway im totally bogged down with bugs now, even simple improvements or additions seem to take day or two to implement, so im rather sceptic about being able to make new version within deadline. However my laptop looks like it could use windows restall, so i might just keep a week rest of coding and then have another month of stabbing xPerT up.

[P3rv3rt B3ar]

new xperimental version for rika is here

I dont recommend it for others, most traditional xPerT features are probably unstable so u are better off with older versions.

[P3rv3rt B3ar]

It contains slideshow features but theyre not yet fully implemented, so far it only accepts png files. usage is much like loadanimation:

Code: Select all

plugin>xPerT>loadslideshow>name>files>runmode>slidetime

where:

name is user selectable string which works as handle to slideshow, u use it in slideshow commands and ull need to put it in ID of text field containing loadslideshow variable.

files: these are files included into slideslow, there is several ways to specifie them, first of all u can specifie whole directory, with full path, all .png files in directory will be included in slideshow, but order is unknown. Second way to specifie file attribute is use several full path filenamesseparated from eachother by comma. Third way is to use some xPerT variable magic [C:\animation[1...10].png] will include all files from animation1.png to animation10.png in C: root. Note that u must not use variable amount of leading zeros within filenames. Also note that outern brackets in that type of expression are mandatory too.

runmode should contain one of three following options stopped|runonce|runover this will tell how slideshow will be run when it is first loaded. runover means it will loop, rest are obvious i suppose.

slidetime, number telling how long each slide will be show in seconds. this works opposite than framerate in animations, so if u wanna achieve 20fps
u can specifie it as "1/20" so fractional numbers are allowed together with regular integers.

Here is one example of use:

Code: Select all

plugin>xPerT>!0!loadslideshow>animation>[C:\weatherimage\[1...48].png]>runover>1/5

Slideshow called animation will be loaded with 48 slides from c:\weatherimage folder and show to user in constant loop with framerate of five images per second.

note that !0! above is needed if slide time is smaller than one second, other wise animation wont be updated often enough. If u want u can replace it with !instant! that might give surprisingly enough much more CPU efficient performance, but with sacrificing some responsivenes to user input. However responsivness lost should be rather small with high framerate. In most practical situation !instant! will prolly work better of two options.

There are also few slideshow related commands:

StartSlideshow
StopSlideshow
ContinueSlideshow

startslideshow takes as first parameter name of slideshow, and as second parameter runmode as explained above. Other two commands take single parameter which is name of slideshow. Startslideshow will always start slideshow from beginning. Stopslideshow will stop it and continue will start where stop left. Separator for parameter is as usual '>'.[/code]

[P3rv3rt B3ar]

There seems to be bug, which causes xlobby to hang. It happens only when non fractional value is used in slide showtime. reason i didnt notice it before is cause i only tested with fractional values, cause i believed Rika was more interested about showtime of less than second. Ill look into it.

EDIT: i tested with value 5/1 and it doesnt work either, so problem seems actually be related to fact if value is larger than 1, not related how it is given (fractional, or integer).

2nd EDIT: yeah fixed it, just stupid little oversight, i wont be putting fixed version out just yet though... will work on something else too... buggy version should be fine for testing as long as slide time is kept under one second.

[rika]

P3rv3rt B3ar. Thanks for all the effort you put in to this.
This is going to be super cool!!.
The cpu is ok even with big animations. What i have notised is that even if a animation is stopped it runs in back and takes cpu. If you hide the animation after stopped or go to another screen the cpu is back to normal again.
If it´s not to much work i would like a possibility to hide the animation from the plugin after "runonce" (hide as an plugin parameter) . Or some how make it not take cpu after a animation has runed once or has been stopped.
I allso have problem with framrate, i dont seem to be able to set them even with animations less then one sec. !0! or !instant! doesent mather. But this might been fixed with your changes.
It seems that when a id has been set and loaded by the plugin you can´t edit the plugin text (Eg: change png folder). If you delete a animation ,you can´t use the same id for a new animation. It seems that once a id is loaded by the plug you can only use it for that specific animation. Doesent matter if you delete the animation, you can only use that id for the same animation again.
Is all animations cached by the plugin?
If it´s possible i would like to be able to use "skin://" insted of full folder patch for png folders.
Once again thanks for your work on this

Rika

[P3rv3rt B3ar]

The cpu is ok even with big animations.

That is very good news. I noticed that especially when using !instant! CPU consumptions wasnt much more than xPerT in dormant state. Ofcourse in that case slideshow have to fast enough, not to cause too much inconvinience for user as slow responsivines. Ok ill answer these points now without checking code, ull have better answer later when i have change to do little testing and debugging.

What i have notised is that even if a animation is stopped it runs in back and takes cpu. If you hide the animation after stopped or go to another screen the cpu is back to normal again.

Ill have to test this to find the culprit. It really shouldnt be the case, they should only take up memory while not running, since i havent implemented housecleaner for slides yet. Im certain this will get fixed, it just might take time to locate, i have one possible cause already in mind though.

If it´s not to much work i would like a possibility to hide the animation from the plugin after "runonce" (hide as an plugin parameter) . Or some how make it not take cpu after a animation has runed once or has been stopped.

I think i can do it.

I allso have problem with framrate, i dont seem to be able to set them even with animations less then one sec. !0! or !instant! doesent mather. But this might been fixed with your changes.

Hmm, this sounds alarming, have to do some tests. Its certainly not fixed.
Double check u didnt forget ID value though. Also xPerT in noway gives any realtime guarantee, its just best effort, but really what u r saying sounds like its not putting even near the best effort, so i must assume theres a bug, which values have u used for framerate?

It seems that when a id has been set and loaded by the plugin you can´t edit the plugin text (Eg: change png folder). If you delete a animation ,you can´t use the same id for a new animation. It seems that once a id is loaded by the plug you can only use it for that specific animation. Doesent matter if you delete the animation, you can only use that id for the same animation again.
Is all animations cached by the plugin?

Yes, all are cached, and i dont currently do any housecleaning on slides yet. I will add housecleaning shortly though. Generally with xPerT it is good to reset XLobby after changes to text elements to be certain of its true effects. Unfortunate, but it is how it still is with many variables. So anyway, house cleaning i was planning is type i do with many other features, which after certain amount of seconds removes unneeded (unrequested) stuff from cache. But reading between lines what u r saying here, it sounds like u would like to reuse slide names, i can imagine that it could be great help for u to have one command to control several different animation on different screens, is this what ud like to achieve? in that case i could add besides above described housecleaner, a command which would let u purge cache, so u could use it when changing screens...

If it´s possible i would like to be able to use "skin://" insted of full folder patch for png folders.

did u try it? it didnt work? it should be there, but i cant remember if i ever tested it or not. if "skinn://" doesnt work try "skin:/"...

[P3rv3rt B3ar]

Ok Rika,

I did tests concerning about slidetimes under one second. I was using your 30 frame png animation and slidetime 1/15, so if animation would really run that fast it would need to complite in 2 seconds. My machine is 2.8 dual core. So when i used !0! animation took about 7 seconds to run, taking up around 50% of CPU, so this is far from what it should be, but still double better than times u reported (no better than one frame in second) When i replaced !0! with !instant! performance was considerably better, animation run about in 4 seconds, well ofcourse this is still only half what it should be, but almost double as fast as with !0!, i guess that creating many threads which !0! does to ensure responsiveness, is too slow for animation. Also processor consumption was only around 30%. Im pretty sure that fact u use bigger animation explains that u experience only one frame per second framerate.

Ill have to try to figure something to improve the performance... but thing is im not quite sure what... so for now ull just have to take slidetime as limit, which means that slide is atleast shown that long

[P3rv3rt B3ar]

Ok rika, fixed it.

It turns out there where couple sleeps there on reused code parts, they were in place to limit processor consumption, but ofcourse when its about animation they did bit too much limiting.

So my new test version, with same parameters than above runs it either 3 seconds or 2 seconds like it should, its just hard to say cause it is so fast , but naturally this is on expense of processing cost, just unavoidable when u remove sleeps, so it will consume about 50% in my test.

Ill start to wonder stopping animation prob now...

[P3rv3rt B3ar]

Yes rika, it turned out youre quite a bughound huh... it was a bug, just stupid little wrong order of few sentences which caused something needles to run in background within endless loop, while animations were stopped. It is fixed now in my new version. However even the animation is stopped processing consumption seems to stay somewhat high. Ill better to release it soon for u to test, hopefully u can point out another culprit... but seriously it might be just general overhead asociated with xPerT, i need to run certain upkeep stuff on background, managing caches and such. Also im doing screen update in every 10 seconds in this xperimental version, but i think ill set this user configurable in final release version. Well problem is i cant quite explain consumption just with background functions alone, but there is also several other plugins and stuff running on my test screen so mayby u can better analyse the performance.

Ill make some other additions and fixes and will release it for u to test some point in the morning, scandinavian time.

EDIT: just as i suspected, it should be totally fine now. turned out that it is actually xclock which is giving me extra overhead, im having it on "eye of the dragon" in menu screen, while mouse is not over menuitems. It fits there perfectly. Anyways when i move mouse over menu items (xclock gets hidden) animation stopped, process consumption drops around 10%, thats explained by xPerTs house keep and all random processes running on comp.

[P3rv3rt B3ar]

Made few addations, to boost use of slideshow for its namesake purpose.

first three new runmodes:

"runandhide" got idea from rika, he needed this in case to minimize resource comsumption, but since problem got already solved i made this only for cosmetic purposes, it runs slideshow once and then disappears.

"boomerun" runs once and returns back to first slide.

"reverse" name says it all, except it runs continously like runover.

And then two new commands:

"NextSlide" and "PreviousSlide" i have feelin these dont need explanation either. Both take one parameter which is name of the slideshow.

Also "StartSlideshow" now takes one extra parameter, which is slidetime, it can be omitted if wanted.

Like i mentioned earlier, release at dawn.

[P3rv3rt B3ar]

Ok, as promised new xperimental build, for Rika and Scalt as well, is for u to experiment, just use last download link.

Unfortunately couldnt cram all i planned inside yet... forexample house cleaning for slideshows is still on to-do list, i just love cleaning tasks

But there is command FlushSlides for manually cleaning slideshow cache. So if u plan to change slideshow in fly, ull need first call "set text" command and "flush slides" afterwards, and slideshow should change, untested, but neat if works flush slides doesnt take any parameters.

For Scalt there is implementation of few of those wishes u made, percentage view, and incremental/decremental value change. But before u do anything u better copy your old xPerT and affected skin files to safe. Anyway i suppose there is no hurry before i write instructions for use of new features and im too tired now... so watch out kXd thread in near future.

I even did graphical progress bar... but that beast has sticky bug... cant figure out what to do with it