|
mandy Novice
Joined: 10 Jul 2007 Posts: 47
|
Posted: Thu Jul 01, 2010 12:20 am
Installing CMud/CMud Beta |
Was using Cmud on a temporary computer while i didnt have access to my main computer. Now I'm trying to install CMud/and I was using the betas and transfer all my information from the one computer to the main computer..
I installed the basic cmud, installed the beta from there and opened the packages that i had saved from computer a(temp) onto computer b(main). I am experiencing all sorts of problems. My #win (windows) aren't opening correctly or functionally correct - manually deleting and re-making them seems to work temporary but in the then the program crashes and it doesn't save.
The program constantly freezes, any time i do anything other than just sit still in the mud, then cmud will freeze and crash. The session won't open correctly - just opens a blank black window and won't even connect to the mud - the mud is fully functional - can ping it from cmud and telnet to the mud.
I can't even really describe all the problems I've been having.
I have uninstalled/reinstalled several times - even went through file folders manually to delete anything i found that was zmud related.
All I want to do is move all my information from computer a to computer b.
If it matters computer a is running xp and has beta 3.2, computer b is vista and i dont care what cmud version i get so long as it works...but beta is preferred - i do want scripts from computer a on computer b. |
|
|
|
MattLofton GURU
Joined: 23 Dec 2000 Posts: 4834 Location: USA
|
Posted: Thu Jul 01, 2010 4:21 am |
First, completely remove CMud from Computer B. If there aren't any data files on Computer B that you definitely want to keep, go ahead and delete all the CMud folders. Once you are again at a pre-CMud configuration for Computer B, download and install version 3.21. If you need to, go ahead and create a new session for your game. Connect to the game, use the #SAVE command to force a settings save, and close down the session. Open the session a second time and connect to the game, so that you can get past the autologin stuff (it probably doesn't matter how you answer the autologin stuff, so you can choose between the Stop Asking option or filling in the correct info).
Second, on Computer A open up your session in offline mode (don't connect to the game). Open up the package editor. There should be a row of tabs (assuming you have more than one package). Click on each one to bring that package to the front, and choose the File|Export XML (All) menu option.
Third, find each of the exported XML files. Move the .xml and any .dbm/.db/.dbd files you want to keep out of the CMud folders. If Computer A has access to email, it's easiest to just attach those files to an email that you send to yourself. Similarly, if you have a thumb drive or a floppy or some other sort of portable storage device that you can physically connect/insert into Computer B you can put the files in that device. Once you are confident that all your necessary data is safely stored elsewhere, feel free to delete all traces of CMud from Computer A. Insofar as CMud is concerned, you have no more reason to bother with Computer A.
Fourth, back on Computer B, install your data files to their appropriate places. The .xml file that equates to your main package goes into the session subfolder found in the CMud Documents folder (My Documents/My Games/CMud/sessionname). If you have a mapfile (.dbm), it goes here as well. DB module database files (.db/.dbd) go into the DB folder found in the sessionname folder. All other .XML files go into the Packages folder.
Fifth, while not strictly necessary, get your hands on the 1.2 mapconverter utility. There's a Repair option that is likely to fix any mapfile-specific errors that might have been contributing to your prior mess. You may also want to get the cmud_map_doctor utility, but this is just for an extreme last-ditch backup plan (while it may fix some problems that the 1.2 mapconverter might not, it will interfere with your room script associations). Also, if you are familiar with your scripts and with the XML format, you might wish to take a look at your .xml files to make sure there aren't any extra or missing parts.
Sixth, taking one .xml file at a time, create a new package and import the XML to that package. It will probably be easier to check out your scripts one package at a time, since there are still some aspects of importing/copy-pasting various settings that aren't 100% stable (mostly this just means that various options are incorrectly set, rather than anything causing AVs and crashes).
Seventh, after all of your packages are created and imported, arrange your layout as desired. One VERY IMPORTANT thing to remember is that you are 100% limited to just 13 windows including both the DB module and the Mapper. Any more than that and your layout will self-corrupt as soon as you close the session. Once this has occurred, the session will be unplayable using the session layout file and any attempt to close this corrupted-layout session will result in an AV. This is completely non-negotiable until Zugg gets a chance to fix/replace the docking system components he's using.
Eighth, once you have laid out your windows exactly as you wish them, make sure the main window has the focus and then choose the Layout|Save Layout menu option. There appears to be a bug that leads/increases the likelihood of layout corruption if a secondary window is selected, which is probably similarly entwined with the docking system.
Ninth, for good measure, fire off a #SAVE from the commandline so that you don't have to worry about doing all this all over because something didn't save (entirely a piece of mind thing, since you're not going to be in a good mood).
Now, all of that was just generic cleanup/recovery stuff that doesn't even consider the fact that perhaps you or the person you got your scripts from either didn't know what they were doing or did things using an "old" and perhaps no-longer-working way of doing things. This sort of "bad code" can lead to AVs and problems of its own, so it's important that we know for sure we're on a clean slate. From here on out, you will have to post real code for us to be able to offer any help. |
|
_________________ EDIT: I didn't like my old signature |
|
|
|
mandy Novice
Joined: 10 Jul 2007 Posts: 47
|
Posted: Thu Jul 01, 2010 4:59 am |
I managed to get all my packages moved over except the main session package... also the one containing the maps... So i just re-did the important triggers (it was just single triggers not really any full out scripts) by hand. But it does contain my maps and I would really like to transfer those. Is there a way I can just export the maps? I poked around a bit but didnt see how to do this and am VERY new to using the mapper but once I figured it out I started mapping everything! I would so hate to see that work go to waste.
About the converter, I saw a 1.3 converter on the downloads site - not 1.2, and it says for changing from zmud to cmud? would that still apply to me when im just transferring cmud from one computer to another?
Also I noticed another difference... on computer a, i have cmud pro and computer b is just cmud, does that affect? computer a doesnt use my license so i just downloaded the trial of the first link i saw *blush* |
|
|
|
mandy Novice
Joined: 10 Jul 2007 Posts: 47
|
Posted: Thu Jul 01, 2010 5:09 am |
actually nevermind the maps question i think i understand that now... kinda... but i dont have any files with the .dbm
whats the .zfg extension? lots of those |
|
|
|
MattLofton GURU
Joined: 23 Dec 2000 Posts: 4834 Location: USA
|
Posted: Thu Jul 01, 2010 5:24 pm |
The licenses are different between pro and regular, yes. If you used regular on the temp computer then you need to either install regular on the main computer and reissue a license key (it's free, just have to log into the zuggstore to get it) or buy a new license for pro. Vice versa if you started with pro and ended up with regular. The license key is only active for 7 days, so if you waited until the 8th day to apply it to CMud it won't work and you'll need to get a new one.
Map info is stored in the .dbm file. If you opened up the mapper at any time in the beta version and proceeded to create new rooms, you have a .dbm file somewhere on that computer. If you don't, then either you were using version 2.37 or someone/something on that computer deleted your file and the mapper work is gone forever. 2.37 uses the old .mdb ADO format.
If you were using 2.37, you have two choices. The first is that you use the MapConverter utility (use whatever is the latest version) on the file yourself to convert it to a .dbm SQLite format. I think the default behavior for the utility is to convert a .dbm file to a .mdb and a .mdb to a .dbm. Once converted, you would then move the new .dbm file into your session subfolder and open it by editing the properties of the mapper object in the Package Editor or by using the File menu in the mapper itself. The second is to just move that .mdb file to the session subfolder and open that file via the mapper. This will make CMud handle the conversion for you. |
|
_________________ EDIT: I didn't like my old signature |
|
|
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
|