Apropos 2

[gooser]

47 minutes ago, xyzxyz said:

Do you know what tags the animation "3jou laying variant" has? It looks like anal for me but this mod thinks it's vaginal.

Depends upon how it's tagged, not how it looks.

 

EDIT: You can always change the tags yourself, using a patchup edit (Animation_Patchups.txt, iirc) and running [Patchups] in the Apropos MCM.

[xyzxyz]

There are some mistakes in the sex counter. For example it says for IngunBlack-briar 1 Anal (that was my player), 1 Abuse and 1 creature. That is not true. Same problem for other NPCs.

When is a animation counted as anal and when as abuse? Their are some aggressive anal animation that are started as cons. sex via dialogue but counted as abuse, I think.

[gooser]

2 hours ago, xyzxyz said:

There are some mistakes in the sex counter. For example it says for IngunBlack-briar 1 Anal (that was my player), 1 Abuse and 1 creature. That is not true. Same problem for other NPCs.

When is a animation counted as anal and when as abuse? Their are some aggressive anal animation that are started as cons. sex via dialogue but counted as abuse, I think.

Again, read the OP.

 

Wear and Tear

 

Overview:

 

- Detects 'abuse' during SL orgasm events, and if the character qualifies, then their abuse state is tracked over time. Continued abuse accrues and weakens the character, and time (and certain consumables) will heal the character.

- Abuse is defined as one of two conditions:
  - The actor was tagged as a victim in an animation, most often - SL Defeat.
  - The animation itself is tagged with: Aggressive, Rough, or Forced.

 

What is triggering the animations has influence on whether the actor is tagged as a victim. It is possible that consensual animations can be played for rape scenarios - it depends upon your SL settings, and things like Defeat, etc. Again, it depends upon what mod you are using to start the animations, things like SL Defeat, Aroused Creatures, etc, etc, etc.

 

It doesn't matter what the animation "looks like":

- An animation that looks vaginal could be tagged as anal, depends upon animation author, and any patchups you might be using. Because there are differences in alignment, sometimes vaginal looks anal, and vise versa because of UNP vs CBBE differences, etc.

-  Sometimes an author mis-tags or under-tags their animations.

- The TAGS determine when abuse is directed towards specific body parts

 

In summary, it depends upon what mod is triggering the animation PLUS what tags the animation author (or overrides in a patchup) has used.

[xyzxyz]

2 hours ago, gooser said:

Again, read the OP.

 

Wear and Tear

 

Overview:

 

- Detects 'abuse' during SL orgasm events, and if the character qualifies, then their abuse state is tracked over time. Continued abuse accrues and weakens the character, and time (and certain consumables) will heal the character.

- Abuse is defined as one of two conditions:
  - The actor was tagged as a victim in an animation, most often - SL Defeat.
  - The animation itself is tagged with: Aggressive, Rough, or Forced.

 

What is triggering the animations has influence on whether the actor is tagged as a victim. It is possible that consensual animations can be played for rape scenarios - it depends upon your SL settings, and things like Defeat, etc. Again, it depends upon what mod you are using to start the animations, things like SL Defeat, Aroused Creatures, etc, etc, etc.

 

It doesn't matter what the animation "looks like":

- An animation that looks vaginal could be tagged as anal, depends upon animation author, and any patchups you might be using. Because there are differences in alignment, sometimes vaginal looks anal, and vise versa because of UNP vs CBBE differences, etc.

-  Sometimes an author mis-tags or under-tags their animations.

- The TAGS determine when abuse is directed towards specific body parts

 

In summary, it depends upon what mod is triggering the animation PLUS what tags the animation author (or overrides in a patchup) has used.

That answers some of my questions. But it doesn't say why so many of my female NPCs have 1 creature sex listed. They never did that.

[gooser]

20 hours ago, xyzxyz said:

That answers some of my questions. But it doesn't say why so many of my female NPCs have 1 creature sex listed. They never did that.

To diagnose that I would need you to post some log files, after enabling Debug and Trace in MCM, and reproducing the problem in game (making the creature count increase)

[Lilzt3hcat]

Would (or is?) it be possible split up race based definitions abit further, for example having it where Dremoras have unique text (currently uses generic male text) (and other situations where there's a different creature using the same skeleton (ashhopper - chaurus, ashspawn - draugr, werewolf - werebear, ect)? Would def be useful for further refining the database to be more specific.

[gooser]

8 hours ago, Lilzt3hcat said:

Would (or is?) it be possible split up race based definitions abit further, for example having it where Dremoras have unique text (currently uses generic male text) (and other situations where there's a different creature using the same skeleton (ashhopper - chaurus, ashspawn - draugr, werewolf - werebear, ect)? Would def be useful for further refining the database to be more specific.

Not possible to look at skeletons, but races might work.

[Carl Finkerton]

What does *.STRINGS in UTF8 format mean? Do I also just download it like any other mod? Like with NMM?

[Lilzt3hcat]

9 hours ago, gooser said:

Not possible to look at skeletons, but races might work.

I wasn't suggesting looking at skeletons, clearly bad explaining on my part -sorry about that. I was more so trying to say since those races use the same animations as their counterpart but are a different entity, individualizing the ability to write for them would be helpful. ☺️

[Eadoo]

19 hours ago, Carl Finkerton said:

What does *.STRINGS in UTF8 format mean? Do I also just download it like any other mod? Like with NMM?

Are you in an English-speaking location, using an English distribution of the game?

Yes:  Don't worry about this.

No:  Probably don't worry about this.

 

Mostly, don't get worked up about this if you don't understand what it means. 

[Szlordrin]

Just a suggestion, or rather a wishlist item could we add a secondary "Climax" Text file that recognizes separate orgasms. That way a message could independently fire off whenever one occurs, similar to the go-back messages. Orgasm usually only describes the male orgasm, and I fee like we could do with a little more female friendly climaxes leading up to that. On that same note, I wouldn't mind seeing an "Afterglow message" for placeholder purposes, similar to startup messages.

[Eadoo]

13 hours ago, Szlordrin said:

Just a suggestion, or rather a wishlist item could we add a secondary "Climax" Text file that recognizes separate orgasms. That way a message could independently fire off whenever one occurs, similar to the go-back messages. Orgasm usually only describes the male orgasm, and I fee like we could do with a little more female friendly climaxes leading up to that. On that same note, I wouldn't mind seeing an "Afterglow message" for placeholder purposes, similar to startup messages.

SLSO is something frequently discussed.  It'll require code changes, though.

Your "afterglow" text is sort of already implemented.  It'd be in FemaleActor_WearTearIncreased_X.  The catch is that you lose the {ACTIVE} actor (so your text doesn't know the partner anymore), and it relies on transitioning a Wear and Tear level (although that's fairly common, at least in my playthroughs).

Now if you'll excuse me, I need to go enjoy some fine mead.  I'm gonna get drunk and do some DB updates.  Hope you're all looking forward to fellating draugr.

[7osisg4d]

On 5/10/2020 at 2:18 PM, Eadoo said:

SLSO is something frequently discussed.  It'll require code changes, though.

SLSO has always been a disaster for me.  I get script lag, their thread blames it on apropos, I disable apropos and still get lag

[King-Crimson]

Heya,

sometimes the apropos synonyms are in complete capslock.

This has been a problem for a very long time, but recently it has gotten worse.

I've looked into the db myself (i use the newly maintained Apropos DB Updates with my custom changes here and there) and I can't find any reason for this.

 

Here is what happens:

 

 

Excerpt from the Synonyms.txt:

"{QUIVERING}": ["quivering", "trembling", "shaking", "unsteady", "twitching", "hesitant", "shuddering", "quaking", "shivering"],

UPDATE: In my infinite wisdom, I copied the wrong line from my Synonyms.txt *facepalm*

 

Here is the correct line:

"{QUIVER}": ["quiver", "shiver", "shudder", "spasm", "tremor"],

 

 

The line from the "FemaleActor_WearTearIncreased_Vaginal.txt":

"You try to walk on {QUIVER}ing legs. Cum drips down your legs. He came a ton...",

Does someone have an idea what might be the problem?

 

Some clues:

- ALL Synonyms in the Synonyms.txt are lowercase.

- Most Synonyms end up (ingame widget) lowercase. This is the correct and expected behavior that I would like to see for every Synonym.

- Some Synonyms end up (ingame widget) with a leading capital i.e. "Quivering"

- Some Synonyms end up (ingame widget) in complete CAPITALS. See the image above.

- I've already reset the Apropos DB in MCM

- I've already tried to reset Apropos in MCM

- I've already tried to cleanly uninstall and reinstall Apropos

 

(If this should be better posted in the Apropos DB Support thread, just tell me, but I honestly don't think this is a database problem).

 

Cheers.

[Seijin8]

1 hour ago, King-Crimson said:

I can't find any reason for this.

Every time that happens it is a string/word that the game uses residently: Body, Head, Quiver (for storing arrows), etc.  No way to control it, that is Skyrim's engine screaming "HEY I KNOW THAT WORD!!"  The only real solution is to remove such words from the synonyms set, and as solutions go, that sorta sucks.

[gooser]

2 hours ago, Seijin8 said:

Every time that happens it is a string/word that the game uses residently: Body, Head, Quiver (for storing arrows), etc.  No way to control it, that is Skyrim's engine screaming "HEY I KNOW THAT WORD!!"  The only real solution is to remove such words from the synonyms set, and as solutions go, that sorta sucks.

Correct. It's called string interning, a way of optimizing storage for strings. Once Skyrim sees a "word" it interns it and you have to live with it.

[Skarab]

5 hours ago, King-Crimson said:

Heya,

sometimes the apropos synonyms are in complete capslock.

This has been a problem for a very long time, but recently it has gotten worse.

I've looked into the db myself (i use the newly maintained Apropos DB Updates with my custom changes here and there) and I can't find any reason for this.

 

Here is what happens:

 

 

Excerpt from the Synonyms.txt:

"{QUIVERING}": ["quivering", "trembling", "shaking", "unsteady", "twitching", "hesitant", "shuddering", "quaking", "shivering"],

 

The line from the "FemaleActor_WearTearIncreased_Vaginal.txt":

"You try to walk on {QUIVER}ing legs. Cum drips down your legs. He came a ton...",

Does someone have an idea what might be the problem?

 

 

 

Cheers.

 

 I beg to differ with the other replies:

 

The synonym {QUIVER} with the added letters "ing", is from the new Apropos2 Text DB Update from Eadoo in which he is tring to reduce the number of synonyms. My guess is that you are using Eadoo's "FemaleActor_WearTearIncreased_Vaginal.txt" data but are not using his synonyms, therefore, since {QUIVER} is not in your synonym list it is actually correct in it's output,

 

I have merged Eadoo's synonym.txt with my own so in my synonym.txt I have both {QUIVER} and {QUIVERING} as synonyms, I attach it below if you want to try  it but bear in mind that it's larger and also is tailored to my game, it's in UK English for the most part too.

 

 

Synonyms.txt

[Seijin8]

38 minutes ago, Skarab said:

 I beg to differ with the other replies:

If that were true, the brackets would also be present.  It would say {QUIVER}ing.

 

Clearly, it doesn't.

[Skarab]

21 minutes ago, Seijin8 said:

If that were true, the brackets would also be present.  It would say {QUIVER}ing.

 

Clearly, it doesn't.

Good point, however he obviously has {QUIVERING}, rather than {QUIVER} in his synonyms.txt

[Seijin8]

3 minutes ago, Skarab said:

Good point, however he obviously has {QUIVERING}, rather than {QUIVER} in his synonyms.txt

Possibly.  I've seen the game take the all caps thing to the word HEADache before, and the token it was filling didn't have "head" in it, so I doubt it is a reliable way of judging.  The main issue (for me) is that it only does this sometimes.  Consistency would be better all around for finding and fixing the issue, but when the game randomly does this, it is extra obnoxious.

 

EDIT: Really, the best solution in this case would be to replace {QUIVER} with {SHUDDER}, which wouldn't get hit by this bug.

[Guest]

Bethesda in their infinite wisdom thought it was a good idea to make the data stored by strings case-insensitive. The case of a string, which is going to be printed in-game, is undefined behavior and depends on the case-insensitive string being cached within the PapyrusVM.

Sometimes you will see synonyms capitalized, while other times you will see mod options in the MCM being displayed as lowercase even when you clearly wrote them capitalized.

In your case, the key name "QUIVER" is read first and then gets cached by the PapyrusVM. Any subsequent use of the case-insentitive string "quiver" will just point to the cache.

 

I don't know who was the genius at Bethesda that thought this was a good idea (unreliable data content of the only native way to represent texts/strings), but considering how shitty Papyrus is (lack of an iteration loop statement, lack of flow control statements for the only loop statement, lack of built-in utility methods for native data types, etc) I would say no one in there questioned those obviously terrible design choices and just went with them.

Compare them with say, Witcher Script (REDEngine's high-level scripting language) and you will just feel dirty writing those ugly ass codes in Papyrus and still getting goddamned undefined behaviors within a high-level scripting language.

 

A dirty solution would be to write all the keynames with a prefix ("{SYNONYM_QUIVER}" for example) to prevent caching, but that would still not solve the issue for strings cached from the vanilla game or other mods.

A better solution would be to write all the communication with the action script directly from C++. C++ parses and stores the data internally in a case sensitive manner. Papyrus would then call the native C++ function (with a specific id) to have it deliver the string to the action script.

 

EDIT: {QUIVERING} was changed to {QUIVER} in one of the db updates. He is probably reading from an outdated file since his text clearly uses {QUIVER} and not {QUIVERING}.

[gooser]

2 hours ago, Hawk9969 said:

Bethesda in their infinite wisdom thought it was a good idea to make the data stored by strings case-insensitive. The case of a string, which is going to be printed in-game, is undefined behavior and depends on the case-insensitive string being cached within the PapyrusVM.

Sometimes you will see synonyms capitalized, while other times you will see mod options in the MCM being displayed as lowercase even when you clearly wrote them capitalized.

In your case, the key name "QUIVER" is read first and then gets cached by the PapyrusVM. Any subsequent use of the case-insentitive string "quiver" will just point to the cache.

 

I don't know who was the genius at Bethesda that thought this was a good idea (unreliable data content of the only native way to represent texts/strings), but considering how shitty Papyrus is (lack of an iteration loop statement, lack of flow control statements for the only loop statement, lack of built-in utility methods for native data types, etc) I would say no one in there questioned those obviously terrible design choices and just went with them.

Compare them with say, Witcher Script (REDEngine's high-level scripting language) and you will just feel dirty writing those ugly ass codes in Papyrus and still getting goddamned undefined behaviors within a high-level scripting language.

 

A dirty solution would be to write all the keynames with a prefix ("{SYNONYM_QUIVER}" for example) to prevent caching, but that would still not solve the issue for strings cached from the vanilla game or other mods.

A better solution would be to write all the communication with the action script directly from C++. C++ parses and stores the data internally in a case sensitive manner. Papyrus would then call the native C++ function (with a specific id) to have it deliver the string to the action script.

 

EDIT: {QUIVERING} was changed to {QUIVER} in one of the db updates. He is probably reading from an outdated file since his text clearly uses {QUIVER} and not {QUIVERING}.

Thanks. Something I explored with the JContainers author years ago, possibly handing string management at the SKSE/C++ level but we never found a real solution.

[Guest]

48 minutes ago, gooser said:

Thanks. Something I explored with the JContainers author years ago, possibly handing string management at the SKSE/C++ level but we never found a real solution.

Are you willing to restructure all of your scripts to make the switch from JContainers to a self tailored plugin specific for Apropos use? If so, I can point you in the right direction.

[gooser]

1 hour ago, Hawk9969 said:

Are you willing to restructure all of your scripts to make the switch from JContainers to a self tailored plugin specific for Apropos use? If so, I can point you in the right direction.

Sure, all ears.

 

Was looking at Meh's .Net framework skse plugin actually.

[Malos323]

Are there any descriptions for mind-control related ones?

 

I know the Daedra ones have it but with about things like the Anubs Animation Mind Control animations.etc