Beer + Noemi = happy!!!

I don't buy most cards right away.
I bought this one.
this is an example of the props being well used and fun.

great stuff.

Not directly the cause, but might have been a good idea to check with billing firms before going down this road.

When they set up the arrangement the billing firms were quite happy to support recurring subscriptions - for some reason some have now changed their minds (and I would not be in the least surprised if the reason for the change was pressure from the credit card companies). I believe the change does not only affect Totem.

Totem didn't cause our subscritions to lapse, it seems it was one of the intermediary company handling billing

Not directly the cause, but might have been a good idea to check with billing firms before going down this road.

Maybe Totem will see the light and change this back for us who lost our membership on this way ...

Yep, plenty of scope for U-turns. Just get advice from the UK government. So many they have made now no idea which way they face now.

@R2D34ever2, and others, I think @manue 's post is relevant here

https://www.istripper.com/forum/thread/51793/1?post=750508

Totem didn't cause our subscritions to lapse, it seems it was one of the intermediary company handling billing. Try contacting Totem as per Manue's post.

It happened to me, but as I was thinking of temporarilly cancelling my Premium subscription anyway (my spending habits having changed radically) the fact that it has lapsed has actually done me a favour.

it seems like all the money they earned because of us just is not enough...
I have 22 giftcards and 18 jokers left...

I am going to sent these very wisely and then move on..

Just a shame that this is changed for a few euro's more...
Maybe Totem will see the light and change this back for us who lost our membership on this way ...

ja meine jahres mitgliedschaft ist jetzt futsch und ich kann nur noch auf das monatliche model was mich sehr ärgert da ich premium seit der ersten stunde war

@TheEmu ahh i see. i have always left adding uniforms till after i have completed the shader which usually avoids the missing uniform problem as i copy paste the framebuffer code then adjust to suit.

I find this a very strange way to deal with customers and a very good way for Totem to loose them.

Yep, this was all so totally unnecessary. I'll probably cancel the sub anyway since I don't buy everything I could with it.

@redstealth
We are talking about Kylie Green here, please stay on topic and have fun with iStripper 😎

If the off topic rule was strictly applied to every thread this forum would surely die a very quick death.

Yes, but go back on topic is a good thing too. Thank you 😎

We are often told to have fun with iStripper. Banter here is just that.
If the off topic rule was strictly applied to every thread this forum would surely die a very quick death.
And with all the posts Noemi Moon's new show has been kept high in the last posts list.

I hope al the fans are making sure that if they use a prepaid card like me that there is money enough on it...
If not Epoch cancels your sub without any warning so you HAVE tto get the new monthly subscription..
I find this a very strange way to deal with customers and avery good way for Totem to loose them.

Would like to see Calypso in VR

@Z22

Sure, that works as intended.

But if you omit "uniform: some cak, float, 1.0" from the second then it will be as if you had specified "uniform: some cak, float, 0.1" rather than "uniform: some cak, float, 0.0" (its default vaue) which is what you would get if you had omitted both of the uniform: causes.

Not much of a problem if you always fully define all inputs to each instance of a shader, but even then it complicates maintenance and incremental development both of .scn files and of shaders because changing something in one place may need to have a different modification made elsewhere.

As a simple case consider your example as a starting point. Now modify the shader to optionally use a second uniform which could properly default to a value of zero but which you want to have a non-zero value for one of your uses. You will have to specify the uniform in both of the scene nodes in which you use the shader. Not much of a problem for this simple case, but much more of a nuisance in complex scenes where the two instances may be hundreds of lines apart in the .scn file.

In complex scenes altering the order in which the nodes are declared can, and often does, affect the values of uniforms seen by the shaders unless every uniform used by each shader is explicitly declared in each node that the shader is used in. Some of my shaders use a significant number of uniforms to provide optional parameters and having to reset them after using one with a non-default value is a ***** - especially if I am only doing so for debugging purposes.

It also means that you can test two pieces of the .scn file in isolation, find that they both work as expected, but that when combined one of them is no longer producing the expected result.

The problems arise because in the code processing the ,scn file (not in the code running the shaders) there is effectively a global variable for the uniform. This means that local changes have ramifications outside their natural scope and need to be "corrected" somewhere else in the source.

Note, this also results in user defined uniforms behaving differently to system defined ones such as gl_Color. For the latter any changes made to them in the .scn file (via color: or Opactity: clauses) are local to the node in which the change is made.

Note also, for me all of this is no more than a nuisance. I know what the potential problems are and how to avoid them (and I can recognise them when I make a mistake). But for others, particularly those with little or no programming background, there can be real difficulties in understanding why changing one thing in a scene can have a large effect on something else that is apparently unconnected with it. This will be especially so if two different shaders, doing completely different things, just happen to have an input parameter provided by a uniform with the same name.

I have the ( almos t) same problem ..
What i do like to know is there a change to get my premium anual sub up and running again ?
Would be nice after all these years ...

Back on track guys ... Back on track..
this thread is for Noemi Moon Take 2

Take the banter elsewhere

ist das jahres ***** nicht mehr vorhanden ?

@Z22

The problem arises because the same user defined "uniform" is used for all shaders - they are implemented (in the code processing the .scn files) as global variables and have the problems that always accompany shared global variables. If you change it for one instance it is changed for all of them.

Each instance of a shader will get its own copy of the global used by iStripper so at the GLSL level the uniforms are not global variables, but they will be in the layer above that (unlike gl_Color which, I think, is an output from a vertex shader whch selects it from gl_FrontColor and gl_BackColor).

framebuffer {
id: err
sprite{
source: dunno
Shader dont care.fsh
uniform: some cak, float, 0.1
}
}

framebuffer {
id: woo
sprite{
source: dunno
Shader dont care.fsh
uniform: some cak, float, 1.0
}
}

is valid and works as intended. Iv'e used multiple instances of shaders like this so it must just be weird with animate. so you should be able to animate(colour cycle ect) in shader with uniforms.

gl_FrontColor + gl_BackColor are for vertex are they not? So are only used if you are using a frag with a vetex shader.

you need the line

gl_FrontColor = gl_Color

in the vertex shader
What are you guys trying to do?

No one is ***** you to take part in the TGIF events.

I completely agree with you ... there are many far better ways to spend both your time and money.

They may only be small words but at least we spell them correctly!!
😊

I do all my writing in American. 😜
(and I was drinking!)

I played the 25 game on Friday. I knew I'd win some "free" cards I'd not purchased when they came out.
Only 11 outside the 45 days cut off and sure enough I now have them all.
I'll probably look at them and some I bet I will be pleasantly surprised. Others I know I will just delete.

While getting those 11 cards in the first 37 plays, I also won 17 times either 15 or 35 credits.
In the next 37 plays I won 26 times either 15 or 35 credits plus 1 gift card.

Totally random I know, but it does seem to show that when you have no card to win, you win credits back more often.

👍

Maybe he was thinking of people like Britt Ekland - who could forget her (and her body double) in The Wicker Man.

I remember reading an article about that somewhere. Apparently Ms Eckland was absolutely furious about it as she didn't know it was being done. Also accused the double of having a fat arse I think.

Great film though.

Pity about the remake😠

All these Britts on here....
I guess I should use small words!

They may only be small words but at least we spell them correctly!!

Maybe he was thinking of people like Britt Ekland - who could forget her (and her body double) in The Wicker Man.

All these Britts on here....
I guess I should use small words!

They may only be small words but at least we spell them correctly!!
😊

It's been said over and over to nauseum...

Most of the TGIF events are tailored towards the new members and lower level members.
They benefit the most from these events.

Members with Full or Nearly full collections are not where most of these events are tailored.

No one is ***** you to take part in the TGIF events.
If there is no benefit to you as a high level member
then don't take part in the event.

Cards Newer than 45 days old, are Generally, Not Included in the Events.
So as a full collector, you should wait at least 45 days, so there is a pool of cards for you to win in the events.

If you are the discriminating purchaser
TGIF events will benefit you the least.

Only participate when the event has the most value for you.

Do I get credits in place of cards if I own the full collection?

It has been my experience, on certain TGIF events
that you get more credits returned in place of winning a card.
So if for example the 25 event,
your chance would have given you a card, in it's place you get back the 15 credits used for that chance.

I play the 25 event to gain Joker cards.
and often, I will walk away with a joker, and be almost even on the credits won back, vs the credits used.
or I will be down a small amount.

Full Collection owners
Near Full Collection owners
Discriminating Buyers

Chose the events that offer you the best value.
Most of them are not tailored towards your benefit.

All these Britts on here....
I guess I should use small words!

(Ha! see what I did there? I made fun of the entire group! Zing!!!)

Luckily, I have plenty of beer, here in the colonies, so my humor is funny. Beer makes everything better!

Hey guys and gals,wish i was that mug😍

@dar2112v - my experience as a full-collection owner is that the game will give a money-back reward (i.e. your stake money returned) instead of a free card - which usually means you can play longer and hence have more opportunity for higher value wins (note: you still win gift cards though).

I've been saying this for a long time, which is why I see no advantage in having a complete collection of regular cards to play these games.

How it reacts to a full collection is anyones guess. If your prize was to be a free card but there are no cards to give you then does it give you nothing or does it substitute a different prize instead? If your win gets your credits and jokers instead of random cards than maybe that works out in your favor since you buy anything anyways?

If you have a large collection but not full it makes no sense at all to play as your prize(s) will likely be one you don't want. I know I'm not playing for that reason alone and honestly I had to ask myself even if it were not the cards I dont want getting stuck in my collection do I really want to pay $25, $50, or possibly more for a single card when I could put that money into a nice meal or even another site with many girls that I could enjoy for months.

I don't want a full collection so for me the exclusive cards are a hard pass.

Lottie Magne - Teen's Gambit - f1175 - iStripper XXX
Kylie Green - Alerte Rouge ! - f1155 - iStripper XXX
Erin Pink - Spot The Boots - e1786 - iStripper
Ariela Donovan - Scotland Babe - f1167 - iStripper XXX
Ana B - Downtown Girl - f1135 - iStripper XXX
Yenifer Chacon - Dentelle Noire - e1780 - iStripper
Milena Ray - Bosun's Knot - f1183 - iStripper XXX

@TheEmu
using a test edited version of Wicked isometryMod01.fsh by illus0r (FG700)
Sorry to say..No compile with either #version header for using gl_FrontColor in place of gl_Color

2022-10-23T06:42:25[] WARNING[QOpenGLShader::compile(Fragment): 0(234) : error C5052: gl_FrontColor is not accessible in this profile]
2022-10-23T06:42:25[] WARNING[*** Problematic Fragment shader source code ***]
2022-10-23T06:42:25[] WARNING[#version 120
---------------------------------------------
2022-10-23T06:46:51[] WARNING[QOpenGLShader::compile(Fragment): 0(234) : warning C7533: global variable gl_FragColor is deprecated after version 120
0(234) : error C5052: gl_FrontColor is not accessible in this profile
0(234) : warning C7533: global variable gl_FrontColor is deprecated after version 120]
2022-10-23T06:46:51[] WARNING[*** Problematic Fragment shader source code ***]
2022-10-23T06:46:51[] WARNING[#version 330

@EverthangForever

Can you please try

gl_FragColor = vec4(cc) * gl_FrontColor;

i.e. try gl_FrontColor in place of gl_Color.

And if it compiles and runs is the result affected by a Color: or Opacity: clause in the .scn file.

@Wyldanimal

gl_TexCoord[0].rgba;

seems to me to be a very strange usage.

gl_TexCoord is an array of vec2 elements and its components would normally be accessed as gl_TexCoord[0].xy or gl_TexCoord[0].st etc.

So I suppose we could use gl_FrontFacing as a replacement for gl_Color.

As @EverthangForever found I was completely wrong when making that suggestion. It serves me right for Googling for information at 5:00 in the morning and quickly making a post based on that information while in a hurry to leave home in order to catch a train.

I've been saying this for a long time, which is why I see no advantage in having a complete collection of regular cards to play these games.

Trying to acquire an SEC, without any other benefits, is a major loss of credits (money) assured. Especially since a regular card as a PREMIUM costs me 11 credits and 13.20 credits for a card with a costume on a specific theme.

I have more advantage to buy my credits, when there are credits in bonus, which allows me to have really free cards, and this, without playing these "stupid" games, which makes us pay to have cards called "gifts" at the end of a progress bar.


Je le dit depuis longtemps, c'est pourquoi je ne vois aucun avantage en ayant une collection complète des cartes régulières à jouer à ces jeux.

Essayez d'acquérir une SEC, sans autres avantages, est une perte importante de crédits (argent) assurés. Surtout qu'une carte régulière en tant que PREMIUM me coûte 11 crédits et 13.20 crédits pour une carte avec un costume sur un thème précis.

J'ai plus avantage à acheter mes crédits, lorsqu'il y a des crédits en bonus, ce qui me permet d'avoir des cartes vraiment gratuites, et ce, sans jouer à ces jeux "stupides", qui nous fait payer pour avoir des cartes dites "cadeaux" au bout d'une barre de progression.

I just played a TGIF game after more than a year of avoiding them and I made an interesting observation. The larger your collection, the less valuable the game becomes. The most common rewards from a game are free cards and gift cards. The more cards you own, the less likely it is that a free card will be something you would buy. The higher your reward level, the less valuable a gift card becomes. In my case, a gift card is worth at most 16.5 credits, but that is only if I buy an old card with a higher than normal price. Since I'm a premium member I almost always buy cards within the week they are released and that reduces the value of a gift card to 13.75 credits. For a member with a lower discount level, the value of a gift card is greater. For a member with a small collect, the chance that a free card will be valuable is also greater.

It will probably be a few more years before I play another game and that will only be after I use my one remaining Joker.

Warum kann man Paypal nicht nutzen?

Sorry for the bad information caused by an errant typo.
But It's all corrected.
Edit...

just tested on my other pc and it DOES NOT work with my Nvida GPU
so forget all of this...


turns out my intel cpu wasn't generating any errors,
but the shader wasn't even running.

I'll do more testing and let you all know what I find..

I discovered an error in my shader
caused by a misplaced cursor when I typed in a vec4

this casued the shader to Not run,
Once I fixed the errant vec4

I was able to find a better system variable to use as a replacement for gl_color.

this fully supports animations.

I will go back and edit my two prior posts to show the use of this new system variable

////////////////////////////////////////////////////////
vec4 RGBA0 = texture2D(texture0).rgba; // color and alpha of Texture0
vec3 RGB0 = texture2D(texture0).rgb; // color only of Texture0
float A0 = texture2D(texture0).a; // alpha only of Texture0
////////////////////////////////////////////////////////

@theemu

my post does not use a user created uniform.
it uses the built in system Variables.
https://www.istripper.com/forum/thread/27449/137?post=750406



but you are correct in one thing.

setting a variable to

vec4 RGBA0 = gl_TexCoord[0].rgba;

will not Vary with the scene animation,

but using

gl_TexCoord[0].rgba;

Will vary with the scene animation.

So as a shader creator, you just have to decide if it is important to allow the passed Color and Opacity to vary or not.

I want to keep my yearly subscription but I forgot to reload my prepaid creditcard.
Can you please help me set it up again?

***** de rajouté la SEC sur un event déja commancé.

Oui, assez inhabituel, en effet. Ils l'ont ajoutée le 21 au milieu d'un évènement. Il n'y aura donc qu'une semaine pour ceux qui veulent l'obtenir maintenant.😐

hi all, so there is no SEC this month?
On en reparlera le 28 😉

ah ben j'ai écris trop vite ils l'ont rajouté avant la fin de cet event donc le 28 comme tu avais dit 😪
***** de rajouté la SEC sur un event déja commancé.

@TheEmu ,
So I suppose we could use gl_FrontFacing as a replacement for gl_Color. I have not tried this as I have hardware problems at the moment.

if I run a shader with say equal to or less than #version 130 header and

gl_FragColor = vec4(cc) * gl_FrontFacing;

I get a compile (implicit cast) error however there appears to be no 'gl_FrontFacing is deprecated' error

2022-10-22T16:39:03[] WARNING[QOpenGLShader::compile(Fragment): 0(233) : error C7011: implicit cast from "bool" to "float"]
2022-10-22T16:39:03[] WARNING[*** Problematic Fragment shader source code ***]
2022-10-22T16:39:03[] WARNING[#version 110

If I try to run

gl_FragColor = vec4(cc) * gl_FrontFacing;

with a #version header greater than 130 I get a 'gl_FragColor is deprecated' error
which to me looks way worse , so no joy either way there.

So, for the time being until this can be resolved, I may stick to just using #version 130 headers
and

gl_FragColor = vec4(cc) * gl_Color;

@trov
I got the nice shot 500 achievement
Earned: November 5, 2021

Me, too. Mine is from November 12th, 2018. Must have been some nice promotion :) Maybe an early start to Black Friday or something... can't remember.

Congrats @Dfner😎💰👍 Sweet!

@Z22

The problem arises because the same user defined "uniform" is used for all shaders - they are implemented (in the code processing the .scn files) as global variables and have the problems that always accompany shared global variables. If you change it for one instance it is changed for all of them.

Each instance of a shader will get its own copy of the global used by iStripper so at the GLSL level the uniforms are not global variables, but they will be in the layer above that (unlike gl_Color which, I think, is an output from a vertex shader whch selects it from gl_FrontColor and gl_BackColor).

https://stackoverflow.com/questions/20286156/why-gl-color-is-not-a-built-in-variable-for-the-fragment-shader

discusses gl_Color. It contains the following paragraph

However, none of this behavior exists in newer versions of GLSL. You must supply your own vertex attributes, your own varyings and you pick between colors using the value of gl_FrontFacing. I actually explained this in more detail in a different question related to OpenGL ES 2.0, but the basic principle is the same.

So I suppose we could use gl_FrontFacing as a replacement for gl_Color. I have not tried this as I have hardware problems at the moment.

@EverthangForever

The problem, a ***** one, is that in the following

Sprite { // node 1
source : source1
shader: myshader
}

Sprite { // Node 2
source : source2
uniform : float, ABCD, 1.0
shader: myshader
}

Sprite { // Node 3
source : source3
shader: myshader
}

Sprite { // Node 4
source : source4
uniform : float, ABCD, 2.0
shader: myshader
}

When the shader runs it will see, and use, the following values for the uniform ABCD

0 - First time for Node1 - uses the default value of 0.0
1 - Node 2 - uses explicitly declared value
1 - Node 3 - "inherits" the value from the previous use
2 - Node 4 - uses explicitly declared value

2 - Second time for node 1 - which is different from the first time
1 - Node 2
1 - Node 3
2 - Node 4

This will be true even if you try to detect the use of default zero values wihin the shader in order to override the default. Furthermre if you then introduce a 5th node and use a different value for the uniform there this value will then be used instead of 2 for the second time for node 2. Also if you change the order of the node the effect on the values used will vary.

This is not a big problem, but is is an annoying one even if you are aware of it, and I am sure it would be a very ***** one for those that encounter it for the first time. Using gl_Color does not have this problem but replacing gl_Color with a user defined uniform variable would have.

A simple example of the annoyance is that if I have scene uing a set of (quads, sprites, clipsprites etc.) all using the default values for a uniform and then decide that for one of them I want to use some non-default value I have to make two edits to the source - one to assigne the uniform its new value in the node I want to change and a second to set it back to its defalut value in the node following it.


@Wyldanimal

Yes you can use a framebuffer - but that is much mre complex than just directly animating Color and/r Opacity. I should have made it clear that I was trying to say that you can't use animate on the user define uniform variable in the way that you can with gl_Color even though you can, with some effort, have the same end result.

That would work, but with the severe limitation that the values could not be made to vary using animate: clauses in the .scn file.

you would use the shader is a frame buffer or a node.
and the shader would preserve the color or opacity assigned in that framebuffer or node..

this gets around the limitation of the version of the shader being limited to 1.4 or lower.

Now, you can use version 3.3 up to 4.5 in the shader while still preserving the color or opacity of the source.


later in the camera
you use the sprite with the source id of the framebuffer or node and that can be animated.