Let me start of my defining the problem:

Defining quad and cell:

Imagine the game as a 2 dimensional map, looking down on top of the map there is an x,y grid. http://www.instructables.com/image/FK077AIFR12319A/X-Y-Axis-Graph.jpg

Look at the X axis (east to west in the game) and keep this in mind.

Now look at how the game is set up:

The game is made of cells and quads that define the playable space. This image explains what a game cell is and how they work in a 2d image http://cs.elderscrolls.com/images/8/80/Overviewgrid.jpg

So looking down onto an Oblivion or Skyrim map as a piece of graph paper we get this: http://cs.elderscrolls.com/index.php/Oblivion_Units

So there we have cells, quads and the game axis. Here is the Mesogea map and the Skyrim map as that grid in comparison:
http://mesogea.spruz.com/user/380826/members/A7EDA3B7-F0E8-43D9-86CE-5576CA91B0E6/big_201220807012148.jpg

You can see that Skyrim is built within a 4x4 quad range, that is 128x128 cells approx. Mesogea is considerably bigger, as is the Middle Earth Role Playing map and other extended worldspaces. In order to go much beyond Skyrim in a meaningful way, that is encompassing other regions of Tamriel would require a map beyond the 128x128 cell range.

Defining the problem:

Watch this Youtube video and see how the horses react. These creatures are placed on the cusp of the 128 cell grid. As the horse walks from cell 64 into cell 65 the problem occurs: http://www.youtube.com/watch?v=qndePb5jEO4&feature=youtu.be

Recall our speaking about the X,Y axis? and that the X axis is east to west (or vice versa). This issue ONLY occurs when going beyond cell 64 east and cell 64 west (ie: -64 on the X axis from the centre of the game world point 0,0 and +64 on the X axis from point 0,0 again).

Defining this area by map we can see on the Middle Earth map made up of an ingame heightmap showing the QUADS layout;

http://img13.imageshack.us/img13/8141/problemarea.png

The area in RED is affected by the bug. The area in BLUE is workable, as in there is no issue as highlighted in the video.

As you can see this is not an inconsiderable area.

Comparing this with Oblivion:

Oblivion provided a 16x16 quad workable area. Imagine the Middle Earth map above with no red area, that is what Oblivion provides for. This bug appears unique to Skyrim.

Bethesda and fixing it:

We received a reply from Gstaff who represents Bethesda as a collective here on the forum. They state that the problem is with HAVOK and is not going to be fixed by Bethesda. We can debate the validity of this elsewhere.

Please try to keep to the following in this thread:

What this thread is for:

1. Coming up with ideas to overcome the bug.
2. Posting results of tests
3. Addressing Havok and CK issues to try to resolve the bug

What this thread is not for:

1. Arguing the merits of large worlds
2. Arguing the merits of the thread being here (if you dont like it, make your own elsewhere)
3. Having a dig at each other, complaining about Bethesda (whether we think it thoroughly deserve or not)
4. Trying to force Bethesda to do something about it. (whether we think they should or not)

I am not a moderator, and I am quite guilty of sometimes going off thread, banging on about a subject, getting annoyed and hot under the collar. I will try not to. If we end up with the usual slanging match I will ask a moderator to kindly cull anything that isnt focussed on resolving this bug and would ask others to do the same, even if its me banging on again

I would really appreciate it if one of the moderators, preferably someone with an interest in this particular subject to drop in now and again and do a bit of policing the comments to keep it on track, from the usual unbias perspective.

So lets see what we can do:

Thanks for setting this up.

Can someone please confirm that the issue is beyond -64 x to +64 x ? Specifically, that's 129 cells - not 128, because of cell (0,0) which has positive x coordinates. If the issue is based on the x-axis displacement then we would expect it to happen outside the range
-65 < x < 64 ( or possibly -64 < x < 63 ).

As we have the bug characterised at the moment it rather implies it's about cell numbering, not displacement.

Its -64 < x < 63

Basically, the only usable area is 128 cells across the 0 position.

Could a repro-plugin be uploaded? Not promising anything but I can try looking into this if I get time.

I suspect I may have been guilty of derailing the last one a tad early on haha, although it certainly snowballed of it's own accord after that! I'd agree with your later posts on the previous topic though - the two most viable solutions currently available are splitting the worldspace into several large areas or finding a scripted fix. The scripting I guess would depend on the impact on game performances. I suppose if you get that working the questions you then have to ask are;

What kind of performance hit will this realistically cause?
How many NPCs etc will need to be running this simultaneously?
What are the impacts on lower-spec machines and your minimum system requirements for playing your mod?

I suppose extensive testing is the only way to go. I guess since we already have skyrim one relatively quick way is just to set it off on a bunch of NPCs all over tamriel as a mod and see how your game performs in relation to vanilla skyrim. You could distribute that as a .esp and easily have other people with different specs report back on performance/stability as well.

It would be great if you could have a look! I can send you our MiddleEarth.esm, containing our heightmap. It should be easy to reproduce in there. The file is about 250 MB.

Is Havok completely integrated into the Skyrim engine, or does it run as a separate process or element in the game engine? If the latter, would it be possible to insert the working Havok components from Oblivion (which does not seem to suffer from the -64/+64 problem, if I understand correctly) into Skyrim? Or perhaps replacing the Havok/Skyrim interface with that of Havok/Oblivion?

Just a few (very) random thoughts (which might well not be possible). Thought I'd just throw it out there in case it sparks off some new avenues or ideas.

I think the only issue with this would be that Skyrim likely requires a very different version of Havok than the one Oblivion uses. I think I mentioned in the previous thread that there's actually 3 different Havok products at work inside of Skyrim - Animation, Physics, and Behaviour. If you go on Havok's site and look at their http://www.havok.com/products/behavior, I'm willing to put money on it being the culprit, especially since other object physics seems to work as normal and the player remains unaffected. As far as I'm aware this system is relatively new and does not exist within Oblivion.

As mentioned before though it could still be an implementation issue rather than a specific limitation of Havok itself. As previously mentioned the fact the Y axis remains unnaffected seems incredibly suspect in this regard.

That has been my thoughts all along as well. I am wondering if there is a way to establish this definitively, one way or the other.
Anyway, I am not able to mess around with Havok and I don't even know if it is possible to augment/mod Havok the way the Skyrim enginne can be modded. It would be good to find out though, if someone knows for certain.

I guess it would depend how tightly the havok code was integrated with Skyrim's engine. However since it's licensed middleware I'm guessing it would be of dubious legality to implement any form of havok modification that wasn't also licensed for development anyway. Maybe not, but then you've got the issue of whether it's even possible to isolate the issue without access to the specific tools Bethesda used. Once again this is something only the devs can easily answer in full. As TheKarithian said mind, this isn't really the place to go hounding Bethesda about it. Since their flat answer thus far is 'no' I'm merely assuming this bug won't get fixed anytime soon and we need to think of a relatively simple workaround.

It's not a bug in Skyrim (nor in havok). It's a havok setting in skyrim (hard coded). Whether one of the SKSE-types hanging around here can somehow change that setting (worldsize), idk.

However: As said above by others, what is the extent of the useable Y Axis? Someone needs to find out, because - if assumptions on what causes the effect are true - it cannot be "unlimited"

(Failing an SKSE type solution) The only "work around" - which isn't a work around - is worldspaces no larger than 128 cells. So you will have to divide your "world" into multiple worldspaces (and come up with somewhat realistic ways of steering the player to the doors/loading-screens)

yeah, it's sad, but the worldspace size in Skyrim is smaller than Oblivion, and that's that. I can't see how you get around it without some Magic I don't understand ... Ask the SKSE Team people, maybe they can?

Other than that, think hard about your world design and how you can cut it up.

I find it perculiar that the bug does not affect the player at all, only other actors, and not havoked objects. So NPC actors with a skeleton setup, particularly when locomotion animations are initiated or idle animations are about to restart. Correct me if im wrong, ive been testing it with a simple, flat worldspace I made.
It makes me wonder where it would be set and why the player is treated differently. Wether its set all in one place or somewhere on the havok setup within the skeleton .

My thoughts also. If it was a general game coded issue, it would be more generic (though I dont have a clue really) the logic seems to suggest that it is bound up with the skeleton/nif.

We really do need someone who is clued up on nifs and the game code to anolyse this. I appreciate that Bethesda are not going to fix it but surely one of them knows where the problem sits.

I have my fingers crossed that Shade_me can come up with something (decent of you to offer to take a look)

@admins: could one of you please pass a message to the developers that all we need now is to know exactly what the issue is with, is it in the game itself or is it within individual nif/skeletons etc.

"@admins: could one of you please pass a message to the developers that all we need now is to know exactly what the issue is with, is it in the game itself or is it within individual nif/skeletons etc."

Just a quick thought, but the problem area is not along the Y axis, which means that slicing the world up would not be in 4x4 quad chunks but 4x16 quad chunks. A world would therefore need 4x 4x16 quad slices on the Y axis. Is this feasible for Middle Earth? I think it may be if one slice went from the Ered Luin to the Misty Mountains, but its going beyond that where the issue may sit, in that how do you slice down the middle of Mirkwood and still make it possible for players to wander through the forest rather than stick to specific paths, or go around the north of Mirkwood? The next issue then is slicing down between Gondor and Mordor and the Dead marshes, theres no way to seamlessly transfer other than by thousands of invisible doors along the cell lines. Rubbish really.

Is there a way to run a script on transfer between world slices? Check the current location and teleport the player to the relevant Y location in the next world (and back again)

Good point. To be honest, I am still much preferring and really hoping for a work-around through scripting - possibly through SKSA and even Havok components. But if all else fails, it might well be possible to do MERP with four 4 x 16 quads. I guess it depends on where you put the centre of the map (0,0).

If you cloned two cells (exact copies), one at the W edge of a border and one at the East side of the same border, you could do a teleport on entering (or being at such and such a position in) either of the cells to the opposite cell - so that it appeared the PC was in exactly the same place, following a loading screen.

That's (sort of) how the gated cities work in Skyrim. It looks and feels like you have just gone through a door, but actually you have loaded a new worldspace (lod tricks make it appear that the same scenery exists outside the city, when the PC is inside) but it is merely a limited fake in the same way LOD for other countries exists (and can be seen) outside of Skyrim

The advantage Skyrim has is this always happens having entered a door, that the player does not want to come straight back out of ... though the PC can do that, I've about-turned at the entrance to a couple of dungeons.

It won't be straight-forward, but I think it could be done.

Try changing these settings to your skyrim.ini:

fMaxTime:HAVOK (default: 0.01666)fWarmStartMaxTime:HAVOK (4.0)fTimePerSubStep:HAVOK (0.008)fMaxTimeComplex:HAVOK (0.033)iMinNumSubSteps:HAVOK (8)uMaxNumPhysicsStepsPerUpdate:HAVOK (3)uMaxNumPhysicsStepsPerUpdateComplex:HAVOK (1)

If they aren't there, add them. Play around with the settings and see if they make a difference.

http://www.gamesas.com/topic/1351453-gamebreaking-bug-for-worldspaces-bigger-than-4-quads-in-width-thread-2/page__st__30__p__20381063#entry20381063

http://www.gamesas.com/topic/1351453-gamebreaking-bug-for-worldspaces-bigger-than-4-quads-in-width-thread-2/page__st__120__p__20386358#entry20386358

I realize that this is a hot topic, and comments go by pretty fast, but I for one would appreciate it if people would take a bit of time to actually read _ALL_ the posts in a topic/thread.... might have gotten some people's attention sooner and gotten more people poking into things that might be able to solve a problem.

This is about the 6th or 7th time I've piped up on a topic/thread, only to be (seemingly) ignored and then pages later in a thread, or a new thread on the same topic and then see the same thing I've said spouted out previously.. Rather irritating. Anyways, my point is... SLOW DOWN AND READ... don't just skim a thread because it has 7 pages, or gets responded to every 5 seconds.


Certain mods and the way game assets are used is not discussed here.

Going through the released mod, the final script itself, seems there's some changes... due to differing sizes in worldspaces or somesuch (haven't dug into why yet, was just doing a quick peek to make sure it's still there)...

So yes, it's possible, here's a possible solution that needs some update to papyrus...


This is what happens when you take your time and read all over the place... you discover possible solutions to problems....

That said... Shall we?

So seems bethesda wants us to make mods but not wants to help us make mods or put us in the condition to make them ?

As someone who spends his working days concerned with numerical stability, this looks suspect. It might just be possible that the coordinate system used runs into precision issues, and the mathematics implode. Seeing how it happens at +64/-64 (which is EXACTLY 8 bytes) is a huge indicator.

Simplified example for people who don't have a math degree: If you have a number for coordinates which can only go to four digits (+999.9 / - 999.9) and you go one further, you lose your .9 digit, and your precision is suddenly ten times worse. Which is exactly what we see: Y-axis precision drops by a magnitude, and actors start to move around for no reason.

Take a look at IEEE Floating Point arithmetic on Wikipedia to understand what I am talking about. If that is the case, "fixing" it would involve completely rewriting a few major pieces of the engine, such as positioning and physics. I'll put it bluntly: That won't happen. Write a mod that doesn't require this functionality instead. You can also use instanced interior maps which come with their own coordinates, as a small work-around. Size doesn't matter, make something awesome without requiring a second continent. It's not like a small team of five people is able to fill a continent with interesting content.

But all this whining or complaining of people who have absolutely no clue what they are talking about is aggravating for those people who actually want to get something done.

Dear Mods: Please lock all threads about this issue, and put a sticky on top.

I have another solution. Need to create simple program, that would be create dummy model without mesh, but with collision, based of terrain from plugin. When you just need add terrain collision like a static model and put into the cell.
But this method have two bad issue. First, guys from NifTools just didn't finish decoding .nif collision for now. And second, the size of mod will grown up.
Hope, this problem have alternative solution.

And why would they do that? Because you said so? That would kind of put a damper on people working together to come up with alternative solutions don't you think?

And just because you say you are a mathematician... this is the internet, people can claim all kinds of things.... I'm an astronaut! (no, not really, but is my point made?)

You could be what you claim, and probably are correct about it being a precision issue, but tone it down a bit eh? Granted text does not convey tone or attitude well, or at times at all, but your post comes across more than a bit arrogant and not very conducive to assisting in finding a solution to the problem.

Back on topic... I looked a bit more at the solution Ice came up with for morroblivion... They used Onra's HM and the 'size difference' issue was their morrowind vs his morrowind, so he had to do some tom-jiggery size comparison/teleporting scripting bits. Finding current coords, compare coords between world space sizes, then teleporting equivelant coords between the worldspaces... Works well in game (I've played the hell out of morroblivion and didn't really notice it much)...

I'm sure that it could be converted for use in papyrus with some effort.

If it were a precision issue, wouldn't it then affect both the X, Y, and Z axis?
In this case it is only the X-axis that is problematic.

And just because you say you are a mathematician... this is the internet, people can claim all kinds of things.... I'm an astronaut! (no, not really, but is my point made?)

Yes, your point being that you claim that because you cannot tell if I am lying, my arguments are wrong. I recommend you look this up: http://en.wikipedia.org/wiki/Fallacy. I only say that it looks like a precision issue to me, and if it is, Bethesda can't easily fix it.

Congratulations on being an astronaut though. You sure are awesome.

If it were a precision issue, wouldn't it then affect both the X, Y, and Z axis?
In this case it is only the X-axis that is problematic.

Only X? I thought is was X and Y? It's still entirely possible that the algorithm used by Havok uses the coordinates in a way where X's size results in issues. I would expect Z to behave normally, because it is usually the *result* and not the input.

Example
Precision: 4 digits.
X: 10'000
Y: 5
Z: 5



X+Y+Z = 10000 (rounded down after every calculation)
Z+Y+X = 10010 (5+5 is fine, and 1000+10 works)

Order is often important. Recommended reading: IEEE floating points, numerical stability.