syscrusher

I don't think the OnHitWith event can be used to detect an unarmed attack. According to the CS Wiki, leaving empty its weapon type parameter causes it to fire regardless of the weapon. The closest thing I can think of would be to do a Fortify HandToHand custom spell effect combined with a scripted spell effect that does the damage programmatically on the nearest hostile NPC. I know that's not much of an answer. Maybe someone else has a better idea.

I think you're conflating a Leveled List with a spawn point that is a leveled spawn. The Leveled List itself is just that; a list of the spawning parameters. You can test the distance from a persistent object, but you may want to use an X marker placed near your creature spawn point rather than testing the distance to the spawn point. The X marker would be always enabled, and those are always persistent automatically. I've never tried dynamically enabling leveled spawns; I'm not sure how they behave. One caveat is to test your distance calculating functions with some temporary console log messages as you walk around. I have found that *some* of the distance calculations don't work in outdoor cells. It's been about 3 years since I encountered this, so please forgive that I don't remember which one. I had a script that looked for the nearest of a certain type of persistent object. My script worked 100% indoors but not at all outdoors, and I finally traced the problem to that issue with distance calculations.

Just found out about this situation -- very sorry to hear it. I've been away from TESA for a while due to a combination of crazy work hours and some medical issues (all better now). Donated in gratitude for all you and this site have done for modding, and because it's the decent and right thing to do.

Hello, all! It's been a long time coming, but Rathunas just finally went out of beta last week. I have found a minor issue that I want to clean up, though, just to be a good citizen with respect to exterior cells. I have a few cells where I edited in my own area, but either just barely touched the terrain in an adjacent cell, or modified the pathgrid in *my* cell but thereby affected a link to the adjacent cell's otherwise-unmodified pathgrid. What I'd like to do is to back off the edits within my own cell so they are a ways back from the boundary, then use TES4Edit to zap all edits of pathgrid and landscape in the adjacent cell, thereby making it untouched by my mod. If I use TES4Edit to zap the adjacent cell edits first, then this leaves a tear in the landscape (as one would expect). The problem is that I don't have a way to match my cell's edge up to the other cell's edge, because in doing so I would once again touch the other cell just slightly and thereby contaminate it. For pathgrid, I can zap the pathgrid record in the other cell using TES4Edit, but that leaves orphan node links in the pathgrid record for my own cell, and my initial testing (with a copy, not my original ESP) suggests that this leads to a lot of CTDs. I've got to believe someone else has solved this. Any ideas? Is there a tool out there to selectively remove modifications by area? I can deal with a tear *within* my cell, because then I could just smooth it out in the CSE. Ideas, anyone? Thanks!

I think I might be able to help here, although my experience relates to the OnTrigger block. I had a problem just about like this and found that it was not an engine bug, but rather an engine quirk. I suspect strongly that Bethesda's internals for OnTrigger may be the same as for On.... other things. :-) In my case, the symptom was that I had a dungeon cell that worked perfectly for months. Then, suddenly, I would hang the game every time I did a "coc" to that cell for testing. If I walked into it normally, no problem. Finally I found the issue. There is a trigger zone in the cell that looks for a particular creature which is supposed to never enter a certain area, and usually doesn't. But because of some Havok weirdness, occasionally the creature passes through a solid obstacle and gets into that area anyway. No problem....trigger zone, detect that actor, move them to an XMarker outside the forbidden area. It turns out that if you have a MoveTo of an actor within an OnTrigger block, the MoveTo works as planned but the trigger detection does not stop until the *next* frame after the move. The Havok bug doesn't happen during normal gameplay; it only seems to occur during the cell loading process when it is settling mobile objects. So if the creature was in the forbidden zone exactly when I "coc" into the cell....zap! Hung game! I beat my head against this for hours, then stumbled upon the note at the bottom of the OnTrigger wiki page. May the Divines bless whoever posted that little note! Solution: Don't do the MoveTo of an actor directly in the detection block. Instead, set a variable in your object script from zero to one during the hit detection. Then do the MoveTo from the GameMode block, and clear the variable to zero when you do the move. IMPORTANT: Make sure the OnGame block is *before* the OnMagicEffectHit block in your code, so the OnGame code will interpret on the *next* frame. No guarantees this is the problem, but coders tend to reuse logic once it's tested, and I think there's a good chance Bethesda did that here. Hope this helps!

Hi, KWITS.....glad as always to help, since lots and lots of others have helped (and continue to help) me when I'm stuck! I am not clear from your reply whether you're saying you can' see the dropdown list I mentioned, or if you're saying you couldn't see it before but can now. I can send a screenshot if you need me to.

A really easy way to create the quest script is to hit the ellipsis button in the quest panel where you would select an existing quest. Once the script edit window opens in the CS[E], look down in the extreme lower-right corner of the script window, in the status bar. There is a dropdown box to choose Quest Script. You'll have to save your script, then you may need to exit from the quest dialog and reload it. The dialogs in the CS prepopulate their dropdown lists as the dialog is invoked, and they're not very smart about updating the list if you add something new *from* the list. ShadeMe has done wonderful things with the CSE, but some of the original limitations aren't practical to be fixed by the community.

Mea culpa! This notice caused me to wonder what my subscription plan was, and to my surprise it had expired. I just took care of that, and I apologize for letting it lapse.

Greetings, all! I am using an excellent tutorial from the CS wiki to create my first from-scratch creature for Oblivion. I've got a mesh (with temporary textures), skeleton, and rigging and skinning done. Everything works just fine in Blender, in pose mode. If I move the bones of my skeleton around, the mesh follows as intended. I also created the skeleton collision for ragdoll behavior, skeleton constraints, and the BSBounds object for weapon and spell impact detection. The creature isn't yet animated. I know how to do that part, mostly, and I wanted to test the mesh and skeleton in the game engine before expending the vast effort to animate it. This is where things have gone a bit wonky, and I'm hoping someone out there can help me out. I don't want to post my mesh online, because it would be a total spoiler for my new quest (an addition to Rathunas). The custom creature is intended to be my "boss" for the dungeon. What's working: The mesh and textures look fine in the TestingHall. Pose mode in Blender works perfectly, suggesting that animation will also work when I attempt it. Cursor on the creature shows its human-visible name, and you can activate it as you would a vanilla creature. The creature is selectable with the mouse in console mode. With "motion guides" displayed via console command, you can see the collision mesh, and it looks correct. What's not working: Collision with the player -- I can walk right through my creature. Placement on a console disable/enable cycle -- it mysteriously translates and rotates on the z axis when you do this. Ragdoll -- if I kill the creature, via console or attack, I crash to desktop. I think my ragdoll problems may be because my constraints, which are all of the "ball joint" type, are not all correctly aimed along the axis of the bones. I know how to do that in NifSkope, but it's really tedious and would have to be repeated every time I re-export the skeleton. Hopefully that won't be too often, but during development it will happen a few times. One of the areas where I'd like to get some help is to understand how to set those constraints within Blender so they export correctly. I also have a small number of bones that are not connected to parent bones; they just have an origin in space because for my animations they didn't *need* to be connected. But maybe Oblivion requires all bones to be connected? The biggest problem, obviously, is the CTD when I try to ragdoll this beastie. That is, ummm, kind of a show-stopper. :-) So, are there any creature animators out there who might be willing to take a look at my mesh (which I'll supply by private communication) and help me figure out where I'm being stupid? Thanks for any help that someone might care to offer. :-)

Great! Your little spell works a treat! Have you considered separating the spell, perhaps with a smaller push distance, and offering that as a standalone mod for immersive RP and people who don't want to leave bodies of friendly NPCs just lying around randomly?

I've observed this behavior with NPCs also. They don't always Havok settle when you would expect them to. (I actually exploit this at one point for some eye-candy in Rathunas, although in a situation where if it *doesn't* behave that way, no harm done -- in general, relying on a game engine bug for anything critical isn't a great idea!) I know you don't want to resurrect the dead, but you may find that you can resolve this by doing a resurrect() on one frame and then a kill() on the next. This is fairly easy to achieve in a GameMode block: ; Object script attached to the NPC that is to die and be moved short wasKilled short doRelocate begin OnDeath set wasKilled to 1 end begin GameMode ; We assume that external logic will set doRelocate when it is time to move the corpse ; If this NPC has been resurrected, re-kill them and enable. ; This might be replaced with just "if getDisabled", if there is no other occasion ; in which this reference would ever be disabled in your mod. if getDead == 0 && wasKilled enable kill endif ; This has to go *after* the preceding so its effects last through a frame transition if wasKilled && doRelocate disable MoveTo my-new-location resurrect set doRelocate to 0 endif end ; GameMode You may (probably *will*) have to tinker with when the resurrect and kill calls happen. In particular, the kill may need to move down into the block right after the resurrect, rather than being in the next frame with the enable. Also, I'm not 100% sure how the timing of getDead behaves with respect to frame timing and the resurrection animation. In other words, here's a skeleton of an idea -- your mileage will vary. :-) One other little tip: In my testing, I have found that NPC bodies do *not* behave properly with respect to an Enable Parent switching them on and off. I found that to reliably switch their rendering on and off, I needed to explicitly disable or enable each NPC reference. I haven't tested this with creatures, only humanoid NPCs. Another possible approach, though more involved: Copy the NPC skeleton meshes to your own directory, and make a custom race that uses your copy of the skeleton meshes instead of the originals. You can use NIFskope to fine-tune the physics behavior of the meshes, setting their mass, damping coefficients, and so forth. I shudder to think of the unforseen side effects of this, but it might be workable if your NPCs are sufficiently generic and all of one race, and they don't have need of the default dialog. Hope this helps.

Have you tried using the Texture Replacer (tr) command to dump out the list of textures in the NIFs? That's a lot quicker than opening each one in NIFskope.

You've set yourself quite a challenge. Our team just released a mod that has several scenes in it with large numbers of NPCs, and the Oblivion engine doesn't make that easy to do. It *is* possible, and I certainly encourage you to go for it -- but don't underestimate the challenge of getting it right. Those NPCs will do some amazingly stupid things when you start play testing, and you'll have to work around the issues that arise. I would suggest tossing out #4 right away. If there is only one way to play through your mod, you've just killed a lot of the re-play value. The battlemage ally concept is interesting. How about something like this: * Player acquires the magic/potion for a stealth approach and is given the option of allies or solo mission. * They can complete the mission either with stealth or combat, but the more allies they take along, the more likely enemies will detect them if they try stealth. * Once they are detected, battle ensues, and the odds are determined by how many allies they took along. You can make some enemy guards that are scripted to have a random chance of a direct StartCombat(Player) script function call, with the random percentage being directly proportional to how many allies the player chose to take along. If you do something like this, then it gives the player a lot of ways to approach the scenario, and you force them to make some tough choices. Take a lot of allies, you have a great chance to win at combat but a lousy chance of avoiding it. Take few or no allies, you have a great chance to sneak your way out, but if you get caught, all hell breaks loose. It sounds as if you've put a lot of work into your mod! I look forward to playing it, and please let me know if you need a beta tester, when the time comes. EDIT: Instead of just 9 battle mages, you could also consider offering the player three different pools of allies, with only up to 3 of each. Archers, mages, and warriors... Give them dialog of "I'll take 3 archers/2 archers/1 archer/no archers", repeated for each category. Then calculate your detection odds based not only on how many, but what kind. Warriors most likely detected, archers next (lighter, quieter armor), and mages least (no armor, and presumably some illusion magic for concealment, though you might not actually want to do that for real because the player couldn't see them either). Now the player has to factor in the survivability of their allies by category, and weigh that off against the PC's own choices of armor and combat style.

I'm so sorry! Actually, what happened here is that I replied during a short break in the middle of my workday. I remembered multiple replies, and didn't realize all of them but one were from Harvald. Just skimming the scrollback my brain registered multiple people, and I was in a hurry. I'm truly sorry about the slight -- it was absolutely not intentional, and I did actually follow all of your ideas except (so far) the one of deleting and recreating the pathgrid. The AI packages are simple, and the preferred path is an unbroken line of blue nodes. I tried deleting the connections where they are straying aside, and what happened is that they just strayed aside in a different place. Argh! My next step is to check the connection counts between cells, as Harvald suggested, and to take your final suggestion of deleting and recreating the pathgrid. If all that fails, I'll take your *other* suggestion of just leaving it alone, since my quest doesn't depend on their exact route. This is just an annoying cosmetic issue, not a quest-stalling fatal bug. Again, please accept my humble apologies for allowing my haste to displace good manners.

Ooooohhh, that bit about the cell border may be the key. This situation is, in fact, near a cell border. I'll check how many connections there are with neighboring cells. It's not a problem of being too narrow; it happens even if there is only one NPC walking through there at a time. Thanks for the tips, Harvald and others who've replied.