Jump to content

Sex animations.


Recommended Posts

I was thinking more of sex positions and role.

 

I mean "m_missionary.hkx" for the partner in the male role (who could be a female with a strap on' date=' of course) and "f_missionary.hkx" for the actor in the female role (who for biological reasons probably has to be female.

 

Things get a bit more complex in cases both roles can potentially be taken by either gender, but I figure we can still use traditional hetero roles to define who goes where. Unless of course there are cases where anatomy requires different animation for different genders.

[/quote']

 

When I rewrote sexout I intentionally got rid of gender specific variable names, and I think in this system you're wise to do the same. First as you said, the 'male' actor can be either gender easily. Second, the work involved in making two different animations for something like doggy style (anal vs. vaginal) is pretty high compared to just using the same one, and of course anal can be either gender.

 

Last and most importantly, my main purpose behind taking over Sexout to begin with was to add threeways, to progress on to n-ways as the animators wished. In that scenario, naming based on gender becomes extremely unwieldy for the modders.

 

I opted for just using actorA, actorB, and actorC as ref vars (FONV). In BlueSky, I started working with a simple array of actors, with their index in the array indicating their position, and no care at all for gender.

 

The random animation picking logic can find a suitable animation for any combination of genders, or exclude actual gender-specific ones.

 

On the other hand if you have an animation of someone sucking cock and masturbating at the time, that would need to be different for male and female suckers. so we'd need f_blowjob_plus_mast_f and f_blowjob_plus_mast_m to specify an animation for a male in the female role.

 

This is going to be problematic in the long run. Is there no way to dynamically combine two single actor animations as the previous games have done? It may not fit the mold as far as "paired animations" but it certainly reduces the complexity in these situations.

 

Then there's the question of what to call some of these positions, and which ones are credible variations of others, and it all gets a bit complicated. Which is why I'm hoping someone has already sorted out a naming convention for lovers or sexout that we could adopt.

 

In Sexout only a few of the animations are named, for the most part only the numbers matter. I broke the animation number range up into a series of groups like "solo", "2pOral1", "2pOral2", etc. The different groups are mainly for the overall position of some/all actors such as laying down, standing, kneeling, etc.

 

Giving them actual names inside the engine that match the positions is just too cumbersome. Easy enough for a modder to pick the animation they want based on number and then set some constant var to that value if they want to reference it by 'name'.

Link to comment

Giving them actual names inside the engine that match the positions is just too cumbersome. Easy enough for a modder to pick the animation they want based on number and then set some constant var to that value if they want to reference it by 'name'.

Exactly. And then what is the reason to make an extra tool just to make new names? Except to make things more complicated and unhandy to deal with fixes which have to be made because underlaying layers change?

 

They just announced new killmoves at BethBlog. And what does this mean? New behaviors!!!

 

Link to comment

thanks guys for the help. i have a solution now. but a strange one.

 

ive tried both ideas' date=' nothing work.

 

ive tried another idea: disable the NPC COM bone and never enable it again. ive tried first, disable in the end enabled gain.

 

but the only way it works is disbaleing the bone.

im not sure if its the direct translation, i hate my language version. sucks in many ways.

 

anyway if you delete the bone. the animation is broken,

if you delete it and create in the end. same result,

if you relink it in the end, the animation turns 90° to the right,

 

the only way is to disbale it and thats it.

 

many thanks to canderes and fore. :)

[/quote']

 

Actually you found an easier way to do it nice. The reason the animation turns 90 to the right is because it screws up the parent and child relationships between the root, com, animobjecta/animobjectb, and character bumper. I forgot to mention that you have to relink everything as it was in the original skeleton. Good thing you figured out a better way its a pain in the ass to relink everything the way it was before.

Link to comment

Last and most importantly' date=' my main purpose behind taking over Sexout to begin with was to add threeways, to progress on to n-ways as the animators wished. In that scenario, naming based on gender becomes extremely unwieldy for the modders.

[/quote']

 

Exactly the problem we hit on otherworld with sex act pictures. Which is why I asked, of course.

 

Giving them actual names inside the engine that match the positions is just too cumbersome. Easy enough for a modder to pick the animation they want based on number and then set some constant var to that value if they want to reference it by 'name'.

 

To be honest' date=' I'm more interested in names [b']outside[/b] the engine. I have what seems like a hundred different animation files at the moment, all them seemingly called mt_idle.hkx, and none of them I can examine without a good deal of work. That's not a sensible way to organise information to my mind.

 

Exactly. And then what is the reason to make an extra tool just to make new names? Except to make things more complicated and unhandy to deal with fixes which have to be made because underlaying layers change?

 

Apart from you saying on Nexus that you expected someone else to write a management tool? Well...

 

  • It means that instead of "zFNISc379" we can have "zFNISc_the_name_of_the_animation_file"' date=' which arguably conveys more information about the nature of the animation.
    [*'] It means that if I have an animation I want to use in my mod, I don't have to wait for a central authority to add it for me.
  • It means that if I add a local copy, I don't have to change things if I get allocated different numbers to the ones I anticipated.
  • All I was proposing was to generate the same xml file you posted to nexus, only without the hard-coded limit and the necessity to discard textual information in favor of numeric codes.

 

Looked at from a certain light, all of those could be considered valid reasons.

 

Now prideslayer seems to have his hands full with sexout right now and you've talked about needing SKSE to progress. Me, I have some spare time in the evenings. So I thought that rather than curse the darkness, I might try lighting a candle, instead. I never expected it to be remotely controversial.

 

Still, neither you nor prideslayer seem happy with my involving myself and I've no wish to work on this against either of your wishes. If you don't want my help, I'm sure I can find other things to do with my time.

 

Link to comment

To be honest' date=' I'm more interested in names [b']outside[/b] the engine. I have what seems like a hundred different animation files at the moment, all them seemingly called mt_idle.hkx, and none of them I can examine without a good deal of work. That's not a sensible way to organise information to my mind.

 

Ahhh sure, I agree. Name those whatever you want to name them, it shouldn't matter. The installer can hook them up with an automatic prefix or something like that to ensure they are unique.

 

Exactly. And then what is the reason to make an extra tool just to make new names? Except to make things more complicated and unhandy to deal with fixes which have to be made because underlaying layers change?

All I was proposing was to generate the same xml file you posted to nexus' date=' only without the hard-coded limit and the necessity to discard textual information in favor of numeric codes.

[/quote']

 

I've agreed with this tack here in the forums. I haven't looked in detail at everything Fore has done, but automatically generating the XML file is a better solution. I don't know when I'll get back to working on bluesky, but when I do, I can promise it will come hand in hand with such a system if one isn't invented by then.

 

Fixed names and a "central authority" aren't things I'm going to bother with. "That dog won't hunt" so to speak.

 

Now prideslayer seems to have his hands full with sexout right now and you've talked about needing SKSE to progress. Me, I have some spare time in the evenings. So I thought that rather than curse the darkness, I might try lighting a candle, instead. I never expected it to be remotely controversial.

 

Busy with an NVSE plugin right now and skyrim support in FOMM actually, but the first one is sexout related I suppose. ;)

 

Still, neither you nor prideslayer seem happy with my involving myself and I've no wish to work on this against either of your wishes. If you don't want my help, I'm sure I can find other things to do with my time.

 

I don't know how I gave you that impression. Your ideas have been fine so far as I've seen, I just wanted to raise a hand of caution against "genderizing" any of the core system. In the long run it will just end up causing confusion, and almost all the animations work fine regardless of gender.

 

Don't let me stop you from doing anything though. I'm not working on anything skyrim related right now (except FOMM support), and I don't know when I'll get back to it. Not until after the FOMM support is done though; I make too much of a mess of my directories doing this stuff, and am not going to mess around with NMM, so my skyrim directory is staying pristine until I have a reliable tool to manage it.

Link to comment

Sorry to ask for this quick question, but i am dealing with some stuff in RL and dont have time at the mo to re read all the thread..

 

is there a download yet..of a working animation replacer or a system decided on yet? great work with this, from what i remember back in the earlier pages..i just have been away for a bit and wanted to see how things were going. thanks.

Link to comment

I don't know how I gave you that impression. Your ideas have been fine so far as I've seen' date=' I just wanted to raise a hand of caution against "genderizing" any of the core system.

[/quote']

 

That's a fair point and I withdraw the comment. :)

Link to comment

Apart from you saying on Nexus that you expected someone else to write a management tool? Well...

 

  • It means that instead of "zFNISc379" we can have "zFNISc_the_name_of_the_animation_file"' date=' which arguably conveys more information about the nature of the animation.
    [*'] It means that if I have an animation I want to use in my mod, I don't have to wait for a central authority to add it for me.
  • It means that if I add a local copy, I don't have to change things if I get allocated different numbers to the ones I anticipated.
  • All I was proposing was to generate the same xml file you posted to nexus, only without the hard-coded limit and the necessity to discard textual information in favor of numeric codes.

 

PLEASE don't get me wrong here. I like having a managing tool, and I have no objection at you doing something like that. I just want to raise my point that you tackle it the wrong way.

 

My main concern is that behavior files should be touched by as few people/mods as possible. And instead of thinking about a tool that generates new versions of behavior files, you should (in my opinion) rather think of ways how to keep ONE file, and find ways around it to make it user friendly WITHOUT changing it (by coping descriptive filenames into the hard-coded ones, by providing ini files ...)

 

Behavior files are a highly critical thing, and if "everyone" modifies them, we will see incompatibilities, and system mal-functioning all over the mod-world. Not because I want to protect my baby, but to protect all mod users. There are so many scenarios possible, that tons of mods don't work any more, because the developer of the managing tool is on vacation. And those tons of mods rely on a working managing file, which relies on a specific behavior version. But Beth just has made a new release update...

 

I start feeling like Robert Oppenheimer, who developed the nuclear bomb. And then (too late) started thinking "what will happen if" ....

Link to comment

is the next update going to mess anything up ?

sence beth is adding new animations

 

YES. In any case defaultmale.hkx and defaultfemale.hkx will change. Because these are 2 places where names of new animations go in any case. And then I have to hope. If it's only those new killmoves then I might be fine. If they change anything non-combat (and this might be a side-effect of the combat stuff) it's most likely in mt_behavior.xml. And then I have to re-integrate all I have done before. New recordIDs, new event numbers, ...

 

See why I'm opposing XML generators? The same will happen by the way, when some other mod (like a "Skyrim Deadly Reflex") comes into play.

 

Link to comment

Fixed names and a "central authority" aren't things I'm going to bother with. "That dog won't hunt" so to speak.

 

I should probably explain. I'm not complaining about having an overall maintainer. I just think that as proposed' date=' we're building a bottleneck into the system, and one that's not necessary. Having someone who volunteers to maintain a central animation repository is a great idea. But we should be able to implement local extensions without needing to rewrite code once the animations make it into the "official" release.

 

Admittedly, it's not such a big deal as I thought it was a week or so ago. If we're defining our own idle objects based on animation names in the behaviors then we just have one drop down to tweak for each file. But it's still an unnecessary overhead, and a possible cause of bugs.

 

I don't know how I gave you that impression. Your ideas have been fine so far as I've seen, I just wanted to raise a hand of caution against "genderizing" any of the core system. In the long run it will just end up causing confusion, and almost all the animations work fine regardless of gender.

 

Well, the fun thing is that I'm not planning on building in any naming conventions. Just asking about good names for animations. I'm still not convinced there's any real harm in using m_ and f_ to indicate the, uh, penetrating and penetrated roles in an animation. A little politically incorrect, perhaps, but nicely terse. But for what I was proposing, it can use any names at all.

 

But then again, like I say, I really don't have a very deep understanding of how animations work in Gamebryo/Creation. So I could be talking utter twaddle.

 

 

Don't let me stop you from doing anything though. I'm not working on anything skyrim related right now (except FOMM support)' date=' and I don't know when I'll get back to it.

[/quote']

 

Looking forward to seeing a Skyrim capable FOMM, I must admit :)

 

is there a download yet..of a working animation replacer or a system decided on yet? great work with this' date=' from what i remember back in the earlier pages..i just have been away for a bit and wanted to see how things were going. thanks.

[/quote']

 

Try this: http://skyrim.nexusmods.com/downloads/file.php?id=11811

 

My main concern is that behavior files should be touched by as few people/mods as possible. And instead of thinking about a tool that generates new versions of behavior files' date=' you should (in my opinion) rather think of ways how to keep ONE file, and find ways around it to make it user friendly WITHOUT changing it (by coping descriptive filenames into the hard-coded ones, by providing ini files ...)

[/quote']

 

OK. I can see that the fastest way to set your mind at rest here will be if I just show you what I'm doing. I really don't think you'll have a problem.

 

Let me get it so it runs again and I'll post it here. Then if you still think I'm going to cause a nuclear chain reaction, I'll go back to speccing slave trade quests.

 

Behavior files are a highly critical thing' date=' and if "everyone" modifies them, we will see incompatibilities, and system mal-functioning all over the mod-world.

[/quote']

 

Well, yeah. If everyone hand-edits the xml, I agree. Which is why I'm trying to generalise your edits to the original, and for a given set of files, output the xml you yourself might have written had you hand edited for that exact file set.

 

It's not like "everyone" changing the behaviors, any more than a compiler means "everyone" changing the machine code in the operating system. But it does lower the barrier to entry a little, and hopefully allows routine changes to be made rather more safely. Which is probably no bad thing.

 

Not because I want to protect my baby' date=' but to protect all mod users. There are so many scenarios possible, that tons of mods don't work any more, because the developer of the managing tool is on vacation. And those tons of mods rely on a working managing file, which relies on a specific behavior version. But Beth just has made a new release update...

[/quote']

 

Granted, yes. But that argument applies just as much to your hand-edited XML file. Now the tool I'm proposing is just a script that embeds the whole of mt_behavior.xml, splits it up and does a little variable expansion, adds a few loops. If you run it with an animations/FNIS folder that has files named 001.hkx to 400.hkx you should get an identical file to the one you created. If you run it with an empty folder, you should get the original output from hkxcmd, plus a few FNIS comments. We can check it's working right with diff(1).

 

So it shouldn't be too hard to maintain. If the format of the hkx file changes, the hard part is going to be updating hkxcmd. After that, we either need to work out a new way to embed extra files in it (which will probably rely on you, either way) or else we just splice missing sections of XML into the static blocks and loop formats until the output matches again. Job done.

 

is the next update going to mess anything up ?

sence beth is adding new animations

 

Based on the above, we don't really know. Probably it'll need a new mt_behavior.xml file, or else the game won't see the new animations, and that could be bad. We'll know better once we get a chance to decode the new files and see how they differ.

Link to comment

Fixed names and a "central authority" aren't things I'm going to bother with. "That dog won't hunt" so to speak.

 

I should probably explain. I'm not complaining about having an overall maintainer. I just think that as proposed' date=' we're building a bottleneck into the system, and one that's not necessary. Having someone who volunteers to maintain a central animation repository is a great idea. But we should be able to implement local extensions without needing to rewrite code once the animations make it into the "official" release.

 

Admittedly, it's not such a big deal as I thought it was a week or so ago. If we're defining our own idle objects based on animation names in the behaviors then we just have one drop down to tweak for each file. But it's still an unnecessary overhead, and a possible cause of bugs.

[/quote']

 

I am complaining about that; well not exactly complaining, just unwilling to accept it, and trying to make my position clear without being too confrontational. I suppose I'm failing on the last part. I'm sick of things like this emerging and then eventually the author(s) falling off the face of the earth with no recourse because they were control freaks in their terms of use/redistribution. Especially when there's a more open alternative, and in this case, there is as you've already recognized.

 

Well, the fun thing is that I'm not planning on building in any naming conventions. Just asking about good names for animations. I'm still not convinced there's any real harm in using m_ and f_ to indicate the, uh, penetrating and penetrated roles in an animation. A little politically incorrect, perhaps, but nicely terse. But for what I was proposing, it can use any names at all.

 

But then again, like I say, I really don't have a very deep understanding of how animations work in Gamebryo/Creation. So I could be talking utter twaddle.

 

They work fine and it takes a while for them to start becoming cumbersome, but I ask you this. For the 3way animations, how would you propose they be named? Especially the ones that will work with any gender in any of the positions, like a "spitroast" -- someone blowing one person while being screwed by another.

 

I've found it to be easier to simply name the positions A, B, and C. It's just as terse as m_ and f_, is more easily extended, and doesn't cause confusion when the positions are "reversed" in a script. The only general guideline is that actor B is, by default, the one being penetrated.

 

Looking forward to seeing a Skyrim capable FOMM, I must admit :)

More on this in a second.

 

Granted, yes. But that argument applies just as much to your hand-edited XML file. Now the tool I'm proposing is just a script that embeds the whole of mt_behavior.xml, splits it up and does a little variable expansion, adds a few loops. If you run it with an animations/FNIS folder that has files named 001.hkx to 400.hkx you should get an identical file to the one you created. If you run it with an empty folder, you should get the original output from hkxcmd, plus a few FNIS comments. We can check it's working right with diff(1).

 

So it shouldn't be too hard to maintain. If the format of the hkx file changes, the hard part is going to be updating hkxcmd. After that, we either need to work out a new way to embed extra files in it (which will probably rely on you, either way) or else we just splice missing sections of XML into the static blocks and loop formats until the output matches again. Job done.

 

This type of functionality is exactly what I intend to put into FOMM and is one of the reasons I'm working on skyrim support there. I mentioned this earlier in the thread and Fore said he'd prefer a standalone tool. I'm fine with that, though I'd prefer it be a lib (dll) and not an executable. A standalone executable could be written that just uses the same dll. I want to avoid shelling out to run an external process as much as possible is all. So all the different tools, including standalone, can use the dll and everyone gets what they want.

 

This lib would do just what you're saying.

- Extract the current hkx from the BSA.(1)

- Serialize it with hkxcmd.

- Insert the mods "xml fragment(s)" in the proper spot.

- Recompile the xml with hkxcmd.

- Repack the hkx into the BSA.(1)

 

(1) may not be needed of course, if the hkx has already been extracted and is being loaded from an external source and not from the BSA, assuming that works like the other BSA packaged assets.

 

This can all be done very reliably in an automatic fashion, and the markers for where and how to insert the xml fragment can be stored in a config file, which means updates to the library will not be required to support changes from bethesda -- just config file changes, that anyone can create and put up for download.

 

As you mentioned, tools like diff can be used to validate the output both manually and automatically.

 

This is more work (obviously) but in the long run it's a better solution than one person maintaining a 'master' XML file and then modders all having to cooperate (or collide) on which animations they are going to take over.

 

 

Link to comment

They work fine and it takes a while for them to start becoming cumbersome' date=' but I ask you this. For the 3way animations, how would you propose they be named? Especially the ones that will work with any gender in any of the positions, like a "spitroast" -- someone blowing one person while being screwed by another.

[/quote']

 

Well, if the basic layout is mfm we could write

 

m___spitroast.hkx

_f__spitroast.hkx

__m_spitroast.hkx

 

Assuming we do indeed need to do it in three animation files. Then you know by looking the role and position.

 

Granted, I'm entirely happy with the way I'm overloading the humble underscore there. hyphens might work better:

 

m__-spitroast.hkx

_f_-spitroast.hkx

__m-spitroast.hkx

 

Also has the advantage that it's extensible beyond three players. Two girls in a 69, a guy at either end: mffm

 

m___-fourway.hkx

_f__-fourway.hkx

__f_-fourway.hkx

___m-fourway.hkx

 

That would break down with ABC. You can specify "D" as a fourth partner but then do you have a consistent role for "D"? Suppose you have 3 guys on one girl: mfmm? Then D is penetrating rather than penetrated.

 

I've found it to be easier to simply name the positions A' date=' B, and C. It's just as terse as m_ and f_, is more easily extended, and doesn't cause confusion when the positions are "reversed" in a script. The only general guideline is that actor B is, by default, the one being penetrated.

[/quote']

 

Well, I'm not entirely convinced, but so long as the naming conventions lets me tell what in the blessed things, it's not something I feel particularly strongly about.

 

This type of functionality is exactly what I intend to put into FOMM and is one of the reasons I'm working on skyrim support there. I mentioned this earlier in the thread and Fore said he'd prefer a standalone tool. I'm fine with that' date=' though I'd prefer it be a lib (dll) and not an executable. A standalone executable could be written that just uses the same dll. I want to avoid shelling out to run an external process as much as possible is all. So all the different tools, including standalone, can use the dll and everyone gets what they want.

[/quote']

 

Well, I'm going to supply one in the form of a Perl script, which is probably going to please no-one :) On the bright side, it should be ready tonight, so it may serve as a stop-gap until a better solution is in place.

 

This lib would do just what you're saying.

- Extract the current hkx from the BSA.(1)

- Serialize it with hkxcmd.

- Insert the mods "xml fragment(s)" in the proper spot.

- Recompile the xml with hkxcmd.

- Repack the hkx into the BSA.(1)

 

I'm just doing item 3 of course.

 

Can I just question the wisdom of re-packing the BSA? If we do that' date=' we overwrite am important reference file with one that is potentially broken. If we leave the file loose, we can recover from errors by deleting the loose file. It's not so easy if the BSA is altered.

 

This can all be done very reliably in an automatic fashion, and the markers for where and how to insert the xml fragment can be stored in a config file, which means updates to the library will not be required to support changes from bethesda -- just config file changes, that anyone can create and put up for download.

 

mmm... finding the patterns for the config file may not be altogether straight forward. I'm using Perl and I decided not to go that route. Which isn't to say it can't be made to work, of course. But I anticipate problems.

 

This is more work (obviously) but in the long run it's a better solution than one person maintaining a 'master' XML file and then modders all having to cooperate (or collide) on which animations they are going to take over.

 

Agreed.

Link to comment

Forgive the double post, but here it is.

 

It's a perl script, so you'll need cygwin or activision perl installed. The program is called fgen and runs from the command line.

 

It looks for animations/FNIS, makes a list of all the files it finds, and uses them to build a new mt_behaviors.xml from code embedded inside the script.

 

Currently it has 400 files in the animations/FNIS folder and it produces output identical to Fore's original xml file, apart from a modified comment at the top and a few blank lines I was too lazy to chase down.

 

I haven't tested it in many other configurations, and I don't have my CK handy to test it before the weekend. Feel free to try and break it before the if you're so inclined.

 

 

Link to comment

 

Well' date=' if the basic layout is mfm we could write

 

m___spitroast.hkx

_f__spitroast.hkx

__m_spitroast.hkx

[/quote']

 

This just doesn't really.. "work" for me. I don't see a reason to call them 'm' or 'f' when that isn't representative of what they are, and this is also now causing a "what if" for four-ways and further expansion. a_spitroast, b_spitroast, etc. doesn't cause that type of confusion, and is expandable up to any number of positions without changing the interpretation via pretty standard regex pattern matching: (/(.*?)_(.*?)\.hkx/).

 

In any case, with the automatic hkx integration, this is entirely up to the mod providing the animation.

 

Assuming we do indeed need to do it in three animation files. Then you know by looking the role and position.

 

We don't "need" to, but I want to. It makes it easier to combine existing animations on the fly to create new combinations. The initial sexout 3ways were added this way (as demos) with existing positions being recombined to form new 'positions', without a single new .kf being created.

 

Their alignment was not great and they weren't moving in sync, but as a proof of concept it worked and was very fast to demo. Making new three way animations only required the creation of a single new .kf file that "fit" with an existing 2-person one.

 

Also has the advantage that it's extensible beyond three players. Two girls in a 69, a guy at either end: mffm

 

m___-fourway.hkx

_f__-fourway.hkx

__f_-fourway.hkx

___m-fourway.hkx

 

It works, I just don't like genderizing them, because they are not gender specific.

 

That would break down with ABC. You can specify "D" as a fourth partner but then do you have a consistent role for "D"? Suppose you have 3 guys on one girl: mfmm? Then D is penetrating rather than penetrated.

 

How does it break down?

a_(anim name).hkx.. b_, c_, d_.. you can take it as far as you want to. Realistically when I get around to this in bluesky I will probably use numbers and not letters, which will be the index into the actors array for the scene; e.g. 0_blowjob_01.hkx, 3_spitroast_01.hkx, etc.

 

So given an array of actors (alex, betty, charlie) and an animation name "blowjob_01" I can assign the animations to the actors easily...

 

pardon the pseudocode.

for (i=0;i{
 actors[i].playidle(i + 'blowjob_01.hkx');
}

 

This also lets me pick a random blowjob with the numbered suffix part.

 

Well, I'm not entirely convinced, but so long as the naming conventions lets me tell what in the blessed things, it's not something I feel particularly strongly about.

 

If I don't convince you it's no sweat off my back. The naming of these is really up to the modder anyway, that's the whole point of the discussion right? Not forcing any modder to name their stuff anything specific. You could name it according to your scheme, the tool just needs to slap a prefix to the front that would be the same as the mod name or definied in the mods installer .ini file or whatever -- to keep the names shortish. The installer could warn you if two mods try to use the same prefix.

 

Well, I'm going to supply one in the form of a Perl script, which is probably going to please no-one :) On the bright side, it should be ready tonight, so it may serve as a stop-gap until a better solution is in place.

 

Saw your script, looking forward to checking it out.. I probably won't actually be able to devote any real time to this stuff until Thursday though; booked today and tomorrow. :)

 

Can I just question the wisdom of re-packing the BSA? If we do that, we overwrite am important reference file with one that is potentially broken. If we leave the file loose, we can recover from errors by deleting the loose file. It's not so easy if the BSA is altered.

 

I was just putting it out there as a "can do." FOMM option to the end user. FOMM does make a backup of anything it's going to modify or overwrite before it does so, and that behavior would carry over to BSAs, so you could always go back to the vanilla one easily if you opted to modify it and then changed your mind.

 

mmm... finding the patterns for the config file may not be altogether straight forward. I'm using Perl and I decided not to go that route. Which isn't to say it can't be made to work, of course. But I anticipate problems.

 

Perhaps, but tokenizing things, parsing xml, and resorting to regex are things I'm well versed in. It'll probably be structured as a set of rules to find the location like.. find the Nth instance of this tag with these attributes, in the children do the same thing for these.. then put these entries in that place.

 

Something like that. I haven't looked at the diff between the vanilla xml and the modified one, but if a human can find the right place to put it, then so can the code. ;)

 

Link to comment

Has anyone managed to manipulate the 0_master.hkx file in regards to the hkbBehaviorReferenceGenerator class, as this would seem like a good place to reference user created behavior files.

 

It might also make it easier to manage user behaviors and animations as once the reference is added you can modify the user behavior file as much as you want.

 

This in theory would mean each modder can be assigned a single behavior file at which they are responsible for.

 

However I know its not that simple as the defaultmale.hkx and defaultfemale.hkx needs to be altered as well, but that would not be such a ball ache as DocClox pearl script could be modified to generate the new files by recursively searching for animations.

 

Just a thought.

Link to comment

However I know its not that simple as the defaultmale.hkx and defaultfemale.hkx needs to be altered as well' date=' but that would not be such a ball ache as DocClox pearl script could be modified to generate the new files by recursively searching for animations.

[/quote']

 

Way ahead of you there. it already does a recursive search, with path separators being replaced with double underscores. That means that stuff in animations/FNIS/whatever will be picked up and added, which means we can use specific folders to organise things. Unless Havok uses folders for its own purposes in which case I'm talking rubbish again.

 

What my script doesn't do at the moment is modify the defaultmale.hkx and defaultfemale.hkx files ... mainly because Fore didn't add any FNIS annotations, and that's what I was following. So they may need to be looked at. That shouldn't be so bad - they're nowhere near as big and complicated as the mt_behavior file.

 

No idea about 0_master.hkx I'm afraid.

 

Link to comment

OK, following on from my previous post I found the smallest behavior file containing a reference to the hkbBehaviorReferenceGenerator class. Using this file I have removed all (I think) useless references that do not pertain to this class.

 

I then changed the file it was referencing to the original file which I changed to Meapequip.hkx, this doesn't do much other than pass all calls through it to the original behavior file.

 

I started with the weapequip.hkx file as it was the smallest and easiest file to start with.

 

I have attached the XML file that I have changed.

 

To use it rename the original weapequip.hkx to Meapequip.hkx, compile and put it into the behavior folder.

 

I did test this (briefly) and it did appear to work, however let me appologise before hand if im talking rubbish.

 

 

Link to comment
  • 2 weeks later...

What is happening ? Why is there stil no real Sex Mod ? Why is there no progress ?

 

Because the new way Skyrim handles animation files and the way Bethesda decided to dick modders out of helping them edit them is hindering progress.

 

PLEASE remember. It took Oblivion YEARS to get to where it was. We are already progressing at a pretty extraordinary rate considering the changes that are needing to be made. There are some very very talented modders and scripters working hard on this stuff. They have lives and we get this stuff on their time. It'll be ready when it's ready.

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