Apropos

[jmlabskyrim]

So I'm having trouble figuring out which files to download.  Should I download them all?  I do have SD+ and PO for slavery stuff I just don't want to get anything that will seriously mess it up.

[blabla11]

It's time to attack?

 

Well, you can make a soft dependency

string name

if JContainers.isInstalled()
  int jnames = JValue.readFromFile("Data/XXX/names.json")
  name = JArray.getStr( jnames, Utility.Random(0, JArray.count(jnames)-1) )
endif

names.json is a text file:

["Peter", "ololo", "Jonh"]

As @gooser suggested, you may cache it if you read it really often

 

Thanks, that's perfect

[WaxenFigure]

 

Do you understand the difference between the ActorBase and the LeveledActorBase objects?

 

Are you sure this "DisplayName" isn't the name stored in the LeveledActorBase?  (Wouldn't surprise me if Bethesda has hidden objects and properties)

Using LeveledActorBase means I'll have to keep track of it and redo everything should the GC decide to destroy it (or CTD my users, should I screw up something)

Using setDisplayName means smarter people (SKSE team) than me handle it probably in a better way than I ever could.

 

Maybe, I don't know (and frankly, don't care how SKSE handles it internally).

 

 

The point you need to understand is that you should never go to the ActorBase object for any value unless you want the original values the actor started with.  Current values will always be found using the GetLeveledActorBase object.

I'd say GetDisplayName is probably the best way to get the name now that it's available.

[blabla11]

The point you need to understand is that you should never go to the ActorBase object for any value unless you want the original values the actor started with.  Current values will always be found using the GetLeveledActorBase object.

I'd say GetDisplayName is probably the best way to get the name now that it's available.

The problem isn't getting stuff, it's setting stuff in a consistent and non-problematic way.

Setting something on LeveledActorBase() can cause CTDs if the ActorBase has been destroyed by the GC, so I have to grab it every single time I want to do something.

I also have to keep track of every change I did to it, since the changes are not persistant for the Actor, only for that specific, volatile ActorBase.

 

Using ActorBase() opens a completely different can of worms, with loads of error-prone behaviours.

 

So I like to stay away from any ActorBase as far as I possibly can.

[WaxenFigure]

 

I keep meaning to mention this but I find there's one problem, whenever I do an aggressive animation where it is ambiguous whether the action is anal or vaginal this mod always assumes anal, when there are multiple possibilities then there ought to be a random chance at least that the action could go either way as simple always preferring one.

[Dorllanen]

animation where it is ambiguous whether the action is anal or vaginal this mod always assumes anal

 

Not a bug - a feature! ;D

[gooser]

I keep meaning to mention this but I find there's one problem, whenever I do an aggressive animation where it is ambiguous whether the action is anal or vaginal this mod always assumes anal, when there are multiple possibilities then there ought to be a random chance at least that the action could go either way as simple always preferring one.

 

Is it basically doggystyle? I know we tweak the tags on some of the anims to be anal (or vice versa).

 

Maybe a MCM option:

 

Doggystyle Animations [Always Anal | Always Vaginal | Random] 

 

?

[WaxenFigure]

 

I keep meaning to mention this but I find there's one problem, whenever I do an aggressive animation where it is ambiguous whether the action is anal or vaginal this mod always assumes anal, when there are multiple possibilities then there ought to be a random chance at least that the action could go either way as simple always preferring one.

 

Is it basically doggystyle? I know we tweak the tags on some of the anims to be anal (or vice versa).

 

Maybe a MCM option:

 

Doggystyle Animations [Always Anal | Always Vaginal | Random] 

 

?

 

Any aggressive animation seems to be considered anal, even if it was called up using the dialogue for vaginal sex in Submit.

[gooser]

 

 

I keep meaning to mention this but I find there's one problem, whenever I do an aggressive animation where it is ambiguous whether the action is anal or vaginal this mod always assumes anal, when there are multiple possibilities then there ought to be a random chance at least that the action could go either way as simple always preferring one.

 

Is it basically doggystyle? I know we tweak the tags on some of the anims to be anal (or vice versa).

 

Maybe a MCM option:

 

Doggystyle Animations [Always Anal | Always Vaginal | Random] 

 

?

 

Any aggressive animation seems to be considered anal, even if it was called up using the dialogue for vaginal sex in Submit.

 

 

I'm scratching my head on that one. Are you playing female or male?

 

I'm in process of completely rewriting a lot of this logic so I'm not sure I will actually get to track this down.

[Leito86]

It'll be nice if we can chose whether an animation is anal or vaginal in MCM.

[AlericoftheNords]

It'll be nice if we can chose whether an animation is anal or vaginal in MCM.

 

That would be awesome.

[WaxenFigure]

 

 

 

I keep meaning to mention this but I find there's one problem, whenever I do an aggressive animation where it is ambiguous whether the action is anal or vaginal this mod always assumes anal, when there are multiple possibilities then there ought to be a random chance at least that the action could go either way as simple always preferring one.

 

Is it basically doggystyle? I know we tweak the tags on some of the anims to be anal (or vice versa).

 

Maybe a MCM option:

 

Doggystyle Animations [Always Anal | Always Vaginal | Random] 

 

?

 

Any aggressive animation seems to be considered anal, even if it was called up using the dialogue for vaginal sex in Submit.

 

 

I'm scratching my head on that one. Are you playing female or male?

 

I'm in process of completely rewriting a lot of this logic so I'm not sure I will actually get to track this down.

 

If you are rewriting it then lets just ignore it for now and only worry about it if it pops up in the new code. Playing a male characater right now though to answer that question. No point in your wasting any good time on this.

[balth]

Fantastic mod. Really looking forward to that text widget. Thanks for all your hard work!

[gooser]

Developer update. Working on widget refinements. Widget test mode in action. Does that font size seem readable?

[Reesewow]

Developer update. Working on widget refinements. Widget test mode in action. Does that font size seem readable?

 

Looks good, I'd say the font size would be fine for me.  The only improvement I could think of is if the font itself could have shadowing similar to the in-game debug messages so it is easier to read vs bright screen effects like sky or light sources.  On that example some of the text gets harder to read when it is overlapping the brightened wall.

[chajapa]

Gooser,

 

What is the fade delay and will it be configurable?

Will each stage message stay on screen in its own location? (stage 1 message where we see widget one in the preview, stage 2 message where we see widget two, etc)

 

I agree that back-shadowing would be nice if it's something that can be implemented.

 

 

[gooser]

Gooser,

 

What is the fade delay and will it be configurable?

Will each stage message stay on screen in its own location? (stage 1 message where we see widget one in the preview, stage 2 message where we see widget two, etc)

 

I agree that back-shadowing would be nice if it's something that can be implemented.

 

The fade delay is 5 seconds, and it is configurable.

 

Yes, once a SL animation has begun, it "grabs" one of these widgets and uses it during the lifetime of the animation.

 

 

 

Developer update. Working on widget refinements. Widget test mode in action. Does that font size seem readable?

 

Looks good, I'd say the font size would be fine for me.  The only improvement I could think of is if the font itself could have shadowing similar to the in-game debug messages so it is easier to read vs bright screen effects like sky or light sources.  On that example some of the text gets harder to read when it is overlapping the brightened wall.

 

 

Interesting. Do you personally have a hard time reading the normal Skyrim top-left corner messages, since those don't have  background like you suggest? Does the larger text size make the difference?

 

Attached: Black background. Personally I find the black boxes distracting.

[musicman019]

does this work for males?

[Camila]

 

Gooser,

 

What is the fade delay and will it be configurable?

Will each stage message stay on screen in its own location? (stage 1 message where we see widget one in the preview, stage 2 message where we see widget two, etc)

 

I agree that back-shadowing would be nice if it's something that can be implemented.

 

The fade delay is 5 seconds, and it is configurable.

 

Yes, once a SL animation has begun, it "grabs" one of these widgets and uses it during the lifetime of the animation.

 

 

 

Developer update. Working on widget refinements. Widget test mode in action. Does that font size seem readable?

 

Looks good, I'd say the font size would be fine for me.  The only improvement I could think of is if the font itself could have shadowing similar to the in-game debug messages so it is easier to read vs bright screen effects like sky or light sources.  On that example some of the text gets harder to read when it is overlapping the brightened wall.

 

 

Interesting. Do you personally have a hard time reading the normal Skyrim top-left corner messages, since those don't have  background like you suggest? Does the larger text size make the difference?

 

Attached: Black background. Personally I find the black boxes distracting.

 

 

He meant letter shadow. If you notice the part where it says Apropos ready and above, it have shadows oh the letters. (normal skyrim msgs)

What would happen if you place one widget in front of another, the first one is white and the last one is black. Then move the last one a few pixels to the right/down. In theory would produce the shadow, but i have no idea what would happen if you try to overlap one widget with another

[gooser]

 

 

Gooser,

 

What is the fade delay and will it be configurable?

Will each stage message stay on screen in its own location? (stage 1 message where we see widget one in the preview, stage 2 message where we see widget two, etc)

 

I agree that back-shadowing would be nice if it's something that can be implemented.

 

The fade delay is 5 seconds, and it is configurable.

 

Yes, once a SL animation has begun, it "grabs" one of these widgets and uses it during the lifetime of the animation.

 

 

 

Developer update. Working on widget refinements. Widget test mode in action. Does that font size seem readable?

 

Looks good, I'd say the font size would be fine for me.  The only improvement I could think of is if the font itself could have shadowing similar to the in-game debug messages so it is easier to read vs bright screen effects like sky or light sources.  On that example some of the text gets harder to read when it is overlapping the brightened wall.

 

 

Interesting. Do you personally have a hard time reading the normal Skyrim top-left corner messages, since those don't have  background like you suggest? Does the larger text size make the difference?

 

Attached: Black background. Personally I find the black boxes distracting.

 

 

He meant letter shadow. If you notice the part where it says Apropos ready and above, it have shadows oh the letters. (normal skyrim msgs)

What would happen if you place one widget in front of another, the first one is white and the last one is black. Then move the last one a few pixels to the right/down. In theory would produce the shadow, but i have no idea what would happen if you try to overlap one widget with another

 

 

Ok, I see what you mean. Yes a dropshadow filter would be perfect, except its not available in the AS2 TextFormat model, so I would have to try what you suggest, thereby doubling the number of widget instances... 

 

Figured it out. AS2 supports dropshadows directly on the textfield. 

 

Here's a sample.

[gooser]

I think I must have been imagining it because now I'm not seeing it applied. 

[Reesewow]

 

 

 

 

 

Gooser,

 

What is the fade delay and will it be configurable?

Will each stage message stay on screen in its own location? (stage 1 message where we see widget one in the preview, stage 2 message where we see widget two, etc)

 

I agree that back-shadowing would be nice if it's something that can be implemented.

 

The fade delay is 5 seconds, and it is configurable.

 

Yes, once a SL animation has begun, it "grabs" one of these widgets and uses it during the lifetime of the animation.

 

 

 

Developer update. Working on widget refinements. Widget test mode in action. Does that font size seem readable?

 

Looks good, I'd say the font size would be fine for me.  The only improvement I could think of is if the font itself could have shadowing similar to the in-game debug messages so it is easier to read vs bright screen effects like sky or light sources.  On that example some of the text gets harder to read when it is overlapping the brightened wall.

 

 

Interesting. Do you personally have a hard time reading the normal Skyrim top-left corner messages, since those don't have  background like you suggest? Does the larger text size make the difference?

 

Attached: Black background. Personally I find the black boxes distracting.

 

 

He meant letter shadow. If you notice the part where it says Apropos ready and above, it have shadows oh the letters. (normal skyrim msgs)

What would happen if you place one widget in front of another, the first one is white and the last one is black. Then move the last one a few pixels to the right/down. In theory would produce the shadow, but i have no idea what would happen if you try to overlap one widget with another

 

 

Ok, I see what you mean. Yes a dropshadow filter would be perfect, except its not available in the AS2 TextFormat model, so I would have to try what you suggest, thereby doubling the number of widget instances... 

 

Figured it out. AS2 supports dropshadows directly on the textfield. 

 

Here's a sample.

 

 

 

 

Yes, I was referring to drop shadows on the text itself, not black letter boxes.  This is just a suggestion without knowing what your constraints are within the widget formats you are using, mostly based on experience where the top left skryim messages are perfectly readable but I need to find a dark wall sometimes to read text in console (as text in the skyrim console is not shadowed).  

[AlericoftheNords]

Developer update. Working on widget refinements. Widget test mode in action. Does that font size seem readable?

 

I'd say it looks great.

 

Maybe one font size larger, but that's just me.

[crs030]

I like the size in the 3. screen, but i play on a lower resolution so smaller text would be harder to read.

[Grimbold the unlovely]

Developer update. Working on widget refinements. Widget test mode in action. Does that font size seem readable?

 

Extemplo Libyae magnas it Fama per urbes, ingrediturque solo et caput inter nubile condit