Lewd Talks

[Moneido]

Hello. First of all, thanks for this mod. Second of all, I just downloaded this mod and started testing it. 

 

So far, it looks pretty cool and functional. The only thing out of place is the text output length during scenes.

 

No matter what I pick in the MCM, "notification" or "widgets" the text during sex scenes will only last for literally one second, making it impossible to read. I've been messing around with the MCM, but nothing seems to change.

 

I'm sorry if this is an already known issue, just wanted to report that. And again, this is a cool-looking mod. Hope you keep working on it.

[Beerbatty]

Heya

When you say to "rewrite the lines in the config" is this straight text edit of the .ini file that can be accessed vid mod manager?

[Operand]

On 11/3/2021 at 9:17 AM, Beerbatty said:

Heya

When you say to "rewrite the lines in the config" is this straight text edit of the .ini file that can be accessed vid mod manager?

 

I don't know which mod manager are you using, but yes - it's just a text file. You don't need any mod managers to access it, it will be located at the %Fallout4%\Data\F4SE\Plugins\LewdTalks.ini folder where %Fallout4% is your game installation path (that's where your Fallout4.exe can be found).

 

You will need to then go to the MCM menu and in the "Admin" tab of this mod config page chose the "re-read config" option.

Edited November 18, 2021 by Operand

[xt0n1]

Thanks for sharing this mod with us! Little mod with a big impact. Everything is working fine, the only thing that seems to be off place is that, after starting a new game, letting everything load say for 30+ minutes in a normal gameplay before closing the game or anything, after I reload or close the game and load that save back, I'm getting a notification in the top left of the screen saying "HUD Framework Init Completed; THIS IS A TESTING NOTIFICATION" and no matter how many times I reload a save or close and open back the game, it stays there to the point where I had to uninstall the mod because of how annoying it is. I'm currently using FallUI HUD along with its requirements and other mods, like FallUI - Inventory, Confirm Boxes, Map, Sleep & Wait and Workbenches, no other HUD modifiers used at all. It's very strange even if I change the HUD layout to say, Vanilla or Minimalistic in FallUI - HUD  it remains there.

[Operand]

On 12/8/2021 at 8:33 AM, LexieSky said:

Thanks for sharing this mod with us! Little mod with a big impact. Everything is working fine, the only thing that seems to be off place is that, after starting a new game, letting everything load say for 30+ minutes in a normal gameplay before closing the game or anything, after I reload or close the game and load that save back, I'm getting a notification in the top left of the screen saying "HUD Framework Init Completed; THIS IS A TESTING NOTIFICATION" and no matter how many times I reload a save or close and open back the game, it stays there to the point where I had to uninstall the mod because of how annoying it is. I'm currently using FallUI HUD along with its requirements and other mods, like FallUI - Inventory, Confirm Boxes, Map, Sleep & Wait and Workbenches, no other HUD modifiers used at all. It's very strange even if I change the HUD layout to say, Vanilla or Minimalistic in FallUI - HUD  it remains there.

 

Ha! At least you're getting the notification. Half the people can't make the widget work at all. Nothing I can help. Yet again - the HUD Framework (or the underlying abomination of tech also known as "flash") is a bad piece of software. But it's the only thing currently existing in the game that allows for custom text output. My code is carbon copy of what other mods do. Yet for some reason it fails every so often. My guess is that other mods only output numeric values - good example are HUDs for things like Sex Attributes. But in my case the widget is unstable using the same code.

 

If someone knows how to make it work - be my guest, I wasted many hours trying and retrying it. If you know a fix - I'll immediately include it into the mod.

[2_Unknown_2]

Nice mod, just one issue though, everything works as intended exept that the talking never happens, no matter how long i stand still not touching my keyboard my PC never talks to herself, and im forced to use middle mouse button to force it everytime. Everything else works though.

 

Edited January 8, 2022 by TheGamingSoviet1944

[Operand]

On 1/8/2022 at 7:00 PM, TheGamingSoviet1944 said:

Nice mod, just one issue though, everything works as intended exept that the talking never happens, no matter how long i stand still not touching my keyboard my PC never talks to herself, and im forced to use middle mouse button to force it everytime. Everything else works though.

 

 

If I recall correctly, by default the non-AAF talks are disabled. Check if it's enabled in the MCM. You can also press Mouse3 ("middle button") to see if it works - this is a backup option to force the dialogue line even if it's disabled.

 

Another thing - if you have mods like "Player Comments" then you may also need to disable them either permanently (by uninstalling) or temporarily (Player Comments has a hotkey to switch the talks from it On/Off). The same applies for the majority of the head-tracking mods. Any mod that puts the PC into the "scene" mode will interfere with this mod because to not break things I check if PC is in scene and if yes - don't trigger the dialogue lines.

[xgthxhnmp]

I'm going to open this by saying that I have no idea what I'm talking about, but I tried the mod for a bit and tried changing some lines in the .ini, and I noticed that you have different lines for each of the perspectives, when it seems like something that might be possible to handle that programatically, and I suspect that it is also possible to bypass the issues with the hard limits on numbers of synonyms and stuff through similar means. I don't know anything about fallout 4 modding except a little bit of twiddling with xedit, but from how that one mod IN GAME ESP EXPLORER searches your mods using c++ I bet there is some way to use f4se to allow you to handle the string manipulation with something other than papyrus and simply inject the manipulated strings into the game on demand (I think you might just be able to include compiled code in f4se plugins, that would obviously allow some serious performance benefits). You could probably get some performance benefits from this too, and allow for easier customization by users, since most people are just going to use one perspective all the time.

 

Anyways, I really like the mod, it's a really neat idea. I hope you have fun figuring out different ways to overcome the limitations imposed by Fallout 4.

[dragon13]

may want to mention in main post you need to download main version to get the mod assets as they are not included in no-anim version

[Operand]

On 1/24/2022 at 10:58 PM, xgthxhnmp said:

I'm going to open this by saying that I have no idea what I'm talking about, but I tried the mod for a bit and tried changing some lines in the .ini, and I noticed that you have different lines for each of the perspectives, when it seems like something that might be possible to handle that programatically, and I suspect that it is also possible to bypass the issues with the hard limits on numbers of synonyms and stuff through similar means.

 

Um.. if I got you correctly then it's a hard "NO". Because:

• You suggest to change the phrase on the fly depending on the perspective - that implies that there is a semantic analysis engine somewhere in the mod kernel that's capable of such transformation
• Even on a chance it's possible to devise such an engine, it will be most definitely necessary to implement as F4SE plugin, not in Papyrus, because..
  • Good luck scripting that in Papyrus where even the basic string functions (like length or replacement) are absent and need an extension + Papyrus is not a general level language: you can't instantiate stuff on a whim or have abstract types etc etc
  • Even if one manages to code it in Papyrus, that will be horrendously slow - even a simple string replacement of this mod can lag sometimes (and that's with a ton of optimization I did internally, such as fixed-length aligned synonyms)
• But most likely it's impossible to create such a replacement engine because:
  • It's speech analysis. Speech is messy, irregular, not possible to structure. It is a problem even corporations like Google fail to solve
  • A lot of corner cases arise - usage of idioms, "colorful language" or plain typos in the config can lead to pretty bad outcomes
  • Not everything can be even said properly in the chosen tense, speech modus (active/passive), cases and references - at least, in English

 

All in all - the effort necessary to achieve even a proximate result here is far greater than that of a simple config matter. If I was capable of implementing what you said, I'd sell this to some company that researches this subject - or better yet - patent it and live my life off those royalties.

Edited February 7, 2022 by Operand

[xgthxhnmp]

2 hours ago, Operand said:

 

Um.. if I got you correctly then it's a hard "NO". Because:

• You suggest to change the phrase on the fly depending on the perspective - that implies that there is a semantic analysis engine somewhere in the mod kernel that's capable of such transformation
• Even on a chance it's possible to devise such an engine, it will be most definitely necessary to implement as F4SE plugin, not in Papyrus, because..
  • Good luck scripting that in Papyrus where even the basic string functions (like length or replacement) are absent and need an extension + Papyrus is not a general level language: you can't instantiate stuff on a whim or have abstract types etc etc
  • Even if one manages to code it in Papyrus, that will be horrendously slow - even a simple string replacement of this mod can lag sometimes (and that's with a ton of optimization I did internally, such as fixed-length aligned synonyms)
• But most likely it's impossible to create such a replacement engine because:
  • It's speech analysis. Speech is messy, irregular, not possible to structure. It is a problem even corporations like Google fail to solve
  • A lot of corner cases arise - usage of idioms, "colorful language" or plain typos in the config can lead to pretty bad outcomes
  • Not everything can be even said properly in the chosen tense, speech modus (active/passive), cases and references - at least, in English

 

All in all - the effort necessary to achieve even a proximate result here is far greater than that of a simple config matter. If I was capable of implementing what you said, I'd sell this to some company that researches this subject - or better yet - patent it and live my life off those royalties.

not quite on the fly, and you already basically do it with the synonyms system. I hadn't actually looked at papyrus scripting yet when I made my post, so I wasn't aware of just how awful it was (people constantly talk about papyrus scripts, but then I discover it's compiled, that definitely threw me for a loop). There is a pretty obvious problem where the papyrus language doesn't have good tools for string replacement, among a lot of other things it really should have, like adequate documentation (I can't even find a good resource for syntax, it's just awful). Trying to handle strings in papyrus would be a pain in the ass, but while trying to sort something else out I discovered PapyrusDotNet, which I haven't looked too closely at, because it didn't end up being the solution I was looking for, but it might be what could be what you need, since even if you don't want to write the whole plugin in C# or VB you might be able construct a library of more efficient string handling functions to then call in papyrus. I'd imagine there is also some way to do it properly in papyrus only, but I'd imagine that you'd basically be creating a weird machine and falling into a turing tarpit. You might not want to create your own f4se plugin, but you already have some f4se plugins for the mcm stuff after all. So importing one for getting some basic functionality you need to construct the functions you would need wouldn't be that big a step. this might work.

I wasn't actually suggesting implementing any sort ofsemantic analysis, I think I said it wrong. I was also operating under the assumption that you had at least some very basic things that you don't seem to. I don't think it's possible to do what I was suggesting anymore, but in the hopes that it might alleviate my embarassment, I'll pseudocode my idea out a bit so that maybe it will seem a little less stupid and a little more just naive about how bad Papyrus is.

0th person: I try to relax my {~~~~~WEARA} {~~~ASSHOLE}.. and with that I feel you press the gloriously {~~~~~~HUGE} cock head of your {~~~~~~COCK} into me..

1st person: I try to relax my {~~~~~WEARA} {~~~ASSHOLE}.. and with that I feel {~~~ACTIVE0} press the gloriously {~~~~~~HUGE} cock head of his {~~~~~~COCK} into me..

2nd person: You try to relax your {~~~~~WEARA} {~~~ASSHOLE}.. and with that you feel {~~~ACTIVE0} press the gloriously {~~~~~~HUGE} cock head of his {~~~~~~COCK} into me..

3rd person: {~~~PASSIVE} tries to relax her {~~~~~WEARA} {~~~ASSHOLE}.. and with that she feels {~~~ACTIVE0} press the gloriously {~~~~~~HUGE} cock head of his {~~~~~~COCK} into her..

could be turned into something like

{perspective} tr({ies} IF perspective==3 ELSE {y}) to relax {selfPossessive} {~~~~~WEARA} {~~~ASSHOLE}.. and with that {perspective} feel({s} IF perspective==3) (you IF perspective==1 ELSE {~~~ACTIVE0}) press the gloriously {~~~~~~HUGE} cock head of ({your} IF perspective==1 ELSE {~~~ACTIVE0}{'s}) {~~~~~~COCK} into {perspectivePronoun}..

 

that would really only require a couple of conditional checks and string concatenations, certainly not natural language processing. I haven't written anything in papyrus yet, so I don't have a clue if that's even possible, but I doubt it is. If it was possible to add some sort of conditional checking to the synonyms system then you might be able to do something like that, but I think that'd be a pain in papyrus. I'm going to take a look at the sources for this mod when I have more free time, since having taken a quick look at papyrus, I'm very impressed you managed to do this at all.

The reason I thought that approach might help users edit it is because if a user only ever intends to use one perspective, they could simply not add the conditions for the other perspectives.

Edited February 7, 2022 by xgthxhnmp

[Operand]

16 minutes ago, xgthxhnmp said:

not quite on the fly, and you already basically do it with the synonyms system. I hadn't actually looked at papyrus scripting yet when I made my post, so I wasn't aware of just how awful it was (people constantly talk about papyrus scripts, but then I discover it's compiled, that definitely threw me for a loop).

 

No, not really. Papyrus is a scripting language and uses interpreting layer, it's not a compiled language. Think of it as something like opcodes for language like PHP. It works like this: Script -> compiled into opcodes <- picked up by a thread in Zenimax VM <- a thread spawned inside Zenimax VM <- launched by in-game thread <- executable by OS (binary level). So as you see it's pretty far away from the real compiled stuff. F4SE is what makes compiled code possible to inject into the game - hence it is capable of bypassing many limitations.

 

16 minutes ago, xgthxhnmp said:

PapyrusDotNet,

 

This has nothing to do with "compilation", all it does is a fancy compilation to the Zenimax VM "binaries" (this term is misleading as those are not executed directly by the game as I've explained above). On top of that it adds some syntax sugar which in the end it translates into the opcodes recognizable by the aforementioned VM. Bottom line: if the call to a string function is done in Papyrus, even if that function is implemented in a binary extension such as LL_Fourplay community plugin - the call itself would be made by the VM and therefore will be much slower compared to the call done directly by the game engine through the dll of some F4SE plugin.

 

16 minutes ago, xgthxhnmp said:

I'll pseudocode my idea out a bit

 

The problem with this approach is that it assumes something that won't be there in a general case. Users can change the config to whatever they like - add, remove more synonyms, rewrite the tense / the speech modus etc etc. It's impossible to include all those possibilities via branching.

Edited February 7, 2022 by Operand

[xgthxhnmp]

7 minutes ago, Operand said:

 

No, not really. Papyrus is a scripting language and uses interpreting layer, it's not a compiled language. Think of it as something like opcodes for language like PHP. It works like this: Script -> compiled into opcodes <- picked up by a thread in Zenimax VM <- a thread spawned inside Zenimax VM <- launched by in-game thread <- executable by OS (binary level). So as you see it's pretty far away from the real compiled stuff. F4SE is what makes compiled code possible to inject into the game - hence it is capable of bypassing many limitations.

 

 

This has nothing to do with "compilation", all it does is a fancy compilation to the Zenimax VM "binaries" (this term is misleading as those are not executed directly by the game as I've explained above). On top of that it adds some syntax sugar which in the end it translates into the opcodes recognizable by the aforementioned VM. Bottom line: if the call to a string function is done in Papyrus, even if that function is implemented in a binary extension such as LL_Fourplay community plugin - the call itself would be made by the VM and therefore will be much slower compared to the call done directly by the game engine through the dll of some F4SE plugin.

 

 

The problem with this approach is that it assumes something that won't be there in a general case. Users can change the config to whatever they like - add, remove more synonyms, rewrite the tense / the speech modus etc etc. It's impossible to include all those possibilities via branching.

yeah, I was kinda bouncing around and I kept editing it as I was typing, so I ended up taking out parts then not changing other parts to make sense later. I wasn't aware that it wasn't truly compiled, when I initially made my first post I thought papyrus was like python in how it worked. When I found out there was a compile step, I just assumed that it was compiled and thus the papyrusdotnet thing must just be another compiler, I didn't look into it further because I was really just looking for a way to make mods with scripts without downloading the creation kit, which I finally gave up on and just downloaded last night, and I really haven't taken much of a look at yet. Now that you have explained it, what barriers exist to just doing everything as f4se plugins? Did you make this mod in papyrus just to challenge yourself, or is there a technical reason for not using f4se?

[Operand]

20 minutes ago, xgthxhnmp said:

Did you make this mod in papyrus just to challenge yourself, or is there a technical reason for not using f4se?

 

No. It's simply because I have no idea about "how to F4SE". It may sound arrogant, yet I consider myself a decent engineer - I've learned everything about the architecture of the game myself and coded all my mods using only FO4Edit and scripting everything from scratch and creating extendable, maintainable and well-thought architecture while doing so.

 

However I don't know how F4SE works and unlike Papyrus the documentation there is close to non-existent and there is no frame of reference one can use to learn it properly. If there was a way to pick up those skills and understand it - I'm sure I'd do a lot with it, but alas - so far I didn't. Though perhaps it's a good reason to humble myself from a "decent engineer" label.

Edited February 7, 2022 by Operand

[xgthxhnmp]

33 minutes ago, Operand said:

 

The problem with this approach is that it assumes something that won't be there in a general case. Users can change the config to whatever they like - add, remove more synonyms, rewrite the tense / the speech modus etc etc. It's impossible to include all those possibilities via branching.

I was thinking that if a user does that, they probably would simply write a list of whatever lines they specifically want for the type of speech they want, so they would probably create a list of synonyms which work in the tense and modus which they want. So a user who had edited their config wouldn't have all those conditions. If it were possible to use a conditional in the synonyms list so that it injects a different variation of the synonym based upon conditionals, or perhaps simply excludes certain synonyms based upon conditionals, that might allow certain words to be used in a way that allows their correct declension to be used. For instance with the synonyms for lewd, you might have that list look in a pseudocode idea of this as

~~~~~~LEWD=lewd(1:ly|2:ness),naughty(1:ly|2:ness),erotic(1:ally|2:ness),slutt(null:y|1:ily|2:yness),sex(null:y|1:ily|2:yness)

and then when somebody inserts the lewd synonym, they would call it like {~~~~~~LEWD}[1] if they want the declension marked with 1.

No idea if this is possible to implement, it was just what I was thinking of back when I wrote my original post.

[Operand]

5 minutes ago, xgthxhnmp said:

For instance with the synonyms for lewd, you might have that list look in a pseudocode idea of this as

 

So, knowing that Papyrus has very limited capabilities of working with strings you suggest to.. parse a regular structure in it Nope, that won't fly. Heck, it's won't even crawl. And that's only performance, not to tell about the approach - since at the very least it will make configs very user-unfriendly to edit and very error-prone to such edits but realistically - I bet there will be adjectives/adverbs/whatnot that will just defy any sort of logic in different combinations.

Edited February 7, 2022 by Operand

[xgthxhnmp]

20 minutes ago, Operand said:

 

No. It's simply because I have no idea about "how to F4SE". It may sound arrogant, yet I consider myself a decent engineer - I've learned everything about the architecture of the game myself and coded all my mods using only FO4Edit and scripting everything from scratch and creating extendable, maintainable and well-thought architecture while doing so.

 

However I don't know how F4SE works and unlike Papyrus the documentation there is close to non-existent and there is no frame of reference one can use to learn it properly. If there was a way to pick up those skills and understand it - I'm sure I'd do a lot with it, but alas - so far I didn't. Though perhaps it's a good reason to humble myself from a "decent engineer" label.

that makes sense, I was thinking that since F4SE allowed the use of compiled binaries, it was simply a matter of writing it in a language you were more comfortable with and including whatever little bits of f4se were required to hook it up to fallout. Trivializing that part in my head though is probably one of several errors with my reasoning here. I had been wondering where people figure out how to use F4SE, since I couldn't find any useful documentation either, although admittedly I only looked briefly while trying to figure something else out. I figure it must be out there, because so many people have made plugins using it.

[xgthxhnmp]

5 minutes ago, Operand said:

 

So, knowing that Papyrus has very limited capabilities of working with strings you suggest to.. parse a regular structure in it Nope, that won't fly. Heck, it's won't even crawl. And that's only performance, not to tell about the approach - since at the very least it will make configs very user-unfriendly to edit and very error-prone to such edits but realistically - I bet there will be adjectives/adverbs/whatnot that will just defy any sort of logic in different combinations.

Well I understand that now, like I said, I don't think any of this is possible anymore, I was simply trying to make it clear I was naive about how limited papyrus is, not stupid.

[Operand]

8 minutes ago, xgthxhnmp said:

that makes sense, I was thinking that since F4SE allowed the use of compiled binaries, it was simply a matter of writing it in a language you were more comfortable with and including whatever little bits of f4se were required to hook it up to fallout.

 

Of course not. One needs to understand the game engine, its architecture, what can be used, what APIs does it use, what the game expects etc. From what I understand, F4SE works as a process of "hijacking" calls that the game makes and then using it as an entry point. The game itself doesn't have a clue about the fact its engine now uses F4SE-provided implementations of the internal APIs it uses - but nevertheless, the provider (i.e. the plugin that F4SE will utilize for the call) of said implementation must follow the contract that the game engine expects (or crash in the most painful way possible).

 

And there's no clear way of understanding those internal APIs, you just .. need to go there, decompile, iterate, try-fail, rinse and repeat. F4SE is just a broker, it doesn't do any magic by itself, the knowledge about the engine still falls into the shoulders of the plugin author. To make it readily available and easy to understand one would simply need to.. have access to Fallout4 source code, at least partially. But at that point it will be probably much easier to extend that code directly with the desired change(s) and not bother with the brokerage dance. That is at least how I understand it.

Edited February 7, 2022 by Operand

[xgthxhnmp]

1 minute ago, Operand said:

 

Of course not. One needs to understand the game engine, its architecture, what can be used, what APIs does F4SE provide, what the game expects etc. From what I understand, F4SE works as a process of "hijacking" calls that the game makes and then using it as an entry point. The game itself doesn't have a clue about the fact its engine now uses F4SE-provided implementations of the internal APIs it uses - but nevertheless, the provider of said implementation must follow the contract that the game engine expects (or crash in the most painful way possible).

 

And there's no clear way of understanding those internal APIs, you just .. need to go there, decompile, iterate, try-fail, rinse and repeat. F4SE is just a broker, it doesn't do any magic by itself, the knowledge about the engine still falls into the shoulders of the plugin author. To make it readily available and easy to understand one would simply need to.. have access to Fallout4 source code, at least partially. But at that point it will be probably much easier to extend that code directly with the desired change(s) and not bother with the brokerage dance. That is at least how I understand it.

Yeah, of course it's just a broker, I don't know if it adds any functions which can be called in a papyrus script to simply run a compiled binary with certain inputs, but I assumed that was the case, then I extended that idea to assume that that meant that, for instance, in the case of strings, you could just go f4se.compiledstringparserscript(string) and get whatever you wanted from that. I assumed that in that case the static program of the binary could on the dynamic input of the papyrus function, thus essentially being partial evaluation.

[Operand]

14 minutes ago, xgthxhnmp said:

Yeah, of course it's just a broker, I don't know if it adds any functions which can be called in a papyrus script to simply run a compiled binary with certain inputs, but I assumed that was the case, then I extended that idea to assume that that meant that, for instance, in the case of strings, you could just go f4se.compiledstringparserscript(string) and get whatever you wanted from that. I assumed that in that case the static program of the binary could on the dynamic input of the papyrus function, thus essentially being partial evaluation.

 

You're mixing two different cases here I think.

 

1. The F4SE plugin adds a native function that becomes visible in Papyrus scripts. In this case such a plugin also comes with the .pex file containing the prototype of this new function so that other Papyrus scripts could recognize it and compile. In run-time the plugin intercepts the VM call to the new function and redirects it to the binary implementation it has. Execution-wise it has two parts: first, the path to the call via Zenimax VM which will be slow and the second is the execution of the binary code triggered by the VM call which will be fast. But since it all happens within the VM, it can be compared with a call of any standard Papyrus function and is therefore no better.

 

2. The F4SE plugin has some new/custom functionality and  the binary implementation of it which happens when the game engine does some stuff (outside of Zenimax VM and not related to it at all). For instance, something happening when the game loads a new cell and the plugin wants to do something about it - that's how all of the "crash fixers" work for such cases. In this scenario there's no VM involved, so no need to boot all the lengthy invocation sequence and all happens as it normally would - directly in-game engine. This is as fast as the newly written implementation would be so this case is what's considered "the fast" one.

 

TL;DR - Papyrus is still Papyrus even if the stuff it calls was added by F4SE.

Edited February 7, 2022 by Operand

[xgthxhnmp]

28 minutes ago, Operand said:

 

You're mixing two different cases here I think.

 

1. The F4SE plugin adds a native function that becomes visible in Papyrus scripts. In this case such a plugin also comes with the .pex file containing the prototype of this new function so that other Papyrus scripts could recognize it and compile. In run-time the plugin intercepts the VM call to the new function and redirects it to the binary implementation it has. Execution-wise it has two parts: first, the path to the call via Zenimax VM which will be slow and the second is the execution of the binary code triggered by the VM call which will be fast. But since it all happens within the VM, it can be compared with a call of any standard Papyrus function and is therefore no better.

 

2. The F4SE plugin has some new/custom functionality and  the binary implementation of it which happens when the game engine does some stuff (outside of Zenimax VM and not related to it at all). For instance, something happening when the game loads a new cell and the plugin wants to do something about it - that's how all of the "crash fixers" work for such cases. In this scenario there's no VM involved, so no need to boot all the lengthy invocation sequence and all happens as it normally would - directly in-game engine. This is as fast as the newly written implementation would be so this case is what's considered "the fast" one.

 

TL;DR - Papyrus is still Papyrus even if the stuff it calls was added by F4SE.

let's see if I understand it here, because I get the bit about how f4se handles calling the function, then the function itself runs as fast as it would under any circumstance once it is called. So if that is the case, the steps for a hypothetical mod which does something similar to this one would be something along the lines of:

 

1. The mod runs initially which calls the function which is actually the compiled binary (papyrus)

2. Then the compiled binary would read the config file with all the lines and do all the replacements which are static like tense and player name. It could just hold these strings in memory since it's not like they will take up much space as long as you do garbage cleanup whenever they are changed (compiled binary)

3. Then when the mod has an event which it needs a string for, a function is called which passes to the binary which string it needs and all the non static data(papyrus)

4. Then the binary would give the game the string it has generated. (compiled binary)

5. The game would use that parsed string. (papyrus/game engine)

 

Is that more or less right?

Edited February 7, 2022 by xgthxhnmp

[Missynissy]

Is there a way to make the lines last abit longer? they dont seem to last for more then a second or two making them hard to read

[Dez65]

Really loving this mod!  

 

I have [AAF] M.C.G. (Extended Social Interactions) installed.  As you may know, that mod also uses HUD Framework to display Lust, Wear and Infamy values in the upper left hand corner of the screen.  

 

After installing this, the values for these attributes are displayed to six decimal places, rather than just as whole numbers.  (See spoiler).  I raised this with Martin56 and he suggested that I bring it up here.  Any ideas how I can correct this issue?  

 

Again, love your mod and it will definitely have a permanent place in my load order.  Thanks for your anticipated help.

 

Spoiler

 

[Martin56]

On 4/1/2022 at 9:12 PM, Dez65 said:

Really loving this mod!  

 

I have [AAF] M.C.G. (Extended Social Interactions) installed.  As you may know, that mod also uses HUD Framework to display Lust, Wear and Infamy values in the upper left hand corner of the screen.  

 

After installing this, the values for these attributes are displayed to six decimal places, rather than just as whole numbers.  (See spoiler).  I raised this with Martin56 and he suggested that I bring it up here.  Any ideas how I can correct this issue?  

 

Again, love your mod and it will definitely have a permanent place in my load order.  Thanks for your anticipated help.

 

  Reveal hidden contents

 

Hi! 

R3z Shark has provided a possible fix, you could test it by downloading it here:

 

 

 

Please let him know if it works!