ST Dependant?

[Seniosh]

Maintaining your own ESM makes sense, and prehaps having a separate add-on of things such as the Telvanni set that ST won't have, but using the ST assets, at least for now, is very convenient.

Come release time though, it should be made very very clear that the Vvardenfell assets ARE the Silgrad Tower assets. There is bound to be gigabites of meshes, textures, ect, and i don't want to DL the same stuff 2x, as previously stated. Just make sure your ESM uses the correct filepaths. The other question, is will there be naming conflicts? if the game finds StRwRedHut4 in both ESMs, will it flip out? or is it OK.

That right there might be your major problem, which could be fixed by just adding Vv infront of every ST-added item, but it would be tedious, and would mean there are 2 copies of everything, one Vv version and one ST version, that won't mean anything in terms of gameplay, but i'm not sure about proccessing. of course i'm kinda sleepy and out of it, so this could be completely off. Just want to try and find conflicts before they arise and ruin everyone's day

[Dave_91]

Yeah I'm a bit sleepy too, it's like 4am here and it's nearly daylight again.

Anyway, that's what I had originally planned, adding the Vv ID to the assets from St, but that'd take ages probably and would be very tedious like you said. We could perhaps make a main mod file, like ST, when in the (example) texture folder, ST's textures were all in the ST folder, so we could sopy that and make a Vvardenfell main folder for each type (meshes, sounds etc.) with the Vv ID. Know what I mean?

[Razorwing]

If Silgrad Tower's private models are distributed by the Vvardenfell team it would defeat the purpose of even having a public/private system. If that happened I would take action. There are few things I care more about, so I hope it doesn't become an issue. I spend some time and energy making special public models and it takes a bit of planning to keep them separated since they're named alike. What I didn't spend time and energy on, due to time constraints at the time, were the interior Redoran models. I do plan to remake them before ST's next full release so that they look like low-poly alternatives rather than look corrupted and ghastly. Apart from those models I can't think of any public models that look bad to any degree so I don't see any reason you'd need to distribute our private models.

I would suggest taking a copy of our esm, deleting everything from it through TES4Gecko that isn't an object, saving it as an esp, then merging it to your esm. Then rename the ID's so people can play both mods. That would be a one-time thing though, I wager you'll need to enter new models manually.

But I also think it would save you guys a lot of time and energy if you kept the filepaths unaltered. That way you'd get updates to the models via the asset updates I post. That doesn't necessarily mean you'd have to ask people to download stuff from us - you can distribute our public models, textures etc if you want, just mention other mods are forbidden from using them - but if I update two dozen nifs you won't have to keep track of them, rename them, etc you can just overwrite the nifs in your folder with my asset update.

Concievably you could make your esm dependant on ours but I have strong doubts that would work without landscape problems. Keeping your mod as an esp is another option but I don't think that would work either because there'd be so much data involved. Being a part of our esm... that could be an idea, but I wouldn't dare say anything about that even if you guys would happen to be open towards the prospect and I don't know if you are or not. A couple of months ago I wouldn't have thought it even a theoretical idea but today, with TES4Gecko, it could be a theoretical possibility. We couldn't be in the same worldspace because of the LOD limit inherant to Oblivion but it's not impossible to have seamless transitions between the worldspaces through scripts. It's an interesting idea, I think... worth exploring through discussion maybe?

[Lightwave]

I don't think it's a good idea to use SilgradTower.esm outright. The master file for Vvardenfell should contain all the (non-private) references ready for placing on the heightmap; statics, trees, fauna, weapons, clothing, armour, sounds etc. It should not contain any extraneous worldspaces, interiors, quests, scripts, NPCs etc. Having a dependency on the ST ESM file wastes memory, loading time and complicates the final redistribution of the mod.

It should probably be an esm, though this isn't absolutely necessary. In either case if the master file were to be shifted to modindex 00 we'd have no load order problems, whether it's an ESP or ESM; to the game it looks like the mod is in Oblivion.esm. I don't think ScripterRon has added the shifting of an entire mod into or out of modindex 00 in TES4Gecko yet, but I believe it's something he'll be doing in the future. In any case, I've got enough programs handy to easily shift the master to modindex 00.

Btw, you are aware that Beth solved the LOD distance problem back in March when they released the first Patch 1.2? The game loads up to 64x64 'quads' now which is 2048x2048 cells or over 5,500 square miles. Also TESAnnwyn solved the massive worldspace limitation in February (including the LOD load order issue that TES4Gecko also now implements) So there's nothing to stop massive worldspaces hundreds of square miles in size from being one, though I think there'd be performance benefits keeping them separate (e.g. NPC AI travel) and just scripting the jump once the player's X,Y value exceeds certain values. Since TESAnnwyn does not optimize the massive worldspace creation yet, keeping the heightmap small enough for the CS to load and save more efficiently is still preferred.

Since the LOD for Vvardenfell is pretty dire in places (esp. Balmora) I'm still working on creating a new landscape LOD system using smaller heightmap quads (currently 3x3 cells each) placed as "Visible When Distant" statics. Theoretically we should be able to see much further in one go than before and certainly with better quality. Performance thus far seems OK, but that's with just a few high detail heightmap LOD quads (and a bare landscape without any other statics).

Lightwave

[Razorwing]

Originally posted by Lightwave
I don't think it's a good idea to use SilgradTower.esm outright. The master file for Vvardenfell should contain all the (non-private) references ready for placing on the heightmap; statics, trees, fauna, weapons, clothing, armour, sounds etc.

I think there's some confusion over the public/private system. The system affects nif files, not Construction Set entries. We use the same esm for public & private use, the difference is the mod looks a bit better with the private models than it does with the public version of those models. So the public version isn't missing anything, it just looks more basic in places.

I conferred with sandor, ST's resident expert on modding, and sharing space with Vvardenfell in a joint esm is not a possibility. On the other hand it should be theoretically possible to make a Vvardenfell esm dependant on Silgrad Tower esm without landscape or LOD problems, which surprised me. Apparantly it's made possible through TES4Gecko. So that would be a theoretical option, but whether it's something the Vvardenfell team wants to pursure is another question. There's nothing hindering you to distribute a copy of our esm file with your release btw.

I wasn't aware the 64 quad LOD limit had been solved. But according to the information I have, graciously provided by sandor, there is a max limit of 16,777,215 formid's in an esm file. Oblivion uses 1,100,000 formid's. So as far as I understand it, if you make a landmass larger than a dozen times Cyrodiil's size you'll have to start compromising because there'll start to become more land than you can decorate and still have enough formid room for interiors and other content. You could always use additional esp's to place trees, rocks and other things on the landmass but I mean come on, who needs that much space for a mod anyways.

[Lightwave]

The landscape LOD solution is essentially very simple; id's done by changing the last byte on the FormID for the worldspace to 0 where it's stored in the ESM/ESP and those problems go away. I posted the solution here which ScripterRon added to TES4Gecko; it was an accidental discovery I came across when adding TES4 header writing to TESAnnwyn in February, which is why the Vvardenfell heightmap ESP is impervious to load order or missing land issues (because the CELL-LAND records are also in modindex 00). It turns out Rocket also discovered that modindex 00 worldspaces fix the LOD back in January too.

Visible When Distant objects also suffer the same load order issue; I only posted the solution last Thursday and ScripterRon managed to implement that in TES4Gecko by last Monday, impressive timing really.

Btw, a staticless landscape (including textures, vertex colour map etc) uses just 2 FormIDs per cell. Tamriel uses less than 30,000 FormIDs for the landscape worldspace. The vast majority of the others have gone to placed objects, scripts, dialogue, quests, interiors etc, but obviously you're right that for any mod that scales similarly in detail to Oblivion's, one can only manage about 16x the area of Oblivion's "Tamriel" (which is 60% larger than Cyrodiil) in a single file, but this is no limitation since so long as the Worldspace is in modindex 00, the rest of the cells can be distributed across the other 255 ESP/ESMs, something only a true loon would attempt of course. I doubt the CS could load that many of them at the same time on XP, even if most were inactive.

The exact number of available FormIDs in a single mod file (ESM/ESP) is 16,777,216 (2^24), but Oblivion.esm uses about 1,020,000 overall, just 6%, for the entire game whilst the landscape itself uses just 0.2% of those FormIDs.

TES4 suffers from the same jittery rendering issue that TES3 shows once you're more than about 100 or so cells from the world-centre (e.g. NPCs look like they have nervous problems) so there are other issues to consider if combining several large worldspaces.

Going back to the original topic though, I personally still do not feel we should be making any a dependency on silgrad.esm at this stage. The two projects can be gelled together later on (or even now for that matter if someone really wants it) using a separate ESP to script movement between the worlds and the LOD can be shared for each without too much difficulty so the landscapes appear seamless from one another's shores. There's no sense in forcing people to lose memory and load times to something that isn't required and should be left an option.

The other problem is over scale, I don't know what scale ST uses, but I assume it's truer to Vvardenfell's original scale (?) and would look a bit dwarfed next to the double-scale Vvardenfell this project is using. But I could possibly make a scaled up copy of ST in the future to match if you permitted me.

Lightwave

[Mormacil]

I thought ST is even bigger in scale then Vv

[Lightwave]

Originally posted by MormacilI thought ST is even bigger in scale then Vv

Yup, I think you're right. The ST heightmap (for the SilgradTowerLand worldspace) is 6208x6208, compared to TES4: Vvardenfell's 5376x5632, and we've got more surrounding water too.

I couldn't find any images showing how ST should look in relation to Vvardenfell (e.g. lore scale maps), but it'd be curious to see how far different these scales actually are. Any have any?

[blackbird]

There is a map on TR which contains the whole province of morrowind, including the vvardefell and silgrad tower.