in space.c
around line 6442
find

      ship->dest = STRALLOC( arg );

change that to

      if( ship->dest )
         STRFREE( ship->dest );
      ship->dest = STRALLOC( arg );

around line 9944
find

      target->dest = STRALLOC( ship->name );

change that to

      if( target->dest )
         STRFREE( target->dest );
      target->dest = STRALLOC( ship->name );

Ok, well unless someone points out some bugs etc... I'm done for the most part.

It will still need a cleanup_memory function added and all to help find more possible leaks. Maybe some runs through valgrind also.

If anyone knows of more bugs feel free to post them for someone to check out.

Well, Now that I'm back from the MudMeet, it looks like I have my work cut out for me. I guess I'll get these added into the release at some point today/tomorrow and get it updated.

Alright, I just finished cleaning up the area files so most of them are no longer loading objects and mobs from other areas to clean up the startup log spam. There are a few objects, primarily boards and packages, that I can't really do much about.

I've redone the area list file so areas load up in vnum order, and everything loads up with no error messages. So, what to do with them? Package everything up in a rar file or something and upload here?

Tarball the fixed up areas and email them to me at @malevolentwhispers.org.

I'll add them to the official package when I get the bugs in this thread patched up. I got distracted writing a space system from scratch into SmaugFUSS... >.>

Hate to dig up a rather old thread, however did everything Remcon here post about get patched or ignored for SWFOTEFUSS?
I ask because I was looking at void do_tellsnoop in slicers.c and noticed the current version under the files is still using:

 if( !str_cmp( arg, "clear" ) || !str_cmp( arg, "self" ) )
   {
      send_to_char( "You turn your radio off.\r\n", ch );
      ch->pcdata->tell_snoop = NULL;
      return;
   }

Instead of Remcon's suggestion of:

   if( !str_cmp( arg, "clear" ) || !str_cmp( arg, "self" ) )
   {
      send_to_char( "You turn your radio off.\r\n", ch );
      STRFREE( ch->pcdata->tell_snoop );
      return;
   }

ayuri

Just wanted to say, maybe using 'ignored' in the above post was a wrong choice of words. I know Kayle and the others here have been busy with other projects and RealLifeâ„¢. It could have just slipped though the cracks. Heck, I all but dropped off the face of the earth for 2 years... My apologies if I offended anyone.

Taking a quick peek though the code, seems like most of the items Remcon posted weren't included in the latest FOTEFUSS 1.4 modified Oct 16, 2010. Or somehow I managed to grab a weird copy that yet still has keyed area formats???

Again, my apologies,
ayuri

Well thanks go to you for bringing all this to my attention, it will be in the next update that I'll put up tonight or tomorrow Thanks

Heh, if you don't mind having another external library, you can somewhat solve many of those stupid C memory issues (freeing the mallocs!) by using gcmalloc.

http://www.hpl.hp.com/personal/Hans_Boehm/gc/

Why worry about which bits you have to free, or trying to keep "spare" copies around when you can just let the system deal with it?

In the above examples, a regular malloc results in a memory leak because you didn't free the previously allocated chunk and lost the pointer to it. Using a garbage collector, once any memory chunk has no valid pointer, the system will free it. You just need to stick a call to the collector in your main loop so it gets called periodically.