Jump to content

SexoutNG - need input


astymma

Recommended Posts

That also introduces some other... really kind of clever things that could be done. The in-game world could communicate with other processes on the machine, of somebody were to write them. Say you wrote a mod to adjust the weather in game in 'realtime'. If you were reading the weather vars from external NX vars, an external app monitoring the real weather in vegas could be writing to those values. Or player2player chat, or even something akin to the skyrim 'multiplayer' could be done through a similar interface, if someone had the time to devote to solving all the issues that would come along with such a huge project.

 

Now I'm trying to imagine how I'd build a 'generic' interface for NX to communicate with the outside world.. so other people could write their little apps or applets to plug into it.

Link to comment

There's modding a game, and modding a game, I guess. Pretty soon we'll all be smelling the wasteland or something, lol. Watch youtube on those busted game tvs. :D

Anyway, about generic bed sex, took me a bit to think this through (gad, math, noes!): pos offsets per anim per base object are the prettiest way of going about it, I fully agree - provided someone does the leg work first of course. Those raw numbers you guys are speaking of the best way to organize & apply don't exist yet. The lists are mostly meant to help with prep work like that.

Angle per anim per bed can easily be derived from angling for the anims I've done on mine*, and then transposed to all beds, through those lists. Except some of the oral ones, because all I could do for some there was put them across or diagonally & that wouldn't work everywhere. Without those, there isn't much to it, but occasionally there's a +180 tweak or something to line it up facing the head.
(* I probably left out 1 or 2 that didn't fit my own setting there.)

XYZ: not sure about this. All I have is fSurface stuff for the one base form & none of that'll probably be any good for this anyway. Z, maybe, I'm not sure. Someone's gonna have to pick up this particular torch. Especially for Z, you can't just wing it. I think the best way here would be running getpos per anim in-game, getting the positioning right in real time (not going in & out of the game to adjust, that's murder) with some sort of repositioning tool maybe. :)

The good news is: with this random angle business pre-figured out for him, this enigmatic hero of the community (just having a little fun there) may only have to do the XYZ for each particular size group of bed base forms, again using those tiny angle lists to transpose. There aren't a lot of different sized meshes being used really. The only thing keeping anim pos data for each bed base form apart are size and this random 'base' angle. Being able to do it per size group would cut down on quite a bit of work I'd think: you'd maybe have to do test anims for a handful of base forms instead of all. If anything looks off afterwards, that can still be finetuned. Maybe there's a flaw in my logic here, but I think it's ok?

It's the actual data on this haphazard way that Beth's gone about making bed base forms point every which way that's the resource, maybe not so much from the coder's pov, but for the someone getting you the pos data. The base forms' angle offsets as they look in the cell, compared to their detected placement angle with getangle z, pre-sorted. That this bit of intel is organized in formlists only happens to be something that makes refsurface be able to do that too in the meantime, as the poor man's option that a modder can already use, hehe. ;)

---
FNV could also do better than Oblivion's ugly messagebox to give the ok in such a system, with an MCM option for a player to set a default choice. And maybe an nx-var for a modder to override it for something specific. Just musing there.

Link to comment

I'm not grokking much of what you're saying.. but to rewind a bit and touch on the formlists, they seem like they will only be useful if the offsets of everything we're tracking are broken up into nice little chunks of 'families'. 'Here are the beds rotated 90', 'here are the beds rotated 45', etc.

 

This might be the case for the angles (but it might not, I have not looked), but it is almost certainly not going to be the case for the height.

 

Because of that, I will have to do height positioning 'manually' -- meaning, in a script, per anim, the same way the actor x/y/z offsets are already handled. If I have to go through the work of making such a script, then adding angles to it is not going to be any extra work, and will save us from deciding to put the bed that requires a 10 degree offset into the 0 degree list, or into a new 10 degree list, or....?

 

The NX thing I mentioned can solve most/all of this. A simple ESP that simply grabs the current refsurface base form ID, primary actor x/y/z and offsets, and refsurface position, can calculate the *current* angle and Z offsets. Couple that with something like astymma's positioning mod, and you have your tool -- Start the game, spawn a bed, run an animation with it as the refsurface, adjust, and then 'save' via console NX call. No need to exit/enter the game and you can do them one by one.

 

A clever person might even make a room that has one of each bed in it already all 'aligned' to what the geck says is 0 degrees.

Link to comment

Well, I just tried to point out this categorization could still be useful for the person getting you the raw pos data per anim per base form there, before it reaches you to enter into scripts. But sure, maybe the method I suggested was still colored by how I did things with the surface vars. Bed sizes hadn't factored in my original tests etc, just how do you keep your tweaks from one bed for another that has a different placement angle, or one that's not a multiple of 90, that sort of thing. Looking at it as a quester, at the time. Also looking at it that way trying to give Bruce some pointers to that effect with surface in the meantime. The idea of a generic functionality maybe just being something that could build on that, but never considering the problem of getting anim pos per anim per base form & applying it on any reference found in the cell with a refwalk so far.

So my first idea is, at least someone can cut down on the grunt work by taking a shortcut on the angles with what I had, it's all +0, 90, 180, 270 however you cut it (in the base, and usually in the cell), you just need it sorted out. xyz, some of that could've been calculated with the angles, existing x&y offsets to be transposed depending on base angle. The idea was to do around a dozen forms, figure out a baseline for the rest from that, and then finetune things if/as anomalies arise. Of course that left the problem with z being based on nothing but estimation - the part that'd need the finetuning most.

Now, I've looked in the geck since, and the person doing this would probably be way better off just going by the nif. There are 50 base bed forms in vanilla, spread out over 20 or so nifs. (Including some bedrolls too probably.) And, I hadn't realized, the base angle seems to be the same per nif too - just comparing the lists (still finding use for 'em, hehe) with the nif file paths in the object window at a glance. So there's no point doing the angles separately for pos at all really, you just do it all at once per nif. Well, erm, someone.

I may be getting a little funny about this 'someone' guy - doesn't mean I want to put anybody else here under any sort of pressure, just saying it's not me, anytime soon :)

(Also, somewhere along the way, I wondered about scaling. Not that I think a lot of beds are scaled differently than default in the cells, just putting it up. Doesn't take much to throw Z off.)

Link to comment

Yeah, wsex has organized beds according to z offset and then calculates angles automatically. IIRC wsex has never adjusted bed sex according to the bed z angle so some beds you'll be head to header, some head to footer, and some turned various other directions. The bed sex in wsex does in fact work though. We may want to copy the z-offset lists since it appears to cover a fairly large selection of the vanilla beds. It uses z+5, z+10 and z+35... but only covers vanilla beds, nothing else. It is, however, a good start.

Link to comment

Archived

This topic is now archived and is closed to further replies.

  • 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