@EverthangForever userProfile.php?usLogin=v8224782

OK. I've written the script and tested it against ETFractalGardenUpdate002.zip

http://scenes.virtuastripper.net/ETFractalGardenUpdate001.zipThe script works. However, the original scenes seem to run fine in the latest version of VG on my Mac Pro. The revised scenes also work. Go figure!?

My advice: Test the scenes. If they work, nothing more. If not run my script.

The script is the next message. It can be run by pasting the text into the AppleScript Editor in the Utilities folder of you Mac. You can then save it as a script file. To run it, just click run in the editor.

There is some self-defense built in. It will create a back-up folder on your desktop with the name of the original folder followed by "(original)". It will copy the existing scene files to that folder before making changes. If that folder already exists, it will issue a warning and not run. Also it creates a journal of all the scene files revised and the number of backslashes found in a file named "scene repair log.txt" on your desktop.

One last item. I intend to simply past all the source code into the next message. Sometimes this message system drops special characters. If this happens, I'll add an edit note at the end saying where the source must be repaired.

set parent_folder to (choose folder with prompt "Pick the folder containing the sceens to process:")

-- Set up
tell application "Finder"
set folder_name to name of parent_folder
set dup_name to folder_name & " (original)"
if exists folder (((path to desktop) as string) & dup_name) then
display dialog "An original scenes folder named " & quote & dup_name & quote & " already exists on the desktop.
Rename or move it." with icon stop buttons "OK" cancel button "OK"
end if
set file_list to every file in parent_folder
set backup_folder to (make new folder at (path to desktop) with properties {name:dup_name})
end tell
set log_id to open for access file (((path to desktop) as string) & "scene repair log.txt") with write permission
write return & return & (current date) & return to log_id starting at eof
close access log_id

-- Process each file
repeat with this_file in file_list
tell application "Finder" to set file_name to name of this_file
if file_name ends with ".scn" then

-- Read scene file
set input_id to open for access file (this_file as string)
set scene_code to read input_id
close access input_id

-- save backup
tell application "Finder" to move this_file to backup_folder

-- replace \ with /
-- Note \ is a control character in AppleScript so it must be repeated "\\" to be the explicite character
set AppleScript's text item delimiters to "\\"
set backslash_count to (count of text items in scene_code) - 1
set fixed_code to text items of scene_code
set AppleScript's text item delimiters to "/"
set fixed_code to fixed_code as string

-- save revised file
set output_id to open for access file (this_file as string) with write permission
write fixed_code to output_id
close access output_id

-- log action taken
set log_id to open for access file (((path to desktop) as string) & "scene repair log.txt") with write permission
write file_name & tab & backslash_count & return to log_id starting at eof
close access log_id
end if
end repeat
say "finished"
display dialog "Finished"

ET - +SeptetFountain.scn code within the ZIP ( example shown above) was a good example to try @Dorsai6. Thank you.
We need some other Apple users to report back whether the most recent VGHD +/or iStripper versions are still affected by incorrect backslashes on their systems. Most grateful for your work on the script.

@Dorsai..well thats a relief. No reported problems. I guess Totem fixed the apple player to use both \ and /.
---------------------------------------------------------------
Pic above is further to the points raised by @Number6 in
"InOut" Clip Types In Fullscreen Mode

http://www.virtuagirl.com/forumPost.php?foId=4&ftId=32442&gotolastpage=1#post494511

このトピックに関して見る事やデータへのアクセスは許可されていません。

I've been looking for an entertaining way to use these 'in / out' clips in fullscreen however I keep running into problems with em.
I am trying to seamlessly mirror the model at center screen the way some cam-models do with their cameras.
When I get it right for one clip, the identical scene shows the models are offset in another clip. They either overlap or further away with a gap. Either way it is not seamless from clip to clip, card to card.

In other words there appears to be no consistant reference position for any of these animations when 'in / out' clips are filmed. Unlike pole clips which generally match centers ok when models change. That sort of puts an end to thoughts of scene authors using these clips with any sort of positioned accuracy.
I've Illustrated the problem in above scaps of exactly the same scene using different cards.
As can be seen, when its perfect for Sapphira it is hopeless for Sarika & obviously also vice versa.😢

@EverthangForever

In other words there appears to be no consistant reference position for any of these animations when 'in / out' clips are filmed.

I did some experimenting. I have 3 monitors. It appears that the reference position for an in/out clip is the edge of the screen. I expect that the pole positon with reference to that edge may vary from one shoot to another. Also the window width for each clip is not the same, so a fixed side will result is a different center.

@Dorsai yes I suspected that. Each clip has different width. Unfortunately there is no way we can code scenes so that left and reversed right edges meet unless @Team or @TheEmu knows of a way.

Here is the SCN code for the clipsprite I was using
to experiment with Sapphira ~Secret Garden clip e0340_2112201
camera {
type: 3D
angle: 45
pos: 0, -480, 900
target: 0, -500, 0

clipSprite {
pos: 108, -160, -50
rot: 180, 0, 0
source: clip
standingHeight: 660
scale: 1, -1, 1
}
clipSprite {
pos: -108, -160, -50
rot: 0, 0, 0
scale: -1, 1, 1
source: clip
standingHeight: 660
}

@Dorsai6. I started learning Basic computer language over 30 years ago. Ok, it WAS Sinclair Basic but it was pretty easy to learn as it used REAL English words, in general. (Peek, Poke, etc..)

I've never seen Mac code in so much detail before. I think I have to buy a Mac one of these days...

Hell, your AppleScript looks like you're sending a letter in almost plain English to your CPU!!!
Hey, CPU, do this for me will ya? Cheers! :)

I could learn that language in a week ;) Hehehe. Nice one buddy :)

Hombre,

I learned FORTRAN in 1963, BASIC somtime about 1969, COBOL in 1976 and C in 1984. There has been more since then. Apple was attempting to make AppleScript an approachable language for casual users. I'm not sure how successful they were. It's a straight text based compiled language. However, it does provide some very powerful feature that allow you to ***** almost any application running on your Mac. I use it, for example, to extract my checking and credit card information from the internet and load the processed results into a database.

The Mac is a fine computer with an excellent operating system, but over priced. I bought my first in 1985 and I've never owned an MS-DOS or Windows computer, but I've been ***** to use them by clients.

Edit: Added paragraph 2

Hmm.. I'm tending to agree with @Number6 about needing a parameter Clip allow: setting like InOut3K
for in/out clips.

I'm not convinced Totem cannot do something about in/out clip shoots, to make placement consistant. Surely all they have to do is move their blue divider screen edge to the exact same position as the pole would usually be in, when they film. Totem control the sweet spot settings on the side screen edges for rotations of clipsprites..not us. I suspect the current inconsistant flaw with centering is maybe a touch of carelessness in setting up the camera & blue divider screen by the techs.:-/.

Why is all this important ? Fullscreen users pay for all the clips in a card. They don't like having to uncheck or deactivate 2 or 3 clips every second or third card they buy because they look incomplete on fullscreen.

@EverthangForever

I'm not convinced Totem cannot do something about in/out clip shoots, to make placement consistant. Surely all they have to do is move their blue divider screen edge to the exact same position as the pole would usually be in, when they film. Totem control the sweet spot settings on the side screen edges for rotations of clipsprites..not us.

I agree with you, but I'd suggest a different solution. (I have never tried to create a full screen show, but I have looked at various people's code.) Right now, the only placement control is based on center stage. What if you could tell an in/out clip which side of the stage to come from and place that edge in your scene instead of the clip center? I think that would give you what you want and it would work with all in/out clips.

@Dorsai6
Yes I can do that already ..say..with pole clips. But the pole position in relation to the camera is agreed exactly the same for every pole shooting. The scene coder can place the pole exactly where he wants..so many pixels left or right of center, so that it is located right on the edge. of the side of stage/screen for every pole scene.

Problem I have is that in the new 3K in/out clips, we do not seem to have an agreed model center measurement like with a pole. Sometimes the masking out part starts a little to the left or a little to the right depending on the card and this varies for every in / out clip made.

It means that even if @Number6 gets his request granted for a clip parameter syntax ~ allow: inout3K
he will still be unable to acheive agreed positioning for his scene file because the in/out model referencing position will vary the placement of the blank-out position for each different card that plays.

Totem's player must have a clipsprite hotspot position they can reference for every clip for the desktop to work.
It is just that we cannot access this the same way in fullscreen.

@EverthangForever userProfile.php?usLogin=v8224782

Sometimes the masking out part starts a little to the left or a little to the right depending on the card and this varies for every in / out clip made.

Yes. This is because the exact width of a clip's "stage" is not constant. When iStripper places an in-out clip it uses the edge of the stage as the basis and align's that with the edge of the monitor. When it places all other clips, it uses "stage" center point. This is pretty clear if you play just one clip in small mode at, say, 20% of full size. The regular clips are centered and the in/outs are at the edge.

Totem's player must have a clipsprite hotspot position they can reference for every clip for the desktop to work.

That's just the problem. For an in/out clip there needs to be an alternate hot spot -- the edge of the stage rather than the center. This is what Totem uses. They need to make this available to full screen programmers.

I suspect that the VG and iStripper software calculates the edge position each time it prepares to display an in/out clip. It must do this because the stage width is different for every clip and the needed offset depends on the scale factor the user has selected. This would explain the long delay I notice before an in/out clip starts playing. It would also explain some strange behavior I see when I use very small scales on my 3-display system.

Yep - I'm somwhat disappointed to the least.

I though I had done a couple of scenes which actually worked for the 3K in out cards - positioning the models at the very edge of the screen.

Unfortunately I only tried it with a few 3K inout clips and it seemed OK.

I tried it again last night after @EverthangForever's post and low and behold some of the clips were actually well away from the screen edge.

The only advantage of have ing a second keyword for 3K inout would be to "deny" it in the old inout scenes.

I think I'll end up creating a non-3K playlist just for those old scenes. I'd actually been playing with them with a view to re-issuing with some mods and the anti-alias shader, but it all seems a bit pointless now.

Hi @Number6

The only advantage of having a second keyword for 3K inout would be to "deny" it in the old inout scenes.

You would have to deny it in every scene I guess until Totem give us some means of controlling the position of the 'masked' portion they use. And such a hot spot would have to be consistent for every card's in/out clips.

@EverthangFroever.

You were dead right about the pole though.

I found a picture of the interior of the Cazy Horse III club with a pole in it and did a quisk pole scene with it. The VG pole rarely varies by more than a few pixels either way. The 2nd cap it is is spot on and the 3rd cap is about the worst it gets.

Cages are good too!! Unfortunately Totem appear to have abandoned them.

Editd - thats weird - I put 3 screencaps in the post but onle the 3rd showed up. Have tried re-adding them.

Even staranger - now they've all disappeared.

OK added them here. I stripper doesn't appear to like adding pics to edited posts.

Apologies also for the typo's above - unfortunately I can't now edit it.

@Number6 thats right !
srry, I meant to say above..

...And such a hot spot would have to be consistent for filming every card's in/out clips.

I don't know how much show time fullscreeners are losing on average per new card with in/out clips
however more than 10% would defer my purchase decisions unless it was an outstanding model.
Totem provide no information about this prior to-purchase so we will have to rely on members who have purchased a new card to tell us the duration of in/out clips. Something I will be doing when I roll over to iSt.

With repect to positioning of clips. The co-ordinates you specify with pos:are for the clip's hotspot. For most clips the hot spot is 0.5,1.0 which is the center of the bottom edge of the clip but for "top" clips (swings) it is 0.5,0.0 which is center of the top edge. I haven't tried it but you may be able to specify a different hot spot for a clipSprite just as you can an ordinary sprite, with 0,0,1.0 being the bottom left corner and 1.0,1.0 the bottom right. Assuming that you can specify a hotspot for a clipSprite then then the pos: clause will accurately position the edges of the clip rather than its center so you can arrange for an inout clip to always be at the edge of the screen or by some object that you have deliberately introduced into the scene. If clipsprites do not let you change their hotspots then it should probably be a simple task for Totem to allow it.

Clip Sprites Do not let you Specify the Hot Spot.

the Desktop Player reads the Width and Height of the Clip and Can position the Clip to the Screen's Edge.
based on the Width.
Width is the invisible BOX that the MASK fills.
Remeber Every Clip is two Animations. The Model and the Mask.

We do not Have Access to the Clips Width Property in Full Screen.
And No Math to Allow positioning based on Variable Width.

Correct??

Can the Clip be placed on a Quad, and the Quad be Positioned?

@Wyld if I run fullscreen on 16 bit I can see the Masks for clipsprites
By trial & error I could determine pixels either way & set a quad there
That would be treating the quad rendered clipsprite like you would a shader ?
However the next model may have larger mask and I think the seam of the quad would show up.
At least thats my experience in trying to apply quads as masks over shadered backgrounds elsewhere

In the Beta Thread, shortly before it closed, @Rex said

"@Wyldanimal Same model is now permited in Full Screen for fantasy purpose. We are only screening same card more than once on the screen."

@Wyldanimal - do you know what the syntax is for this and where it needs to be declared, please?

Edit

@Wyldanimal - forget my query. The "What's New In Virtuagirl forum" isn't avaiable in the iStripper Beta Software consequently I hadn't seen your posts regarding this matter. Apparently you are as much in the dark as the rest of us.

Assuming the clipsprite could be rendered on a quad the other problem with running a quad is movement.
The clipsprite model mask usually moves all over the screen, so any quad used would have to be as large as the screen and the clipsprite down-scalable..

I tried to redefine the hotspot for a clipsprite - but it had no effect and he hptspot was taken from the clip. However, it seems that the fullsize of a clipspite as opposed to the instantaneously visible part, is the size set by the camera - at least for 2D clips so you can use a simple offset of half the size specified there to align the edge of a in-out clip wherever you want. The following shows the two approaches, the one on the left fails but that on the right has, so far, always caused the girl to enter where I have set the "doorway". It has limitations in that it will not take into account any scale changes and it would be much better if Totem allowed us to override the hotspot of clip sprites.

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

clip {
id: Clip1
allow: inout
deny: table, top
}

clip {
id: Clip2
allow: inout
deny: table, top
}
////////////////////////////////////////////////////////////////////////////////

camera {

type: 2D
pos: 800, 450
size: 1600, 900

// Put a tall thin rectangle near each side of the screen but well
// away from the sides. We will try to position the clips so that
// the performers appear to enter or exit via these "doorways".

quad {
color: 1, 1, 0
pos: -600, 0
size: 100, 900
}

quad {
color: 1, 1, 0
pos: 600, 0
size: 100, 900
}

// Attempt to directly position the edge of the clip by changing
// its hot spot to one of its corners. If this worked then it
// would automatically take care of any scale:, standingheight:
// or sittingheight: clauses that may be used and, for a 3d camera
// of any Z coordinate in a pos: clause. Unfortunately the hotspot:
// clause seems to be ignored for a clipSprite so this still only
// sets the position of the mid point of the bottom of the clip.

clipSprite {
hotspot: 0.0, 1.0 // This seems to have no effect
pos: -650, 350
source: Clip1
}

// Attempt to indirectly position the edge of the clip by setting
// the position of its midpoint and assuming its width. Here I am
// assuming that the full width of the clipSprite is the same as
// that given by the size: specified for the camera. The value used
// for the X coordinate is
//
// entryPositionX - cameraSizeX/2 = 600 - 1600/2 = -200
//
// This method seems to work, but is less convenient than directly
// positioning a modified hotspot (if that had worked) because it
// does not automatically allow for any changes of scale.

clipSprite {
scale: -1, 1, 1
pos: -200, 350
source: Clip2
}


}

@Emu I tried all manner of attempting to nest the clipsprite in a quad via a framebuffer without success. I could not get the clipsprite to render on a quad at all. Unfortunately there is no help from the debug which remains mute throughout all this. I hope Totem will give us access to a hotspot parameter for clipsprite which is scaleable in 3D camera and allow/deny specific to 3K in/out. It seems the only way we are going to be able to incorporate precise location of in/out edge clips in our fullscreen scenes.

Can you imagine travelling through an avenue of edgeclip scenes...the mind boggles !!
You could have a camera at 90 degrees simultaneously filming against blue and combine theclips.
I wonder if Ennie Paris is still around. She would be great at that.

@Rex mentioned some time ago (around the time idancer was being discussed I think)
that Fullscreen player could be revised after the new desktop player was completed.
Consequently, there are a few issues with clipsprites that need to be discussed similar to those above.

There are still problems with proper 3D tracking of clipsprite shadows with X + Z axis model movements.
Also masking reflections in general remains problematic when shaders are being used.

I have noticed that trying to mask deep overhanging leg reflections using shader rendered quads to blend with same shader-rendered background does work. However unlike masking via a sprite over a static image, shader quad masking leaves quite a visable seam on the background where the quad boundaries end. Because of the movemnet, I have not been able to make that seam invisible.

Hence I suggest in addition to the above discussion about clipsprites, Totem also look at the possibility of giving us a scene code method to make part of the reflection clipsprite invisible. Bottom up transparency option as say a percentage, or number of clipsprite pixels up the Y axis would do it.. This would overcome difficulties of hiding masks for deep leg reflections when they overlay moving shader backgrounds, and dramaticaly improve efficiency of scenes.

With respect to my post from 3 days ago. It seems that I was wrong about the second method of fixing the edge of a clipSprite. It appeared to wok perfectly for the first dozen of inout clips that were chosen but since then I have seen several for which it failed (though the edge was never very far off from the "doorway"). It seems that there is as yet no simple way to do this. It may be possible via a shader, but that would not be at all a convenient method.

This may well be my last post for a couple of months. The place I have been regularly using to connect may have blocked VirtuaGirl and if it has I will only have very intermittent access when, as now, I am travelling. I will of course tr to find a permanent solution, but that is likely to take me quite some time.

Sorry about your access issues @TheEmu. I don't expect the detail of fullscreen will be looked at in such depth until well after the Final Release candidate of iStripper player anyhow. Thanks for new scenes. I especially like the closeup starts and the animations with your newly adapted clipsprite Fairy Magic fragment shader.

Just wanted to pop in and say: Keep up the great work!

For me so far the Full Screen has been working better on iStrip than it was on VG.

Before often when wanting to exit full screen, my computer would often freeze. That has not happened with iStrip. And the full screns seem to work even better.

Will this thread and the new background download threads be moving over to forum at iStripper? Or can you already access this the forum from the iStrip app itself? I will have to explore.

Wunnerful fun stuff you guys! Dear cheers to all! Mike

Hi MikeDreams, there were some earlier bugs with use of these forums in iStripper. Some peeps reported not getting past the first page of some threads. Last time I was in there, it would not send PMs and one could not buy credits.
@Rex said they are looking at reworking to making download easier as a priority, but nothing about fullscreen, which leads me to think further fullscreen 'engine' development may be a whole project in itself.
I noticed that the models comments section was much narrower in iSt so wordwrap left a lot of white space between lines. However fullscreen image quality seemed a lot better and smoother running than VGHD , so I guess something was done to improve the player platform.
From scene makers perspective, the current iStripper release is not very FS author friendly because it will not group scenes by name, hence you can't quickly make a name group of try-out scenes and let them cycle play non-stop to compare different tweeks of the same scene. Also the way random works is a little too restrictive imo
Unlike VGHD Player, you cannot as easily make to cycle randomly:...

• one card ~ new random scenes from anywhere based on a selection
  
• one card ~ selected scene group headings only
  
• multiple cards ~ single scene
  
• multiple cards ~ same scene group
  

...and so on.:-/