Jump to content

OSex+ The Greatest Virtual Sex Ever


Recommended Posts

Sorry these ladies are very dear to me and I want to keep them private so my projects and screen shots are recognizable. I also use their avatars as an online persona so I feel strongly about having them be unique to me. Very sorry for being like that if this is disappointing.

Well since OP doesn't want to share his followers, anyone can recommend some that are equally good? I like Pasq, anyone happens to know a mod of a follower that looks similar?

Link to comment

clipping animations go to show how poor skyrim physics engine is..........

FIFA has the best interactive physics engine which is why the footballing experience seems so realistic when playing FIFA even though in a real game, you wouldn't be dribbling and passing the ball like that.

WTF....

Link to comment

I belive what he said was about tentacles. That he doesn't like those. Usualy he is really helpful person but not so much at this time. Anyway i would invite both you and pipdude to join unofficial LL chat. Lots of great modders are there so you can get help with what you need real time if not from them then from pipdude. (guys there can be weird sometimes but usualy they always help and they are pros even if they are big headed sometimes :D).

 

Thank you. Where is the unofficial LL chat at?

Link to comment

 

That's the idea. Build functionality and tuck the wires away. Then you can focus more on the bigger picture and how all the pieces interact.

Let me know what questions you run into.

 

 

Thank you for all of this very helpful! In my mind the animations were in the specific scene data as being tied together and I couldn't quite figure out the plan of separating them but it just made sense to me and it's good. Separating animation data from the scenes and the scenes can call animations as needed. I made the adjustment to the scene but I think the animations would still have to exist within the module and not a global place outside of the stage as in that case all modules animations would have to all be preloaded at once. I have the model almost done that can switch scenes etc. basically full OSA but just a couple scenes in the xml format. Here's my xml plan I'm currently using I think you know a much better way to managing the StageID then I am but I'm setting this up just for now in the only way i can see and I'm sure you can help me make this a more awesome system:

 

tumblr_o38kuz1sYJ1ubnr1mo2_r2_1280.png

 

----------------------------------------------

 

Bad news and the first wall this awesome new approach is hitting is MiscUtil. If I copy the scene block x 10 the screen starts feeling unstable on start anywhere between 10 and 50 is a Skyrim crash. MiscUtil appears to only be able to push a small amount of text through Skyrim at a time.

 

Options that I see are load each scene one at a time but this would head back to the json layout where quite a bit of stuff has to be loaded constantly. Animation, Scene, Identity etc. since it would all have to be in relatively small packages and divided up to get through. The second that we maybe can do is have the XML's cleaned into a straight string and placed into a JSON array so at least we can push 128 entries through at a time, (maybe). 

 

InvokeStringA(".LoadXML", JsonUtil.GetStringList())

 

ActionScript

 

While argumenets[zI] > 0 etc.

arguments[zi].loadXML

EndWhile

 

Potentially the string[0] of the JSON could be used to signify if a second entry is needed. So the papyrus could if check the first field and if so it will take the next array and send it up too. (For modules that have more then 128 scenes.) The actionscript seems like it would easily be able to take and place the XML even if it came in multiple segments.

 

 

Makes the data entry portion substantially less fun but might be the only way. Could still crash Skyrim idk.

 

Last idea is that the animations are grouped by "Family" ST9 for example. The AInav requires a horrid amount of Data entry to accomplish and I made the family grouping to quarantine the data into sections so it doesn't snowball. It could potentially load just one family at a time and if it doesn't have a family it's heading to already the Actionscript could ask Papyrus to load and send it.

 

I'll have to think about it a bit more but that's all I can think of for now. Regardless if it does have to shift back towards the older approach of loading, I think Actionscript will be able to take a majority of the persistent strain away from Papyrus and the XML Actonscript combo will allow for much more powerful and efficient scenes. It could have some other benefits like being able to check if it has preloaded a scene already so it only loads them once etc. Worse case it would most likely wind up a messy combo of JSON sending XML strings to Papyrus then to the UI but that's still a hell of a lot stronger then the previous versions.

 

On that last note. Let's say I have 50 XML blocks labeled scene and I want to find the (id=) DoggyStyle scene. What's the best way to go about finding the index of the scene based on something like the id in <scene id="doggystyle">.

 

 

Link to comment

 

Anyway i would invite both you and pipdude to join unofficial LL chat. Lots of great modders are there so you can get help with what you need real time if not from them then from pipdude. (guys there can be weird sometimes but usualy they always help and they are pros even if they are big headed sometimes :D).

 

Thank you. Where is the unofficial LL chat at?

 

 

You can find more about it on this topic http://www.loverslab.com/topic/30178-ll-unofficial-web-based-irc-chatroom/

 

Or direct link:

https://kiwiirc.com/client/irc.rizon.net/LL

Link to comment

 

 

Thank you for all of this very helpful! In my mind the animations were in the specific scene data as being tied together and I couldn't quite figure out the plan of separating them but it just made sense to me and it's good. Separating animation data from the scenes and the scenes can call animations as needed. I made the adjustment to the scene but I think the animations would still have to exist within the module and not a global place outside of the stage as in that case all modules animations would have to all be preloaded at once. I have the model almost done that can switch scenes etc. basically full OSA but just a couple scenes in the xml format. Here's my xml plan I'm currently using I think you know a much better way to managing the StageID then I am but I'm setting this up just for now in the only way i can see and I'm sure you can help me make this a more awesome system:

 

That works. You can send the StageID over that way. I would probably just send an array with it separated out. But, no significant different in approaches really.

 

 

Bad news and the first wall this awesome new approach is hitting is MiscUtil. If I copy the scene block x 10 the screen starts feeling unstable on start anywhere between 10 and 50 is a Skyrim crash. MiscUtil appears to only be able to push a small amount of text through Skyrim at a time.

 

Options that I see are load each scene one at a time but this would head back to the json layout where quite a bit of stuff has to be loaded constantly. Animation, Scene, Identity etc. since it would all have to be in relatively small packages and divided up to get through. The second that we maybe can do is have the XML's cleaned into a straight string and placed into a JSON array so at least we can push 128 entries through at a time, (maybe). 

 

Hm. Definitely an obstacle. Here is the action plan that I would consider:
 
A. Research whether or not we can get LoadVars to work. It is used in SkyUI code. So, seems like there must be a way. If we can load the text directly into Flash this issue should be fixed. Would be great if Schlangster could be reached. I tried once and never heard anything back.
 
B. Research what is causing the bottleneck. Is it a limitation of Papyrus? Or, does it have something to do with the method MiscUtil is using for the load. If it's MiscUtil, maybe the dll can be re-written in a way that allows larger files to be sent in. Would be really helpful if the author of MiscUtil could be reached.
 
C. Research whether or not the load can be staggered. If a large master xml doesn't change much, maybe it wouldn't be too much of a hassle to break it into several files and load them sequentially in chunks that MiscUtil can handle. Then it would be simple for flash to concatenate them and treat as one large xml.
 
D. Devise a scheme using smaller xml files. Would be a step back toward the old JSON model. But, I think that the performance and flexibility of xml would still be an improvement as you point out.
 
E. The JSON hybrid solution you describe is a possibility as well. Though, it makes me think that if it is possible to send 128 at once, there should be a way to do a custom dll that does the same thing without the JSON overhead. Seems like one of the above options will work before we get down to this plan.
 

 

Last idea is that the animations are grouped by "Family" ST9 for example. The AInav requires a horrid amount of Data entry to accomplish and I made the family grouping to quarantine the data into sections so it doesn't snowball. It could potentially load just one family at a time and if it doesn't have a family it's heading to already the Actionscript could ask Papyrus to load and send it.

 

This is option D from above. Could work. One thing to look at is whether or not the data is really optimized to be the minimum needed. May be able to sneak in some more valuable data by trimming off data that isn't necessary.
 

 

I'll have to think about it a bit more but that's all I can think of for now. Regardless if it does have to shift back towards the older approach of loading, I think Actionscript will be able to take a majority of the persistent strain away from Papyrus and the XML Actonscript combo will allow for much more powerful and efficient scenes. It could have some other benefits like being able to check if it has preloaded a scene already so it only loads them once etc. Worse case it would most likely wind up a messy combo of JSON sending XML strings to Papyrus then to the UI but that's still a hell of a lot stronger then the previous versions.

 

There is evidence that option A, LoadVars can save the day. I say test that. I will also when I can. Might need some time to get to it right now though.
 

 

On that last note. Let's say I have 50 XML blocks labeled scene and I want to find the (id=) DoggyStyle scene. What's the best way to go about finding the index of the scene based on something like the id in <scene id="doggystyle">.

 

You could simply make a loop that iterates through the scenes until it finds the target and stops. At 50 tries that really is nothing in Flash.

 

But, if you wanted to be more efficient, you could build a reference index. Have a separate object built that gets populated with every id as a variable name with whatever reference you want as it's value. Then you could just directly find it:

theIDYouSeek = indexObject["DoggyStyle"];
Link to comment

when i start my game from the beginning i cant use my SL hotkeys, is there any conflict between 0SEX mod and with sexlab mod?

 

There shouldn't be any. Also i believe you have to enable in MCM new versions of Sexlab after installing it.

 

Link to comment

 

 

 

Hey. Good news. I did some more testing and was able to get LoadVars to work.

 

It turned out to be a path issue after all. Loaded widget files treat "Data/Interface/Exported/" as their root. I could have sworn that I tried loading files from that location. But, that was probably for some other API I was testing (XML.load or LoadVariablesNum or something).

 

Anyway, it works. I made an XML file about 1000 lines long and it loaded instantly. Loadable xml size should be nearly unlimited now.

 

Saving xml will still need to go through Papyrus to write to a file. But, I think that the data that needs to be saved can be narrowed to a relatively small file(s).

 

I'll probably follow up by adding a "load" function to the parser so that you can simply give it a file name and it sends a parsed object back.

Link to comment

 

 

 

I ended up leaving a "load" function out of the parser. You can't just return a value because it has to call a second function after it is finished loading (even though that is nearly instant). So, to make a loader you have to employ an event or callback function system. And at that point you're not really making any less work for users than the current usage model for LoadVars.

 

So, using LoadVars looks like this:

var lv = new LoadVars();
lv.onData = Delegate.create(this, varsLoaded); // Side note: Delegate is needed here to make it treat the callback function like it is being fired within "this" class. If you don't use that, it looks to fire the function within the LoadVars object.
lv.load("yourXML.xml"); // yourXML.xml needs to be in /Data/Interface/Exported/ folder.

private function varsLoaded(str)
{
   loadXML(str); // Or whatever parsing type of actions you want to run on the loaded str.
}

I had another thought about saving XML. It might be possible to use SkyUI's GameDelegate.call function to avoid having to send text through Papyrus to save. I haven't tested and am not sure exactly how it works. But, it may be possible to use MiscUtil.WriteToFile that way directly. Worth looking into if save sizes turn into an inconvenience.

Link to comment

 

 

 

Pip dude you are a god, that's the last piece of the puzzle I think and basically gives us endless power here. This is going to be fast, responsive, limitless, sleek and sexy and it's all thanks to you. This is going to be a game changer if it's not too late for the Skyrim Era.

 

I've made the loop and it works, trying to do my best to follow your suggestions. I like best your idea to summarize the block chain, it's only a complicated block for one step then becomes oss. oss.module oss.actors oss.animations oss.stage. Very simple and easy to access information. I'm thinking of not having a "scene" category and just calling each scene by it's name in the xml <bST9Adore00></bST9Adore00> each one would have identical fields to a scene just they would be named their official id so I can get them with a dynamic string as the indexing doesn't seem to have any benefit over just calling it by the scene ID string and there's not a real way I can see to logically order them by number.

 

to hold global stuff like settings

 

osa.settings

osa.translation

osa.esg

 

I'm putting identity in it's own category since a lot of the time it might be shared by multiple actors so the script doesn't load multiple instances of the same XML. Also it will persist until the game is restarted so the players identity for example wouldn't have to be loaded over and over if they are having a wild night.

 

(osa.)  osid."package".

 

         (each instance of the spell in game get's it's own oss.)

(osa.) oss.animation

         oss.actors

         oss."animationname"

 

Also I've rewritten what remains of the Papyrus segment of the OSA script. I was very incompetent when I started writing it just making one thing happen at a time just for fun and so it had a lot of vestiges etc. left over that I had the chance to clean up/remove/improve I used proper clear (I hope) naming conventions and included hash text for what various things do. It's a very good suggestion you made, having your help has been amazing for the potential of this project, and in it's current scale I can't do it all on my in a reasonable time line so having it transparent to others will be good for the future and getting others involved, especially in terms of code, my code presence is most likely a detriment to the project lol.

 

I need to alter some things to adjust to the new load method but I can post maybe tomorrow. A few scene's connected up with UI on the new xml system powered by Actionscript+XML if you want to take a crack at fixing up the hack jobs I'm likely to do or if anyone wants to preview the new UI it's coming, I decided this adjustment to XML would be easier then I initially thought and am just getting it out of the way instead of redoing all scenes in JSON for a UI preview just to have to do it again in XML.

 

-----------------------------------------------------------

 

Also if anyone out there wants to expedite this process and is comfortable figuring out what the JSON stuff represents enough to help me redo the data entry by shifting it into XML data instead it would be appreciated. Not quite there yet but in the next few days. Also very sorry to anyone that has done substantial amount JSON, the switch to XML will be much more powerful and easier to figure out what everything does it most likely will not taken very long to move a scene over.

 

------------------------------------------------------------

 

Here's the first draft of the right side panel: It's not always open, only when you hit some Num Key.  Replaces the previous Num Keys for Randomizer, Warp, Travel, Lights, ESG, Equip Slots, Strip All, Devleoper etc. Also it's color is defined by the module so Developers you won't have to use OS Pink if that's not your thing.

 

 

tumblr_o3ccl1FU8x1ubnr1mo1_1280.jpg

Link to comment

 

 

This is going to be a game changer if it's not too late for the Skyrim Era.

 
Aha. But consider this: I'm pretty certain that Fallout 4 uses Scaleform also. So, that means that much of your code, being in Flash, will be re-usable in Fallout 4. I imagine it will be much easier to port that than the Papyrus-heavy version.
 
Will just have to wait for Fallout 4 versions of some of the dependencies (full featured F4SE mainly).
 

 

I've made the loop and it works, trying to do my best to follow your suggestions. I like best your idea to summarize the block chain, it's only a complicated block for one step then becomes oss. oss.module oss.actors oss.animations oss.stage. Very simple and easy to access information. I'm thinking of not having a "scene" category and just calling each scene by it's name in the xml <bST9Adore00></bST9Adore00> each one would have identical fields to a scene just they would be named their official id so I can get them with a dynamic string as the indexing doesn't seem to have any benefit over just calling it by the scene ID string and there's not a real way I can see to logically order them by number.

 

I would recommend not using the node names dynamically like that in XML and sticking with "scene". Think of the nodes as your framework/structure/skeleton. The node names should never be the actual content. Instead, have the scene name as an attribute:
 
<scene label="bST9Adore00"/>

The idea is that if the structure remains generic, you can later interchange it around into different systems to be processed. If you use one off node names you start to eliminate options and could create dead ends later that require going back and reworking the whole data structure. One off node names make the code that reads them strongly "coupled" to it. You want your code to have as loose a dependency on the data structure as possible. (This is MVC principles coming back. Keep the model separated from the views and controllers! The idea is that you could change controllers and views without the model being aware of it or needing updating itself.)

 

 

Also I've rewritten what remains of the Papyrus segment of the OSA script. I was very incompetent when I started writing it just making one thing happen at a time just for fun and so it had a lot of vestiges etc. left over that I had the chance to clean up/remove/improve I used proper clear (I hope) naming conventions and included hash text for what various things do. It's a very good suggestion you made, having your help has been amazing for the potential of this project, and in it's current scale I can't do it all on my in a reasonable time line so having it transparent to others will be good for the future and getting others involved, especially in terms of code, my code presence is most likely a detriment to the project lol.

 

Cool. I've been there many times. So, hoping to share lessons learned on other projects where I eventually hit a wall with code.

 

 

I need to alter some things to adjust to the new load method but I can post maybe tomorrow. A few scene's connected up with UI on the new xml system powered by Actionscript+XML if you want to take a crack at fixing up the hack jobs I'm likely to do or if anyone wants to preview the new UI it's coming, I decided this adjustment to XML would be easier then I initially thought and am just getting it out of the way instead of redoing all scenes in JSON for a UI preview just to have to do it again in XML.

 

Sure. I'll take a look when it's ready. Great that you took the bull by the horns and picked up the transition so quickly.

 

 

Here's the first draft of the right side panel: It's not always open, only when you hit some Num Key.  Replaces the previous Num Keys for Randomizer, Warp, Travel, Lights, ESG, Equip Slots, Strip All, Devleoper etc. Also it's color is defined by the module so Developers you won't have to use OS Pink if that's not your thing.

 

 

tumblr_o3ccl1FU8x1ubnr1mo1_1280.jpg

 

 

Looking sharp.

Link to comment

 

 

 

This is going to be a game changer if it's not too late for the Skyrim Era.

 
Aha. But consider this: I'm pretty certain that Fallout 4 uses Scaleform also. So, that means that much of your code, being in Flash, will be re-usable in Fallout 4. I imagine it will be much easier to port that than the Papyrus-heavy version.
 
Will just have to wait for Fallout 4 versions of some of the dependencies (full featured F4SE mainly).
 

 

I've made the loop and it works, trying to do my best to follow your suggestions. I like best your idea to summarize the block chain, it's only a complicated block for one step then becomes oss. oss.module oss.actors oss.animations oss.stage. Very simple and easy to access information. I'm thinking of not having a "scene" category and just calling each scene by it's name in the xml <bST9Adore00></bST9Adore00> each one would have identical fields to a scene just they would be named their official id so I can get them with a dynamic string as the indexing doesn't seem to have any benefit over just calling it by the scene ID string and there's not a real way I can see to logically order them by number.

 

I would recommend not using the node names dynamically like that in XML and sticking with "scene". Think of the nodes as your framework/structure/skeleton. The node names should never be the actual content. Instead, have the scene name as an attribute:
 
<scene label="bST9Adore00"/>

The idea is that if the structure remains generic, you can later interchange it around into different systems to be processed. If you use one off node names you start to eliminate options and could create dead ends later that require going back and reworking the whole data structure. One off node names make the code that reads them strongly "coupled" to it. You want your code to have as loose a dependency on the data structure as possible. (This is MVC principles coming back. Keep the model separated from the views and controllers! The idea is that you could change controllers and views without the model being aware of it or needing updating itself.)

 

 

Also I've rewritten what remains of the Papyrus segment of the OSA script. I was very incompetent when I started writing it just making one thing happen at a time just for fun and so it had a lot of vestiges etc. left over that I had the chance to clean up/remove/improve I used proper clear (I hope) naming conventions and included hash text for what various things do. It's a very good suggestion you made, having your help has been amazing for the potential of this project, and in it's current scale I can't do it all on my in a reasonable time line so having it transparent to others will be good for the future and getting others involved, especially in terms of code, my code presence is most likely a detriment to the project lol.

 

Cool. I've been there many times. So, hoping to share lessons learned on other projects where I eventually hit a wall with code.

 

 

I need to alter some things to adjust to the new load method but I can post maybe tomorrow. A few scene's connected up with UI on the new xml system powered by Actionscript+XML if you want to take a crack at fixing up the hack jobs I'm likely to do or if anyone wants to preview the new UI it's coming, I decided this adjustment to XML would be easier then I initially thought and am just getting it out of the way instead of redoing all scenes in JSON for a UI preview just to have to do it again in XML.

 

Sure. I'll take a look when it's ready. Great that you took the bull by the horns and picked up the transition so quickly.

 

 

Here's the first draft of the right side panel: It's not always open, only when you hit some Num Key.  Replaces the previous Num Keys for Randomizer, Warp, Travel, Lights, ESG, Equip Slots, Strip All, Devleoper etc. Also it's color is defined by the module so Developers you won't have to use OS Pink if that's not your thing.

 

 

tumblr_o3ccl1FU8x1ubnr1mo1_1280.jpg

 

 

Looking sharp.

 

 

 Me likey!!

 

Link to comment

It's astonnishing how much progress has been made here. I will give hats off to all of you involved in this project, as this is the one of the most revolutionary mods for the Skyrim, taking in consideration quality and contents it provides, as well as constant and determined workflow you guys manage to keep at daily level. I am proud to say that when this project finishes I will gladly donate to the CEO and pipdude.

 

Thank you for your time, passion and work you are doing for the community. 

Link to comment

Really liking this mod so far, easily the best sex sim that Skyrim has had so far in terms of sheer quality and polish.

 

One problem I currently have with it though on version 1.063, is that the Positioning Mode shown in Advanced Controls doesn't seem to work. It puts me in the freecam mode, but none of the hotkeys actually change the coordinates of the actors. I'm playing as a female Dark Elf with Nord males as my test partners if that helps any, and the positioning of her hand and mouth in oral scenes don't align properly with the SoS penis, but only by a little bit. The angle is definitely correct, but she is just a little too low for anything to line up. I tried adjusting her height, since she is usually rather short, but changing it to the same as the Nord male didn't help too much.

 

I also noticed some alightment issues with the other animations too, which would all be solved if I could only change the coordinates. Is this feature disabled or am I not pressing the right keys?

 

Edit: Had a question about the teeth appearing improperly, but figured out the solution for myself. Just had to reinstall my teeth mods. :)

Link to comment

 

 

 

Updated version of XMLParser.as attached.

 

A. Improved the toXML function. Now generates XML strings with consistent node ordering and proper whitespace for readability.

B. Added a flag to toXML to allow generating the string in compressed mode (leaving no whitespace) to make the file as small as possible (at the expense of readability).

 

To use compressed mode:

// Set the 2nd parameter to 'true' on toXML to generate XML string with no whitespace:
var parser = new XMLParser();
var xmlString = parser.toXML(xmlDataObject, true);

-------------------------------------------

 

I uncovered a new issue. For some reason, I am only able to modify an XML file once. After the first modification, it just doesn't seem to record further changes.

 

I'm double-checking the Flash. But, this might be some kind of issue with MiscUtil.WriteToFile. Maybe it leaves a write stream open, blocking new attempts to write?

XMLParserV4.zip

Link to comment

 

 

 

Thanks I've got it in all is working good!

 

Also noted your strong objection to my data plan and your solution is perfect. Much cleaner! Here's my attempt at setting it up: 

 

o is a temp abbreviation of the scene storage and I'm adding .ix to it which holds the reference index.   ix.r = "bst9Adore".2 for example.

 

o.ix = new Object
for (var i=0; i < o.scene.length; i++) {
 
o.ix[o.scene.id] = new Object
o.ix[o.scene.id].r = i
 
//trace("Scene Name: "+o.scene.id)
//trace("Index #: "+o.ix[o.scene.id].r)
 
}

 

I'm so happy about this XML solution. Since the swf storage only lasts one game session I'm just letting it perm store data that it loads and it's checking if it has it before pulling more information, it seems like the swf is handling the xml .loads with ease so it most likely doesn't matter much but I still think it's cool.

 

I've got the papyrus side handled in a few functions. Basically each actor's spell just gathers all the papyrus info up as fast as possible and puts it into xml then sends it to the UI. Like this: 

 

string function xmlScaleBelly(actor zAct) Global
Return "<node id=\"belly\" origin=\""+NetImmerse.GetNodeScale(zAct, "NPC Belly", False)+"\" name=\"NPC Belly\"/>"
EndFunction
 
a bunch of these all get wrapped in a <scale></scale> combined with similar functions for name gender race etc. wraps it all under <actor> then sends it to the UI which just sticks it on it's data tree and that's the end of the papyrus outside of a few events it waits for, voice, expression, modifier, phoneme, scale, shader, animation.
 
----------------------
 
The <scene> block is pretty thick and maybe it can be compacted quite a bit but there's definitely a pause still when doing a huge module, much better then before since it's not a crash, it's the identical time in game it takes debug mode in flash to load on very large modules. I have do more precise tests and I tend to over-future proof things but I might have it load scene family as opposed to the entire module at once. In the case that a very large module was made it would freeze the game for a couple seconds on loading (for the first time) divided up into families there would be no hard limit, albeit the limit before a load delay is most likely very high already.
 
 

 

 

Is there a way to hide that    IEI Talk    Fione and targeting cursor during 0sex?

 

I want it gone too, I've tried a bunch of things to disable it but no luck so far, mainly I can get the script to stop it but if it's on screen once it's stopped stays, so you'd have to somehow take the cross hairs off then back on at that point which is impossible.

 

Pipdude might know, if it is possible through UI it's most likely straightforward. I imagine it is a part of the UI and we can toggle it's visibility. Now that I think about it being able to toggle the stamina bar, compass, crosshairs, and |E| to talk would be best during a scene, as you can't TM as much with the UI since I believe TM would hide the osa ui also.

Link to comment

Is there a way to hide that    IEI Talk    Fione and targeting cursor during 0sex?

 

 

 

I want it gone too, I've tried a bunch of things to disable it but no luck so far, mainly I can get the script to stop it but if it's on screen once it's stopped stays, so you'd have to somehow take the cross hairs off then back on at that point which is impossible.

 

Pipdude might know, if it is possible through UI it's most likely straightforward. I imagine it is a part of the UI and we can toggle it's visibility. Now that I think about it being able to toggle the stamina bar, compass, crosshairs, and |E| to talk would be best during a scene, as you can't TM as much with the UI since I believe TM would hide the osa ui also.

 

 

In Flash:

_root.HUDMovieBaseInstance.Crosshair._visible = false;

In Papyrus should be:

UI.SetBool(HUD_MENU, "_root.HUDMovieBaseInstance.Crosshair._visible", false)

The vanilla UI files are available here: http://www.nexusmods.com/skyrim/mods/216/

 

The one with the crosshair is in the second downloadable "GFX" files: hudmenu.swf.fla

 

Not sure about the "E Talk" part. But, that is probably within the same hudmenu.swf file. You can either figure out the path to that element and turn its visibility off the same way or turn off visibility of one of its parent elements and turn off a group of items at a time. In fact, "_root.HUDMovieBaseInstance._visible = false;" may be what you are after as it turns off the compass, crosshair and a bunch of back-button, dialogue type fields.

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   1 member

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue. For more information, see our Privacy Policy & Terms of Use