So I'm wondering how to use the new zipfile stuff when DragonSnot has two versions.
There is DragonSnotClient.zip, which is the client-only URL w/resources version.
There is DragonSnotGame.zip which is the full game, only available to those who purchased it.
Both are tied to the same name and all that...what would make sense to do here so that purchasers of the game are notified of new versions?
ID:138109
 Mar 30 2001, 2:59 pm
|
|
On 3/31/01 7:15 am Dan wrote:
There is DragonSnotClient.zip, which is the client-only URL w/resources version. That's okay -- I wasn't really making use of it (yet) anyway. I was waiting until we have a full game. Of course, given that you already have your own central server and everything, you could also just do your own version update checks through that. This is a very good point, and one for some reason I didn't really think about. Given this, you guys shouldn't do too many acrobatics to accomodate the DDT unless it will also help others. (I think a solution to the 2 zipfile problem would be generally helpful...but I'm not sure there is one!) The version updates are now generated from What are these files? Is there a write-up somewhere on them? Sorry to be kind of dense on all this...it would be very wonderful if there was a page that described all the hub stuff in one place. | |
Oops. I just realized that I effectively dissabled version update notification for games like yours which are distributed externally to the hub.
It used to report a version update whenever you ran the game locally (and it used the game's reported world.hub and world.version values). Now, it only uses world.hub for reporting live connections, scores, and for hubfiles, and it never uses world.version. The version updates are now generated from information in your installation database (cfg/MyHub.txt and cfg/hub.txt).
I will think about this and try to come up with a good solution for your case. This relates to the next feature I am going to add to the hub, which is an option for having paid subscriptions. If you want to manage the subscription yourself, as you are currently doing, we may need some mechanism for you to make an entry into the hub's own subscription database. Then a user could sign up and you could connect them to Deadron.DragonSnot, which would do the installation through the hub.
Of course, given that you already have your own central server and everything, you could also just do your own version update checks through that.
In any case, I expect that you will want to set world.hub to the same value in both the central and distributed version of the game, since that is only used for grouping together the live connections and a few other things that do not relate to the now separate issue of distribution.
To give you an example of what I mean, I am planning to create a hub entry called "BYOND.Chat" which could be used by any number of different chat worlds as world.hub, allowing them to all be visible in the same place when they are live. They would, of course, be distributed through their own separate places in the hub.
Sorry to have messed you up. I tried to be careful and preserve the ability to conveniently distribute externally to the hub, specifically because of your case, but I overlooked the issue of version update notifications.
--Dan