03 Jan, 2009, kaervos wrote in the 21st comment:
Votes: 0
Tyche:

You can get the latest Fire by:

svn co http://sulinea.arthmoor.com/ram/Fire

OLC hasn't been merged yet though, and trying to compile the latest, I got the following error:

g++ -Werror -Wall -Wformat -Wformat-security -Wmissing-format-attribute -Wmissing-braces -Wparentheses -Wshadow -Wredundant-decls -Wcast-qual -Wcast-align -Wchar-subscripts -Wreturn-type -Wswitch -Wwrite-strings -Wunused -Wuninitialized -Wpointer-arith -Winline -O3 -g -c magic.c -o magic.o
magic.c: In function ‘int qcmp_skill(const void*, const void*)’:
magic.c:83: error: invalid conversion from ‘const void*’ to ‘const skill_type*’
magic.c:84: error: invalid conversion from ‘const void*’ to ‘const skill_type*’
make: *** [magic.o] Error 1

Quix has to finish up what he is working on…

In anticipation of that, I'm eager to get the color code in place. When we meet Tomorrow night we should discuss how we should modify Lope's color code to minimize the patch's impact. It's going to be really be our average color preferences versus the patch's default scheme. I think in it's default setup, Lope's color code is a bit much. I dislike the way it colorizes the prefix to channel communication ("You say ", "You Gossip ", etc) and the way it colorizes combat damage messages (highlights the ENTIRE line either green or red depending on causing or taking damage).

I've been through Lope's color code, and although saving color preferences for each channel may be nice to some, I question if it would be a good addition for RaM. I think just hard coding some color scheme and allowing the admin to change it if they like is sufficient.

On top of that, I'm keen on Quix's idea of having all communications run through a common filter which would do things like make speech drunken slurred / in a different language / ansi colorized. We should toss around some ideas on this, and build something from the ground up so we don't need to worry about Lope's license.
04 Jan, 2009, Sharmair wrote in the 22nd comment:
Votes: 0
kaervos said:
OLC hasn't been merged yet though, and trying to compile the latest, I got the following error:

g++ -Werror -Wall -Wformat -Wformat-security -Wmissing-format-attribute -Wmissing-braces -Wparentheses -Wshadow -Wredundant-decls -Wcast-qual -Wcast-align -Wchar-subscripts -Wreturn-type -Wswitch -Wwrite-strings -Wunused -Wuninitialized -Wpointer-arith -Winline -O3 -g -c magic.c -o magic.o
magic.c: In function �int qcmp_skill(const void*, const void*)�:
magic.c:83: error: invalid conversion from �const void*� to �const skill_type*�
magic.c:84: error: invalid conversion from �const void*� to �const skill_type*�
make: *** [magic.o] Error 1

In C++ you can't just casually assign a void pointer to some other pointer type as it is not type safe (and
C++ is much more picky about type then C). The best thing to do in most cases is to not use void pointers
at all. If all this function does is use the input void*s as skill_type*s, I would try just changing the type
of the arguments to const skill_type*s. There are also some tricks you can sometimes use with unions or
inheritance if the void* is used for more then one type. But if all else fails and you feel you HAVE to use
a void*, you just have to tell the compiler that you intend to use the void* as some other type with a
cast like:
const skill_type* skill = (const skill_type*)TypeUnsafeVoidPtr;

You could also use the C++ static_cast operator here if you like of course.
04 Jan, 2009, ghasatta wrote in the 23rd comment:
Votes: 0
I saw this same error when I downloaded the code for the first time. I thought it was something specific to my OS/compiler version. I submitted a patch for Mac OS X compatibility here that resolves this issue.

So, once Quix applies my patch, the issue will be fixed in the repos *poke poke*
04 Jan, 2009, quixadhal wrote in the 24th comment:
Votes: 0
Tyche said:
Maybe it is, maybe it isn't. One could suggest the game is poorly designed as well.
So does it fit under the scope of the project?


I think it does. I have zero qualms about ripping out and replacing sections of code, wholesale, to provide more stability, consistency, or just to make it easier to manage.

You could make an argument with the command parser, by saying that throwing up an ambiguity message changes the feel of the game, but I don't see that flying with respect to data. If somebody used an abbreviation in the world files, they deserve to have it crash and burn at startup, rather than letting the code make a bad guess and corrupting something else further down the road.

To me, the soul of a game is the feel that the user gets while playing it, or that the builder gets while creating content for it. The mechanics of how it sits on the disk, what sorting routines get used, and all that should be transparent and hidden away.

Now, if ROM had a solid, well-defined programming API, I'd be a little more careful about changing things left and right, but it doesn't. Since that's the case, I try to refactor things and rearrange things so it's a little easier to follow.

As for the void pointers, those are required to use the glibc-supplied quicksort function. In that case, I don't think it should be "const skill_type *", it should be "const struct skill_type *". Either way though, the cast is required for C++, good catch. :)
05 Jan, 2009, Sharmair wrote in the 25th comment:
Votes: 0
quixadhal said:
As for the void pointers, those are required to use the glibc-supplied quicksort function.

Though it would still take a cast, you could cast the function in the qsort call. Then your compare
function could use the real types with no casts. Though I suppose there would not be much difference
one way or the other (I mean cast your compare function to (int(*)(const void*, const void*)) in the
qsort call). Just a personal preference I guess.
quixadhal said:
In that case, I don't think it should be "const skill_type *", it should be "const struct skill_type *".

I am only going by the error, and have not seen the code itself (and the example I gave was really
meant to show the case). The error does not specify it is a struct, it could be, or even a class, union
typedef or even an enum. Assuming it is in fact a struct name, the struct keyword is not needed
(though it can be used). Unlike C, when you define a struct, class, union or enum in C++ you are
defining a new type and the keyword is not needed when using that type later. It could be argued
that not using the keyword is better as you might change skill_type to a class later and would have to
go through all the old code changing struct to class.
05 Jan, 2009, quixadhal wrote in the 26th comment:
Votes: 0
Good point. :)

As we're about to jump off the deep end and start the std::string conversion, we'll be leaving the dinosaur land of C behind. I'm an old C warhorse, so I'll have some habits to break.
20.0/26