05 Jun, 2012, lilmike wrote in the 1st comment:
Votes: 0
Hi,
I was thinking of using awemud, so I decided to give it a try. I got quite a few errors, but most were solved by including a few additional header files. However, now I get to a point where the scriptix sourcecode is not compiling, and I really don't have time to poke around for hours to see what is supposed to be where. The errors are below:

make all-am
make[1]: Entering directory `/muds/aime/aime/awemud-0.24'
depbase=`echo src/scriptix/compiler.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`; \
if g++ -DHAVE_CONFIG_H -I. -I. -I./include -I./include/common -I./include/scriptix -I./include/mud -I./include -g -O2 -MT src/scriptix/compiler.o -MD -MP -MF "$depbase.Tpo" -c -o src/scriptix/compiler.o src/scriptix/compiler.cc; \
then mv -f "$depbase.Tpo" "$depbase.Po"; else rm -f "$depbase.Tpo"; exit 1; fi
In file included from src/scriptix/compiler.cc:33:0:
./include/scriptix/compiler.h:207:13: error: conflicting declaration ‘Scriptix::TypeInfo* type’
./include/scriptix/compiler.h:201:7: error: ‘type’ has a previous declaration as ‘int type’
make[1]: *** [src/scriptix/compiler.o] Error 1
make[1]: Leaving directory `/muds/aime/aime/awemud-0.24'
make: *** [all] Error 2

Any help is appreciated.
Thanks,
-Michael.
05 Jun, 2012, plamzi wrote in the 2nd comment:
Votes: 0
You can start by looking at lines 201 and 207 of compiler.h to check if they really declare the same variable ("type") in two different ways. There might be a broken #if statement there, or something simple like that.
05 Jun, 2012, lilmike wrote in the 3rd comment:
Votes: 0
Hey,
Well the funny thing is it's in the declaration of a function (I think a constructor) and there seems to be no constructor implementation in the .cc file. The offending block is below:

// create new node
CompilerNode(Compiler* info,
int type,
CompilerNode* node1,
CompilerNode* node2,
CompilerNode* node3,
CompilerNode* node4,
Atom name,
TypeInfo* type,
Value value,
int op);

I can't seem to find the implementation in the compiler.cc file at all.
Thanks,
-Michael.
06 Jun, 2012, plamzi wrote in the 4th comment:
Votes: 0
If there's no implementation, then it may not be referenced at all. If it is referenced, and commenting it out reveals that, then someone submitted incomplete code.

You could also try to rename one of the two 'type' vars into something else as the most minimal way to get past this error.
06 Jun, 2012, lilmike wrote in the 5th comment:
Votes: 0
Hi,
I got past that point, by changing the name of the second type – it doesn't complain. Now I'm to a point where it's trying to provide an implimentation of something declared in events.h in eventids.cc. However, eventids.cc is surrounded by a namespace events, and the other one isn't. It keeps telling me "SEventManager is not in enclosing namespace". Any help is appreciated.
Thanks,
-Michael.
06 Jun, 2012, plamzi wrote in the 6th comment:
Votes: 0
lilmike said:
Hi,
I got past that point, by changing the name of the second type – it doesn't complain. Now I'm to a point where it's trying to provide an implimentation of something declared in events.h in eventids.cc. However, eventids.cc is surrounded by a namespace events, and the other one isn't. It keeps telling me "SEventManager is not in enclosing namespace". Any help is appreciated.
Thanks,
-Michael.


Hmm, well I'm not familiar with this particular codebase–others who know more might chime in if you wait. But given that the first error was due to something sloppy, and given that you've said you don't have much time, why not pick a codebase that compiles OOB and is likely to cause you less grief over time?
06 Jun, 2012, lilmike wrote in the 7th comment:
Votes: 0
Hi,
Well… I was actually trying to do that. I was looking for well-maintainable, c++ muds relatively up-to-date so I didn't have to fix a bunch of errors that more likely than not were warnings back when it was created, and hopefully had scripting of some kind or online editting of races and other stuff like that built in, although that is not the biggest requirement and I would skip it if the others were met satisfactorally. I downloaded the mud codebases that were available on sourcery.dyndns.org ftp server under I think servers/other/c++ or something, and absolutely none of them but one compiled without errors out of the box, and that one would've been perfect as it met all the standards I put in place above.. except that it seems to crash once a day, and I couldn't find a core dump or anything. It was aime v 0/61.1 if anyone's interested. The others all had errors, and the ones I could I fixed the trivial errors like headers not being included, and all of them had some kind of error that was non-trivial, including this one. This one was the last one I had to try. Anyway, if you can recommend another mud base with the features above that I mentioned that I haven't tried, or if you have a newer version I don't that would compile out of the box that would be great :). Anyway, other than that I'm kind of at a loss.
Thanks,
-Michael.
07 Jun, 2012, Kjwah wrote in the 8th comment:
Votes: 0
0.24 isn't the latest version. Also make sure you have the latest version of scriptix.

http://sourceforge.net/projects/awemud/
07 Jun, 2012, lilmike wrote in the 9th comment:
Votes: 0
Hi,
Thanks for the link. I downloaded the 0.25 version, and luckily didn't have as many include errors to fix (at least from where I got to). However, now I have a new error, which I can't seem to figure out what it's supposed to be doing. Error is below…

make all-am
make[1]: Entering directory `/muds/aime/aime/awemud-0.25'
depbase=`echo src/common/imanager.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`; \
if g++ -DHAVE_CONFIG_H -I. -I. -I./include -I./include -g -O2 -MT src/common/imanager.o -MD -MP -MF "$depbase.Tpo" -c -o src/common/imanager.o src/common/imanager.cc; \
then mv -f "$depbase.Tpo" "$depbase.Po"; else rm -f "$depbase.Tpo"; exit 1; fi
src/common/imanager.cc: In static member function ‘static int IManager::require(IManager&)’:
src/common/imanager.cc:34:60: error: no matching function for call to ‘find(std::vector<IManager*, gc_allocator<IManager*> >::iterator, std::vector<IManager*, gc_allocator<IManager*> >::iterator, IManager*)’
src/common/imanager.cc:34:60: note: candidate is:
/usr/include/c++/4.6/bits/streambuf_iterator.h:359:5: note: template<class _CharT2> typename __gnu_cxx::__enable_if<std::__is_char<_CharT2>::__value, std::istreambuf_iterator<_CharT2, std::char_traits<_CharT> > >::__type std::find(std::istreambuf_iterator<_CharT2, std::char_traits<_CharT> >, std::istreambuf_iterator<_CharT2, std::char_traits<_CharT> >, const _CharT2&)
make[1]: *** [src/common/imanager.o] Error 1
make[1]: Leaving directory `/muds/aime/aime/awemud-0.25'
make: *** [all] Error 2

I can't see how this could've slipped past the developer if they built it, unless the c++ standard headers have changed so much since then :P.
Any help is appreciated – thanks!
-Michael.
08 Jun, 2012, plamzi wrote in the 10th comment:
Votes: 0
If you're looking for a C++ codebase, I think Runter or one of the other specialists in that area would recommend something like Murk++.

May I ask what you're looking to accomplish exactly? Let's say you compile a C++ codebase. Then what?
08 Jun, 2012, lilmike wrote in the 11th comment:
Votes: 0
Hi,
The main reason I'm looking for a c++ codebase is that a friend is trying to start a mud, and they are currently using coffeemud. I can program in java, but I prefer c++. The only big problem with coffeemud that they're using is that when they paste a long description (or perhaps just try and save it) it takes anywhere from 30 seconds to (I've heard a claim of) 5 minutes, all the while they can't do anything. I have looked at murk++, but the only thing I don't like about it is the comercial part of the diku license. I'm not certain, but I think my friends may want to give something in return for donating (even if it's simply an extra description or something that has no impact on the game at all) but this would be against the terms of the diku license as I have been told. I actually found one codebase called UnsignedByte in c++, it compiled fine after including a few forgotten header files (I'm still stumped as to how this gets past the developers, especially since this was in a library that they didn't write – I mean… didn't they compile it at least once? :P). The only thing I don't like about it is that it doesn't have much (if any) documentation on how to build or run the mud or anything, but I guess that's what most of the codebases were like anyway. It does have some good looking doxygen docs though, so I think that may help if I need to add something (which I probably will).
Thanks,
-Michael.
09 Jun, 2012, Kline wrote in the 12th comment:
Votes: 0
Depending on how barebones you want to get I started work awhile back on my own server from scratch in C++. If you rollback a few revisions I had a stable / working multiplexed socket core and had just started adding commands and other basic elements in. In my own interest of learning, and some prodding from Quix on here, the current builds are multi-threaded and I'm still working some things out with concurrency and locking. So they range from mostly working to horribly broken. I haven't touched anything for a month or so, life caught hold for the moment, but I do plan to try and pick it back up and get it further featured and complete once things settle down for me a bit. Currently everything is GPLv3. FWIW I think a game's content should matter over what's under the hood, but I know many here don't agree with that and I've already mentioned I'm not against re-licencing it down the road with something akin to "do what you want". Maybe when it's a fully working system.

Here's the Github if you're interested at all: https://github.com/Kline-/NAMS
There's also Doxygen pages for most things: http://kline-.github.com/NAMS/

It looks like this commit was the last one before I started toying with threads.
09 Jun, 2012, lilmike wrote in the 13th comment:
Votes: 0
Hi,
I may check it out, although I prefer to have a mud that's slightly more fully featured, preferably with a way to build in races/classes/etc. Anyway, if i can't find what I need I may just go with nams :).
Thanks,
-Michael.
09 Jun, 2012, plamzi wrote in the 14th comment:
Votes: 0
In other news, a CoffeeMUD taking 5 min. to change a single description doesn't sound right. Maybe it's hardware, but more likely it's insufficient memory allotted to the JVM. Least likely, maybe something was added to the editor saving logic that is horribly inefficient. Just speculating, but it may be easier to fix your friends' CoffeeMUD issues than to switch code entirely.
11 Jun, 2012, Tyche wrote in the 15th comment:
Votes: 0
I didn't have any problems compiling Awemud 0.25 on Fedora Linux 12.0 - i386 using g++ 3.4.4

./configure CXX=g++34
0.0/15