I noticed i did do some modifications at the beginning of the file, but i dont think changing "()" to "( )" would have much to do with it

Ok, I've been working at this for a while now and I hate to be a pain, but this is where I am…

For reference:

void copyover_recover ()
{
  DESCRIPTOR_DATA *d;
  FILE *fp;
  char name [100];
  char buf[1000];
  char protocol_stuff[MSL];
  char host[MSL];
  int desc;
  bool fOld;
  extern char *help_copyover_end;

  logf ("Copyover recovery initiated");

  fp = fopen (COPYOVER_FILE, "r");

  if (!fp) /* there are some descriptors open which will hang forever then ? */
  {
	  perror ("copyover_recover:fopen");
	  logf ("Copyover file not found. Exitting.\r\n");
	  exit (1);
  }

  unlink (COPYOVER_FILE); /* In case something crashes - doesn't prevent reading	*/

  for (;;)
  {
	  fscanf (fp, "%d %s %s %s\n", &desc, name, host, protocol_stuff );
	  //fscanf (fp, "%d %s %s\n", &desc, name, host);
	  if (desc == -1)
		  break;

	  /* Write something, and check if it goes error-free */
	  if (help_copyover_end == '\0')
		  sprintf(buf, "\r\nRestoring from copyover…\r\n");
	  else
		  sprintf(buf, help_copyover_end);

	  //if (!write_to_descriptor (desc, "\r\nRestoring from copyover…\r\n",0))
	  if (!write_to_descriptor (desc, buf,0))
	  {
		  close (desc); /* nope */
		  continue;
	  }

	  d = new_descriptor();
	  d->descriptor = desc;
	  d->pProtocol     = ProtocolCreate();
	  d->host = str_dup (host);

	  d->next = descriptor_list;
	  descriptor_list = d;
	  ProtocolNegotiate(d);
	  d->connected = CON_COPYOVER_RECOVER; /* -15, so close_socket frees the char */

	  /* Now, find the pfile */

	  fOld = load_char_obj (d, name);

	  if (!fOld) /* Player file not found?! */
	  {
		  write_to_descriptor (desc, "\r\nSomehow, your character was lost in the copyover. Sorry.\r\n", 0);
		  close_socket (d);
	  }
	  else /* ok! */
	  {

		  /* Just In Case */
		  if (!d->character->in_room)
			  d->character->in_room = get_room_index (ROOM_VNUM_TEMPLE);

		  /* Insert in the char_list */
		  d->character->next = char_list;
		  char_list = d->character;

		  char_to_room (d->character, d->character->in_room);

		  act ("$n materializes!", d->character, NULL, NULL, TO_ROOM);
		  d->connected = CON_PLAYING;
		  d->character->pcdata->noagg = 0;
		  CopyoverSet( d, protocol_stuff );
		  ROOM_INDEX_DATA *to_room;

			if(is_room_owner(d->character,d->character->in_room) && IS_SET(d->character->in_room->croom_flag2, ROOM_SHIP))
			{
				if((to_room = get_room_index(d->character->pcdata->seanum)) != NULL)
				{
					OBJ_DATA *ship;
					char buf[MSL];
					char *name;

					name		= d->character->name;
					ship		= create_object(get_obj_index(OBJ_VNUM_SHIP), 0, 44);
					ship->owner = str_dup(d->character->name);

					ship->level = d->character->level;

					sprintf( buf, ship->short_descr, name );
					free_string( ship->short_descr );
					ship->short_descr = str_dup( buf );

					sprintf( buf, ship->description, name );
					free_string( ship->description );
					ship->description = str_dup( buf );
					obj_to_room( ship, to_room );
				}
			}

		  do_look (d->character, "auto");

		  if (d->character->pet != NULL)
		  {
			  char_to_room(d->character->pet,d->character->in_room);
			if (HAS_TRIGGER_MOB(d->character->pet, TRIG_PETLOG))
				p_percent_trigger( d->character->pet, NULL, NULL, NULL, NULL, NULL, TRIG_PETLOG );
			  act("$n materializes!",d->character->pet,NULL,NULL,TO_ROOM);
		  }
	  }

  }
  fclose (fp);

}

In the function, no matter where I put

d->pProtocol = ProtocolCreate();
ProtocolNegotiate(d);

(at least in any of the sensible places) and as long as it is before the do_look stuff, then it seems to loop until a buffer overflow causes it to crash, repeatedly sending the copyover_end message to me, while giving this coredump:

#583 0x080caef4 in write_to_buffer (d=0xb4899fc8, txt=0x8517600 "[*****] BUG: Buffer overflow. Closing.\r\n\n\r", length=42) at comm.c:2188
#584 0x080ddfe9 in act_new (format=0xbfbec5b0 "[*****] BUG: Buffer overflow. Closing.\r\n", ch=0xb489b85c, arg1=0x0, arg2=0x0, type=3, min_pos=0) at comm.c:9692
#585 0x080909ab in wiznet (string=0xbfbec5b0 "[*****] BUG: Buffer overflow. Closing.\r\n", ch=0x0, obj=0x0, flag=1048576, flag_skip=0, min_level=0) at act_wiz.c:920
#586 0x080e89e1 in bug (str=0x0, param=0) at db.c:5059
#587 0x080caef4 in write_to_buffer (d=0xb4899fc8, txt=0x8517600 "[*****] BUG: Buffer overflow. Closing.\r\n\n\r", length=42) at comm.c:2188
#588 0x080ddfe9 in act_new (format=0xbfbfd880 "[*****] BUG: Buffer overflow. Closing.\r\n", ch=0xb489b85c, arg1=0x0, arg2=0x0, type=3, min_pos=0) at comm.c:9692
#589 0x080909ab in wiznet (string=0xbfbfd880 "[*****] BUG: Buffer overflow. Closing.\r\n", ch=0x0, obj=0x0, flag=1048576, flag_skip=0, min_level=0) at act_wiz.c:920
#590 0x080e89e1 in bug (str=0x0, param=0) at db.c:5059
#591 0x080caef4 in write_to_buffer (d=0xb4899fc8, txt=0x8517600 "[*****] BUG: Buffer overflow. Closing.\r\n\n\r", length=23) at comm.c:2188
#592 0x080ddfe9 in act_new (format=0x8223aaa "$n materializes!", ch=0xb48b0574, arg1=0x0, arg2=0x0, type=0, min_pos=5) at comm.c:9692
#593 0x0809d633 in copyover_recover () at act_wiz.c:6728
#594 0x080c7fe0 in main (argc=4, argv=0xbfc14a74) at comm.c:464

The ProtocolNegotiate(d); line doesn't seem to make a difference here, although not having d->pProtocol = ProtocolCreate(); will cause the first crash problem.

Since it was requested, I also printed the values from that first bit:

(gdb) print d
$1 = (DESCRIPTOR_DATA *) 0xb7436e04
(gdb) print *d
$2 = {next = 0x0, snoop_by = 0x0, character = 0xb7438e98, original = 0x0, valid = 1 '\001', host = 0xb7438e5c "173-217-57-163-bssr.mid.dyn.suddenlink.net", descriptor = 9,
  connected = 0, fcommand = 0 '\0', inbuf = '\0' <repeats 4095 times>, incomm = '\0' <repeats 1023 times>, inlast = '\0' <repeats 1023 times>, repeat = 0,
  outbuf = 0xb743865c "", outsize = 2000, outtop = 0, showstr_head = 0x0, showstr_point = 0x0, ansi = 0 '\0', pEdit = 0x0, pString = 0x0, editor = 0, acc_name = 0x0,
  last_input = 0, pProtocol = 0x0}
(gdb) print d->pProtocol
$3 = (protocol_t *) 0x0
(gdb) print *d->pProtocol
Cannot access memory at address 0x0
(gdb)

The location of ProtocolCreate() looks fine, but you shouldn't call ProtocolNegotiate() after a copyover, the CopyoverSet() will restore the previous options (the reason for this is explained in the README.TXT, as well as in the comment above CopyoverSet() in protocol.h).

Can you please confirm that you're using the latest version (SNIPPET_VERSION should be 8)?

Is the copyover your only problem now, or does the code crash elsewhere as well?

It crashed here a few times too, but I haven't even begun investigating that until I could get the copyover thing sorted out:

#0  0x00d90643 in strlen () from /lib/libc.so.6
#1  0x00d603ec in vfprintf () from /lib/libc.so.6
#2  0x00d7c94c in vsprintf () from /lib/libc.so.6
#3  0x00d6619b in sprintf () from /lib/libc.so.6
#4  0x0820ae66 in msdp_update () at update.c:4279
#5  0x08206ed3 in update_handler () at update.c:3023
#6  0x080c88a4 in game_loop_unix (control=4) at comm.c:952
#7  0x080c7fd9 in main (argc=2, argv=0xbfb64204) at comm.c:466

Also, I haven't had it in place long enough to be sure if there are problems anywhere else. Admittedly, I haven't gotten any of it to work (as far as I can tell) yet, but I'm probably not properly using it either, all I've played around with so far was uncommenting what was necessary in order to allow the ^ code to be used for colors, along with allowing players to use extended color. Using those codes in-game hasn't produced any results for me, but it's also possible I might have something turned off in MUSH Client or something, I hadn't investigated that too much either yet because my main focus has been the copyover issue.

I'm 99% sure I downloaded it directly from this link, but when I get home from work, I'll confirm it's version 8.
http://www.mudbytes.net/file-2811

Also, I initially didn't have ProtocolNegotiate() in the code, but in trying some different things to see if something would affect it, I tried adding it in, but it's inclusion or exclusion didn't seem to make any bit of difference.

I'll post again when I'm sure which version.

As I mentioned on the other thread, msdp_update() isn't technically part of the snippet. The installation instructions show you how to get it working within a stock codebase, but you'll have to check the variables are correct for your particular mud. For now, I suggest commenting most of them out - just leave in a few for testing, like health and max health.


Do you mean it displays the codes as-is? Or that it always displays basic ANSI colour? If you tested them by adding them to your GREETING, the mud probably can't negotiate that fast, so make sure you test it with something in-game if you haven't already.


Both that and my website offer the latest version, I mostly just wanted to make sure you hadn't downloaded the snippet ages ago and only just got around to adding it. If you downloaded it recently then it should be fine.


It may cause problems with some clients (Windows Telnet springs to mind), but it shouldn't cause a crash. However it shouldn't be called, CopyoverSet() removes the need for doing so.

What you could also try is temporarily commenting out MCCP negotiation (if you've added it), and see that helps the copyover.

Are you running this on a test port somewhere?

ok i found out what went wrong with my problem, it was when i defined read_buf, im still tryin to remember how to do this exactly.

Any help.. sorry kinda did alot of stuff i shouldnt have done in those years i was away..

Yeah, I went through and modified the variables for the MSDP. I probably overlooked something, though.

It was displaying basic ANSI colour. ^o for example was showing as red instead of orange. I was using things like the say channel and the echo command. I haven't tried having the MUD outright attempt to send it, such through some output on a coded command. That was my next step before I worried myself too much on whether this part was working. I assume I'm overlooking or missing something on this. I haven't dedicated much time to this yet.

I haven't added any MCCP stuff, the only references anywhere in the code to it are in the protocol files. It is commented out in the protocol.h file as it came.

Yes, the version of the code with this installed is on a test port.

My best guess is that something is causing the loop that grabs the descriptors to just keep on looping instead of stopping after one time, at least based on the hundreds of times it sends the copyover_end message to me when I do a copyover, but I'm not seeing anywhere that could be causing that. Without the d->pProtocol = ProtocolCreate() inserted, it crashes, with it in, it loops. I'll remove the ProtocolNegotiate() part in there again, and double check it makes no difference.

edited to add: Made no difference :p

Ugh, I feel like an idiot.

Apparently -just- adding in the d->pProtocol = ProtocolCreate(); was what I needed to do. The weird looping issue was because I was using my code port, there were a couple of mismatches between the names of the executable file because I use "eot" on the normal and "eotcode" on the code port to help distinguish in the shell when using things like 'ps vx'. I crawled through everywhere and made sure everything matched and it seems fine now.

Additionally, the color codes are working. I haven't put any of this on the live port, and I still need to crawl through the msdp_update stuff to make sure I don't have any values in there that don't match EoT, but the main thing seems to be fine now.

Thanks a bunch for your help, I truly do try to exhaust every thing I can think of doing before I come to the forums to ask for help :p

Ok, got another issue… I expect it to probably be the last, everything else I've messed with seems to be working (still haven't looked into the msdp_update crash).

When I log into the game, the "[INFO] MXP version 0.5 detected and enabled." message isn't happening, nor is the extended color stuff working. If I reconnect, or connect and override the current connection, or do a copyover, then it enables and I see the message.

Any ideas on where I should be looking? I double checked over the ROM Installation instructions, and everything appears to be right, and I went through the init_descriptor, check_reconnect, and nanny functions but nothing popped out at me.

It really seems like you're missing something upon the initial handshake that you have in the reconnect and copyover. TBH, when I installed this snippet I had the -exact- opposite problem. Due to a missing initializing var, things would only work on the initial connection :). You need some kind of debugging. It's hard to say what's happening when we cannot see the handshake going on. Debugging protocols is tricky work. It took me hours to figure out that uninitialized var thing (however… that could say more about me than the code :D).

Try showing us the handshake. I honestly have no idea how you do that with any client. I know TinTin++ will have something for it, and I seem to remember Scandum posting on how to do it in one of the MSDP/MSSP threads. This is crucial to us helping to aid you. Or post a url/port, I have a (non-public atm) client that do it and I can post results.

Probably not the problem: but do you allow player to save their mxp options (I allow player to disable it and save the status so it does not get activated the next time they log)
chain of event being different between a simple connection and a reconnection may explain it.

Sounds like you're not calling MXPSendTag() after the player logs on. Extended colour isn't enabled for MUSHclient until the client responds to the MXP <VERSION> tag.

Out of curiosity, as a builder, does the color support mean that the protocol will send 256 if the mud itself supports them? Or does it include both?

The protocol snippet is hooked into the mud. The mud will send extended ANSI colour codes to the client if the client supports them, otherwise it'll send regular ANSI colour codes.

So as a builder you might add "^O" for orange text, and the players would see either orange or red (or no colour at all) depending on their client.

Davion… I'm running the code port with it installed at eotmud.com:4001

I wouldn't be sure how to show the handshake either.

Rarva: I haven't added anything like that, no. Right now, it's just the snippet without much in the way of modifications yet. I've tweaked some of the color values to make the darker colors just a tad brighter, and I've modified the msdp values to try to match EoT stuff. I've tried to trace the difference in what happens between a normal login and a reconnect, and I'm not seeing anything that would explain it.

KaVir: The MXPSendTag is currently in two places… In check_reconnect immediately after d->connected = CON_PLAYING; and the wiznet and logbuf login notifications… and in the nanny function immediately after the act call that notifies the room of the character having connected (immediately after this is the calls that bring up the note board, and notify the character of any server flags. The character is definitely in the game at this point that it sends that.

Ssol: Currently, normal color codes are still using { and all of the extended stuff is using ^. After the remaining issues are fixed and everything is working the way it's supposed to, I'm going to attempt to tie all of this into using the { character. I figure I'm going to have to do something in the code to basically alias the { symbol followed by, for example, the code for orange "O" to then produce the same thing that ^O is making. If I can do this, then I'm hoping it should basically be a seamless "addition" of new color codes that won't require keeping track of two different color codes and while keeping everything in the game that uses color the same.

Ahh, thank you. So we should probably update help color? :P

I have one in check reconnect, but the other one is in the READ_MOTD part in nanny, so just before the char goes in the CON_PLAYING state.
I plugged the snippet very easily in my code following instruction (minor tweak due to some of my changes in) and I think that except copyover that probably is totally broken because I never cared about it, everything 'seems' to work flawlessly. Added mccp right after in a breeze as well.

Would be great if there was a mush or tintin script that tested all cases and reported if something is wrong. ATM I have no idea if what I do is actually right (except that all clients seems to 'work')

If you have a branch without the snippet, it may be a good idea to go from then and 'readd' the snippet, maybe faster to find the step you missed than looking afterwards. (at least it was for me, the first time I added it , it was not working, as I missed a step somewhere, never could find what it was, so started again and it worked right away)

Ssol: If I can get everything working. Before I put it into the main port, though, I want to see if I can get it working where the "{" code will work with all of it, letting the MUD default to the normal ANSI color we already have in place, and switching to the new color codes when supported.

Rarva: I'll try moving the MXPSendTag in some other places in nanny. I can't imagine that it being before or after setting the player to PLAYING would make a difference, but it's worth a shot regardless :p

If I can't get it working, I can definitely try to go through and reinstall. I feel like I followed the directions pretty well and even double checking the installation instructions step by step, everything seems to be right, but it's worth a shot too. After my initial attempt at getting it working and realizing that it was going to take more time, I undid the changes and have the main game running without any of it, and I have the code port running where I'm making all the changes and additions related to this, so that should be the only difference between my main and my code port in order to install it fresh again.

And speaking of MCCP, I'm not very familiar with it… Aside from the server side benefit of reduced bandwidth, what are the advantages for the player? I did a little bit of googling and it said a faster connection, so the player side should see quicker response time, less lag, stuff like that?

I guess I'm not sure what the point is. Also, is there a particular version or uploader I should be searching for to get the most up-to-date version?