This forum is a read-only archive of the Gammon Software forum (2000–2026). No new posts can be made. Search the archive.

SWR Fuss Hotboot compile

Posted by Asean Novari on Sun 17 Oct 2004 10:01 PM — 10 posts, 34,209 views.

Asean Novari USA #0
I apologize for overlooking the right to share part. It was a
mistake that will not happen again. I do however appreciate
you taking the time to fix the code so it works. I have
gotten it running and it works perfectly.
Amended on Wed 20 Oct 2004 07:30 AM by Asean Novari
Greven Canada #1
If your using fuss, then you would want to make it look like 
    if (!fCopyOver) /* We have already the port if copyover'ed */
	control  = init_socket( port   );


That should be what you need.

2 points, though. The reason that you can't find it is that SWRFUSS, while superior to stock 1.0, isn't 1.0, so there will be minor differences. Secondly, I would like to quote the .txt file
Quote:
This snippet may not be posted for redistribution on any site
without obtaining prior written consent from the Alsherok team and
the Dark Warriors team.

3. For support of this snippet, come to Greven first, at either
http://darkwars.wolfpaw.net/cgi-bin/ikonboard.cgi or darkwarsmud@hotmail.com. I will do
what I can for email support, but the forum is generally a better way to
go.
Now I realize that your not trying to distribute it, and its seems that you may be inexperienced in such matters, but if you do not follow terms of agreement in snippets, people generally get angry and stop releasing them, as has happened so many times before to various people. In this circumstance I don't mind, its was an honest mistake, though since this work is based on Samson's original, he might, I don't know.

The 3rd term there isn't quite as strict, though if someone has support available for code they write directly, its usually a good idea to talk to them first, as they will know the code better.


Also as a side note, I will be working on a new version of it that should have FUSS supported and clean up some of the problem that have cropped up from time to time. I will post here when its available.
Amended on Mon 18 Oct 2004 12:12 AM by Greven
Greven Canada #2
I have update the snippet for be a little cleaner, ran it through indent and put in some instructions on what needs to be changed for FUSS. Its available where it always is, I don't want to advertise, but since someone got it already, they must know where again :)
Samson USA #3
A correction I think needs to be made here:


/*
 * Connected state for a channel.
 */
typedef enum
{
  CON_PLAYING,		CON_GET_NAME,		CON_GET_OLD_PASSWORD,
  CON_CONFIRM_NEW_NAME,	CON_GET_NEW_PASSWORD,	CON_CONFIRM_NEW_PASSWORD,
  CON_GET_NEW_SEX,	CON_READ_MOTD,
  CON_GET_NEW_RACE,	CON_GET_EMULATION,	CON_EDITING,
  CON_GET_WANT_RIPANSI,	CON_TITLE,		CON_PRESS_ENTER,
  CON_WAIT_1,		CON_WAIT_2,		CON_WAIT_3,
  CON_ACCEPTED,         CON_GET_PKILL,		CON_READ_IMOTD,
  CON_GET_NEW_EMAIL,    CON_GET_MSP,            CON_GET_NEW_CLASS,
  CON_ROLL_STATS,	CON_STATS_OK
} connection_types;

  Add the con stats and the = to make it look like this:

/*
 * Connected state for a channel.
 */
typedef enum
{
  CON_GET_NAME = -99,	CON_GET_OLD_PASSWORD,
  CON_CONFIRM_NEW_NAME,	CON_GET_NEW_PASSWORD,	CON_CONFIRM_NEW_PASSWORD,
  CON_GET_NEW_SEX,	CON_READ_MOTD,
  CON_GET_NEW_RACE,	CON_GET_EMULATION,	
  CON_GET_WANT_RIPANSI,	CON_TITLE,		CON_PRESS_ENTER,
  CON_WAIT_1,		CON_WAIT_2,		CON_WAIT_3,
  CON_ACCEPTED,         CON_GET_PKILL,		CON_READ_IMOTD,
  CON_GET_NEW_EMAIL,    CON_GET_MSP,            CON_GET_NEW_CLASS,
  CON_ROLL_STATS,	CON_STATS_OK, 		CON_COPYOVER_RECOVER,
  CON_PLAYING = 0,      CON_EDITING
} connection_types;


In your instructions you have CON_EDITING unspecified after CON_GET_NAME is set to -99. Due to how enumerations work, it won't be > 0 as you were probably hoping it would.

When you set a value in an enum, every value which follows it will be +1 more than the one before it. Where you have it now it would come out as -90 and not +1 like it should be. CON_EDITING isn't likely to be true for anyone in the chargen sequence of a stock SWR or Smaug. Also not sure where your CON_ROLL_STATS and CON_STATS_OK fit in, but if those should be > 0 they need to be moved as well.
Greven Canada #4
I'm at work so I can't pull up specific references, but I think that the example I included may be old. The = 0 looks like its in the wrong place to me, thoug I am going totally off of memory. I know that I haven't encountered any problems at all with it. The CON_PLAYING looks very strange. I'll check when I get home.
Greven Canada #5
Thanks for info, I was using in my test SWRFUSS
/*
 * Connected state for a channel.
 */
typedef enum
{
  CON_PLAYING = 0,	CON_GET_NAME,	CON_GET_OLD_PASSWORD,
  CON_CONFIRM_NEW_NAME,	CON_GET_NEW_PASSWORD,	CON_CONFIRM_NEW_PASSWORD,
  CON_GET_NEW_SEX,	CON_READ_MOTD,
  CON_GET_NEW_RACE,	CON_GET_EMULATION,	CON_EDITING,
  CON_GET_WANT_RIPANSI,	CON_TITLE,		CON_PRESS_ENTER,
  CON_WAIT_1,		CON_WAIT_2,		CON_WAIT_3,
  CON_ACCEPTED,         CON_GET_PKILL,		CON_READ_IMOTD,
  CON_GET_NEW_EMAIL,    CON_GET_MSP,            CON_GET_NEW_CLASS,
  CON_ROLL_STATS,	CON_STATS_OK, 		CON_COPYOVER_RECOVER
} connection_types;
The 0 is useless I realize, so I'm going with out it and have updated the snippet as such, thanks for the catch.
Samson USA #6
According to all of the hotboot/copyover snips I've ever seen, CON_PLAYING = 0 is in the right spot where I put it. All of the constates that preceed that are usually set aside for those who have not fully connected to the game. Usually because they're still suck in chargen. So any constate before then would be between -99 and -1 and cause them to get dropped. CON_PLAYING being 0, they get kept and any constate above that would as well.

Now, I haven't examined how your code works, but unless you've reconfigured how the code treats the constates, none of these partially completed people will be dropped. The largest reason for wanting to drop them would be to prevent problems saving data in structs that have not yet been defined.
Greven Canada #7
K, now I'm a little confused. I assume your talking about when someone drops a connection during creation, before being put into game. Now, in my hotboot it will attempt to save all of the descriptors characters, so a person connecting would get caught at this point with an incomplete player file for writing. This is what I assume your talking about, its been a long day so I may be wrong. While looking in both my own and SWRFUSS save_char_obj, if the player is not authed, which they wouldn't be during creation, they do not save, so I don't see how you would get a problem saving them.

Also, I can't seem to find a reference to dropping or not dropping people in regards to their constate being higher or lower, all I can find is checking playing or editing. If there is a problem, I would be very appreciative in some direction, as I don't seem to understand the problem.
Samson USA #8
The problem lies in the fact that you check in do_hotboot for CON_PLAYING < 0, and have specified CON_PLAYING = 0 as your first entry in the enum table. This makes all of the other constates after it positive numbers, so they can not be less than CON_PLAYING. While it's true that save_char_obj won't save their pfiles, your hotboot code *DOES* save their descriptor information to the hotboot file.

When the hotboot_recover code is called, and they don't have a pfile, they will be cut off from the game and told there was an error and that their pfile has been lost. We both know they never had one, but the player won't and would assume based on that message that they've lost something. They would then of course have to start over again.
Greven Canada #9
AH, I gotcha, makes sense. Theres not much of of a difference in just disconnecting them before or after the hotboot to the player, but its still less memory/processor. Been updated, thanks.

Actually, for my own mud, in do_users I use an array of names for the connection state, so in my own it won't work, I just changed it to check playing, but for normal SWR it will still work.