Jump to content

Recommended Posts

Even after 1.7, i still get the flickering schlong but no more "HDT.xml are conflicting" message, weird.

 

What's your fps? If I get any fps above 60 the schlong starts flickering. Somehow I get above 60 fps even with fps locked at times, but that's not related to this mod :P

 

Link to comment

 

Even after 1.7, i still get the flickering schlong but no more "HDT.xml are conflicting" message, weird.

 

What's your fps? If I get any fps above 60 the schlong starts flickering. Somehow I get above 60 fps even with fps locked at times, but that's not related to this mod :P

 

 

 

Turns out that was it, for some fucking reason my fps limiter's values all turned to 0. Everything's working perfectly now.

Link to comment

I noticed some visual glitches with the near-erect custom template and took a look at setup. I noticed that the near-erect custom template moves the gen1 shape up to the plane of genbase when the gen1 bone should remain in the same position. The non-custom templates are good, gen1 is able to rotate around and does not move.

 

I worked on learning how Havok works and tried to do something, but after dicking around for hours, I am clear that I don't know what I am doing.. maybe later. The closest thing I can find is that, in the constraint between genbase and gen01, the transformA/transformB and the target matrix given to the motor atoms is the cause.

   From observation, it might also be that the order of the transformation for motors is a problem.. if it moves first, then applies angle, the tx,ty,tz should be given as a position as if the basis were the model basis rather than the basis given in that matrix.. so, maybe something like  (0.0 -0.7660 0.6428)(1.0 0.0 0.0)(0.0 0.6428 0.7660)(0.0 2.4 -1.3) ... Like said, I don't really know, heh.

   ragdoll motor constraint says of this matrix: "The target relative rotation the motors will try to match. This is the target rotation from bodyA's constraint space into the bodyB's (non-constraint) space." --  Dunno what that precisely wording means. If from A-constraintSpace into B-modelSpace, should that be a matrix mult, by a matrix that transforms TranformA-matrix back to model space, and the matrix that gives the rotation and offset in TransformA basis?

 

Link to comment

So I was fixing to try to personally tackle a little project related to this mod, but halted the idea when I determined that 1) it's a bit more involved than I'd been counting on, and 2) I cannot, for the life of me, detect any difference whatsoever between the default floppiness and the two half-erect modes.

 

The project I had in mind was what you might expect: SOS has 20 states of erectness.  SLA commits those states on a scale, based on character arousal.  Currently, of course, this means that the only time FloppySOS is allowed to function is when the character is completely unaroused.  There are no states of semi-floppiness.  It was my hope that the floppiness could be controlled, for the 21 total individual states, on a scale that would accurately represent the expected floppiness or lack thereof.  The existence of semi-erect options in the menu, coupled with the other control settings, gave me this hope.  Perhaps it was misguided, or perhaps it really could happen, finalizing this effect once and for all.

Link to comment

FPS FLICKER PROBLEM: Enb might fix!

 

I found something interesting while testing some enbs. Lighter ones like Opethfield that can get easily 60 fps, when going lower than 48 makes the schlong start to flicker like everyone here has experienced. But heavy enbs like Kountervibe (Version 266) and the enb that comes with Vivid Weathers (Version 305) didn't have that problem. Even going as low as 30 FPS (with Kountervibe) didn't make the schlong flicker, only on rare occasions when the cpu was very stressed.

 

Something in the newer enb files might fix this physics problem but I have no idea exactly what. Who's up for investigating?

Link to comment

Hey Jopie. Often on hdt activation for the balls, they tend to droop down really far. Occasionally it doesn't happen, and other times it's in conjunction with the schlong being shrunk in length until they're reactivated again. Is a toggle a possibility for this? Sometimes the droop is desired. This has been around for a while, but might not have brought it up as I think I was able to control it more easily before.

 

 

eg. no droop http://gfycat.com/DependentDecentEquestrian

 

vs droop http://gfycat.com/FatalYearlyIndigobunting

 

 

@Devious: Can't remember which one I'm using, but 30 is really the only way I can get rid of the flicker completely. Tempted to try the light one you suggested.

Link to comment

Hey Jopie. Often on hdt activation for the balls, they tend to droop down really far. Occasionally it doesn't happen, and other times it's in conjunction with the schlong being shrunk in length until they're reactivated again. Is a toggle a possibility for this? Sometimes the droop is desired. This has been around for a while, but might not have brought it up as I think I was able to control it more easily before.

 

 

eg. no droop http://gfycat.com/DependentDecentEquestrian

 

vs droop http://gfycat.com/FatalYearlyIndigobunting

 

 

@Devious: Can't remember which one I'm using, but 30 is really the only way I can get rid of the flicker completely. Tempted to try the light one you suggested.

 

Testing most of the famous enbs have been disappointing. Normal Skyrim (1080p ULTRA) for me uses 35-40% of the GPU with physics mods, a lot of texture mods and high poly meshes. Then I add one of those enbs and the usage goes to 99% with the fps falling to 45 sometimes (also because of the crap DX9 usage of CPU)... and the game sometimes doesn't even look that good besides more colors (vanilla is all grey), better shadows + some minor details.

 

That would mean it is using 3x the power to not so much change (i.e. the enb that comes with Vivid Weathers tanks my fps to 50 and it just looks like a tweaked vanilla skyrim).

 

Older ones like Opethfield seems to give the best experience but, as said, are old.

 

Have you got suggestions for a good looking enb that is performance friendly?

Link to comment

I suspect this will be a dead end, but felt I had to ask.  There are certain armors in the game which depend on schlong nodes.  The FloppySOS system appears to essentially ignore node positions, leaving them at whatever SOS dictates.  The effect, then, is that anything equipped on the schlong is not attached to the visible schlong but rather to the phantom schlong.  I'm basically just checking whether this is an unavoidable sacrifice or if it might be something that could be addressed at some point.

 

Link to comment

 

ZaZ-like streams, specifically.

Will have to check O_o

 

I'll have to clarify further.  Pupper Master Swallow uses streams which originate at the urethra, and is apparently still the only mod which does.  It provides a much more realistic effect than simple guessing, and indeed eliminates the need to force a certain state on the schlong.  This is the effect which is being defeated by the FloppySOS system. 

Link to comment

 

 

ZaZ-like streams, specifically.

Will have to check O_o

 

I'll have to clarify further.  Pupper Master Swallow uses streams which originate at the urethra, and is apparently still the only mod which does.  It provides a much more realistic effect than simple guessing, and indeed eliminates the need to force a certain state on the schlong.  This is the effect which is being defeated by the FloppySOS system. 

 

 

So then the effect from Zaz or similar mods, is not applied, or visible? This may be a slot conflict, which can be resolved with the current version of this mod, by changing the slot that the floppy item equips to. it just depends on knowing what slot that Zaz or the like will use, and then changing the slot that FloppySOS uses if it would use the same slot as Zaz.

 

Only I'm just wondering if with that done, and both effects work together, the stream effects will actually still move with the schlong.

Link to comment

 

I'll have to clarify further.  Pupper Master Swallow uses streams which originate at the urethra, and is apparently still the only mod which does.  It provides a much more realistic effect than simple guessing, and indeed eliminates the need to force a certain state on the schlong.  This is the effect which is being defeated by the FloppySOS system. 

 

So then the effect from Zaz or similar mods, is not applied, or visible?

 

The ZaZ version of the male effect simply positions the stream at a spot in front of the character, leaving it up to the modder to ensure that the schlong is angled correctly and, hopefully, roughly the correct length.

I think SOS cumshot worked with floppy just fine. Does the stream from puppet master work with scaling? I know Zaz was prettymuch a static position and never worked correctly for even default female futa.

 

I haven't bothered to go in-game to check but I did investigate the SOS cumshot mesh, and it uses nodes, same as the PMS streams, so it would have the same issues.  The difference, of course, is that you do not, under normal circumstances, encounter a scenario where the cumshot mesh needs to be used and the schlong is not fully erect, ie FloppySOS isn't even equipped.

Link to comment

 

I think SOS cumshot worked with floppy just fine. Does the stream from puppet master work with scaling? I know Zaz was prettymuch a static position and never worked correctly for even default female futa.

 

I haven't bothered to go in-game to check but I did investigate the SOS cumshot mesh, and it uses nodes, same as the PMS streams, so it would have the same issues.  The difference, of course, is that you do not, under normal circumstances, encounter a scenario where the cumshot mesh needs to be used and the schlong is not fully erect, ie FloppySOS isn't even equipped.

 

 

I downloaded PMS (which is great btw, thank you! didn't know about it) just to try it out and see what happens.

 

Just to double check I activated SL Cumshot with floppy moving around and it follows: https://gfycat.com/WickedDeepAruanas

Link to comment

Just to double check I activated SL Cumshot with floppy moving around and it follows: https://gfycat.com/WickedDeepAruanas

 

Confirmed on my end as well.  It's dumbfounding.  Not only does the data between the PMS mesh and the Cumshot mesh agree 100%, but I have even worn both meshes at the same time, and still get the same result, which means that the game is somehow presenting two completely different values for the same exact node, at the same time, to two different armor addons.  Extremely frustrating.

 

Edit: I have combined the PMS stream with a simple mesh (an apple) on the same .nif to see how the game handles it.  Sure enough, the apple is attached to the FloppySOS schlong while the stream is attached to the (invisible) regular SOS schlong which reacts to erection anim events.. despite both being associated with the same exact node.  I never would have thought this possible.

Link to comment

 

Just to double check I activated SL Cumshot with floppy moving around and it follows: https://gfycat.com/WickedDeepAruanas

 

Confirmed on my end as well.  It's dumbfounding.  Not only does the data between the PMS mesh and the Cumshot mesh agree 100%, but I have even worn both meshes at the same time, and still get the same result, which means that the game is somehow presenting two completely different values for the same exact node, at the same time, to two different armor addons.  Extremely frustrating.

 

Edit: I have combined the PMS stream with a simple mesh (an apple) on the same .nif to see how the game handles it.  Sure enough, the apple is attached to the FloppySOS schlong while the stream is attached to the (invisible) regular SOS schlong which reacts to erection anim events.. despite both being associated with the same exact node.  I never would have thought this possible.

 

 

Is it possible to rebuild the object/emitter within one of the meshes that functions correctly?

Link to comment

 

Edit: I have combined the PMS stream with a simple mesh (an apple) on the same .nif to see how the game handles it.  Sure enough, the apple is attached to the FloppySOS schlong while the stream is attached to the (invisible) regular SOS schlong which reacts to erection anim events.. despite both being associated with the same exact node.  I never would have thought this possible.

Is it possible to rebuild the object/emitter within one of the meshes that functions correctly?

 

I struggled with this issue for as long as it took to exhaust my knowledge of Nifskope.  Emitters and such are essentially mysteries to me; the effect produced is one achieved through trial and error and scrutinization of existing assets.  There is no Nifskope guide for such aspects; the closest thing is q&a on forums, where one is lucky to get any response at all.  It does seem as though the components for the emitter must be attached to a proper NiNode, rather than a NiTriShape.

 

The issue boils down to this: The only clue the .nif file has as to where to position itself is the NiStringExtraData "NPC Genitals06 [Gen06]", a child of the root BSFadeNode.  So far so good.  But somehow, while the NiTriShape is attaching itself to the FloppySOS node - ie, the one actually being visibly rendered - the emitter is attaching itself to the location where the node would have been, had SOS still been in effect.  One can fiddle with the erection slider and watch the stream shift up and down, attached to an invisible schlong.  What discrepancy is in play here is a complete mystery.  The .nif only has one node name to work with.

 

Proper, complete documentation on NifSkope might have provided some sort of elucidation, but I am doubtful of even that.

Link to comment

 

 

Edit: I have combined the PMS stream with a simple mesh (an apple) on the same .nif to see how the game handles it.  Sure enough, the apple is attached to the FloppySOS schlong while the stream is attached to the (invisible) regular SOS schlong which reacts to erection anim events.. despite both being associated with the same exact node.  I never would have thought this possible.

Is it possible to rebuild the object/emitter within one of the meshes that functions correctly?

 

I struggled with this issue for as long as it took to exhaust my knowledge of Nifskope.  Emitters and such are essentially mysteries to me; the effect produced is one achieved through trial and error and scrutinization of existing assets.  There is no Nifskope guide for such aspects; the closest thing is q&a on forums, where one is lucky to get any response at all.  It does seem as though the components for the emitter must be attached to a proper NiNode, rather than a NiTriShape.

 

The issue boils down to this: The only clue the .nif file has as to where to position itself is the NiStringExtraData "NPC Genitals06 [Gen06]", a child of the root BSFadeNode.  So far so good.  But somehow, while the NiTriShape is attaching itself to the FloppySOS node - ie, the one actually being visibly rendered - the emitter is attaching itself to the location where the node would have been, had SOS still been in effect.  One can fiddle with the erection slider and watch the stream shift up and down, attached to an invisible schlong.  What discrepancy is in play here is a complete mystery.  The .nif only has one node name to work with.

 

Proper, complete documentation on NifSkope might have provided some sort of elucidation, but I am doubtful of even that.

 

 

Maybe Zaz, Xaz or Belisario could help?

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   0 members

    • No registered users viewing this page.
×
×
  • 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