@WyldAnimal - I think that that you can quite rightly take the credit for several of us trying our hands at scene creation, at least for anythng more than just putting a clip or two in front of a nice background. Alternatively,

[b]I suppose that you could be blamed for the some of us spending far to much time on this hobby.[/b]

Gotta luv it... It's an Addiction. and it's hard to break..

You know you're *****, when you plan Other events around your Scene Coding time!

More control over Card and Clip selection in fullscreen

The Allow /Deny Clauses, and the new Category Clause ...
I think "allow|deny: accessories" must be maintained for backward compatibility, but it could be superceded by the "Category:" clause, providing
the latter worked properly on all categories, allowed the use of multiple categories, and allowed the denial of a category.
I find I would like to use statements such as:
category: bikes, cars, Big Boobs"
nocategory: naked feet
Or simply merge category selection into the allow/deny clauses (as, say fronttable and behindtable are just specific examples of table)

Also it would be nice to exclude the 3K inout clips because they screw up my fullscreens in a way that the older inout clips do not, or to select on hair colour.

I am sure it is not a trivial job, but I would like clip selection in fullscreen to be as versatile as card selection has now become in the GUI.

I guess the fullscreen capability is not at the forefront of Totem's mind - except for the cases where it believes it is losing money by continuous playing in pubs or clubs. The wretched lStripper splash every hour is just an easily programmed ***** nuisance.

I wish that there was a better way of grouping similar scenes, as there was in the old days of VG, but I am not the first to say this, and we have been waiting well over a year for such a facility.

I am sure @TheEmu, @Number6, @EverthangForever will have similar, and more, wishes.
As @WyldAnimal says, fullscreen creation is addictive, especially, I imagine, to erstwhile programmers and IT people! It certainly encourages me to continue buying more cards, even though I can watch so many pretty girls already, and my favourites tend to be the golden oldies from the early days of VGHD.

I have repeated this for benefit of those without iStripper clip manager

You can see what clip types you have in any card in future
by repeating all but step 5. below;

1. In the Fullscreen Page click on any scene except the part that says Start
2. A red outline appears around this scene
3. Ctrl-A to highlight all scenes
4. Click the large tick (top left of Fullscreen Gallery page )
until all scenes are deactivated ie: unticked.

5. download and extract the zip below into your ..scenes/ folder
(ie:...into the folder which opens when you click the folder icon
top left corner of the Fullscreen gallery page - captioned -
..'Browse the directory where Full Scenes are stored')

http://scenes.virtuastripper.net/+Perforationsclips.zip

6. Go to My Collection'
6a. Open the right margin tab 'Now Playing' and 'Clear Next'
7. ***** the card you want to look at into Next and Now Playing (right margin area)
make sure you tick the box below called Repeat
8. Go to iStripper's Fullscreen Gallery page
9. You can find 6 new test scenes labelled +Perforations.. for
Accessories
Cage
Pole
Standing
Swing
Table

10. Leave the 6 +Perforations.. scenes ONLY ticked as active

11. Start the fullscreen by using the icon next to the folder icon (top left of page)
12. Right clicking will run through all the clips in the card, showing you what types of clips the card you ***** into 'Next' has,
with the model's Show name highlighted center in yellow.

clip {
id : GirlBackRight
deny : cage, pole, table, top, sign
allow : accessories
}

In Nasita's xxx ~ 'In the Dark' card there are 5 clips marked accessories
(the handbag symbol) yet when I play the card with the above code for
allowing accessories, I get the 'No Clips.." banner 😢 Is the tangerine banana not an accessory ??
All erotisism settings are on..and yes. that is the top listed clip in the code of the .scn.
Can anyone supply the correct allow:/deny:/category:.. whatever code ? tks.

@EverthangForever -

I have not yet downloaded Nasita's 'In the Dark' card so I can't check it directly and, having a limited download quota at the moment, I can't afford to do so just yet without it afecting what I can do for the next billing period. However, iStripper XXX cards have been essentialy all 'table' clips and they are not allowed because the deny: clause explicitly forbids them. The combination of allow and deny you quote would select only standing clips that also had accessories. I believe that this restriction to all table clips for XXX is changing but I don't know if it has changed already for this card.

Incidently, I wish that there was some way to distinguish in scene files and elsewhere between the accessories for XXX cards (which are always sex toys) and other other accessories. I see three distinct classes of accessories, large ones like desks and chairs which are part of the environment, ***** ones like handbags which are carried by the dancer but are not fundamental to the clips they are in, and sex toys which are fundamental elements in XXX clips. It is a pity they all get lumped together as one category.

@Theemu, thanks I agree about sex toys vs accessories being delineated better.
I just noticed now that leaving 'table' out of deny: fixed things nicely. Will update.
Tags for different accessory classes as you say would be very useful.

Edit: +Perforationsclips.zip updated.
note that there are no pole, swing or cage clips in Nasita's xxx ~ 'In the Dark' card

@EverthangForever

I have just sent you my version of IQ's planet shader, I had to do it as three PM's because the software would not let me send it as a single post claiming it might damage their servers, but you just need to concatenate the three parts in a single .fsh file.

So far I have had no success using multiple textures in a single shader. Lezado seems to have done it in the Bikini's scene but when I tried to do the same thing it failed. I have not yet got round to investigating why it failed for me, but its almost next on the list of scene related things I want to do - if I do crack it then there are a whole bunch of utility type shaders I want to add to TheEmuLib.

Your point

It seems the sightest inconsistency with the iStripper fullscreen platform prevents a successful compile.

is well taken. There are at least two sets of problems

1a) Errors in .scn files are rarely if ever reported.
1b) Some of the unreported errors cause the scene not to play, others alow it to play but wrongly
1c) Some of the unreported errors simply cause a line in the scene file to be ignored
1d) Some of the unreported errors get a fix up by providing a default value
... for example if you misspell inoutexpo as inoutexp it gets treated as if you had specified linear.
... or if you type 1, 2 3, 4 instead of 1, 2, 3, 4 it is as if you typed 1, 0, 4, 0
1e) A blank is required after a colon, but not before it, so pos: -100, 0 is OK but pos:-100, 0 is not.

2a) The shader compiler detects and reports errors and these are logged in vghd.log, but whether these error messages are easy to use depends on the shader compiler. When I use my intel internal graphics processor the messages clearly identify the line in which the error was detected and the line numbers reported exactly match the line numbers given by Notepad++, but when I use my NVIDIA GPU the line numbers, though present, are not so clearly identifiable as line numbers and are usualy off by a few lines. This means that I can easily use the log file as a debugging aid when using the intel GPU, but its a real ***** to use with the NVIDIA GPU.

2b) Currently a shader compilation failure does not prevent a scene using that shader from running. Often it is quite obvious that the shader is not running, but equally often it looks like the shader may be running but not quite producing the effect you wanted. Sometimes it is not even obvious that there has been any problem at all.

2c) With the GLSL shader language, like most languages using a C like syntax, it is hard for the compiler to determine the cause of the error which is often many lines away from where the error is detected - e.g. if you accidently omit a closing curly bracket the compiler will only know that something is wrong when it later finds that there is a mismatch between the numbers of opening and closing curly backets - and this may not be apparent until hundreds of lines later. It is possible to do a better job of error reporting for these errors, but it takes a lot of effort to do so and many compilers just report an error where it is detected rather than try to determine a more exact location of its cause. Short of writing a new GLSL compiler there is little that Totem, or anyone else, can do about this as it is a problem with the laguage design. At least shader sources are usualy quite short, I have had cases when using C or C++ when the reported location of an error was thousands (occasionaly tens of thousands) of lines after the actual error - I do not write such large C or C++ sources, but I do use program generators that often output huge C source files.

Totem could do a lot about the first group of errors, those in the scene file, At the very least they could report them and not silently fix any up.

Totem could improve the handling of errors detected by the shader compiler by outputing messages about them to somewhere other than the vghd.log and providing access to it from the GUI. In principle they could improve the matter of the line number mismatch when using the NVIDIA compiler, but that would need GPU compiler specific code and they can't be expected to handle all possible GPU compilers. They could also not run a scene if a shader error was detected, or at least display a "Shader Error" message. There is nothing anybody can do about the aspects of the GLSL language that make error location difficult.

Here is text of a previous post I accidently deleted to which @TheEmu has replied above.

@TheEmu I am noticing that more and more of the shadertoy.com shaders are using several channels to compile. I am having next to no luck (zippo,nix,nada) trying to adapt them to work on this platform with your conversion protocols. eg: IQ's Planet https://www.shadertoy.com/view/4sf3Rn
It seems the sightest inconsistency with the iStripper fullscreen platform prevents
a successful compile. I wish I knew what it was. I've started to run iStripper desktop over at shadertoy since there is no rebirth of the virtuagirl debug screen. Not very satisfactory, but at least I can tweek the code there.😢

Thanks for helping me resolve the difficulties with IQ's Planet shader.
As you can see your remix of it to one texture channel now works fine.

@EverthangForever - don't know if you are familiar with the Dan Dare strip that used to appear in the old Eagle comic, but the picture in the latest post reminds me of its chief enemy, the Mekon, who floated about on an anti-gravity disc. Though, being a small, green, ugly, evil alien with a very large bald head and tiny arms and legs he would hardly qualify as an iStripper dancer.

HAHa...Looks like Estonika gave him the boot. Yikes 😊
Yes, also tried to post the code you gave me here but was disallowed on both iStripper and web forums.
I don't know what specific symbols are verbotten because I posted earlier lots...very strange hmmm.

Will it work if you post in stages & maybe in quotes:? Edit: No.. Indeed it does not post more than this ~ resistance is futile :-/

// Original obtained from ShaderToy.com
// Adapted, trivialy, for VGHD by TheEmu.

uniform float u_Elapsed; // The elapsed time in seconds
uniform vec2 u_WindowSize; // Window dimensions in pixels

// Use defines here rather than edit the body of the code.

#define iGlobalTime u_Elapsed
#define iResolution u_WindowSize
#define iMouse AUTO_MOUSE

/////////////////////////////////////////////////////////////////////////////////

// The ShaderToy shaders often use textures as inputs named iChannel0. With VGHD
// this may access a Sprite, ClipSprite or ClipNameSprite image depending on how
// the .scn file declares them.
//
// Note, the name used here does not seem to make any difference, so I have used
// iChannel0 which is what is used by ShaderToy but you can use any name as long
// as it matches the use in the main body of the shader. TheEmu.

uniform sampler2D iChannel0;

// With VGHD the range of the P argument's components of the texture functions is
// 0.0 to 1.0 whereas with ShaderToy it seems that the upper limits are given by
// the number of pixels in each direction, typically 512 or 64. We therefore use
// the following functions instead.

vec4 texture2D_Fract(sampler2D sampler,vec2 P) {return texture2D(sampler,fract(P));}
vec4 texture2D_Fract(sampler2D sampler,vec2 P, float Bias) {return texture2D(sampler,fract(P),Bias);}

// Rather than edit the body of the original shader we use use a define here to
// redirect texture calls to the above functions.

#define texture2D texture2D_Fract

/////////////////////////////////////////////////////////////////////////////////

// Simple "Automatic Mouse". Simulates scanning the mouse over the full range of
// the screen with the X and Y scanning frequencies being different. TheEmu.

#define MOUSE_SPEED vec2(0.5,0.577777) * 0.2
#define MOUSE_POS vec2((1.0+cos(iGlobalTime*MOUSE_SPEED))*u_WindowSize/2.0)
#define MOUSE_PRESS vec2(0.0,0.0)
#define AUTO_MOUSE vec4( MOUSE_POS, MOUSE_PRESS )

Being a dedicated fullscreener, I have become accustomed to unticking clips with the double inout symbol.
I've just noticed that in older cards, this symbol does not imply the girl starts as half an image (in desktop its split on the side of the screen). i will have to go back and retick some..
Anyhow it is good to run each inout clip first before you uncheck...gasp !

@EverthangForever

IIRC the problem is only with 3K cards and then only with the ones that were originally issued as 3K. The old 1080p and 720p cards plus the 1080P cards that were upgraded to 3K have the original in/out where the girl enters from the side not in mid-air.

HTH

It would be nice if they added a seperate deny/allow clause just for screen side clips. ( : side ) would work for me. In/out should be only for walk in/pole clips only. I rarely care for any screen side clips except very few ladies :)

@Number6 thats really helpful tks..I used to sometimes put deny: inout in early .scn code for table, pole & other scenes.
I don't really want to go back to doing that again if it affects cards differently:-/
With the latest cards i just untick inout clips as i find them. For older 3K cards which were not 1080p upgrades, here's what I do:
If a split model appears on my fullscreen I immediately go to My Collection the Now playing side tab
and it will be the card most recently played in History.
If I click on that cards pic in History, I can deactivate inouts in clip list from this Card's page.
Its a little cruder than systematically going through them all however gets less and less the more you do.

Edit: @DANO70, agree. However if they brought it in, a lot here will have to edit code & reissue a huge stack of scenes.
thats why I took the lazy way deactivating inouts. Btw, I'm still unclear if clip node 'category:' parameter is up and running or meant to work.

is 'category:' only useful using the latest version of iStripper ?..What are its range of properties ?..etc :-/

It would be nice if they added a seperate deny/allow clause just for screen side clips. ( : side ) would work for me. In/out should be only for walk in/pole clips only. I rarely care for any screen side clips except very few ladies :)

There is no Coded designation for Side type In/Out clips.
All In / Out clips use the same code value of 64

Early On, the Behind the task bar clips, where a model Pop ups from behind the task bar was also called In/Out
It was later used exclusively for clips where the model enter or Leaves the screen from the Side.

The Desktop Player, used the Code value 64, to re-position the clip to the side of the screen.
So the Walk on / Off clips enter or Exit the side, and the Half Clips, are placed at the side of the screen to start.

But All In / Out clips share that one code value of 64.

To get the clip prefix Number, you add together all of the Code values for the clip type.
Then the Last Three Digits, are Level, and Clip number
There could be More than One Clip of the same type, and the same Level, so the last two Digits are clip number.

Clip types use the Binary system.
there is a 24 bit Binary value that determines the clip type.
Each Bit has the Value of 2 raised to the Power of the Bit.
each Bit can be a 1 or a 0 If it's a 1, you Multiply it by the bit value, and add that to the Name.
once you have added all the bit values, that becomes the Prefix Name.

So Bit 0 ( the One all they way to the far right ) , has a value of 1 2^0 Two to the Power of Zero = 1
Bit 4 has the value of 16 2^4 Two the the value of 4 = 16

take this clip name: e0119_38912502.vghd
it's card e0019
the Last 3 digits are Level and Number So its 502 = Level 5 Clip 02
the Prefix is 38912 How do you figure out what it means ?
You subtract the Biggest value you can. Until you get to Zero.

From the List Below, what is the Largest number you can subtract from 38912 ?
32768 - Nude at start
that leaves 6144, what is the largest number you can subtract from 6144?
4096 - Interactive at the end ( it will play a transition clip at it's end )
that Leaves 2048, what the largest number you can subtract from 2048 ?
2048 - Interactive Start ( means it can be played right After a Transition Clip )
we are at Zero.

so 38912 means Nude at Start, Interactive End, Interactive Start
and 502 means Level 5 XXX, and it's clip number 02

Here is the List of the bits, their Value and What they Mean.
This is my own Compiled list, it's not been provided by the Team.

0 - 1 - Over Task Bar (in front of On top of Task bar )
1 - 2 - Task Bar Over (Behind task bar, can climb on top from behind )
2 - 4 - Pole
3 - 8 - Full Legs shot in 4K
4 - 16 - Holds a Buy Me Sign- Holds a Sign
5 - 32 - With Accessory
6 - 64 - Enter Exit from side
7 - 128 - reserved
8 - 256 - reserved
9 - 512 - Cage
10 - 1024 - Swing Top of Screen
11 - 2048 - Interactive Start ( opposite of Dry Start )
12 - 4096 - Interactive End ( opposite of Dead end )
13 - 8192 - Magic Spin at Start
14 - 16384 - Magic Spin at End
15 - 32768 - Starts out Nude
16 - 65536 - Glass
17 - 131072 - reserved
18 - 262144 - reserved
19 - 524288 - reserved
20 - 1048576 - reserved
21 - 2097152 - reserved
22 - 4194304 - reserved
23 - 8388608 - reserved

@DANO70

It would be nice if they added a seperate deny/allow clause just for screen side clips. ( : side ) would work for me. In/out should be only for walk in/pole clips only. I rarely care for any screen side clips except very few ladies :)

I did bring this up last year.

http://www.istripper.com/forum#/forum/thread/32442/last#post494409

Vous n'êtes pas autorisés à voir ce sujet et à accéder aux données relatives à ce sujet

The problem with the In/Out 3K clips is that you can't position them accurately. What works for one clip doesn't work for another otherwise it would have possibilities say for a girl coming out of side room, or appearing from behind a door or a screen.

It was discussed some time back either in this thread or the shared scenes thread.

@Everthang Forever

Btw, I'm still unclear if clip node 'category:' parameter is up and running or meant to work.

is 'category:' only useful using the latest version of iStripper ?..What are its range of properties ?..etc :-/

I think again that this has been discussed either in this thread or the shared scenes thread.

I think the conclusion was that some work and some don't. Bikini's certainly works as Totem use it in their Bikini's full screen scene.

Edit - apologies I'm not sure which version of iStripper it was but I'm fairly certain is was one of the Beta's towards the end of last year when it was announced.

That's right I totaly forgot about the positions differ so much for side clips in scenes. I never use them in scenes so my mistake :0

Re: @Wyldanimal's useful explanation of how clip categories are encoded into the clip file names.

I have long been of the opinion that Totem made a bit of a mistake when they decided to do this as it means that if this is the only source of the clip characteristics then if a clip needs to be recategorised then the clip's file needs to be renamed and any references to it by name (e.g. in playlists) also need to be tracked down and changed if they are to remain valid.

A better scheme, in my opinion, would have been to have a database of some kind which provided a way to look up the actual categories for each clip. At its simplest this could be one extra file per card containing one record per clip. With such a scheme translating from file names to clip characteristics would be done by via the database. This would allow categories to be changed or added without having to rename any files and this would allow the various meanings of "in out" to be disambiguated.

The space overhead should be small, one file per card, one record per clip comprising a file name and a 32 bit or 64 bit integer with the decoded clip categories. There would be a small time overhead, but this would be minimal if the file for a card was read just once when the card is first accessed.

I could envisage such a sceme being introduced incrementaly with the software decoding the file names directly if there was no clip categorisation file for a card. To avoid impacting existing scenes you would probably want to keep the current meaning for "inout" but add something "inoutentry" "inoutedge" just as we currently have "table", "fronttable" and "behindtable".

Re: @Wyldanimal's useful explanation of how clip categories are encoded into the clip file names.

I wrote this in another thread. You Can rename the Clips on your own.
The New Name will Affect how the GUI selects the Clip to be Played.
But changing an In/out clip to a table Clip, wont change how it Plays, only how it is Selected.

Since we know only the 3K in/out clips are the Ones with the Half Image.
you could write a bit of Code, to Locate all the exxxx 3K in/out clips and rename them.

this would then prevent them from being Selected as In/out clips.

you can do this for any .vghd clip in yur Collection. You can't do it for .demo clips.

http://www.istripper.com/forum#/forum/thread/35952/last#post529377

Le coin des nouveaux / How to rename shows to play it diffrently

Members can alter the erotic level classification of the card, but you can't alter the Type of Clip. you can't change a Pole clip to a Table Clip, so it is Zoomed Closer. ( you can rename it, but it w...

@TheEmu

Re: I have long been of the opinion that Totem made a bit of a mistake (by encoding the clip's staging information in the file name)

I agree. This fondness for "smart" codes goes back at least to punch card days where data space was at a premium. It may well predate automation. In Totem's defense, since a card's staging can not be changes they may have seen no problem. As you and others have pointed out while the staging may not change our need to describe it has.

There is also a very human desire not to add new categories to a classification scheme when an existing category can be stretched to "fit". I've been guilty of this myself and often learned to regret it.

Re: A better scheme, in my opinion, would have been to have a database

Totem already has an excellent vehicle for this -- the a9999.xml file in each card's data folder. This file already contains a great deal of descriptive information about each card. It would be easy to extend it to hold clip information including tags. Conceptually, easy but a considerable amount of programming and testing.

@Wyldanimal

I saw yow previous post about renaming so I was aware that it was possible, but it is not a good general solution. As I mentioned if you rename anything you need to track down anywhere that uses the name, such as playlists and backups, presumably your collection would be somewhat out of sync with what Totem thought it was. Introducing a level of indirection via a database avoids most, possible all, problems. There is an old programming aphorism along the line that you can solve any problem by introducing an extra level of indirection, except the problem of too many levels of indirection.

@Dorsai6

Indeed the xml file would be a suitable place to keep the clip characteristics. I personaly do not like the habit of using xml when much simpler file formats would do the job, but given that the file is already there and has to be processed (or a previously cached version of its data has to be used) whenever a card is accessed then it might be sensible to use it.

Ok guys and gals I'm going to try my hand with a file host (never used one before). I want to test it here instead of using the share thread incase I've done something wrong. Any how if you could try to download these test scenes I made to see. I have multiple girl versions of it (up to 5 girls) but these are just the 2 girl.

https://www.dropbox.com/s/vgoezyvklt3zmbw/ATLANTIS-D7.zip?dl=0

Can someone please confirm my scene/linking works for anyone other than myself. I promise it's only a scene and not a Trojan. Pun intended. LOL

@DANO70

Both of ur scenes downloaded fine and run on my machine (Win 10 w/iStripper v1.2.1.72) but the first one "Atlantis 2 Girl" will run table scenes and the clips where the girl is standing behind the table make her look like she is coming up out of the conveyor. I don't know if the other one does it or not...

Was that what you had in mind?

Yes both are set to use all clip types except the swing in these. I thought it looked interesting as if the girl was coming up from behind the conveyer. I didn't think it would be that noticeable :). My goal was to use all types possible. The 5 girl version does have a swing and a flipped conveyer at the top as if the girl is being carried left to right on it. Oh and thanks for the confirming you can access it.

I happen to work on conveyors from time to time in the "real world" so seeing the girl come up through one was a little surreal.

Other than that, I like the motif and may even use it for my screen saver!

Thanks!

LOL..Yeah I guess I should have brought the girls alittle higher up off the conveyer. I'll do that before I make a share thread post.

@DANO70 Love it...It works fine on my PC. The only thing I did to tune it a tad ~ instead of extracting zip directly into the scenes/.. directory
I first made a sub folder ../scenes/DANO70 and extracted it into there.
Less ***** if you want to later intend to use only those images there that you have selected in your scenes as an open folder
Using an author name specific path in your zips overcomes issues where other authors may have used a similar path earlier like ../scenes/images.
Nice going !!!. Thanks 😊

Oh I thought I had it in a sub folder. Glad you said something. No I didn't do that when I zipped it for upload though.