Jump to content

Photo

Important 1.23 Note for Autodownloader (PW/MP Modders) - Please Read!


  • Please log in to reply
10 replies to this topic

#1
Hellfire_RWS

Hellfire_RWS
  • Members
  • 623 posts
Original post by GrinningFool

If you work in the toolset on your PW, and you also will be logging into your module (as most will).

Do not use the same My Documents\\Neverwinter Nights 2 location for playing that you do for building!

That bears repeating, as ignoring it will cause you a ton of headache -- the autodownloader will replace and delete files that you might not want to replace/delete!

Do not use the same My Documents\\Neverwinter Nights 2 location for playing that you do for building!

Now that I have your attention... there are two ways you can do this.
1. Use the toolset normally, but create a special shortcut to nwn2main.exe with the parameter "-home C:\\NWN2\\PWFiles" or something other location of your choosing. When you want to log into your PW, use this new shortcut instead of running normally -- this will make sure that any files added/removed by the downloader can't affect the files you have in place for your modding.

You may also want to copy "nwn2player.ini" from My Documents\\Neverwinter Nights 2 to this new location, so that your preferences are retained.

2. Slightly more work: you can rename your Neverwinter Nights 2 folder in My Documents to something else when you want to play; and rename it back when you want to toolset. (I say that this is more work because you have to do it every time, whereas creating the shortcut you would do only once.)


A couple of other things worth mentioning:

1. If you remove a hak from your module, save the module and close the toolset before staging files. Otherwise, the toolset will think the files are still attached to the module and attempt to stage them. This is an existing issue, but the problem now is that the autodownloader will try to prepare the hak file that is no longer present. Restarting toolset after removing the hak works around this issue.

2. If you want to run the staging tool and are switching between two or more modules, to be safe you should close the toolest and re-open it, then stage the module you want to stage. This is part of the same issue above: the toolset does not properly "release" resources that are loaded in all cases, so the staging tool might attempt to stage files from a different module (as well as the correct module).


Also, if I didn't make it clear above -- if you are building for a PW that will be using auto downloader:

Do not use the same My Documents\\Neverwinter Nights 2 location for playing that you do for building!

Important Note Number 2
It appears that we are facing a problem with staging files, when the size of all files to be staged is > 2GB. This is something that we corrected in the beta, but apparently another variation on the scenario has slipped through. Toolset will crash while attempting to stage files in this case.

This issue can be worked around. The method of working around this depends on how big your haks and other contents are.

Each of these workarounds will generally only ever need to be performed one time: once this is done, incremental updates to staged files will rarely if ever hit the 2GB limit.

Workaround 1
This will resolve the issue for most people who encounter it.
1. Before scanning files for the first time, select "Skip haks" and optionally "Skip Campaign files" if you have a lot of campaign files.
2. Select "Scan"; then "Stage"
3. Close the staging screen, then start it again
4. This time, do not check any boxes - just proceed normally with a scan and stage.

After this is complete, you should generally not need to do this again.

Workaround 2
If you have more than 2GB of hak files you will need to do this.
1. Perform only steps 1 and 2 above in "Workaround 1"
2. Remove enough hak files from your module in the toolset, so that you have less than 2GB of hak files.
3. Restart toolset.
4. Run scan+stage again
5. Re-add the haks you removed
6. Run scan+stage

After this point, you should be able to just run scan+stage normally in the future.

The goal of both of these is to ensure that the toolset is only attempting to stage at most 2GB of content at one time. You may need to modify Workaround 2 keeping this in mind - maybe you have a huge amount of campaign files instead of hak paks. In that case, you'd need to temporarily remove a subset of those files to get below 2GB; restart toolset, stage, add files back and stage again.

#2
DotFreelance

DotFreelance
  • Members
  • 17 posts
Running a dedicated server from the module directory that I use for building, it seems to me that the autodownloader is removing all of the files from the directory except the guid.gff and the MODULENAME.trx. At least I believe this is the autodownloader. This sounds like the issue you're describing.

So now I'm curious why this is happening. I'm sure we all realize that Obsidian appears to be so poor at programming that they really owe us all refunds... but that aside, why is this happening? The autodownloader has been instructed to download files from another location. I don't understand why it's removing the files from the module directory. This is literally invasive, destructive programming that, as far as I can tell, has absolutely no reasoning. It seems intentionally malicious.

#3
painofdungeoneternal

painofdungeoneternal
  • Members
  • 1,799 posts
Ok, i know reading is a lost art, but please read the post you are replying to here. You don't even have to read the whole thing, just the first few paragraphs.

Look for the words "That bears repeating" and see what is said needs repeating.

If you use the ADL, you have to read, and re-read the 2 provided PDF's, and probably this thread.

It is not malicious, but it is not built to allow you to randomly do whatever you want and work, you have to understand the technical issues and set your PW to use it properly, or its going to cause you major headaches. Frankly compared to other things you have to do to host a PW it's pretty easy in comparison. The end users do not have to read anything, they can just join, which was the point, the ADL moves all the technical work from the end user to the PW Admin.

Note that the ADL was created by a fellow PW admin ( Grinning Fool who was Admin of Khaladine ), as part of the deal which allowed us in the community to get it. And frankly despite him not being a real dev, the things he added really attacked core issues dating back to NWN1, and he snuck quite a few features in when they let him in. If it had to be setup to handle the issue you are describing, we'd still be at 1.22. How many other games allow the end users to add features to the games.

( note that my Alpha version of never launcher does the -home parameter and allows multiple player folders, but the features related to hosting a server are not fully implemented or tested yet. However it does have a complete NWNx stack included, and you'd just have to configure the ini files like you do at the moment, i am working on getting that program so it handles the server ini files, i only got the camera and some graphics settings setup properly so far. )

Edited by painofdungeoneternal, 01 January 2012 - 10:45 AM.


#4
DotFreelance

DotFreelance
  • Members
  • 17 posts

painofdungeoneternal wrote...

Ok, i know reading is a lost art, but please read the post you are replying to here. You don't even have to read the whole thing, just the first few paragraphs.

Look for the words "That bears repeating" and see what is said needs repeating.

If you use the ADL, you have to read, and re-read the 2 provided PDF's, and probably this thread.


The Autodownloader isn't something users go out of their way to download. It's just there, implemented with the toolset/server. There is absolutely nothing that would prompt a user to read and re-read this thread or the PDFs included, if any.

Please explain why a programmer would recreate a directory if it already exists. That's poor programming, no way around it, mate.

The way it's set up now any user would by default delete all of their data without knowing it was going to happen, simply because the programmer couldn't be bothered to run a simple directory check.

Edited by DotFreelance, 02 January 2012 - 12:08 AM.


#5
painofdungeoneternal

painofdungeoneternal
  • Members
  • 1,799 posts
It is doing that because the engine requires it basically, and to do it differently would make the project far too big to accomplish. This is generally an issue when you have a new feature added to an existing project, either you have to redo the original structure entirely, or you have to just throw it on top. If you were a programmer, you'd understand that sometimes you just got to make things work with what you have, and that poor programming is done by a programmer who can run circles around most others -- easy to criticize when you have not clue what had to be done to get that working with what he had to work with.

User does not have to read anything. A PW admin will and should read EVERYTHING. You will not be able to get a world working otherwise. And frankly its posted in a position which you seem to have found. You would not even be able to find the ini settings to get the ADL working unless you read those PDF's. Even then you still need to add the various NWNx features and listen to others in the community for how to do things correctly.

Really up to you, but how it works is a fact.

#6
DotFreelance

DotFreelance
  • Members
  • 17 posts
I am a programmer, my friend. The autodownloader is willfully replacing the directory when it could not. That is not in question. If you know anything about programming, and I would wager you do, you know very well that it could have been done properly.

"A PW admin" could have been any user who wanted to play a module he/she made with their friends and setup the autodownloader. I was able to set it up as well as an FTP server for it without once coming across even a MENTION of there being an issue ( an issue that, logically, shouldn't exist. )

The reason I found what I did was because I discovered it to be broken. The only reason I know that it does what it does is because of trial and error.

In this modification the programmer wrote a function that tells the autodownloader where to put files. Instead of programming it to check the validity of a directory, the programmer simply decided to have it write the directory from scratch. This causes all data to be removed if that directory previously existed. Should the programmer have decided for it to write just the files ( if the directory already existed ) there would be no issue. I don't expect the programmer to write a validator for all of the files themselves. What I would expect is for the programmer to have written a validator to ensure that an existing directory wouldn't be completely wiped out. He was, after all, programming for the toolset where he KNEW that same directory would hold all of the data for the module. There is no possible way he couldn't have known that unless he had never worked with the toolset before.

#7
DotFreelance

DotFreelance
  • Members
  • 17 posts
Oh, and another quick thing, those files are downloaded by steam as well, yes, but they don't contain any warnings or information that would suggest that the autodownloader would overwrite any game data.

#8
DotFreelance

DotFreelance
  • Members
  • 17 posts
My solution ended up being to run the module from another directory entirely. The directory can be anything you choose, but should be outside the Neverwinter Nights 2 folder. The toolset and the server on my machine both see the module at "C:\\NwNServer" instead of in the Documents folder.

Once the folder "NwNServer" was created, I used the Stage Server option ( in toolset: File > Shared Content > Prepare Game Server Files ) to put all of the server files with the complete structure into "NwNServer". You can change the staging path to "C:\\NwNServer" to make this easy for you.

When you open the toolset, go to View > Options... and go to the DefaultModulePath setting and put "
C:\\NwNServer\\modules"

Note: If you are running the server on the same computer, the standalone server needs to have a shortcut created, and in the target at the end add:  -home "c:\\NwNServer" -moduledir "NAMEOFYOURMODULEDIRECTORY" . Also note  you may need to copy nwnplayer.ini and ServerDesc.txt to your new server directory.

The reason this method is slightly superior is because it moves the server entirely. This is ideal especially if you later decide to move your server from your current computer to a host ( as I plan to do. ) The transition will be rather smooth.

Edited by DotFreelance, 03 January 2012 - 11:16 AM.


#9
painofdungeoneternal

painofdungeoneternal
  • Members
  • 1,799 posts
You still need to use -home to move the playing folder. It is difficult to move the toolset and does not prevent the problem really as when you play with the regular player folder which is also used for toolset, it ends up overwriting the toolset thus creating the problem. Even then having the server files in a third spot like you suggest is helpful as well as it creates a working version and a live version ( you tend to need to mess things up as you create new areas and only put them live after they are well tested ).

You can just use the -home shortcut for playing the game all the time, have another shortcut for testing which is in my documents, and you should be good to go.

You should really read more things here though, the use of drop box instead of ftp, nwnx and xp_bugfix are pretty much required, and it helps to move the server onto it's own processor ( via NWNx ) especially if you are using the computer while players are on the server.

http://www.nwnx.org has a lot of info as well, and there is a few older articles on nwn2wikia.

Edited by painofdungeoneternal, 03 January 2012 - 04:11 PM.


#10
DotFreelance

DotFreelance
  • Members
  • 17 posts

painofdungeoneternal wrote...

You still need to use -home to move the playing folder. It is difficult to move the toolset and does not prevent the problem really as when you play with the regular player folder which is also used for toolset, it ends up overwriting the toolset thus creating the problem. Even then having the server files in a third spot like you suggest is helpful as well as it creates a working version and a live version ( you tend to need to mess things up as you create new areas and only put them live after they are well tested ).

You can just use the -home shortcut for playing the game all the time, have another shortcut for testing which is in my documents, and you should be good to go.

You should really read more things here though, the use of drop box instead of ftp, nwnx and xp_bugfix are pretty much required, and it helps to move the server onto it's own processor ( via NWNx ) especially if you are using the computer while players are on the server.

http://www.nwnx.org has a lot of info as well, and there is a few older articles on nwn2wikia.


You should actually read my post, as that is exactly what is being done, and the toolset can be changed easily, and work out of any directory.

#11
painofdungeoneternal

painofdungeoneternal
  • Members
  • 1,799 posts
You are checking more than just modules right, there are quite a few things you need in that player folder from bitmaps, music, sound files, and other resources. You don't want to put anything in the program files folder unless you have to. From my experience it's not a good practice and the toolset is only reliable if it's in the player folder, and you also put some resources in the override folder as well ( which need to load at toolset start or they won't go into effect even if you open a module later, of course even than 2 or 3 things will need to go in program files ).

Of course at some point a proper way of moving it, or a completely new homemade toolset will fix issues like this.

Edited by painofdungeoneternal, 04 January 2012 - 07:27 AM.