ID:1018428
 
Applies to:Dream Daemon
Status: Open

Issue hasn't been assigned a status value.
Right now, you can replace the DMB of a world hosted in DD and issue a world.Reboot() and it will update the hosted version of the world. What I'm requesting is for this to also reload the associated .RSC. As of right now, if you replace the DMB and RSC of a hosted world and then issue a world.Reboot() it will re-load the DMB but not the RSC. Instead, it apparently uses the RSC that's in memory which doesn't necessarily match up with the updated DMB and totally borks everything. I'd like for it to re-load both so we can do seamless updates of worlds in all scenarios.
Kind of makes sense that it's using what is in the memory as it isn't actually shutting down DD at all.

But I really like the idea, it would be a simple reboot to push out updates instead of closing DD and losing players connections.

+1
Seconded.
In response to A.T.H.K
A.T.H.K wrote:
Kind of makes sense that it's using what is in the memory as it isn't actually shutting down DD at all.

But going by that logic, it should do the same thing for DMBs as well and it doesn't. It actually loads the new DMB. It's sort of inconsistent.
You can even upload a code file, recompile and reboot the world.
Would make sense to be able to do this with .rsc files as well.
I've always set cache_lifespan to 0 to accomplish this.
Number of days items that are not in use will be saved in the resource cache (.rsc file). Files uploaded by players are stored in the world's .rsc file for future use. If the file is not used for the specified amount of time, it will be removed to save space.

Cache Lifespan seems irrelevant to this post to be honest but if it does truly do what your implying why isn't it documented properly? And wouldn't it force an rsc download each time you login since you are in reality removing the file after the user has closed Dream Seeker? That's not something you would want players to go through if that game is 10MB ...
What you could do is use preload_rsc and store it in an external web, allowing an update to replace the .DMB, and load the rsc again (Externally).

Would that work while this is implemented/rejected?
In response to A.T.H.K
I suppose cache_lifespan doesn't do anything.
All I know is that my game has always coped just fine with replacing both the DMB and RSC between reboots, and I figured it might have had something to do with cache_lifespan but according to here, it no longer does anything.
Of course, preload_rsc = "http://yourfilespath" will force clients to re-download rscs if it changes, making it very easy to update and replace both .rsc and .dmb files with not drawbacks at all.
Yes but your are focusing on the client not the server which is what the OP is about :)
Yeah, I know really.
Was telling murrawhip how more effective preload_rsc would be against cache_lifespan.

This feature request should be taken into account in future builds.
In response to Murrawhip
Murrawhip wrote:
I suppose cache_lifespan doesn't do anything.
All I know is that my game has always coped just fine with replacing both the DMB and RSC between reboots, and I figured it might have had something to do with cache_lifespan but according to here, it no longer does anything.

Just out of curiosity, are you hosting on Windows or Linux and how are you issuing the reboot?
In response to Audeuro
Audeuro wrote:
Just out of curiosity, are you hosting on Windows or Linux and how are you issuing the reboot?

Linux with world.Reboot().
Aren't you having any problems with the .rsc at all?
In response to Murrawhip
Murrawhip wrote:
Linux with world.Reboot().

That's definitely interesting, then. Generally speaking, if the RSC has changed at all then the world will basically be nuked when you reboot it with the updated DMB. This has been true for every world that my acquaintances and I have hosted for as long as I can remember. :O
I guess he using cache_lifespan = 0 has some impact on how .RSC are handled, at least that's what I suspect.
In response to Audeuro
It's worked for me from 2008 up until now.
preload_rsc with a URL was used in the beginning but not for the last year or so.
I can't remember when or why I added cache_lifepsan, or whether or not it fixed anything.
I'll do some further testing in the next day or so and see what's going on. Your cache_lifespan might have fixed it in a way because of the following behavior:


Setting this value to 0 causes items to be saved for the current session only. This is used by the CGI library, because web browsers cannot make use of server-side caches when uploading files anyway.



It might dump all resource data in memory and reload the RSC on reboot to ensure it's all fresh. We'll see.
Except cache_lifespan literally does nothing right now.
Page: 1 2