This is my new deity:
#DEITY
Filename auril.dty~
Name Auril~
Description Neutral evil goddess of winter. Auril's symbol is a six-pointed snowflake.
~
Alignment 0
Worshippers 1
Flee 0
Flee_npcrace 0
Flee_npcfoe 0
Kill 20
Kill_npcrace 0
Kill_npcfoe 0
Kill_magic 0
Sac 20
Bury_corpse 0
Aid_spell 0
Aid 0
Steal 0
Backstab 0
Die 0
Die_npcrace 0
Die_npcfoe 0
Spell_aid 0
Dig_corpse 0
Scorpse 500
Savatar 0
Sdeityobj 0
Srecall 300
Race -1
Class -1
Element 0
Sex -1
Affected 0d
Npcrace 0
Npcfoe 0
Suscept 0
Race2 -1
Susceptnum 0
Elementnum 0
Affectednum 0
Objstat 0
End

#END

Also race file:
Name Tigran~
Race 15
Classes 512
Str_Plus 0
Dex_Plus 1
Wis_Plus 0
Int_Plus 0
Con_Plus -1
Cha_Plus 0
Lck_Plus 0
Hit 0
Mana 0
Affected 0d
Resist 0
Suscept 0
Language 0
Align 0
Min_Align -1000
Max_Align 1000
AC_Plus 0
Exp_Mult 100
Attacks 0d
Defenses 0d
Height 66
Weight 150
Hunger_Mod 0
Thirst_mod 0
Mana_Regen 0
HP_Regen 0
Race_Recall 0
WhereName ~
WhereName ~
WhereName ~
WhereName ~
WhereName ~
WhereName ~
WhereName ~
WhereName ~
WhereName ~
WhereName ~
WhereName ~
WhereName ~
WhereName ~
WhereName ~
WhereName ~
WhereName ~
WhereName ~
WhereName ~
WhereName ~
WhereName ~
WhereName ~
WhereName ~
WhereName ~
WhereName ~
WhereName ~
WhereName ~
WhereName ~
WhereName ~
WhereName ~
End


Once I realized what it was I removed those d in some of the lines and its fixed! Thanks for helping me guys lol (WHY is it putting d's in certain spots I'll never know)

Zedethar said:


Once I realized what it was I removed those d in some of the lines and its fixed! Thanks for helping me guys lol (WHY is it putting d's in certain spots I'll never know)

Well, curious... why is this %ud and not just %d? Is that even correct? It's not %ud in my dated FUSS derivative, and I'm pretty sure I didn't change it. Perhaps this is the reason you are getting an extraneous 'd' ?

/* return a string for writing a bitvector to a file */
char *print_bitvector( EXT_BV * bits )
{
   static char buf[XBI * 12];
   char *p = buf;
   int x, cnt = 0;

   for( cnt = XBI - 1; cnt > 0; cnt-- )
      if( bits->bits[cnt] )
         break;
   for( x = 0; x <= cnt; x++ )
   {
      snprintf( p, ( XBI * 12 ) - ( p - buf ), "%ud", bits->bits[x] );
      p += strlen( p );
      if( x < cnt )
         *p++ = '&';
   }
   *p = '\0';

   return buf;
}

%ud is the specifier for an unsigned integer. Chances are that was done long ago to silence compiler warnings about using the wrong signage in various operations.

Samson said:

%ud is the specifier for an unsigned integer. Chances are that was done long ago to silence compiler warnings about using the wrong signage in various operations.

Only place I could see a lone "d" cropping into this. Is it possible a compiler bug is behind this and not interpreting %ud properly? Isn't this being compiled on Cygwin in this case?

To wit, here's an old 2018 Gammon post on the exact same issue. Stumbled on this while searching "Cygwin %ud bug" of all things. Again, maybe this is a Cygwin thing if %ud is the correct specifier?

Edit: if you go further down the rabbit hole, we can go full circle back to this very forum:

New server errors

It looks like some time in the last 7 years, gcc started only seeing %u as an unsigned int and the %ud modifier doesn't get caught as invalid now.

I changed it on the distribution folder I keep on my linux server and apparently the compiler no longer complains about it being simply %d as it was originally so changing it in the function should stop it from dumping junk into the files. It'll make its way into the next codebase update, whenever that ends up being.

And just for the record, this topic is about 1.9.3, but we updated SmaugFUSS a year ago so new installs shouldn't really be using that anyway.

As for 1.9.4 I mentioned at the beginning of this topic that it contained a bug with config automap that breaks all room descriptions, I would love to use it instead but I never could fix it.

Just did some checking, I wouldn't call the room descriptions "broken" but they're certainly not behaving correctly with that pile of extra space in them if the automap is on.

I'm not sure why that would be either since by the time Smaug had this feature my own MUD was already firmly in the hands of our own codebase instead.

The other bugs reported here have been addressed for the next update. Though in the future it would be appreciated if they were posted as separate threads for better tracking.

Awesome, I would love to try a new version and I will start a topic for it if I catch any bugs.

I hope the other bug was fixed, I stated it in my 'New to Smaugfuss' topic

Issues within the makefile of 1.9.4 in this line

W_FLAGS = -std=c++1z -Wall -Wshadow -Wformat-security -Wpointer-arith -Wcast-align -Wredundant-decls
I had to remove -std=c++1z this to make the makefile complete all the way through and compile Smaug.exe

Is this a bug with -std=c++1z or is my Cygwin failing because maybe I am missing something?

It's possible Cygwin doesn't like that flag for some reason. I don't know why it wouldn't, but I don't think anyone has really been trying to use Cygwin for anything in years and it hasn't come up before.

Is there a better compiler used besides Cygwin? If so maybe I will try something different to see if I get better results.