Will try smaugfuss later today , and will keep the anatolia code so that when I do know more about what I am doing, I can make another attempt at fixing it (correctly).

There's nothing really wrong with Anatolia other than bit rot. Of course fixing that requires a deeper understanding of C and the differences between compiler versions. If you're really set on Diku then you might want to check out RaM project, which is ROM with bugfixes. SmaugFUSS might have usability issues.

When in doubt , download em both, which is exactly what I did….

Well I tried smaugfuss , and it still didn't feel right … too accustomed to rom/anatolia … Read more .. quite a bit more , still reading but Anatolia3.1.1 is now compiled and running and allowing saved Characters to login.

Most of the code fixes were actually much more simple to resolve than trying to rewrite the statement as an if statement.

The only thing I scratch my head on now , is which Compiler do I believe.

Using 1 Compiler I get 1 Error and 0 Warnings (Codelite)
Under command line Compiler using ./configure and make, I get 0 Errors but 6 or so Warnings.

I'm going to run the Code locally for a while to see if there are any adverse affects from the warnings or the 1 error….. If everything checks out I'll submit it as an archive so others can check it out.

Might try to compile RaM using codelite later as well … I know that when I try to do a make that I get multiple compile errors with it… will see how things go with Anatolia :D

Codelite isn't a compiler. It's an IDE which calls whatever compiler is installed, you set it up to call, or what's bundled with Codelite for the system.
If you are running it on Windows, it's going to call MinGW which is some version of gcc 3.x.

Am running under Ubuntu 9.10 …. Codelite has still been a useful program …. Mud runs but isn't stable … now I get to track down buffer overflows …. but at least it is something new to work on and some sort of progress.

I'm glad you got Anatolia to finally run (somewhat) properly! What did you end up changing (you mentioned the if statements we discussed we more easily fixed and you also mentioned that you can re-log in now)?

There were several bits of code like

ORG_RACE(ch) = race_lookup("human");

that were causing lhand operator errors…

changed to :


That solved the login error … now I'm trying to figure out why quest.c is causing a buffer overflow error. (at least I think it's in quest.c somewhere, the mud doesn't seem to crash till I type quest list, which calls stuff in that file).

That's a fail. That makes the statement effectually do nothing. With all due respect, if these are the types of fixes you're doing it's no surprise if the code isn't stable.

To fix what you just posted you need to manually expand the macro and do "= race_lookup("human");" as has already been pointed out.

I have to admit that I don't really understand why you are fixing it like that. The solution for that exact problem has been given very many times already. Not only that, but several times already you have given "fixes" for it, and have been told that they did not work and that you should use the expansion to conditionals. Yet you keep coming back with new and different broken "fixes". Are you unsatisfied with the solution that was given to you? Is it unclear to you? It makes it difficult to help you if you go off doing random (and obviously incorrect) stuff like that despite people trying to help you. If you want us to help you, you need to work with us.

Just did a clean recompile to make sure that I didn't miss anything in these threads (and yes I missed something on the other posts) …. whether it is correct or not … both methods do work ….

The if statements , or = to == both allow me log back in to a saved character. I am currently running on the if statements …. apologies for being a headache …

I don't know enough yet about this to know which method is better(because so far from what I can tell they had the same effect) (yes, I'm still reading) … but I do know enough to know that the changing = to == wasn't the cause of the buffer problem that I mentioned that I'm now looking at , as it occurs even with If statements, unless I botched something , which as the problem is fixed I don't think I did this time …

anatolia.h:2986: error: array type has incomplete element type

Line 2986

extern	const	struct	cmd_type	cmd_table	[];

Extern Const is already defined in interp.h

changed to

//extern	const	struct	cmd_type	cmd_table	[]; –Already Defined in Interp.h

tables.h:40: error: array type has incomplete element type

extern	const	struct	position_type	position_table[];

Moved all Extern const 's from the beginning of the file to the end of the file after the last };


act_comm.c:175: warning: cast from pointer to integer of different size

for (i = 0; speech[i] != (char) NULL; i++) {

Changed to

for (i = 0; speech[i] != '\0'; i++) {

act_wiz.c:4950: error: lvalue required as left operand of assignment

ORG_RACE(victim) = race;

Was changed to

if (IS_NPC(victim))
    victim->pIndexData->race = race;
else
    victim->pcdata->race = race;

Next is in Comm.c Line 1918

ORG_RACE(ch) = race;

to

if (IS_NPC(ch))
    ch->pIndexData->race = race;
else
    ch->pcdata->race = race;

Followed by Save.c Line 752

ORG_RACE(ch) = race_lookup("human");

to

if (IS_NPC(ch))
  ch->pIndexData->race = race_lookup("human");
else
  ch->pcdata->race = race_lookup("human");

and

Line 1213

ORG_RACE(ch) = RACE(ch);

to

if (IS_NPC(ch))
  ch->pIndexData->race = RACE(ch);
else
  ch->pcdata->race = RACE(ch);

And in 1512

ORG_RACE(pet) = RACE(pet);

to

if (IS_NPC(pet))
  pet->pIndexData->race = RACE(pet);
else
  pet->pcdata->race = RACE(pet);

Ty again

I can't quite wrap my head around this…just because two entirely different code statements both compile without errors and allow you to do some things on your MUD for a period of time, you think they are equivalent? And continue to think this even after a number of very knowledgeable and friendly forum members have told you otherwise? I see that you're currently running code with the replaced if statements, but just the fact that you don't know which "fix" is better is troubling.

In C, the assignment operator (=) sets something equal to something else: x = 4 will make the variable x hold the value of 4.

The is equal to operator (==) asks if something is equal to something else: x == 4 will say true if x is 4 and false if x is not 4.

Whatever you have on the left and right sides, these operators can never achieve the same thing - your other fix is wrong, and the fact that it compiles does not make it right. The compiler can only tell you when there is stuff typed in your file that isn't correct C code, it can't tell you whether it does what you want it to do. This is very basic knowledge for C…David's advice that you complete tutorials before trying to fix as complicated a project as a MUD is good advice.

./lurk on …. Already stated that I missed something in the previous post (and caught it when I went through it all again) and apologized for being a headache, and that isn't good enough … Already stated that I am still reading, and learning , and you people continue to attack ….

My next error that I'm running into has nothing to do with the changes made in this thread, but I'll fix it on my own without asking for help here, as yall will just blame it on my lack of coding knowledge…

Listen, to be honest you need to learn to read the tone here.

No one is attacking you, I think there is just genuine disbelief that you are tackling something so complex when it is clear you do not have a grasp of the basics.

I don't think anyone would discourage you for your laudable aims, I just think you need to spend a few weeks brushing up on the fundamentals before you jump in at the deep end. It's one thing to request help but another when we see someone who just has not done their homework first…

As I said spend a few weeks (yes, weeks, full on weeks) going through some tutorials and get used to the syntax and subtleties of the language and then come back; we really are a helpful bunch but we tend to balk at people who do not seem to have put in the hours…

To be honest, it's not that we/I expect you to be an already competent programmer. Obviously, that would be a bad way to help new programmers. My personal issue was that I found it quite surprising for you to have been given solutions but do something else. If the solutions didn't work or were confusing, you should say so. But it's very hard to help somebody when you have the impression that they're simply not listening to you.

First, I would hope you continue to post for help and advice here. I think the
problems most had was they thought their advice was just being ignored as you
were asking about the same problems even after some form of fix was already
given. But as you said, you might have missed it, or it just did not sink in right
away. (looking back, I see some was also incorrect). You for sure would not
be the first to have had either of those situations. Frankly, I would like to see
more ask questions here, even if they seem a bit clueless (at least at first).

In a related thread, there was a comment about what compiler to 'believe'.
Different compilers, platforms and settings can result in different sets of warnings
and even errors. As an example, I do my work on my windows computer using
MSVC and then upload to *nix servers using gcc and there are some warnings
and errors I get on both that I don't see on the other. I consider the code clean
only after it compiles clean on all the platforms I use.

Ok, I wanted to make a few comments on the conditional operator (lvalue) error.
First of all, a legal lvalue is something that is legal on the left side of an assignment.
As it has been pointed out, it seems that the conditional operator (?:) results in
an rvalue (something that is legal on the right side of an assignment (=) but not
the left) with some compilers and an lvalue with others. I am not sure if this change
is from some tighter conformity to a standard, or just a side effect of changes in
the way the compiler creates and uses temporary variables (I have some reason to
think this might be the case) though. You were given a fix where you replaced
the use of the macro with a multi line if statement where you assigned each
target location with the race you wanted to set. An alternate way you could fix
the macro would be to change it to something like:

#define ORG_RACE(ch) (*(IS_NPC(ch)? &(ch)->pIndexData->race: &(ch)->pcdata->race))

In this case, the conditional is choosing one of two locations (not a value that
could be an rvalue) and then dereferencing that location, resulting in an lvalue.

If you don't want to use the macro on the left side of the assignments, and you
have the coding skill and understanding of the code in question, you can probably
simplify the code in most cases. As an example, the use in comm.c in nanny has
to do with player creation and ONLY effects players, so you could just use:

ch->pcdata->race = race;

as it will NEVER be an NPC. Really, about the only place I would think the NPC
case would be used in an assignment (on the left side) would be in mobile OLC.
(even if the pet use in save.c can only be NPC, the loading/saving of a pet
probably should not even be trying to change the prototype mobile's ORG_RACE).