Got this error when make:
.
.
.
act_comm.c:4090: error: ‘CHAR_DATA’ has no member named ‘speaks’
act_comm.c:4099: error: ‘CHAR_DATA’ has no member named ‘practice’
act_comm.c:4105: error: ‘CHAR_DATA’ has no member named ‘practice’
act_comm.c:4110: error: ‘CHAR_DATA’ has no member named ‘speaks’
act_comm.c:4131: error: ‘CHAR_DATA’ has no member named ‘speaking’
act_comm.c:4132: error: ‘CHAR_DATA’ has no member named ‘act’
act_comm.c:4132: error: ‘CHAR_DATA’ has no member named ‘speaking’
act_comm.c: In function ‘do_traffic’:
act_comm.c:4145: error: ‘CHAR_DATA’ has no member named ‘act’
act_comm.c: In function ‘do_wartalk’:
act_comm.c:4156: error: ‘CHAR_DATA’ has no member named ‘act’
act_comm.c: In function ‘do_racetalk’:
act_comm.c:4167: error: ‘CHAR_DATA’ has no member named ‘act’
act_comm.c: In function ‘add_profane_word’:
act_comm.c:4206: warning: incompatible implicit declaration of built-in function ‘strlen’
act_comm.c:4297: warning: incompatible implicit declaration of built-in function ‘strcat’
act_comm.c: In function ‘is_profane’:
act_comm.c:4306: warning: implicit declaration of function ‘re_exec’
make[1]: *** [act_comm.o] Error 1
make[1]: Leaving directory `/home/tan/Desktop/smaug1.8/src'
make: *** [all] Error 2
Any suggestions on where did I go wrong?
I already uncomment out the line in the Makefile.
Here's a little something from the Makefile...
# Uncomment the two lines below if compiling on a Solaris box
#SOLARIS_FLAG = -Dsun -DSYSV
#SOLARIS_LINK = -lnsl -lsocket
#Uncomment the line below if you are getting a line like:
#interp.c:757: warning: int format, time_t arg (arg 7)
#TIME = -DTIMEFORMAT
#Uncomment the line below if you are getting implicit decleration of re_exec
REG = -DREGEX
#Uncomment the line below if you are getting undefined re_exec errors
#NEED_REG = -lgnuregex
#Uncomment the line below if you are getting undefined crypt errors
#NEED_CRYPT = -lcrypt
Smaug 1.8 is still pretty new and not really "supported" because almost none of us have used it. That, and judging from the discussions at the SmaugFUSS forums, it's pretty buggy still and the general sentiment appears to stick with the FUSS versions and update them with the new features.
I'll second David on this one, Kamir. Far as I can tell, particularly from the discussions posted to IMC (http://www.mudbytes.net/imc/), MudBytes (http://www.mudbytes.net/), The FUSS Project (http://www.fussproject.org/), but also from the few posts here and there to TMC (http://www.mudconnect.com/) and the light traffic on the Smaug Mailing List (http://sml.shadow-lands.com/), I'd say that Smaug 1.8 isn't worth trying to fix and that what's going to happen instead is that the FUSS Project will adopt some of it's changes and additions to be incorporated into SmaugFUSS, but until we (collectively) have had more time to play with the code and decide what's worth adding.. it may be awhile yet because most of the more active folk involved in The FUSS Project have been pretty busy lately elsewhere.
With all that said, if you really just want to fiddle with Smaug 1.8 to see for yourself what those changes are, GDB is your best bet to resolve core dump crashes, but you also might want to check out some of those other forums I mentioned, particularly The FUSS Project and MudBytes.
I haven't seen anything in 1.8 that would lead me to think there's been any significant changes in area building. Other than the addition of a credits field to the file, and the new mudprog variable system.
Overall, 1.8 isn't worth deploying in stock form since the devs didn't do more than a few minor FUSS fixes to it. It was mostly the addition of new material in the form of snippets. Some of which leads to all new bugs to resolve since at least one snippet ( house code ) is known to be bugware.
My recommendation would be to wait for us to integrate some of the better stuff into FUSS and then get a release out on that.
To the best of my knowledge, Kamir was primarily trying to check out the MPTags and MPFlags in Smaug 1.8.
But I agree that it's really not worth the headaches of getting it to compile cleanly and not crash just to see what they do. If you're really that curious, follow the code for them and see what they're supposed to do. Otherwise just give us time to get around to figuring out how to make these features clean enough to add to FUSS so you've at least got a clean product to work with.
With that said, I understand that he's already switched to FUSS 1.7 and is much happier at this point.
In addition, and maybe a little bit off topic, but I briefly look at the MPTAG code and if it actually does what it seemed to promise, then builders such as myself would have a field day.
Herne's page can further describe/clarify this:
http://webhome.idirect.com/~helspawn/smaug/olc-mpcommands.html#MP18
What is possible? - Just some examples
- Quest staging: allows quest-givers to set stages in a
particular quest or parts of quest
- Allow for mobiles to react different to PC depending on
whether he/she has done a particular quest or not, or
during what stage of a particular quest he/she is on
- Disallow PC to continue doing the same quest/task/job,
etc. all over again (or at least until the next reboot)
1) A shipping company enlisted a PC help to get rid of some pirates. The PC meets up with the pirates, and is given a counter-offer to rob the shipping company!
- MPTAG in this case can:
a) help the pirates and shipping company be aware of the PC's allegiance.
b) if the PC decided to help out the shipping company and kill off the pirates, a particular NPC could suppress the respawn of the pirates and MPTAG the quest as closed.
c) if the PC decided to side with the pirates, then the shipping company NPCs could have negative reactions toward the PC based upon the way the PC is tagged, or even guards in that particular area would have a death warrant for the PC.
There are numerous other uses for the curious and imaginative builder.
All in all, I think it is a very useful function and definitely would help increase the immersiveness and interactions between a mud and its players.
Having not looked into this myself, my understanding from others so far was that the mptag system implimented in Smaug 1.8 was incomplete, at least to the extent that there is currently nothing implimented to see what tags a victim carries currently.
Also, if the only real use in this would be for staged questing, there are several other snippets out there that can accomplish that in similar fashion, including the qbits/abits snippet. *shrug*
Personally, from what I'd heard cited as being in Smaug 1.8, I think there are actually some other "features" that are more interesting, but we each have our own personal biases and agendas when deciding which features are of the most use.
The tag system is one of the things I want to port out to FUSS as well as into AFKMud. The abit/qbit code is useful for the same purpose, but the Smaug 1.8 code actually handles it in a far more efficient manner, oddly enough. The 1.8 code also doesn't require the quest bits to be predefined. They literally get created on the fly as needed per player.
My analysis of it indicated to me that it's complete enough to be used as intended in what we got with 1.8. So I'd have to say that Kamir is right, it's limited only by builder imagination and is definitely worth the effort to install.
Sure, there are some other things of interest in the 1.8 code but I think this feature will turn out to be one of the best efforts we've seen out of the public code in a long time.