So, as the title suggests, the land is missing from my distant LOD. Here are the pictures.

http://i94.photobucket.com/albums/l117/ashen-shugar_2006/Oblivion2010-03-0300-34-59-70.jpg

http://i94.photobucket.com/albums/l117/ashen-shugar_2006/Oblivion2010-03-0300-34-59-70.jpg

http://i94.photobucket.com/albums/l117/ashen-shugar_2006/Oblivion2010-03-0300-34-59-70.jpg

I have tried generating the LOD with both tes4lodgen and the built in function in the CS.

But the land refuses to show up!

Any suggestions??

Also, not sure whether or not this belongs in the CS section, so if a mod sees this and it's not meant to be here, would they kindly move it

Thanks.

I know this sounds repatitious because you have done this already, but Sometimes you have to repeat the same steps but get rid of the old files first.If you have previous files in these folders then go through the steps listed below to remove them and start over. As a last resort if all else fails, sometimes you have to uninstall Oblivion and the CS and do a new install. But again, only as a last resort. Usually just doing the steps listed works.I hope this helps in some way

1. Delete the Distantlod folder from your Data folder.
2. Go into your Texture folder, then find the landscapelod folder. Inside there is a folder called generated. Delete the generated folder.
3. Go into the Mesh folder and find the landscape folder. Inside the landsape folder is a folder called lod. Delete the lod folder.
4. Load up your cs and save before entering the heightmap tab. When you have your heightmap loaded then go up to file and then down to the generate full lod tab. Once you have generated the lod's then save.
5. After savingt close out ot the heightmap screen. Then save inthe main cs as well. If when you try to save and it says cannot load or find landscape in some cells(usually 0.0, 31.0 etc.) smooth those areas alittle and continue with save in main cs.
6. Use Tes4qlod to generate Distant lod's and all should be well.
I have built many world spaces and have had the same problem you are having now and was able to correct it everytime. Let me know if this works for you.

Assuming you mean landscape LOD:

Use TESGecko's "move worldspaces" function and then generate new landscape LOD. It will show up properly in the game that way.

Thanks, will try both of those

Technical explanation:

Oblivion has a bug in that the whole 32 bit of the LAND (Landscape) record ID are used to reference the landscape LOD file names in Meshes\Landscape\LOD\ and Textures\LandscapeLOD\Generated\ directories, instead of just the lower-byte 24 bit (I'm considering writing an OBSE plugin to fix it, it's a really silly and easily fixable bug ... if you had the source code, else it's a few hours to a few days with the debugger, I think). This means that your load order influences the file names Oblivion is looking for, which is plain stupid.

The solution, aside from Bethesda adding a single "XOR 0x00ffffff, (landid)" instruction to the LOD loader and generator (which would raise the loading times by a few picoseconds and the Oblivion.exe file size by about eight bytes), is to "inject" the LAND record into the main Oblivion ESM file by changing it modindex to 00. Watch out for conflicts with existing items though.

Doing this, however, introduces another bug: The CELL records (containing the height map of the landscape along with all the static objects, textures and so on of it) aren't properly referenced anymore. Specifically, most objects will still appear, but the landscape itself will vanish unless the mod is on the exactly correct place in the load order (usually just after Oblivion.esm). The solution for this is to move the cells to modindex 00 as well. This can lead to quite a bit chunk of the already crowded "00 space" to be taken by your landscape, and heightens the chance of a subtle mod conflict with other mods "injecting" records into Oblivion.esm this way.

Sometimes it is a matter of load order.
try to put relevant esm and esp files as low in your load order as possible, re-generate LODgenerator and visit the place again.

Actually this isn't true. I have moved plenty of worldspaces and gone through and tested them after using Gecko on the file and found that everything is in place as expected. Landscape included. Gecko seems to know how to fix what needs fixing, so the only way I can imagine the problem you describe coming up is if someone is hex editing the ESP file directly, or using a utility that isn't covering all bases.

Tried both methods, and they worked, not sure which did it though or it was both.

ALso I have some lower class buildings that I want to be visible when distant, how do I go about doing this??

I don't know what Gecko is exactly doing with that option. But I wasn't talking about it in any case. What I wrote was: A mod with LAND ID 00xxxxxx (needed for landscape LOD files to work) including CELL IDs 01yyyyyy is subject to the bug as described above. If you don't believe me, I can easily produce a mod which has this behaviour; or just download Land's End which does as well.

TES4LODGen isn't going to help you with something like that. All it does is look for meshes that have the _far.nif extension, then write their location in a DistantLOD file. It does absolutely nothing to textures or base meshes, only VWD objects.

And I can produce two right now that I'm looking at right now in TES4Edit that have had Gecko used on them, moved the worldspaces, which are now injected as 00xxxxxx formIDs with CELL+LAND records still in the 01yyyyyy range and they work just fine. In fact, the ONLY thing Gecko did was change the formID on the WRLD record.

Now it may be that Gecko has properly taken all the 01yyyyyy CELL records and reset their WRLD parent to the proper ID, because I can see it right here in front of me that those are correct.

There appears to be no valid reason to change the IDs on the LAND records at all, or the CELL records they're attached to. So if someone has, and it corrupted the file, then it was due to some kind of funky monkey business the CS by itself won't allow.