Read my former posts, to me this discussion is over and pointless.

Cheers mate

Note: I'm not joking or using sarcasm, I have no more problem whatsoever.

I just had the misfortune of doing... something... that's now causing a mod to crash on save, which all 4 times thus far has kept the file intact and all backups preserved.

So it looks like this one is fixed, because the CK dumped a .tes file for temporary storage which is truncated at the point it crashed. The .esp file is untouched, and none of the backups in the backup folder have been harmed either.

Good news . That one was really scary.

That bug has got a workaround - Look into the OP.

the interior to exterior CTD is definitely a game engine issue.

if by some miracle bethesda were to fix this it would most likely have to be a low-level game engine change (just my guess).

the CTD is caused because of the the difference between how the engine handles esp vs esm memory. esp files have a much lower memory ceiling than esms, which is why none of the very large interiors in skyrim.esm crash on exit, and why the same exact interior on your mod's esp wont crash when it is changed to an esm.

Bug list updated. If the Creation Kit crashes whilst saving, a backup file with the extension '.tes' will be created in your folder, and your other backups will be unharmed. To restore your data, simply switch the extension from '.tes' to '.esp'.

Ok thanks.

If that is true then the ck shouldn't allow you to do something that crashes ingame, should have a size limit or something. Anyways, the bug is up there, that's all I want, to report it.

Cheers!

I don't really see the need to go ahead with such a change when there are easier alternatives available. Such as:

• Update the Creation Kit so that it creates .esps with the same memory ceiling as .esms.
  
• Allow the Creation Kit to create .esms.

Or....

FIX IT!

Just kidding

No. You don't want to do that. The .tes file will be truncated and therefore corrupted. DO NOT use it. The .esp file won't be current but it won't be lost either.


The Creation Kit doesn't have anything to do with the memory limitation issue. That's what I've been trying to tell people, but all I get is "you're not a developer" as a reaction to that. The GAME executable is the one with the limitation in place. THAT'S where the issue ultimately has to be fixed. The CK doesn't have this limitation otherwise as soon as you reach it you'd either no longer be able to edit the level or it would crash, costing you whatever work you'd done in that session.

As far as the CK being able to make .esm files, it can, but you have to use the version control system for that.

And you aren't, that's why people say that, you shouldn't be offended. And again, there's no proof whatsoever that the ck has or has not a part in the bug, also, what are you trying to achieve here? The removal of the bug from the bug list? So others keep loosing time and work like I did? Let the bug be so Bethesda and other modders see it.

We aren't here to discuss that kind of technical details, we use the ck to mod, anything that results in bug we report, Bethesda developers are the ones that have to track down the bug and their origins, not us.

Yes, actually there is proof, but apparently logic isn't something people seem to care about anymore. As I said, if the CK had the bug, you'd be halted in place upon hitting the memory limit, but hey. I guess one can only be a developer before one is allowed to comment on how things actually work.

Yes, I guess that's the logic, one can only talk like a developer of Bethesda when he actually is one.

None that you say convinces me, and the more you say the less I'm convinced, there's a TON of other bugs that make the game act strange or crash and that don't have impact at all in the ck, at least to our eyes.

LOL, is this still going

Apparently he wont stop until this HUGE bug is removed from the op. I've said I had no more problems and that the discussion is over, but he isn't satisfied, what one can do?

To me is as simple as "it's a bug, report it and warn the community, if there's a way to counter it explain it", simple. I don't care about technical details that only Bethesda knows about, that's their job.

the CK editor works a little differently than the run time creation engine (gamebryo). fundamentally, the CK's render window does not represent a true real-time environment (which is in part why running the CK app is way more system intensive than running tesv.exe), and as such it cannot exactly predict something like this (i am not a software engineer these are just my educated guesses). this is the same for any game engine editor like Unity3D and UDK, although those 2 have an in-editor real-time preview. the CK does not.

as far as i know there are no hard measurements any of us know of to calculate exactly when that ceiling is reached. it doesnt have anything to do with physical size (total area of the mod), it is not even entirely based on a hard number object count. i am pretty sure the esp "runs out of available memory" based on how the engine calculates all of the simultaneous renderable assets, and (this is where i personally believe the bug happens) when it loads a new area, it doesn't purge the ram thoroughly before the next area starts loading in more assets (hence causing a memory crash).

for all we know maybe esp's are supposed to have the same memory ceiling as esm's, but the game engine itself mistakenly refuses to purge all of the ram before loading the new area on esp's only. this would require a low-level engine fix if this is true. because if it is true, the CK is doing its job by allowing you to create the intended number of assets per cell. the error is on the runtime engine side

Maybe you are 100% right, but all I want is the bug fixed.

Squash the damn thing!

I think the distinction that Arthmoor is trying to articulate is that I can easily use the tools at my disposal to crash the game, on demand. All I need to do is drop a world object into the world with a collision mesh and set the Scale property of one of the NiTriShapes in that mesh to below 0.001. Boom, instant crash.

So who's fault is that? It's not NifSkopes, where I made this mistake; it's the game's fault for even attempting to render this and blowing up when it tries.

Another example: Force-unequipping a weapon with a custom equipment slot and attached to a base skeleton NiNode will cause the player's skeleton to deform and the game to subsequently crash. Who's fault was that? The CK's, for letting me specify custom slots? NifSkope, for letting me set the weapon's attachment point as something other than the default weapon bones? Notepad++, for letting me even write the script in the first place? No, it was the game for attempting (and failing) to perform the operation.

To use an even more mundane example, placing 5000 iron swords in the same cell as me usually hangs my game. Was that the CK's fault for letting me do it?

So in the context of the bug, the question that needs answering is, what set of runtime circumstances cause it to occur, and are those parameters duplicated anywhere else in the (vanilla) game? I hope I'm making sense.

Yes you are, but the question is:

"Bethesda, please look at this bug and fix it because it's ruining the work of many modders, thanks and keep up the great work."

We aren't suppose to reproduce every condition in which the game/mod/ck or whatever bugs on us, they have a test crew, that's their job. Also, and since they make the game, the tools and use the third party tools (official ones), I'm pretty sure they can trace bugs way faster and better than us. Hope I'm making sense too

LOL @ Arthmoor being some kind of grumpy bugfix killjoy

I think this is actually the thing that needs repeating:

Enough of this pointless bickering. We're not going to get anywhere if we just keep fighting over who's opinion is the right one. Let's just drop it right here and admit that there is a bug, and it needs to be fixed. The technicalities of the bug are unimportant, fixing the bug is what matters.

End of discussion.

i agree with you on this. IMO mostly just matters that the bug is given to bethesda in the first place, as long as the message is delivered. however, specifying it as a CK bug may initially throw off the QA team and waste many hours of testing. trust me, when i am trying to fix bugs on my simple mods based on vague or incorrect reports from users it ends up wasting a lot of my time because i started looking in the wrong place.

ideally, bugs should be reported with as much detail as possible with as precise details as the reporter can give.

yes, this bug should be brought to bethesda's attention but not specifically as a "CK bug" (since none of us really know for sure, but most of the evidence is pointing to the game engine for this particular bug). i'm not necessarily saying we should take it down from the thread, just saying that it should be as specific as possible, so as to not cause any initial confusion.

Why do we keep assuming that we know how Bethesda works and how they program their stuff? If he did know that why didn't we fix the navmesh bug amongst other old and new bugs?

Also the bug is in the game engine section of the post, so unless the people that reads the post doesn't know how to read that isn't a problem or is it? Damn people, do you want the bug to be fixed or not?

THANK GOD! ^^ AMEN TO THAT! ^^


The bug is in the engine section of the post, I don't know if that is correct or if they will laugh at us, but all I want is it fixed and reported, also I've made a video of it to document it and both of us have provided a solution, so now it's up to them.