Register to post in forums, or Log in to your existing account
 

Play RetroMUD
Post new topic  Reply to topic     Home » Forums » CMUD General Discussion
Larkin
Wizard


Joined: 25 Mar 2003
Posts: 1113
Location: USA

PostPosted: Sat May 17, 2008 10:59 pm   

[2.25] Loading packages on different machines
 
I've got at least three computers now that I use for developing my CMUD packages. My current issue is that I build the packages on one machine, copy them to my USB drive, and then load them onto another PC. If the machine didn't already have a copy of the packages (i.e., brand new CMUD installation), the dependencies between packages are lost.

Is there a database cache that "remembers" the UID associations between the packages? This is an issue for when I want to give the two dozen packages I've created to someone else and they have to check all those boxes to set the modules up again...

Or, am I the only one with this problem?
Reply with quote
Vijilante
SubAdmin


Joined: 18 Nov 2001
Posts: 5182

PostPosted: Sun May 18, 2008 1:53 am   
 
If I remember right the packages enabled for a module are stored as part of the module/window setting within the .pkg file. They are stored as a string list of the names of the packages.

I am going to take a wild guess and say that the list is getting paired down during your import. Without knowing how you are importing the packages I really have no way to test that guess. I know that you have used a text based setting creation as an import method in the past, and that would definitely not have the package dependency information.

Interestingly the XML format also does not have this information, so I think the only way you can keep it is to directly transfer the .pkg.
_________________
The only good questions are the ones we have never answered before.
Search the Forums
Reply with quote
Larkin
Wizard


Joined: 25 Mar 2003
Posts: 1113
Location: USA

PostPosted: Sun May 18, 2008 11:49 am   
 
I am importing them directly through the .pkg files now. I create them initially by executing my text scripts, and the XML actually does show a string list of packages for each module. What I did was copy all my .pkg files from one machine to another, open a session offline, open the package editor and File -> Open -> import .pkg. I open my "core" package first and then a package that depends on it, but the second package does not have the core package enabled then.

Yes, I was mistaken in thinking that CMUD uses the UID of each package to associate them, but something is definitely amiss when I have to re-associate them on a new machine.
Reply with quote
Larkin
Wizard


Joined: 25 Mar 2003
Posts: 1113
Location: USA

PostPosted: Thu May 22, 2008 1:58 pm   
 
Turns out that you don't even need to use a clean installation on a separate machine to get this to happen.

1. Open the untitled session.
2. Open the package editor.
3. File -> New package -> TestA
4. File -> New package -> TestB
5. Check TestA on the list of packages enabled for TestB.
6. File -> Save (just to be sure)
7. Close package editor.
8. Close all sessions.
9. Open some other session offline. I used one of the pre-installed ones that had no settings or additional packages.
10. Open the package editor.
11. File -> Open -> TestA
12. File -> Open -> TestB

Note that TestA is not checked in the list of packages enabled for TestB any longer. Now, if you check TestA, save the packages, remove the packages, close the session, re-open the session, and re-add the packages, then TestA will be checked still. This tells me that the session caches the dependencies of the packages and not the packages themselves.
Reply with quote
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA

PostPosted: Wed May 28, 2008 7:34 pm   
 
Yes, I think Larkin is correct. I think this is stored in the Session information and not with the packages themselves. I think when I originally implemented this I wanted different sessions to be able to have different package dependencies. I'll need to think about this more to decide how it should really be done.
Reply with quote
Larkin
Wizard


Joined: 25 Mar 2003
Posts: 1113
Location: USA

PostPosted: Thu May 29, 2008 4:44 pm   
 
I assumed correctly then!

However, I feel it makes more sense for the dependencies to go with the package and not the session. Package dependencies are what allow us to make a couple base packages that we can then build on for other packages, keeping things simpler (i.e., modular) and less redundant. Also, the dependencies are visible in the package XML, which was why I really felt this was a bug.
Reply with quote
Larkin
Wizard


Joined: 25 Mar 2003
Posts: 1113
Location: USA

PostPosted: Tue Jun 10, 2008 4:05 pm   
 
*bump*

Any thoughts of getting this fixed for 2.27?
Reply with quote
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA

PostPosted: Tue Jun 10, 2008 5:00 pm   
 
Not for 2.27, sorry. I'm still trying to figure out exactly how to do it. It's going to wait until I start figuring out how to store mapper configurations in the package library. At that time I'll be in a better position to come up with an updated storage format that can handle things like this.
Reply with quote
Larkin
Wizard


Joined: 25 Mar 2003
Posts: 1113
Location: USA

PostPosted: Tue Jun 10, 2008 8:23 pm   
 
Okay. I just thought I'd ask. What still has me confused, though, is that the dependencies are listed in the package/module XML. So, how is it not stored in the package already and we still need the session to tell us this? Maybe it's a matter of the code internally pulling data from one place versus another, but I'm sure it's not as simple as that or you'd have already changed it.
Reply with quote
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA

PostPosted: Tue Jun 10, 2008 9:53 pm   
 
Yep, it's not as simple as that ;)
Reply with quote
Display posts from previous:   
Post new topic   Reply to topic     Home » Forums » CMUD General Discussion All times are GMT
Page 1 of 1

 
Jump to:  
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

© 2009 Zugg Software. Hosted by Wolfpaw.net