File information

Last updated

Original upload

Created by

Tiawar

Uploaded by

Tiawar

Virus scan

Some manually verified files

669 comments

  1. Tinien
    Tinien
    • member
    • 106 posts
    • 0 kudos
    Hi, Tiawar. I have a repeating bug with NPCs falling from Skingrad castle bridge despite UOP installed. UOP description says that "Using other fix mods with Unofficial Oblivion Patch may cause some fixes not to work at all or break it even more". How do you think could EBF and UOP conflict in some way and if yes then which fix in EBF.ini should be disabled so Toutius Sextius, Vandorallen Trebatius and others wouldn't fall from this bridge anymore?

    And one more thing. Imperial legion soldiers (which patrol Cyrodiil roads) sometimes go astray and ride through fields and forests instead of roads or appear right under a bridge although they should pass over it. And one time I saw that one of two imperial horsemen, which were passing "under" a bridge, was jerking strangely. When I came closer I was amazed by seeing that his torso was spinning rapidly in the direction of travel right through his legs and the horseback. I haven't seen such glitch so far. I don't know whether these two glitches (Skingrad bridge falls and going astray NPCs) are related but nonetheless decided to mention them together. They may have the same root cause (messed up navmeshes or something like that). Could EBF have anything to do with this NPCs straying? Or maybe it's vanilla bug like "fall from Skingrad castle bridge"? Or maybe OOO is the culprit (I play with OOO 1.5.5)? And of course I wish to know the cause of this first seen glitch with spinning torso of a horseman.

    Edit: one more bug - Imperial legion soldiers sometimes don't attack the enemy but stand still near their horse and mark time. And sometimes Imperial legion guards or city guards all of a sudden attack their fellow guards without apparent reason.
  2. XJDHDR
    XJDHDR
    • premium
    • 760 posts
    • 48 kudos
    Hi again Tiawar

    I have another thing I want to discuss with you about a potential bug. On the mod page for the Unofficial Oblivion Patch, it is stated that one of the known issues is that "All changes to load doors (such as the Bravil Skooma Den door being permanently locked) may not take effect if you have already visited their locations before installing the Unofficial Oblivion Patch as load doors' locations are stored in the save." I recently had a similar problem with a mod concept I was testing out. I'm still trying to work out exactly what causes this but I think that once I activate a door, I can't move it using my mod as the position and rotation data seems to get stored in your save.

    I am wondering how feasible it would be to stop Oblivion from saving extraneous door data. As far as I'm concerned, the only door data the game should be saving is it's lock state (locked or unlocked). Everything else (such as position, rotation, linked door, even lock level) should be defined only by loaded plugins.
    1. llde
      llde
      • member
      • 678 posts
      • 17 kudos
      These datas are stored for all persistent references. The fact that a reference position and rotation are stored, allow for permanent changes by scripts, as the SetPos/SetRotation functions.
      If changing the save/load routines to ignore these value, will break mods that use these functions.
      There may be a solution at these problems but it may be quite difficult to imagine (and maybe impossible to implemement).
      And it will probably require a modifications of savefile formats.
    2. forli
      forli
      • member
      • 2,470 posts
      • 71 kudos
      Maybe a possibile solution is adding a "Reset reference to base object" script command, so mods like UOP may manually call it on those specific doors they want to reset
    3. Tiawar
      Tiawar
      • member
      • 174 posts
      • 48 kudos
      Position/rotation is saved at the reference level so this is not specific to doors. Also, changes to the parent cell, position and rotation all count as 'moved' so changing one of those will cause the other two to get saved as well. This cannot be changed without changing the save file format. What can be done is to prevent the automatic setting of the change flag that happens for all persistent references in exterior cells when the cell is loaded. After loading the cell the parent world space adds all matching refs from its persistent cell to the actual cell. This causes an update to the ref's parent cell which (unnecessarily) marks the ref as 'moved'. I could add this as a patch in the next version. For objects like doors it should resolve the problem in most cases provided the patch has been activated before the first time the cell was loaded. However, if the ref is moved by other ways (SetPos, SetAngle, MoveTo, etc) then the position/rotation will be saved and subsequent changes at the mod level will continue to have no effect.
    4. XJDHDR
      XJDHDR
      • premium
      • 760 posts
      • 48 kudos
      @Ilde
      I did forget about scripted changes but when I said that nothing other than lock state should be saved, I was referring to regular gameplay where this is the only thing that changes. Script and console caused changes to the other items should definitely always be saved. I realise I didn't properly explain my testing though: Basically, I moved a door in my mod by editing the reference's position data (no scripts or console commands were touching it). In my testing, I found that the door would sometimes have the position and rotation data that my mod gave it after uninstalling it.

      @Tiawar
      Your proposed solution sounds good. Can't think of anything that would break by doing this and I for one would greatly appreciate such a patch. I think altering the save format should be avoided unless absolutely necessary and as I said above, scripted changes and the like should definitely be saved and override mod changes.

      I was actually going to say that Bethesda should have implemented a way of only saving certain reference data when a script command flags this data as changed. But you say that the game already has such a thing but flags the reference unnecessarily?
    5. Tiawar
      Tiawar
      • member
      • 174 posts
      • 48 kudos
      The game uses change flags to track which object or ref needs to save what kind of data. Scripts are not the only things that cause changes. Any moving actor needs to have the new position stored in the save game.
      If you are interested you can see the change flags for refs in game by turning on debug text (tdt) and switching to page 29 (sdt 29).
  3. Surgo
    Surgo
    • member
    • 16 posts
    • 0 kudos
    Hi Tiawar,

    You mention in the docs the following:

    > However, it is currently NOT possible to compile the plugin from the code as it is missing the project that recreates
    > the game engine classes and maps functions to memory addresses.
    > This project is HUGE and currently not for share (not in a sharable state anyway...).

    Regardless of the shareable status of said project, would you be willing to publish a document / spreadsheet that lists the functions and their corresponding memory addresses? That would be very helpful to those of us looking to write OBSE plugins.
    1. Tiawar
      Tiawar
      • member
      • 174 posts
      • 48 kudos
      A "spreadsheet" like that, if done properly, would be a very large and time consuming project in its own right. And knowing the context is almost as important as knowing the addresses of functions and variables in the code: Just because there is a function called "x" doesn't mean it's safe to call that function anytime.

      I'm afraid, the release of the class library, while definitely planned, has to wait until it has reached a more stable state where it doesn't change almost daily anymore. If you're looking for something specific you can always ask, of course.
  4. KingoftheHole
    KingoftheHole
    • member
    • 1 posts
    • 0 kudos
    I need a new version of Pluggy because all of a sudden mine is only 1kb big.
    But I can't find a download anywhere, according to mod info I need v.132,
    but i remember Esyl stopped with version 122.

    Does any of you know more?
     
    Greetings KingoftheHole
    1. Striker879
      Striker879
      • member
      • 8,956 posts
      • 241 kudos
  5. XJDHDR
    XJDHDR
    • premium
    • 760 posts
    • 48 kudos
    Hi Tiawar

    I found a bug that I'm wondering if you can look into. Basically, I tried to see if Oblivion supports the keys F13 to F24. I have a mouse and keyboard that both have extra buttons and I have assigned these extra buttons to those function keys. This is what I've found:
    https://imgur.com/a/WpqcyUg
    • F13 to F15 work without issue.
    • F16 and F17 are recognised by Oblivion but the Controls menu displays their Scan Codes rather than "F16" and "F17".
    • F18 to F24 are not recognised if I try to bind them.

    I would like to try modify Oblivion.ini to see if the game recognises these keys that way but I have no idea how Oblivion is storing these keys. This is from my copy for the three controls in my screenshot but the first 4 digits don't appear to be Scan Codes or Virtual Key numbers.
    Rest=0014FFFF
    QuickSave=003FFFFF
    QuickLoad=0043FFFF


    Would you be willing to try fix Oblivion so that it recognises F18 to F24 and possibly displays all of them correctly in Controls settings?
    1. laulajatar
      laulajatar
      • supporter
      • 327 posts
      • 17 kudos
      At the bottom of this page is explained how the ini is storing those keys:
      https://en.uesp.net/wiki/Oblivion:Ini_Settings
    2. Tiawar
      Tiawar
      • member
      • 174 posts
      • 48 kudos
      I assume you tested this by assigning keys in the controls menu. The game uses DirectX scan codes to identify keys. it seems like your keyboard sends scan codes 0x67 (103) and 0x68 (104) for F16 and F17. If you google for a list of DX scan codes you'll find that these values aren't defined. The menu doesn't show a name because the values don't have define names. The returned values are probably unique to your keyboard. I assume that the keys for F18-F24 return values outside the single byte value range so they cannot be handled by the game.

      Intercepting the keyboard signals and mapping the unsupported keys to (unused) scan code values would probably work but that wouldn't be a bug fix. It sounds more like a job for a UI mod plugin. ;)


      Btw., the values in the ini file are hex values in the format 'aabbccdd' where

      aaunused
      bbkeyboard scan code
      ccmouse button
      ddjoystick/gamepad key

      0xFF means 'none'.
    3. XJDHDR
      XJDHDR
      • premium
      • 760 posts
      • 48 kudos
      You are correct, I was testing by using the Controls menu to assign keys. I should clarify as well that when I said that "F16" and "F17" are recognised by Oblivion, I mean that whatever control I assign to those 2 keys happens when I press that key (for example, if assigned as my picture shows, pressing F17 makes the game load the last quicksave). The only issue is that they are displayed incorrectly in the Controls menu.

      With all due respect, I don't accept your claim that F16 to F24 are keys unique to my keyboard. If anything, these keys would be unique to AutoHotkey but even that is a stretch from what I'm seeing. To assign these keys to my mouse's and keyboard's extra buttons, I had to write some AutoHotkey scripts to send the key remapping programs for my keyboard and mouse (Logitech Gaming Software) the keys I wanted to assign to those buttons. The only reason for this though is because those keys are not present on my keyboard and so I can't type them out. But when my scripts sent a virtual keypress to LGS, the software recognised the keys. For example, after my script sent a virtual "F13" keypress, LGS informed me that "F13" was now assigned to that button/key. I also tried doing that with oblivion and it too assigned "F13" when AutoHotkey sent the "F13" key press. It just seems odd that LGS would recognize these keys in the same way as AutoHotkey if the latter had just made them up or something. Or that oblivion would recognise them up to F15.

      I wrote up a list of the Scan Codes that AutoHotkey recognises for the keys F13 to F24 here: https://github.com/XJDHDR/xjdhdr-random-code/blob/master/AutoHotkey/F13%20-%2024%20Virtual%20Keys%20and%20Scan%20Codes.txt
      I did see that a lot of Scan Codes lists don't have anything written down for F13 to F24 but I'm pretty sure that those lists are incomplete. I did manage to find this PDF from Microsoft: https://download.microsoft.com/download/1/6/1/161ba512-40e2-4cc9-843a-923143f3456c/translate.pdf I noticed that the figures in the "PS/2 Set 1 Make" column are an exact match to the figures in the list I wrote.
      Finally, I found this spreadsheet written up by Taran at Linus Tech Tips: https://docs.google.com/spreadsheets/d/1GSj0gKDxyWAecB3SIyEZ2ssPETZkkxn67gdIwL1zFUs/edit#gid=0
      In short, officially F13 to F23 use the Scan Codes 0x64 to 0x6E and F24 uses 0x76.

      So as far as I'm concerned, the keys F18 to F24 have official Scan Codes assigned to them, they are single byte values and the only thing that makes them special or unique is that most keyboards don't have dedicated buttons for these keys. So no, I don't believe that anyone would need to intercept signals or remap these keys to other Scan Codes. Instead, Oblivion doesn't recognise these keys because Bethesda either never programmed the game to recognise them or did so in a buggy way. The latter wouldn't surprise me since they didn't properly program Oblivion's handling of "F16" and "F17".
    4. Tiawar
      Tiawar
      • member
      • 174 posts
      • 48 kudos
      I can only try to figure out what is happening using the information you give me. Judging by your initial description and the picture, the point is that the game is receiving keyboard input for keys F13-F17 but not for keys F18-F24. The question is of course why? Oblivion gets its input data from the DirectInput driver. If the flag for the scan code is not set after a call to GetDeviceState() then the key is not pressed from the game's point of view. The DirectInput driver is responsible for querying your keyboard, not the game code, so this is not Bethesda's fault. Without knowing what actual scan codes these keys are supposed to emit I simply offered ONE possible explanation as to why this could happen. Some keyboards DO use multi-byte sequences for extended keys. And by 'unique' I meant that it is not a given that all keyboards with extended keys ever produced always emit the same scan codes for the non-standard keys.
      I did some more research today and I think I now have the real cause for the problem. While I was unable to get official information about DirectInput I found several forum posts that suggest the problem lies within DirectX itself. Here is a quote from a post I found in a Final Fantasy XI forum:

      "i had lengthy talks with devs like 2 years ago and there is only support for f1-f12 we also found out iirc directx was only made with support upto f17 or f18 anyway"

      and another quote from geekhack forum:

      "One frustration, is that for DirectInput games, not all of the keys that are known to windows, and an even smaller sub set of those that are defined in USB, can be used due to the age of that spec. MS has even deprecated it - the current 'correct' way for a game to get keyboard input on a PC is via the OS call GetKeyboardState and/or GetKeyboardAsyncState."

      So the short answer is most likely that keys F18-F24 are simply not supported by DirectInput and that's why the game doesn't receive input data for these keys. And with that in mind my proposed solution still stands: Hook the game code and use windows functions to get input data for the extended keys using OS keyboard functions. Then map the virtual key codes for these keys to scan codes in the recognized range using values that are not already defined in the DirectInput scan code enumeration.
      Of course, if an external tool like AutoHotkey can do this too, all the better, since it won't require a game hook.

      As for the naming issue, again, we need to look at DirectX. I was not sure whether the game uses a DirectX function to get string representation for the scan codes or if it does the conversation itself using a string table. It turns out it uses a table of string game settings that match the DirectInput scan code enumeration with DIK_MEDIASELECT (0xED) being the maximum defined value. The enumeration has gaps and only the defined values have settings (they all start with "sKB"), the values not defined in the enumeration (plus some values only relevant to old Japanese computers) are set to NULL. When the menu looks up the name for a scan code it uses the game setting for that code and prints its value. If there is no setting for a code it just prints the code's numeric value.
      What could be done with a hook is to create game settings for all the undefined values and give them names based on the scan code (like "sKBScanCode67"). These settings could then be configured normally in TES4Edit or similar tools to hold the name of whatever key it maps to on your system.

      However, as I said I don't really consider these to be bug fixes. They are more like extensions that add support for extended keyboard keys to the game.
      I don't really like the idea of adding something like this to EBF. It's just not the right place. IMO patches like these belong into one of the UI enhancing mod.
    5. XJDHDR
      XJDHDR
      • premium
      • 760 posts
      • 48 kudos
      Thing is that when I read your reply, it sounded to me like you were calling the other function keys special keys that only exist on my keyboard and are not standard keys defined by any spec. If this isn't what you were trying to say, then I'm sorry for the misunderstanding. My reply thus was just to point out that they are in fact standard keys and are being sent as per spec. If it looked like I was saying something else, then I'm sorry once again.

      If the lack of support for F18 onwards is due to DirectInput not supporting them, then you are correct that this isn't something EBF should be touching. It's a shame that, thanks to API choice, Morrowind through OpenMW supports all 24 function keys whereas Oblivion only supports up to F17.

      For F16 and F17, I'm not sure I agree with you there. If there are no entries in that table you mentioned for these keys that Oblivion already supports and this is the reason they don't get displayed properly, this looks like a bug in the code to me. This wouldn't be adding support for extended keys but fixing the keys that Oblivion already supports. Just to make sure I understood, the only thing that needs to be done is to add two entries to that table to get the values from a sKBF16 and sKBF17 setting that needs to be added by a mod? If so, I could try ask the UOP team if they are willing to add those settings. But again, just for these two keys since oblivion already supports them. Any other key would be the job of another extension.
    6. Tiawar
      Tiawar
      • member
      • 174 posts
      • 48 kudos
      I can see the game code but I'm not an expert on keyboards so I'm relying on researched information here. It seems like the stuff present in the DirectInput key enumeration is pretty much the 'common ground' whereas most of the other values depend on the keyboard layout. Newer standards like the USB key codes apparently use different values.
      I did a few tests iterating over all 256 virtual key code values and checking the mapped scan codes on my keyboard. Turns out several virtual keys map to the same scan code. When doing the opposite test (scan code to virtual key code) the first value not defined in DirectInput (0x59) maps to VK_NUMPAD5 for some reason. The next 3 values all map to VK_NONAME (reserved value), followed by 0 (undefined) and one more VK_NONAME, so yeah, it's all a bit weird. Other values seem to be specific to the keyboard layout as they only make sense for specific languages. The values for F16-F24 appear to be the same as in your case even though I don't have them on my keyboard. The Windows API function 'GetKeyNameText' I used returns nothing for these keys, but I assume this will be different with a keyboard where the keys are present.
      I think the extended function keys are the only keys were we can assume that they have the same codes at least on newer keyboards. I've compiled a test plugin for the extended function keys that you can try:

      https://www.sendspace.com/file/2jah02

      Does this plugin work for you?
    7. XJDHDR
      XJDHDR
      • premium
      • 760 posts
      • 48 kudos
      Sorry for taking so long to get back to you. I gave your test plugin a try. The game now recognises all 24 function keys. I'm not sure if the plugin was supposed to fix the UI problem but if it was, then it's not working. The keys after F16, including the now working keys, all display as their Scan Codes rather than the key name.

      Thank you very much for fixing this. I am curious though as to what the problem was. Is it still DirectInput or something else?
    8. Tiawar
      Tiawar
      • member
      • 174 posts
      • 48 kudos
      As mentioned above I use Windows API functions to query the state of the function keys using virtual key codes. Then I check the scan code mapped to the virtual key and manually set the value in the keyboard buffer just after it got filled by DirectInput. I tried a similar technique to get the key names from the OS/keyboard but apparently it does not work for the function keys. So here is an updated version with the function key names hard-coded. This should show the proper names in the Controls menu.

      https://www.sendspace.com/file/09py8n
  6. AndalayBay
    AndalayBay
    • supporter
    • 2,404 posts
    • 95 kudos
    Can you do anything about BEX crashes? I'm getting a ton for some reason and I can't figure out why. I have to save every time I enter or leave an interior as it's almost a guaranteed crash when I do. I don't recall it being this bad the last time I played Oblivion.
    1. Tiawar
      Tiawar
      • member
      • 174 posts
      • 48 kudos
      BEX is just access violation. It's probably the most common kind of app crash, often caused by NULL-pointer access.
      A crash log would give more information about the cause.
    2. AndalayBay
      AndalayBay
      • supporter
      • 2,404 posts
      • 95 kudos
      Would you be interested in seeing the last Windows crash dump? The last one occurred when I was riding along the road. It might have been a bad spawn point, but it didn’t happen again when I reloaded the game. Windows isn’t providing much information, probably because I’m still running Win 7.
    3. Tiawar
      Tiawar
      • member
      • 174 posts
      • 48 kudos
      If you have a repeatable crash you can always post crash info from the error message that pops up. If you've already closed the message box the information can be found using the Windows event viewer (Windows Logs -> Application). The information I need is "Faulting module name" and "Fault offset".
      A better solution would be to use this plugin here https://www.nexusmods.com/oblivion/mods/48503 which produces a more helpful crash log for the game. Use pastebin or a similar site to post the crash log if it is too long.
      In any case don't raise your hopes too high. Looking at the crash info might lead us to the source of the crash but there is an equal chance it will give us no clue at all.
    4. AndalayBay
      AndalayBay
      • supporter
      • 2,404 posts
      • 95 kudos
      I'm using Crash Logger - it's blank. It doesn't catch these crashes. There is no offset or name - all blank. Here's an example from event viewer:

      Faulting application name: Oblivion.exe, version: 1.2.0.416, time stamp: 0x462392c7
      Faulting module name: unknown, version: 0.0.0.0, time stamp: 0x00000000
      Exception code: 0xc0000005
      Fault offset: 0x00000000
      Faulting process id: 0x438
      Faulting application start time: 0x01d4771a15c645ad
      Faulting application path: D:\Games\Oblivion\Oblivion.exe
      Faulting module path: unknown
      Report Id: 7f26f5c1-e319-11e8-bf37-54271e32917f

      Here's the error report:
      Fault bucket , type 0
      Event Name: BEX
      Response: Not available
      Cab Id: 0

      Problem signature:
      P1: Oblivion.exe
      P2: 1.2.0.416
      P3: 462392c7
      P4: StackHash_e98d
      P5: 0.0.0.0
      P6: 00000000
      P7: 00000000
      P8: c0000005
      P9: 00000008
      P10:

      I was working with DavidJCobb on this because at one point I thought that Northern UI was the culprit, but I'm not using Northern UI anymore. These crashes are so frequent that it's getting to the point I can't play Oblivion anymore. I'm trying to get a mod update released so I have to play through. Thanks anyway. I saw that you had fixed some of the wilderness crashes, so I was hoping you had some ideas for the crashes I'm getting.
    5. Tiawar
      Tiawar
      • member
      • 174 posts
      • 48 kudos
      Not even a stack trace in Crash Logger log file?
      That of course leaves us with no hint where to start looking. :(
      How big is the Windows crash dump you mentioned?
    6. AndalayBay
      AndalayBay
      • supporter
      • 2,404 posts
      • 95 kudos
      I just upgraded crash reporter, so we’ll see if the new version can capture something. In the past, the log has no entries at all - it’s 0 bytes. I don’t think the Windows crash dump has much more than what I posted. I’m not at my game machine right now. When I play again, I’ll grab all the logs and reports when it crashes.
    7. AndalayBay
      AndalayBay
      • supporter
      • 2,404 posts
      • 95 kudos
      I might have found the issue! I have a fairly old video card (Radeon 290X) and I've always found that it's best to use the drivers from the time frame when the card was released. I was having some issues with the driver I had installed so I decided to upgrade to the latest version. Bad idea. Not only was Oblivion crashing but I couldn't exit the CSE without a crash so I uninstalled the latest drivers and went back to a newer version than the old one I had installed. Basically I went with the latest version of the Crimson drivers versus the Adrenaline drivers AMD has now. That seems to have worked. I have no more problems with the CSE and I haven't gotten any more BEX crashes.
    8. llde
      llde
      • member
      • 678 posts
      • 17 kudos
      The last AMD drivers give me a fair share of troubles with Oblivion and not only, with an RX580.
      (So many that I'm currently playing with Linux)
    9. AndalayBay
      AndalayBay
      • supporter
      • 2,404 posts
      • 95 kudos
      I settled on Crimson 16.12.1 and they seem to be working quite well. I had to search and I found a site called Guru3D that has all the old drivers.
    10. AndalayBay
      AndalayBay
      • supporter
      • 2,404 posts
      • 95 kudos
      Spoke too soon. The crashes are back and as usual, the logs have no info. I guess I'm screwed since Mickeysoft has dropped support for Win 7 so the crashes don't have any info.
    11. llde
      llde
      • member
      • 678 posts
      • 17 kudos
      StackHash crashes seems to be derived from the stack pointer to hit a stack guard instead of correct stack frames or an issue that cause the EIP register to be 0.

      One of the possible causes are softwares that inject into the program address space (as Afterburner) or programs that inject themself as a layer between an application (or more often every application) and the Kernel (syscall hooking) . You may try to start Oblivion with the less software active in absolute Antivirus/Firewall/Antimalware included if 3rd party (of course keep the PC offline).

      Regarding the specific beheviour of CTDs during transitions, the first time I got them the issue was caused by Pluggy (HUD mode), the last time by Oblivion Reloaded SMAA (disabling SMAA fixed the issue).
      Also mangling with some OSR settings, may prove beneficial. (In particular Heap an Threading related)

      If this doesn't help, you can always try with linux and wine-staging (or wine-gallium-nine), I always found Oblivion to be more stablier under wine, than windows.
    12. AndalayBay
      AndalayBay
      • supporter
      • 2,404 posts
      • 95 kudos
      Ilde, thanks for you reply. I’m not using any of those programs. I know about Pluggy causing crashes so I uninstalled it as soon as I was done with it. I don’t use OSR or OR. My virus scanner is Microsoft Essentials. Interesting note about Wine. I might check that out.
  7. Tinien
    Tinien
    • member
    • 106 posts
    • 0 kudos
    The problem with corpses in T-pose (when coming next time and reloading this cell) persists. It happened only once so far but still happened. EBF 2.1. When played with 2.0 I didn't encounter this bug. SavedHavokDataFix is enabled.
    And one more thing. Don't know if this relates to EBF but I'll mention it nonetheless. Sometimes it happens that corpses disappear after revisiting the cell in which they are lying. First I thought that they fall through the ground but thorough search "underground" shows no sign of them there. Not enough time has passed for these corpses to disappear "on schedule". So maybe it is game engine itself that removes them in order to free memory? If so then is there any way to change conditions on which removal of "excessive" corpses triggers? And does EBF have anything to do with it?
    1. Tiawar
      Tiawar
      • member
      • 174 posts
      • 48 kudos
      Thanks for the feedback. It's quite difficult to verify that a randomly occurring bug does not occur anymore. Since you're still seeing T-poses I guess preventing the rag doll data overwrite is not enough to stop the problem completely as I had hoped. I'll look into the issue again when I find the time.

      For corpses disappearing, if it's really excess dead removal then you can tweak game settings iRemoveExcessDeadCount, iRemoveExcessDeadTotalActorCount and the 'complex scene' versions (iRemoveExcessDeadComplexCount and iRemoveExcessDeadComplexTotalActorCount). Setting these to very high values should disable the corpse removal altogether.
      Otherwise I don't know what could cause this. The havok data fix only handles rag doll data so it cannot make corpses disappear.
  8. Kakumei88
    Kakumei88
    • member
    • 13 posts
    • 0 kudos
    i was curious, is this redundant with the unofficial patches or is this a great addition alongside unofficial patches? i don't feel like digging through matching changelogs for hours and hope someone already knows.
    1. DmxLuna
      DmxLuna
      • member
      • 17 posts
      • 1 kudos
      You use this along with the 3 Unofficial patches
    2. Kakumei88
      Kakumei88
      • member
      • 13 posts
      • 0 kudos
      alright, thanks!
  9. etayorius
    etayorius
    • member
    • 2,396 posts
    • 188 kudos
    Tiawar, is there anything you can do for corpses falling in slow motion? Aslo, does "Fixing" this issue will break jumping?

    [edit]

    I am getting the Slow Animation on doors, spells and sword sparks. The thing is i checked the log of EngineBugFixes and i can see this:

    2019/01/10 09:06:36 [ INFO ] GlobalAnimTimerFix: Patch was installed successfully.

    So it's supposed to be working, but it's quite isn't. What seems to work is quitting the game and launch it again, then it would work for a while, but the issue seems to come back after about 2-3 hours requiring another reboot. Is this supposed to happen? by the way, i am only using 5 esp mods along several OBSE dll's, but mostly edited combat settings Esp files. No textures, no models or nothing. I was supposed to play a completely mod free run but in the end i decided to use a a few very simple mods.
    1. Tiawar
      Tiawar
      • member
      • 174 posts
      • 48 kudos
      Falling corpses are Havok controlled. I guess the speed is controlled by the applied force, gravity and the values stored in the collision objects. Again, not much I can do atm. Maybe when more information about the Havok internals is available.

      Your animation problem doesn't sound like the A-bomb glitch. To make sure set the debug level in EBF ini file to 2, load the problematic save file and quit the game. There should be a line in the log file about the anim timer's current state. Can you paste it here?
    2. etayorius
      etayorius
      • member
      • 2,396 posts
      • 188 kudos
      Sure, when i get the issue next time, i will post the log info.

      I been having many other issues too, most of them are just annoying and harmless.

      The first issue i noticed is with items not being displayed in the list from containers, more specifically Weapons and Armor. I usually put a massive amount of them in a single container, i think i might also repaired most of them to 120 condition using hammers. These items are completely missing from the container unless i click the "Take All" option, then they will pop back into my inventory. I believe they are still there, just not being displayed for some reason.

      The third issue i been getting is when continually casting healing spells, the sound will not play until after more times if casting the same spell.

      The fourth issue i been getting, (someone already mentioned it in the comments) is that removing and placing items from a dead npc will dupe it, then removing and placing it again in the same corpse npc sometimes will crash the game, sometimes it won't... not sure what the deal is, it's not consistent but it does seems to be happening. There must be something else at play.

      Finally... those crazy Slaugtherfish, what causes them to spawn in land? i mean it is funny and amusing every time it happens, but Is it a feature or just another bug by Bethesda? is there anyway it can it be fixed or patched if it's not intended? I just saw 5 of them near each other in row, just jumping in synchronition, it kinda seemed like a Circus Show.

      I been playing the past week for 2-3 hours straight every day, so i been noticing most of this stuff more than usual.
    3. Tiawar
      Tiawar
      • member
      • 174 posts
      • 48 kudos
      First and fourth issue are related. As mentioned before I currently have no idea how to fix it without large scale changes to the inventory code. Maybe in a future update, but not anytime soon.

      Third issue may be fixable if I can reproduce it.

      Slaughterfish on land I remember seeing it quite often in the past but not so often anymore. I'll look into it but it could be difficult to track down since it usually happens randomly.
  10. etayorius
    etayorius
    • member
    • 2,396 posts
    • 188 kudos
    Thank you again for the new update. Quick question though, "Fix #51) SavedHavokDataFix (v2.0)" does this corrects NPC and Creatures from reseting to their default value upon death if they have been scaled?
    1. Tiawar
      Tiawar
      • member
      • 174 posts
      • 48 kudos
      No, the scale reset is caused by the Havok controlled actor using the scale and position of the collision objects in the skeleton.nif file which is the same for all actors. To change this one would have to dynamically scale the collision objects but I currently have no idea how to do that.
Top