OSex+ The Greatest Virtual Sex Ever

[LucasHM]

 

 

Is there a way to integrate this with SexLab or have the same animations for SexLab?

 

Not really. This mod is like sexlab its own framework but made in a different way. They both handle animations differently. While this mod has seamless transitions, sexlab jumps from stage to stage.

But sexlab mods could be upgraded to start and use 0sex animations.

 

 

Okay, is there a way to have a dialogue system like SexLab?

 

Not yet.

this is an  awsome thing you have here and i am having fun playing with it. but i have to know what are the two attached files at the bottem of the main post for? i just got the mod from the nexues site

Updated version of 1.06, you can find the latest version on this same topic, at the 65 th page

[Bounty228]

 

 

Some Gifs featuring my forum avatar going nuts, Futa F/F

 

Oral in the spoiler: (Big Gifs in this one)

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

BJ

 

 

 

 

 

 

 

 

 

Standing O

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Missionary

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Misc

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

What's your schlong Config? o.O

 

It seems to go perfectly with the animations.

[pipdude]

 

I went through everything more in depth and have a good idea now how to go about things plus learned a little about XML. I'm making a XML file for a template that has a full scene with all needed fields that 0Sex uses at the moment. I'm still figuring things out but I'll most likely be able to post it tomorrow, whenever you have time and if you want, if you could check it out and give me ideas to improve the structure.

 

If you're interested in getting even more hands on I would love it. Once 1.07 is up I'm going to start assembling a scene around XML just focusing on 1 transition back and forth to get the system working. If you'd like to work on it with me maybe we could set up some way to share files. No pressure of course you've been so awesome for this project and helpful already. I'd need to be able to comprehend the things that are involved so the project can continue if you have less time in the future etc. so I could keep going on my own but you expertise would be great as always.

 

Sure to both. Let me know when you have the xml ready and what makes sense to collab on and I'll take a look.

 

 

A main key to OSA that I'm seeing would most likely have to exist still in Actionscript to an extent of differentiating scenes in the case that multiple are running. I use three levels "passwords" to differentiate. I have a feeling something like this will be needed for the naming convention of variables in the actionscript still, and the tiers for communicating with papyrus through events.

 

I'm not sure if "passwords" are needed for the events. Why not simply an id number corresponding with whichever scene or actor they need to apply to?

 

I can see a system like that being helpful (if not necessary) for the events. But, I would encourage getting away from that for naming conventions/variables. More on that below.

 

 

The gist of it is the MCM menu has a SceneNumber property that it adds +1 to everytime you start a scene and resets back to 0 at 120. When the scene is cast the MCM puts the dom in a special faction and sets his/her rank to the scenenumber. The spell gets the scene number from looking at the rank and this is how the MCM communicates to the spell what 0SA scene was cast. The script then uses 2 passwords to protect it's sendmodevents from other instances of OSA from picking it up.  SceneNumber+99 is the password for things that the main script needs to read but the sub spell that actors get an actor specific password which is their SceneNumber+99+ActorNumber.  

 

I haven't built an MCM before. Isn't that typically just for allowing users to make some setting adjustments? I'm not following why the MCM needs to be so integrated with the management of scenes?

 

Are you familiar with the concept of Model View Controller (MVC)?

 

 

I don't think the 3 tier would be required in the actionscript but I think it would still have to be there for communicating with papyrus. In actionscript it seems like maintaining the scene number as a prefix to all properties might be best unless XML can wrap the entire data for everything involved in the scene into one big tree.

 

Old habits die hard.  But, since you're at a transition point, I would encourage you to move away from your familiar approach of dynamically creating property names and more toward Object Oriented Programming. Essentially, your coding goals are already taking you in that direction. You're trying to add depth and dimension to your data with these long, complicated property names, etc. But, there are easier ways to accomplish that depth. Trust. Once you start seeing these patterns differently, you will never go back and you'll say "now I know why Pipdude kept repeating himself, griping about Papyrus' limitations."

 

There are entire books on this subject. But, I'd like to try explaining to some degree with a simple example:

 

The current way:

this["scene" + i + "actor" + z + "hand"] = 0;
this["scene" + i + "actor" + z + "foot"] = 1;
this["scene" + i + "actor" + z + "arm"] = 2;
this["scene" + i + "actor" + z + "leg"] = 3;
this["scene" + i + "actor" + z + "elbow"] = 4;

Object Oriented Programming way:

actor = {hand:0, foot:1, arm:2, leg:3, elbow:4};
scene.push(actor);

The two accomplish roughly the same things. But, the OOP way is easier to read/write and also opens up options that you don't have with the earlier way. For example, you can move groups of data around that belong to each other into new lists.

 

If you do like the book route, this is a very good one that covers the basic concepts: http://www.amazon.com/Essential-ActionScript-2-0-Colin-Moock/dp/0596006527

 

You can skim through that book and probably get the idea in a day or two really.

 

 

Long ramble on that sorry but it leads me to the question that. The actionscript I use to clear out buttons works nicely I think to delete all the extra on the nav panel.

 

this:

 

 

for (var prop in NavPanelCase) {

  if (NavPanelCase[prop] instanceof MovieClip) {

  NavPanelCase[prop].removeMovieClip();

  }

}

 

I'm curious if when setting up properties. Let's say there are 2 0Sex scenes happening at once. Using something like the above script but for variables instead of MovieClips. Could all the incoming data be placed in an object which i can delete it and all it's "data children" from. Let's say the script needs 20 variables to do everything it needs, so there would be 40 variables in total happening with 2 scenes at once (20 for each scene). It would be nice if when a scene ends the script could dump the 20 variables for it once it ended.

 

I can roughly see how it might be possible but if it is I'd have make on object that extends my root, like how the movieclips are attached to "NavPanelCase", An object meant to be the Case for an entire scene's variables that I can delete all at once?

 

Kind of like this:

this.SceneData.SceneVariable1

this.SceneData.SceneVariable2

this.SceneData.SceneVariable3

 

on scene conclusion

 

FunctionToDeleteAllDataChildren.this["S"+SceneNumber+"_SceneData

 

 

Yes. This is a good case in point for how OOP will help you. Putting variables on the root is asking for a big mess, functions to affect variables unexpectedly, etc. Instead, they should be organized into logical containers (Objects created with {} or Arrays created with []) and contained/defined by a class rather than placed on the MovieClip.

 

In this case, just to delete those variables you would need to create a custom function that iterates through those specifically and deletes them one by one. Had the data been set up like this instead:

sceneData = {};
sceneData.variable1 = 50;
sceneData.variable2 = 100;
sceneData.variable3 = 150;

Then you could clear those variables with one line:

sceneData = {};

For important and re-used data/concepts you could go further and define something like "sceneData" more concretely by giving it its own class. Then you could define defaults, make custom calculations and reports that live on instances of it. Instead of just erasing it entirely, you could have initialize() that would set defaults, clean up, etc. Technically, using classes to define all/most parts is what OOP is. But, getting familiar with the patterns used with Arrays and Objects is a similar fundamental.

[Dexter146]

kinky , u mean it's about the root drive..???.?What it's about?Specifics?

 

ps : the v 1.063 works well but i deal with the 1.07b version now....

[Kinky]

kinky , u mean it's about the root drive..???.?What it's about?Specifics?

 

CEO wrote this in install instructions and its pretty hard to miss considering font size:

 

"

MEGA IMPORTANT 0SEX WILL NOT WORK IF YOU DO NOT DO THIS:

 

To get people used to "Equiping" scenes in 0SA I will be releasing from here on out 0Sex not prebound in the the MCM. You must go to the first page of the 0SA MCM. Pick an Ability Slot (1 through 12) Type in "0SEX" (The 0 is a zero) into the first text entry line for that ability then above that select a key that will cast the spell. This is how you will equip other developers scenes also. "

[Kinky]

 

I agree that moving to OOP is better. It does take time to move to that though since it requires that you think bit different while writing code. I wish more books would teach OOP from start. Usualy the ones i run through about C++ teach you OOP when you are already used to coding "the wrong way" (non-OOP way).

 

 

[tvsct456]

 

 

I agree that moving to OOP is better. It does take time to move to that though since it requires that you think bit different while writing code. I wish more books would teach OOP from start. Usualy the ones i run through about C++ teach you OOP when you are already used to coding "the wrong way" (non-OOP way).

 

 

 

The book Game Programming Patterns did very good jobs about OOP. You can find a free-version in the author's blog:

http://gameprogrammingpatterns.com/contents.html

[pipdude]

 

 

I agree that moving to OOP is better. It does take time to move to that though since it requires that you think bit different while writing code. I wish more books would teach OOP from start. Usualy the ones i run through about C++ teach you OOP when you are already used to coding "the wrong way" (non-OOP way).

 

 

 

 

Yeah. Sometimes it's hard to unlearn patterns that we've trained our minds to rely on.

[meme supreme]

Yo, the latest futa gallery that CEO posted has some really good hair physics going on. The textures are excellent too. Does anyone know where he got that or is it a personal mod?

It's seriously telling that I looked at his post and the first thing I took away from it is "yo, that's some pretty stylin' hair."

[AnubiSs2167]

Excelent gallery CE0. It reminded me, you had a method to make futa shlongs alight better using nifskope. How does it work from technical standpoint? Does it move shlong base down to mach male shlong? Wonder if it would also fix futa for Sexlab.

[Bounty228]

I'm learning more about animating reading your PDF's than I do any other tutorial.

[CEO 0S]

Excelent gallery CE0. It reminded me, you had a method to make futa shlongs alight better using nifskope. How does it work from technical standpoint? Does it move shlong base down to mach male shlong? Wonder if it would also fix futa for Sexlab.

 

I don't fully understand how it works just how to tweak it. The SoS shlongs have bones built into the nif but it also references the bones in your skeleton that you are equipping it on. It's called a sub-graph I think. The schlong has extra data on it which points to a certain sub graph. I think this is how the schlong can be animated while the body is being animated at the same time. For example the actor can  be playing an animation while their schlong i shaving a specific erection animation played at the same time.

 

I believe the skeleton has one behavior file that gets output but also the subgraph can have one too which SoS comes with. The male SoS and female SoS come with different sub graphs to make it shape a little better considering the groin of each gender is in a different spot but regardless of this shape it's still bound to the skeleton so having roughly the same origin. The female groin is higher so the sub graph keeps the bones a little higher.

 

If you leave each using their different sub graphs then the two genders will always having different schlong placement during the same animation. My fix makes the female SoS use the male sub graph so the bones get placed in the exact same spot as male uses. I believe papyrus could potentially change this so the fix isn't needed by assigning what graph to use but I haven't got around to fully checking it out.

 

I hope this helps and sorry if I'm not clear, I only kind of understand the tweak but not fully what's happening.

[Pokerit]

Am I missing something here? I don't know how to start the animation. I DL'd the newest alpha and I dont see any sort of hotkeys or anything? Am I supposed to install it on top of the version in nexus?

[AnubiSs2167]

Thanks CE0, Its exactly what im looking for then. If i understood right it should fix the misaligment in Sexlab aswell. Was actually in the middle of wrestling with profiles and re aligning every animation for my futa follower. Now i need to find your tutorial and try it myself.

edit: Worked like a charm. The mesh is abit stretched but it hell beats realigining everything. Thanks again CE0 you magnificient sex wizard!

[CEO 0S]

 

 

 

 

Thanks Pipdude! No I don't know what MVC is. The MCM's purpose outside of config is to hold the key registration for starting scenes and be the place where different developers scenes can be bound to keys. It could be replaced by the UI entirely but most likely would still be needed in some form as a persistent quest that holds key press data that can hold some information as to what developers scene is assigned to what key. Or in it's most minimal state just have the keypress registration I imagine for initiating a scene.

 

I'll try to show what I mean overall. This would be my rough understanding of how to have the UI control everything. In this papyrus would handle some of the game stuff right at the start of the scene like disabling movement, putting away weapons. Outside of that all it would do would be listen for key presses to tell the UI about or receive events to modify expressions or play animations or sounds:

 

 

The mini spell on actors + password combo was my solution to communicating to just one instance of the spell on the actor I wanted to adjust. It could all live in 1 I think but papyrus might put that script on a time out if it feels it's being to awesome where as if it's split up I find it needs no IF checks to process the events and tricks papyrus to think it's not all one super script. In an extreme example if 9 OSA scenes were running at once if the entirety of events were handled just in the persistent quest script receiving events  Papyrus would most likely stall out a singular script constantly but the two tier spell system let's it expand modularly doing more papyrus as needed without papyrus flagging it.

 

 

I see now what you mean by OOP and did some research. If I'm understanding correctly it seems I would need to make .as  classes for each tier of information and create NEW instances of them as needed. I'd most likely trip up on the syntax for a while but to see if I'm understanding correctly. (Just making names up for a theoretical set up at a glance now.): 

 

<OStage>  < Main Shell for the scene.

     <OStageType>  <-- Heavy scene like OSex or Combat etc.

          <OModule>      <------------ Entire Developer scene (Like OSex)

                   <OScene>      <--------------Specific Looping scene in a module the user is on like some DoggyStyle Scene.

                  </OScene>

          </OModule>

     </OStageType>

<OActor>

       <Details>

       <Stats>

           <BodyStats>

           <EmotionStats>

           <SorenessStats>

            <Speeds>

         </Stats>

        <Record>

            <SexRecord>

        </Record>

        <Identity>

        </identity> 

</OActor>

</OStage>

 

In something like this it would basically be each instance creating / holding the relative records needed per instances by a chain of .as?

 

Or in the case of a button which I guess instances of would get created under OScene

 

<NavButton>

      <Destination Anim = "MissionaryToDoggy" Length = 2 >

       <Information  = "Flip %N2 Over" >

              <Graphics>

                      <Graphic Male  base = "SexyMBase" overlay = "SexyMOverlay" icon = "SexyMIcon">

                      <Graphic Famale  base = "SexyMBase" overlay = "SexyMOverlay" icon = "SexyMIcon">

               </Graphics>

</NavButton>

[pipdude]

 

 

Thanks Pipdude! No I don't know what MVC is. The MCM's purpose outside of config is to hold the key registration for starting scenes and be the place where different developers scenes can be bound to keys. It could be replaced by the UI entirely but most likely would still be needed in some form as a persistent quest that holds key press data that can hold some information as to what developers scene is assigned to what key. Or in it's most minimal state just have the keypress registration I imagine for initiating a scene.

 

Ok. MVC is Model View Controller, a commonly used design pattern. It essentially divides a program into distinct areas. The model is the data. The controller is the code that manipulates the data. The view is the code that shows what is currently in the data. Typically, programs have multiple views showing the data in different ways or different parts of the data. The controller typically handles user input and the data/model is kind of self explanatory.

 

I brought it up because it felt like the MCM, in this case, sort of steps in out of the blue to handle a few tasks. But, otherwise doesn't fit into a clear category of MVC. But, as you describe it. Maybe MCM genuinely is a kind of extension of the Controller.

 

Anyway, MVC is sort of a useful ideal to strive for, knowing that it is unlikely possible to make a program adhere to it absolutely.

 

 

I'll try to show what I mean overall. This would be my rough understanding of how to have the UI control everything. In this papyrus would handle some of the game stuff right at the start of the scene like disabling movement, putting away weapons. Outside of that all it would do would be listen for key presses to tell the UI about or receive events to modify expressions or play animations or sounds:

 

 

The mini spell on actors + password combo was my solution to communicating to just one instance of the spell on the actor I wanted to adjust. It could all live in 1 I think but papyrus might put that script on a time out if it feels it's being to awesome where as if it's split up I find it needs no IF checks to process the events and tricks papyrus to think it's not all one super script.

 

I like it. That is generally what I was thinking. I'm wondering what is gained by running everything through spells rather than through the Quest script? It sounds like the MCM sort of acts like the Perm Quest script. But, what if there was a separate Perm Quest script instead of the spells that handles all Papyrus side logic?

 

 

I see now what you mean by OOP and did some research. If I'm understanding correctly it seems I would need to make .as  classes for each tier of information and create NEW instances of them as needed. I'd most likely trip up on the syntax for a while but to see if I'm understanding correctly. (Just making names up for a theoretical set up at a glance now.): 

 

<OStage>  < Main Shell for the scene.

     <OStageType>  <-- Heavy scene like OSex or Combat etc.

          <OModule>      <------------ Entire Developer scene (Like OSex)

                   <OScene>      <--------------Specific Looping scene in a module the user is on.

                  </OScene>

          </OModule>

     </OStageType>

<OActor>

       <Details>

       <Stats>

           <BodyStats>

           <EmotionStats>

           <SorenessStats>

            <Speeds>

         </Stats>

        <Record>

            <SexRecord>

        </Record>

        <Identity>

        </identity> 

</OActor>

</OStage>

 

In something like this it would basically be each instance creating / holding the relative records needed per instances by a chain of .as?

 

Yes. That is generally right. But, an OOP scheme is considered more or less "granular" depending on how extensively it turns every part into its own class. There is a point of granularity where more classes make it more confusing and less useful. I think that what you're picturing might be too many classes for everything. It's ok to put code for multiple things onto one class when they are closely related. I'm picturing only a few classes for the major parts like: Actor, Scene, Animation. Actually, what I was getting at is even more "OOP-light" than that: simply using Objects and Arrays to wrap data into useful groups instead of trying to group them via variable names. Setting up classes for every type of data will probably just come naturally later once you start seeing data via Objects more.

 

It's a little tough to follow what you are going for in the above xml. By itself, it looks sensible. But, I'm thrown off by the labels you added. For example, OStageType sounds like a node that would contain data telling us what type of OStage it is. But, you describe OstageType itself as a heavy scene. Couldn't a non-heavy scene be a type? Here we're really just looking at semantics. So, there is not right or wrong answer. It's just not clear to me what data these nodes would contain.

 

Side note: looks like you are missing a close node for a few nodes like <Details>. You can close it with "/>" like <Details/> or of course with a full close node like </Details>. You will get errors/crashing from the parser if you don't close every node.

 

 

Or in the case of a button which I guess instances of would get created under OScene

 

<NavButton>

      <Destination Anim = "MissionaryToDoggy" Length = 2 >

       <Information  = "Flip %N2 Over" >

              <Graphics>

                      <Graphic Male  base = "SexyMBase" overlay = "SexyMOverlay" icon = "SexyMIcon">

                      <Graphic Famale  base = "SexyMBase" overlay = "SexyMOverlay" icon = "SexyMIcon">

               </Graphics>

</NavButton>

 

 

You can create classes for your custom buttons. That can be useful in some cases. But, might be overkill in this case. Personally, I would just put the button and nav handling code in the main class that Papyrus talks directly to. I would make custom classes for the major parts as mentioned above like Actor, Scene and so on. It would be nice to build those classes in a way that you could give them a very basic set of commands like setEyes, setEmotion, playAnimation, etc. and the code on the Actor class would intelligently know how to accomplish that, including communicating whatever is necessary to Papyrus.

 

In your xml here there are a few issues:

 

You need quote marks around 2. It needs to parse all attributes as strings. Flash can handle switching those to numbers later. But, it wont parse correctly without the quote marks (double quote marks specifically).

 

You have spaces between Male base and Female base. The attribute names can't contain spaces. Will throw the parser off.

 

All in all, I think you get it. Sorry if I'm dropping a bunch of philosophical mumbo jumbo. Might be best to simply collab and work through the code. These concepts have a way of teaching themselves to people over time because they just prove to be useful.

[dhaedra]

@CEO 0s

 

I have been using a mod that adds wigs to Followers so they can have KS Hairdos with HDT physics as well as a Main Character. The wigs go into a helmet or hair slot- slot# 31. You can check out this mod on Nexus #73137.

 

Could you allow 0sex to let us select slots not to be removed during stripping? Apologies if I missed something and your mod already allows this. I checked it pretty thoroughly and can't see how I can prevent un-equipping a designated slot.

 

Thanks for looking into this. 

[CEO 0S]

 

 

Hi PipDude,

Awesome thanks! In terms of singular script or a few spell scripts it could go either way. I'll try it both a few reasons I think spells might be better:

 

-It's easy to send events to specific actors without needing checks to see which actor should be effected. sendmodevent through skse.actionscript is weaker compared to the modevent skse adds in papyrus so maybe we might start needing if checks if we can't push enough information through the event otherwise.

-Papyrus will pause scripts that it feels are having to much presence to let other scripts do their thing but if it's divided up then it doesn't notice them as being a problem. 

-We might need to assign properties. I'm not sure this is the case but the impact sounds in doggy style I felt responded better when I precasted them as sounds as opposed to casting them as sounds from forms on the moment the sound was to be played. In cases like this we don't have to worry about persistent properties being made as the spell will dump it all and kill any looping events that might survived but that won't be as big a problem with the UI.

-One shortcoming I'm seeing with the UI management is if the player saves and quits while they or other actors are in an 0Sex scene. On return the actors might be semi stuck since the UI would lose the XML data it assembled for that moment in the scene. There might be ways around it but with spells there's a sure fire way we can clean it out on game load. If the player is involved the actors need to be locked down in 5 or 6 different ways to not repel each other in certain situations so it's possible after a load the player might get screwed otherwise. (Might be ways around this though)

-Last would be animation events. If we can't get the timing exact in Actionscript we'd have to use animationevents instead and high speed impact events it gets clogged really fast and there's no way that I know of handling multiple animationevents without multiple IF checks if only one script listening for them. With split scripts each actor can listen only for their own events.

 

I'm not set in stone, you're prob right on this I'll try both and see.

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

 

Now that I see this plan doesn't seem daunting at all. We could feasibly get this set up in no time in a simple state. The XML will be much easier for developers to make on their own as they will not have to reference keys to see what every 0 represents etc and they can be organized in a way that makes more sense.

 

Update: Progress is going good, I'm able to work with the XML very easily thanks to your awesome script and this is so much easier then the fucked up way I was exploding stuff and trying to organize data. There's so much more power the script could have now and I think developers will find the XML far less intimidating then the previous JSON texts since everything is spelled out clearly. It's a pretty thick block of XML per scene OSex would need close to 100 entries (and more for the future) so hopefully that doesn't smash miscutil.

 

I have a mock up in place in game that loads and sends the scene XML to the ui, gathers all the actor information needed and sends each actor to the UI as separate XML entrys, Then locks the actors in place and begins an animation. I need to hook the flash side making it loosely play out a scene but the mock is close, now that you explained it to me this transition to XML isn't going to be bad at all and the benefits are huge. I'll post it as soon the mock up is full circle. Would be especially curious in your ideas to assemble the data, for example as it comes into the UI how does it place and group the xmls together best and thoughts on any of the hack jobs I might have done so far since this is the foundation and further ideas etc.

 

Misc Util comes with the disclaimer: idk if they mean large as in large or LARGE

; Read string from file. Do not read large files!

string function ReadFromFile(string fileName) global native

 

I can send up one fairly large XML block instantly no problem in my current version. A module could get up to 100s of scenes relatively quickly so I'll do some tests multiplying the xml block by 1000 and see what happens.

 

 

 

 

a very basic set of commands like setEyes, setEmotion, playAnimation, etc. and the code on the Actor class would intelligently know how to accomplish that, including communicating whatever is necessary to Papyrus.

 

 

 

This sounds awesome I like this direction and see exactly what you mean. I'll definitely need your help in making it work, I get what you mean how to do it but I would struggle a lot figuring the steps and syntax for it all to come together. Sounds very elegant and efficient.

 

@CEO 0s

 

 

 

Hi Dhaedra,

If you are on 1.07C  the ESG menu you can enter in that slot in the "Exlude" category and it should not remove that slot when doing quick strip. I doubt many have tried it so potentially it has bugs but I haven't heard of it having problems yet. Prior to 1.07C I didn't get to setting up that functionality yet.

[Kinky]

Am I missing something here? I don't know how to start the animation. I DL'd the newest alpha and I dont see any sort of hotkeys or anything? Am I supposed to install it on top of the version in nexus?

No. You need to do clean save then install 1.07c. Also read install instructions.

[Kinky]

CEO i dont like to sidetrack you especialy since i can't wait to try the whole UI thing, but check PM.

[CEO 0S]

CEO i dont like to sidetrack you especialy since i can't wait to try the whole UI thing, but check PM.

 

Thanks Kinky for trying, I'll figure it out eventually but I don't know how to make the export text document. I can make a chain of bones and skin them etc and animate with them but there's some order they have to be written in a text document, to translate the animation to a Skyrim behavior file. It's a source file thing which isn't provided with said mod. I'll figure it out eventually most likely if I focus on it when I have time I can put the pieces together.

 

Also F that guy.

[Kinky]

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 ).

[CEO 0S]

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 ).

 

Really appreciate you trying, I think Osex tentacles would be insane and prob a lot of people would have a good time with it, we'll figure it out!

[pipdude]

 

 

Hi PipDude,

 

Awesome thanks! In terms of singular script or a few spell scripts it could go either way. I'll try it both a few reasons I think spells might be better:

 

-It's easy to send events to specific actors without needing checks to see which actor should be effected. sendmodevent through skse.actionscript is weaker compared to the modevent skse adds in papyrus so maybe we might start needing if checks if we can't push enough information through the event otherwise.

-Papyrus will pause scripts that it feels are having to much presence to let other scripts do their thing but if it's divided up then it doesn't notice them as being a problem. 

-We might need to assign properties. I'm not sure this is the case but the impact sounds in doggy style I felt responded better when I precasted them as sounds as opposed to casting them as sounds from forms on the moment the sound was to be played. In cases like this we don't have to worry about persistent properties being made as the spell will dump it all and kill any looping events that might survived but that won't be as big a problem with the UI.

-One shortcoming I'm seeing with the UI management is if the player saves while they or other actors are in an 0Sex scene. On return the actors might be semi stuck since the UI would lose the XML data it assembled for that moment in the scene. There might be ways around it but with spells there's a sure fire way we can clean it out on game load. If the player is involved the actors need to be locked down in 5 or 6 different ways to not repel each other in certain situations so it's possible after a load the player might get screwed otherwise. (Might be ways around this though)

-Last would be animation events. If we can't get the timing exact in Actionscript we'd have to use animationevents instead and high speed impact events it gets clogged really fast and there's no way that I know of handling multiple animationevents without multiple IF checks if only one script listening for them. With split scripts each actor can listen only for their own events.

 

I'm not set in stone, you're prob right on this I'll try both and see.

 

Those sound like solid reasons for the spell system. I don't really know as I'm not nearly as familiar as you are with the nuances of how Papyrus handles these types of animation demands. I just figured it's a question worth asking since, when possible, fewer moving parts are often better than more.

 

 

Now that I see this plan doesn't seem daunting at all. We could feasibly get this set up in no time in a simple state. The XML will be much easier for developers to make on their own as they will not have to reference keys to see what every 0 represents etc and they can be organized in a way that makes more sense.

 

Update: Progress is going good, I'm able to work with the XML very easily thanks to your awesome script and this is so much easier then the fucked up way I was exploding stuff and trying to organize data. There's so much more power the script could have now and I think developers will find the XML far less intimidating then the previous JSON texts since everything is spelled out clearly. It's a pretty thick block of XML per scene OSex would need close to 100 entries (and more for the future) so hopefully that doesn't smash miscutil.

 

Cool. Great to hear that it's coming along. I agree that XML will be more approachable for modders. With descriptive node names it becomes nearly self explanatory.

 

 

I have a mock up in place in game that loads and sends the scene XML to the ui, gathers all the actor information needed and sends each actor to the UI as separate XML entrys, Then locks the actors in place and begins an animation. I need to hook the flash side making it loosely play out a scene but the mock is close, now that you explained it to me this transition to XML isn't going to be bad at all and the benefits are huge. I'll post it as soon the mock up is full circle. Would be especially curious in your ideas to assemble the data, for example as it comes into the UI how does it place and group the xmls together best and thoughts on any of the hack jobs I might have done so far since this is the foundation and further ideas etc.

 

I would think, for testing first versions, you would just have a few class level properties to hold the data expected to come in. For data that is within the larger data load that gets referenced often, I would probably pull that out into its own property to shorten references. ie. I would probably end up with a few properties like this: gameSettings, animationData, currentAnimation, domActor, subActor.

gameSettings = yourXMLDataObject.topLevel[0].settings[0];
animationData = yourXMLDataObject.topLevel[0].animations[0];

For later, more advanced versions, I would send those pieces of data to custom classes. So, there would be an Actor class and probably function like "initialize" that accepts the actor object from xml and gets everything in place for that actor to take commands. Then the main class would have arrays of all ongoing events so that all could be affected, checked on, etc.

var newActor = new Actor();
newActor.initialize(actorData.actor[0]);

var newScene = new Scene();
newScene.initialize(sceneData.scene[0]);

newScene.addActor(newActor);

actorStack.push(actor);
sceneStack.push(scene);

 

 

Misc Util comes with the disclaimer: idk if they mean large as in large or LARGE

; Read string from file. Do not read large files!

string function ReadFromFile(string fileName) global native

 

I can send up one fairly large XML block instantly no problem in my current version. A module could get up to 100s of scenes relatively quickly so I'll do some tests multiplying the xml block by 1000 and see what happens.

 

Yeah. I saw that. I was thinking that it was referring to trying to load jpegs or something. But, it's worth testing. Making a quick large xml should do it. I'm curious how that went?

 

 

 

a very basic set of commands like setEyes, setEmotion, playAnimation, etc. and the code on the Actor class would intelligently know how to accomplish that, including communicating whatever is necessary to Papyrus.

 

This sounds awesome I like this direction and see exactly what you mean. I'll definitely need your help in making it work, I get what you mean how to do it but I would struggle a lot figuring the steps and syntax for it all to come together. Sounds very elegant and efficient.

 

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.

[lampuiho]

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.