madmongo

Glad you got it working!

What are the X, Y, and Z offsets of your cave tunnel static nif where your character starts to have issues?

And it turns out I do have two ConstructionSetNetwork.ini files. I was looking in the wrong place for them. One is in \\127.0.0.1\merging and the other is in \\127.0.0.1\merging\Ini The one in \\127.0.0.1\merging\Ini has this: [Users] 1=me me=1 The one in \\127.0.0.1\merging has more in it, with most of it being mods that I have worked on using Version Control: [Users] 1=me me=1 [CheckinBackups] LOMongoFreeside.esm=1320642110 HIMongoFreeside.esm=31129608 LOMongoInteriors.esm=2593994871 HIMongoInteriors.esm=31131241 LOMongoBM1.esm=1859166374 HIMongoBM1.esm=31128947 LOMongoHH1.esm=3500798072 HIMongoHH1.esm=31159324 LOMongoWestside.esm=690084381 HIMongoWestside.esm=31000000 LOMongoAerotech.esm=3831531078 HIMongoAerotech.esm=30901776

On my system, these are the differences in GECKCustom.ini between my local ini files and my networked (version control) files: SNewVersionBackupPath= SNewVersionBackupPath=\\127.0.0.1\Merging\VersionBackup\ SNetworkMasterPath= SNetworkMasterPath=\\127.0.0.1\Merging\Data\ bAllowNonGroupedVersionControl=0 bAllowNonGroupedVersionControl=1 SNetwork Path= SNetwork Path=\\127.0.0.1\Merging\ bUseVersionControl=0 bUseVersionControl=1 My GECKPrefs.ini networked version has this at the bottom, which is not in the local non-networked version (the user name on my system is "me"): [SudoWhoCanMerge] me=1 [SudoWhoCanForceCheckout] me=1

I've heard several different numbers. I don't know which one is correct. The first two numbers I've heard make sense since they are on power of 2 boundaries, so the limit in the X, Y, or Z direction would be either 16k or 32k (so +/-16383 or +/-32767). I have also seen a number around 22,000 before things in the game's physics engine start to go wonky. Not sure where the exact limit would be on this one since it's not an even power of 2. Do you know roughly where your player encounters the issue? Do they warp back to the cell origin (0,0,0)?

I don't have a ConstructionSetNetwork.ini file on my system. Those instructions were originally for Fallout 3 and they added the differences for Fallout New Vegas afterwards. Maybe that file is only for Fallout 3? I followed a different set of instructions when I set mine up (and I didn't put my network shares in the same place). But the instructions that I followed had a couple of errors. Your instructions are better, I think. If you delete that file and still get the error, check your paths in your ini files. Make sure there isn't a space between Path= and the path for each. Also, make sure there IS a space in "SNetwork Path". SNetwork Path=\\127.0.0.1\Merging\ SNewVersionBackupPath=\\127.0.0.1\Merging\VersionBackup\ SNetworkMasterPath=\\127.0.0.1\Merging\Data\ You should also be able to copy and paste these into the address bar on File Explorer and they should take you directly to your network folders. If they give you an error then your network shares aren't set up properly. \\127.0.0.1\Merging\ \\127.0.0.1\Merging\VersionBackup\ \\127.0.0.1\Merging\Data\

I don't think there's a simple formula or spreadsheet that you could create that describes how many NPCs or enemies you can spawn. A lot of it depends on the area where you are spawning them and how much memory is being used for other things like textures. When you start digging into things, you'll find that a LOT of things are poorly documented, if they are documented at all. Basic things like how to create a worldscpace aren't well documented, and good luck finding decent info about how to create animations. There is a region navmesher in the GECK that isn't really documented at all, and if you try to use it you'll find out the hard way that it rarely works and often completely locks up the GECK. Who do you think would be creating all of this documentation? Bethesda and Obsidian moved on to other things. They aren't going to spend months and months creating documentation about their game engine. They would rather spend that time creating a better engine or developing a new game. Modders? If you are making mods, your emphasis is on your creations, not creating a full set of documentation. Sometimes people take the time to write tutorials, but not often. There is a huge amount of information here in the Nexus forums, but no one is taking the time to sort through it all and organize it. You've been doing a bunch of experiments with large numbers of NPCs. Have you documented your findings? Where are the spreadsheets that you have created? Will you be creating and releasing this type of documentation? Once you've been modding for a while, you start to get a feel for where some of the limits are, but most of it isn't documented anywhere. If you create a worldspace that is too large in the X and Y directions, when you actually place things in those high offset X and Y cells it breaks the game's physics engine. If your world's landscape is too low, you end up with floating trees in your LOD. Keeping your landscape height above 14,000 seems to work but where exactly is the limit? If you place an object at too far of an offset in the X, Y, or Z directions in an interior cell, it breaks the cell and all of your objects can end up all squished together in the center of the cell. The auto navmesher for regions in the GECK is completely broken, it rarely works and often completely locks up the GECK. There is hidden info in animations which is stored in the GECK. For example, if you create a looping animation and you don't use the correct tags for the loop start and end, the GECK stores that somewhere and doesn't tell you about it. If you fix the loop tags in your kf file, the animation still won't loop properly. You have to rename the kf and re-assign it in the GECK so that the hidden information gets updated. Viewing an NPCs face and then switching to the inventory tab crashes the GECK. Taking the default heights in the heightmap editor crashes the GECK. Starting reference IDs with a number works for some things but not others. Adding too many objects to an exterior cell causes some of the earlier objects that were added to disappear. Where is that limit? Most of these things are not documented anywhere. What are the .fid .fud and .fvd files used for in Version Control in the GECK? What issues can arise if you create an empty list when generating your bit array files for Version Control? How much memory does each record type take in a save file? What is the limit in save files before the game goes wonky? There are a lot of basic things that need to be documented before you even get to things like how various things affect performance. If you think things should be documented, then document them. I'm sure a lot of people will find the information useful.

You need to copy FalloutNV.esm and any DLC esm files that you want to use to your \\127.0.0.1\Merging\Data folder. Run the GECK as administrator. Even before you select your data files, you should be able to click on File and see an option for Version Control. That lets you know you at least have Version Control set up in the ini files. Now go to File -> Data and for each of the files that you copied over to your \\127.0.0.1\Merging\Data folder, select the esm, click on Details, then CTRL-Shift-B. When I get the "Do you want to use an empty list to save memory?" prompt I always select Yes. It's never caused an issue that I can see. Some references say this may take a while, but it always finishes pretty much immediately for me. The 3 files (.fid, .fud, .fvd) will be created in your \\127.0.0.1\Merging\Data folder. If you don't use Run as Administrator when you start the GECK, it probably won't create the files. I can't remember if it gives you an Access Denied error or not for those particular files or if it just silently fails.

I don't know. I've never tried it. If you try it, let me know if it works.

This works. But you will have to go through an extra step. Since you created the esp files in local mode, when you go into Version Control in the GECK you'll have to select all changed items and check them out first, then do the check-in. Otherwise the GECK will think that you don't have any changes to check in (stupid GECK). Also, if you are having difficulty setting up the network shares on your local computer, Microsoft (who I believe is secretly working with Vault-Tec to test our frustration levels) has changed the way that they set up shared folders in recent years. You might have to use the command prompt to set up your share folders. I personally had to set up a desktop shortcut to cmd.exe in Windows\System32 with the "Run as Administrator" box checked on the shortcut, otherwise I got "Access denied" errors. I also happen to use a folder named FNVNetwork on my D drive instead of the location that the article you are looking at uses. The name of the folder doesn't matter as long as you set the names the same in your ini files. On my system, I would use the following commands in the command prompt: net share Merging=d:\FNVNetwork\Merging /grant:everyone,full net share CheckInBackup=d:\FNVNetwork\CheckInBackup /grant:everyone,full I also have to run the GECK from a shortcut with the "Run as Administrator" box checked. I personally keep a backup set of ini files from before the changes for version control and a set of ini files from after the changes were applied, so that I can easily switch between the two modes by simply coping the appropriate set of ini files into my FNV folder in documents.

Let's start with an explanation of what Version Control is. It's basically setting the GECK up to work in a networked configuration for team development. Let's say you have a team of a dozen or so developers, all working on creating a big mod. You're a "professional" team all in an office somewhere, and you need one machine to have the actual final product on it. So you set up a computer on your network, and it is what that article calls the "remote master". It has the actual esm that everyone is working on. Everyone creates esp files on their local computer, and checks their changes into the remote master. So for our example, we'll call our project TheBigMod.esm. Developer Bob grabs a local copy of this mod and puts it on his machine, and makes an esp that depends on this esm. Let's call his local esp file BobsFile.esp. He makes his changes, then he uses the GECK's version control to check the changes from BobsFile.esp into TheBigMod.esm. When he's done checking the file in, TheBigMod.esm incorporates all of his changes, and his local BonsFile.esp ends up empty (since all of the changes are now in TheBIgMod.esm). The important thing here is that when Bob checks his changes into TheBigMod.esm, the GECK doesn't just append things at the end of the file the way it does when you work single user on a mod in the GECK's normal mode. Instead, things that have any kind of reference ID and such get placed at the beginning of the file. Why is this important? Let's say you create an item, called Bob's Wonderful Water (it has super-duper HP healing or something like that). This is stored with two hex digits indicating which mod it's from, and six digits for the offset into your file. The 16 MB bug comes from the fact that if you append something to a file that is larger than 16 MB, the offset is larger than six hex digits and bleeds over into the first two digits which are supposed to be used for the mod number. Some real world examples might help clarify this. Lonesome Road contains a new weapon called the Arc Welder. If you look up the reference for this weapon, it is listed in the Fallout Wiki as xx00766B. On your particular system, the xx will be the mod index of the Lonesome Road esp. On my system, that is mod 8. But if I were to remove GRA and the Tribal Pack from my load order, Lonesome Road would end up being mod 6. So in the first case, the actual ID of the Arc Welder would be 0800766B, and in the second case, the ID would be 0600766B. But what if I created a new weapon and added it to my mod that is larger than 16 MB? If you are just making a local file, the GECK is going to append your new weapon to the end of your file, and you could end up with a file offset of say 01234567 (which would be a bit larger than 19 MB). Notice that your offset now spills over into the first two digits, which is supposed to indicate the mod index, but it actually indicates the offset into your file. When the game encounters this screwed up offset, it crashes. If you try to open the file in the GECK to fix it, the GECK crashes. Hope you had a backup of your file before you added your new weapon, because there is no way to recover from this. However, if you create a master esm out on the network share, and this master happens to be 19 MB in size, and you check in an esp that only contains your new weapon, the GECK is smart enough to place your new weapon down below the 16 MB boundary. Everything with an ID that indicates the mod number is placed at the beginning of the file when you check it in. That is the important difference. The GECK in local mode simply appends your changes. The GECK when you check things in to a master will sort your references so that things that need to be below the 16 MB boundary will end up there. But you're not Bob, and you're not part of a large development team, so what does all of this mean to you? Well, you can take advantage of the way that the GECK checks in esp files into a master to avoid the 16 MB bug on mods that you create on your own computer. To do this, instead of having a repository somewhere on the network, you instead create a local folder. But then you share that folder, so that it can be accessed as if it is out on the network somewhere. You do that through the "loopback" connection, which is an IP of 127.0.0.1. This IP always points to your own local computer, no matter what IP your computer actually has on the network. That is why it is called the "loopback". Once you set this up, the GECK thinks that it is checking files into a network share somewhere on another computer. But actually, since that IP loops back to your own computer, the GECK gets tricked into checking files into a folder on your own computer. A quick and easy way to demonstrate the 16 MB bug is to create a new worldspace. Define your worldspace, save and exit the GECK and restart it (because if you don't the GECK will crash at the next step), then open the heightmap editor. Generate a random landscape with a Base Offset of say 14,000 or so (you need your landscape above 14,000 or so to avoid floating tree LOD issues) and let's say a Frequency of 1000 and an amplitude of 1000. This will generate a reasonably random landscape. Exit out of that and save your mod. Your mod will now probably be around 12 to 13 MB in size. No problem, yet. Go under Regions and create a region that covers most of your new worldspace. Copy all of the objects from the RockTreeGen region into your region, and set up all of the object parameters to be the same as this region (both the Objects tab and the Obects (more) tab). Click on Generate and the GECK will happily create random trees all throughout your defined region. Now you have a problem, because now when you save your mod, it's about 18 to 19 GB in size. So only about half of those trees are under the 16 MB boundary. The GECK will happily save your mod, and give you NO ERROR INDICATIONS WHATSOEVER (because the GECK is really a secret Vault-Tec experiment designed to test your frustration levels). However, when you try to test your mod, the game crashes. When you try to load your mod into the GECK to see what is wrong with it, the GECK crashes. There is no way to fix your mod. It is forever broken. This, incidentally, is basically how I discovered this bug for myself the first time. I was making a dead tree forest in a new worldspace. Now let's do exactly the same thing, but we'll use Version Control instead. I make a new esp, create my worldspace, save and restart the GECK (stupid crash bug...), go into the heightmap editor, save that, and now I have an esp that is roughly 13 MB in size. At this point, I use Version Control, and check my changes into a new esm. Important note - always back up your files before you do this, because if it screws up somehow there is generally no way to recover from it. I copy the new esm from my \\127.0.0.1\Merging\Data folder back to my FNV game folder, create a new esp that depends on this new esm, and now I create my new region, add all the objects etc. to my region, click on Generate, and make my big dead tree forest. Save that esp. Again, back up your files in case something goes south. Now I check in my esp into my master, and voila! I end up with an esm that contains my worldspace, my region, and all of those trees, but all of those trees are up near the beginning of the esm and aren't anywhere near the 16 MB boundary. There's no problem with any of the file offsets, I have avoided the 16 MB bug, and everything works. Then I try out the auto-navmesher for regions and learn the hard way that it almost never works, and you should never, ever use it.

Unfortunately, Photoshop has gone to a monthly subscription model. It's about $270 per year, which in my opinion is ungodly expensive. I think you're stuck at about the same place I was. I could export from the GECK but I could never get anything to import back into the GECK.

For the mesh, I did a quick check on sketchfab and someone does have a Ruger 10/22 model available for free download. You'll have to convert it to nif and add the weapon type nodes to the nif, but at least the modeling and texturing is done.

Heh. That is what I would suggest, but only because I don't know of anything else that works. I tried following some online tutorials for creating heightmaps from real geological data, but could never get anything to work. Speaking as an old fart with bad eyes, I can definitely sympathize with your complaints. For what it's worth, you can go into the heightmap editor, then click on View -> Color Masking, and you can change the height vs. color allocations to make the differences in height a lot more visible while you edit them. The GECK heightmap editor is extremely clunky and I also find it a bit difficult to use. I will be watching this to see if anyone has any better suggestions.

By the way, since you already have your wall as an obj, you can probably directly import the obj file into Blender 2.49b, add the collision mesh, and export it as a nif. You don't need to re-create your mesh in 2.49b. I often use obj as a format to transfer things from newer versions of Blender back to 2.49b to convert them into nif. It works well to port meshes in formats that 2.49b can't read to convert them into nifs. For example, it's a great way to convert fbx into nif. 2.49b claims to be able to handle fbx files but it's buggy as all heck. It's much easier to use a later version of Blender to convert the fbx to obj, then import the obj into 2.49b and export as nif. Don't ever take a .blend from a newer version of Blender and try to open it in 2.49b and then convert it to nif. You'll just run into all kinds of headaches.