Vaelorian

Well I can't say I dislike the concept. So, yes, please do upload the files - just model & texture(s).

May I ask as to where that... Uh, fishnet foot-thing (yes, I am awful when it comes to naming things) comes from, Poontank? And is it using the Robert Feet for HGEC?   Thanks, -V

Your skeleton is missing one or more of the bones used by the model. Change your skeleton and they'll work fine.

Searching for Christmas on the Nexus will get you a few house mods. Might as well start with those.   As for poses that include modern musical instruments, Umpa is the only modder that comes to mind as someone who makes those. There's probably at least one or two more public pose mods, but it's definitely his main style so you might as well check his mods out on the Nexus.

Doubt the game's dev will read this, but you might. And you might consider forwarding this to him, so I'm going to take a few minutes to detail some flaws and concerns.   1. A "struggle" system is never unique, nor new. Let's face it, struggle systems are merely "tiresome" at the best of times. I'd love to see anyone name one single game in which the struggle system was a positive part of the experience, but I'm not even going to issue the challenge because I know the answer. The problem with struggle mechanics is that they rely on one or more of the following: -Reduced stats. -Reduced mobility. -Button-mashing. -QTEs and\or STEs (Slow Time Events). A lot of those systems either wear out their welcome quickly as the player gets further into the game, or have a feeling of futility about them. And, as you are no doubt well aware, a gameplay mechanic that induces frustration or exasperation in it's audience is the exact opposite of a good mechanic.   2. "Unique" scenes per character\clothing combo sound great, in theory, but there's a reason why things like that were never done in the past. A wise man once told me: "The golden rule of video games development is this: KISS." Now, I'm sure that by now everyone knows that this stands for 'Keep It Simple, Stupid!' but the reason I'm bringing this up here is the short-sightedness of the idea. Let's pretend there's ten different characters, and ten different clothes and armors. With the "normal" way of designing scenes, you'll need to create exactly one animation per enemy for all characters and all clothes together. With ten characters and ten clothes and armors, a different scene for each combination would require one hundred animations per enemy. Now, you could obviously argue that if you are willing to put in the time and effort this is not a problem, but that argument is easily countered by the fact that this makes it far more difficult to add new enemy types, makes removing planned enemy types a much more enticing prospect and drastically reduces the variety in scenes - none of which are positive effects.   3.Clothing destruction, vore, tentacles, bestiality, etc etc - all those sound great, except for people that don't like them. You might want to include toggles for each kind of fetish, and if you already thought about that - you might want to mention they will be there. Me? I dislike vore to the point I won't even consider a game that includes it without a toggle. Others might dislike something else to a lesser or greater degree, and losing even just a fraction of your audience over something like that is just silly.   4. Crafting is over-done, what with so many games released recently having crafting included due to the popularity of minecraft, I don't see that as a point in a game's favor. Why? Because crafting is usually one or more of these: -A bloody chore due to having to constantly check your inventory due to limited size\weight capacity. -Mandatory and thus simply yet another gameplay obligation, rather than a tool with which to overcome the challenges presented. -Providing flat stat bonuses (such as: +1 damage) rather than new mechanics or increased gameplay variety. -Absolutely and completely unhelpful due to either requiring too many resources, too much time, too many skillpoints or simply not providing anything useful at any stage of the game. -Removing all challenge in the game due to having one or more broken aspect. If you're sure you have a good system, you should obviously keep it, but there's no way I can tell without at least seeing it. Even after seeing it, I'd need to actually play before I was convinced.   5. Marketing without gameplay is marketing done wrong. I believe we've all seen enough of the games industry to say that no amount of early marketing has any kind of meaning. You can claim the world, and might even have a small slice of it in a demo, but is it representative of the final product? No. As Aliens: Colonial Marines demonstrated, it's very easy to create a couple minutes of excellent gameplay and axe it all later in favor of something far easier to create. So if you don't even have a gameplay trailer to show, you really aren't giving me much to get excited over.   In any case, good luck. Your games' developer is definitely going to need it to pull anything even remotely close to what you advertised off.

*Jumps out of lurking*   Welcome back, Poontank.   *Retreats before anybody notices.*

And that is what you call poisoning the well. First you say it won't work at all, then you say it will, but there's flaws. Flaws which, I might mention, are not at all difficult to overcome, but you're too busy trying to insult me for no sane reason whatsoever.   So you know what? I'm simply going to lurk instead of playing along and trying to help. Goodbye.

Calling the guy you're having a discussion with a liar isn't a particularly good way to move the discussion forward. Especially when the guy is just trying to help you with technical expertise which, frankly, you seem to lack.   I can kill your doubts very, very easily, but you'll have to co-operate with me on this one. What I want you to do is find a shapekey-animated model - any will do, but preferably a model with a very easy to spot animation - and equip it during a Lovers animation. See if it works. If it animates, then my solution will work. If it doesn't animate, make sure it's equipped. If it still doesn't animate, then... Well, let's not go there for now.   If you can't find a shapekey-animated model, just tell me and I'll PM you one.

  Um, no. Sorry, Gregathit, but that's just not true at all. Shapekey animations can run alongside a Lovers animation perfectly fine.

  Supposing you created a lowerbody model that had a "looping" animation of... Oh, say, 100+ seconds, that only really animated during the first 1-2 seconds (opening up) and directed Lovers to it (via a setbody plugin). Wouldn't that be relatively closer to accomplishing the desired goal without requiring too long of a time to make (if and only if we assume we already have the nif files, and are only going to cater to the one or two most common body types)?   It's all hypothetical, but I'm just wondering if there's a quicker way about it. Obviously there are flaws (not all animations feature penetration at the same stage or time), but given the vastly smaller time required for it I think it would have been a fairly decent trade-off (again, if we had the nif files ready).

Not sure what you're searching for, so here's everything that was in the video.   Succubus outfit's just an NPC wearing an armor. The succubus "appearing" on the fire was a simple moveto script. Probably onActivate attached to the fire itself. The "chasing" bit was Joburg. The rest is plain old Lovers.   It's not a scripted section or anything.

There's a harp pose on the nexus. http://www.nexusmods.com/oblivion/mods/42416/?

Ugh, teach me to try to figure what's wrong with an Oblivion script after two hours' sleep. Sorry about that. Still haven't had time to sleep, by the way. Life is being... Rather unkind. Friend is sick and I went to visit him in the hospital.   Anyway, good to see you got this working.   If you set the showMode to 11, it will work in menus. Of course, you then need to add a check for which menu it is, and disable it in ones you don't want it to appear. This page has codes for the various menu modes: http://cs.elderscrolls.com/index.php?title=MenuMode   I don't think an array is optimal here; you're only implementing the system on the player, you don't have to keep track of too many things. You can still do it, of course. If you plan on having a static maximum number of hearts possible, you can use either a standard OBSE array (information about it here: http://cs.elderscrolls.com/index.php?title=Introduction_to_OBSE_arrays) or a Pluggy array (information about it here: http://cs.elderscrolls.com/index.php?title=Introduction_to_Pluggy_Arrays). If you want a dynamic array, use the Pluggy one.   I suppose using an array makes a few things easier to do than quest variables (such as a dynamic number of hearts), but of course the downside is that you have to learn just one more thing. It's up to you.   If you don't want to use arrays, just add two int variables to your script.

According to the CSwiki, what should've been outputted to the console from the HUDSInfo line was 1 (meaning that the HUD displays during gameplay only), so I probably wrote it wrong. I do apologize, it's 8:53 am and I had two hours sleep, so I am tired.   As for pHUDHeart==0 returning true only the first frame, that is expected and intended; you're basically asking the game if the object is empty, and if it is creating the HUD element. After you've created the element, it isn't empty anymore.   Hopefully this will fix it...   It should display 11 in the console this time.

Try this script. If it doesn't work, open your console and tell me what it says:

Frankly, I'm not entirely sure what's wrong at this point...   The scripts are pretty much identical. I have to assume both are quest scripts, being called on game start, yes? Does the battle fatigue mod have any other script that might be related, or perhaps is there any other part to the battle fatigue mod script?

Suggestion: try to use the other mod with your image. See if it works. If it does, you eliminate any possibility of a faulty image. If it doesn't, check the differences between the pictures.   Other than that, try this script: scn zzzOneHeartOnlyMode short x short y float scale short opacity short menuX short menuY float menuScale short menuOpacity short showMode long pTempString long pHUDHeart begin gamemode Let x := 0 Let y := 0 Let scale := .25 Let opacity := 100 Let showMode := 0 Let menuX := 0 Let menuY := 0 Let menuScale := .25 Let menuOpacity := 100 If pTempString == 0     Let pTempString := CreateString -1 "pluggy" 0 1 EndIf If pHUDHeart == 0     SetString pTempString "Textures\Menus\OneHeartOnlyRiskyMode.png"     Let pHUDHeart := NewHudS pTempString 1 11 x y 500 1 90 9 Endif   end   If that doesn't work, try changing this line: SetString pTempString "Textures\Menus\OneHeartOnlyRiskyMode.png" To this: SetString pTempString 1:"Textures\Menus\OneHeartOnlyRiskyMode.png"   And see if it works.   I haven't messed with UI elements in over a year and a half, so I don't really remember everything.   My internet has some... "Issues" lately. Could't use it at all yesterday, and having issues now. I'm not sure what's going on. Tech guy was here today and couldn't figure out what was going on. So if I don't answer as quickly as you'd like, that's why.

Use Gerra6's body conversion tool. It won't be perfect, but it'll only take a minute or two, and there aren't too many Oblivion modders left. Chances are you won't get a conversion done by hand for this.

For movement animations (as in, animations that actually move the character in the game world), I suggest you refer to Coronerra's BBB tutorial (it includes a short yet informative section at the very end).   As far as number of frames go, animations are usually made in a 30*K+1 format. The reason for that is that the game renders 30 frames per second, plus one base. So an animation of 31 frames is exactly one second, 61 frames is two seconds etc. This doesn't mean that a 30 frame animation is inferior, it's just that 31 is the norm used by most animators (for example, most if not all recent Lovers animations use that format).   The injured state could be a spell effect. Basically, apply a penalty to related stats (speed, weapon related skills). I'm not sure how to block access to skill perks - haven't ever tried to before. You'll have to figure that one out yourself I'm afraid.   For risky mode, quite simply have a variable keep the max health value, then set the counter max to 1. When the quest ends, set the max health counter to the temporary variable. Make sure to remember to increase the temporary variable when picking up health ups during risk quests.

The onHit event handler is perfect for what you wish to do, then; it allows you to identify the source of the damage (so you can consider the latest attacker each time the script is ran), and from that point it should be easy to achieve the single-actor fatality system if you want it. The death animation should, as I mentioned before, be played via a playidle command (or a pickidle if you encounter issues, though there shouldn't be any).

  This is what I referred to when I mentioned I wouldn't suggest creating an event handler for NPCs. Event handlers won't cause lag; they'll cause straight crashes once too many copies of them try to run at the same time.   As for fatality - it's up to you. Again, I don't honestly care about it either way because I can edit it (and could indeed have made the system myself had I wanted to). It's your mod, make it how you want it. I'm literally trying to give you suggestions from my own experience. You're free to use or ignore them as you like.

A word of warning: since the event handler will quite literally be called every single time the player should take any kind of damage in the vanilla game, you *might* want to keep the code simple. I'm not saying to abandon all of your ideas... Just the most complex ones. Reason for this is that script overload can and probably will crash the game of anyone not running a machine strong enough for it, and even the most elaborate of mods won't be received positively if the users can't experience it.   And no, I wouldn't suggest trying to apply an event handler for NPCs at all. You could, of course, if you really wanted to, but it would increase script payload quite significantly. The way to go about this would be a second onHit event handler that checks to see that the target is NOT the player, and if the damage would be fatal add them to a faction and apply a script effect. If they are in the faction already, check for the script effect. If it's in place, absorb the damage. If it isn't in place, kill the NPC and remove it from the faction. This avoids trying to maintain an array in the background, which is good because the scripts are already very demanding, and an array might just be the final straw.   As for game balance, I'll leave it to you. I can always change it for myself if I wanted to. I'm just trying to help. If you do want my suggestion, it would be to 'avoid player frustrations'.   -V

  Or, if you have any idea of how to use the CS(E), just load up the esp and change their confidence value to... Oh, say, 100. Modifying the summoned creatures will not affect the normal ones.

Yes, the event handler should be handled by a quest script. My suggestion? Look at Sleepypanda's Death Denied mod on the Nexus. It basically does most of what you want on the event handler portion (and nothing else); it contains an event handler that, when the player takes damage, will absorb it and do something (depending on the version you pick) when the player's health runs out.   Because it's such a tiny mod, you'll be able to find whatever you want very quickly. Shouldn't take you longer than a minute or two to reverse-engineer that and have your own event handler going.   Also, since you're mentioning Lovers, may I suggest that - since you're basically designing a system in which the player has three health at the beginning and gets stunned on every hit while not completely invulnerable - when the player runs out of health his\her character don't die, but rather just trigger a sex scene? Would probably be much less frustration inducing than having to reload.

Pluggy itself does not cause crashes. At least not for me, and I've been using it for several hundred hours by now. It could be that UV is incompatible with Pluggy. I believe I've read at some point that Pluggy wasn't compatible with it's HUD counterpart. Too lazy to look it up now (might've changed) but that could've been the source of the incompatibility.   Anyway, you could trigger the hit animation via script, or simply let the event handler take care of it (you know, while it's reducing the heart counter). A simple playidle line should do, or pickidle at worst.