12 Apr, 2009, Igabod wrote in the 1st comment:
Votes: 0
Alright, I downloaded swr13fuss a while back and finally got around to compiling it today. Problem is I thought the fuss team uploaded their stuff in a form that would compile with no errors/warnings. I'm sure this is probably just a mistake on my part though so I figured I'd post exactly the steps I took and all that.

First, I'm using Cygwin cause my server is down for some retarded reason.

In the makefile I uncommented line 5 and did a compile.

Here are the results of that compile:

$ make
make -s swreality
Compiling o/imc.o….
Compiling o/act_comm.o….
Compiling o/act_info.o….
Compiling o/act_move.o….
Compiling o/act_obj.o….
Compiling o/act_wiz.o….
Compiling o/boards.o….
Compiling o/bounty.o….
Compiling o/build.o….
Compiling o/clans.o….
Compiling o/color.o….
Compiling o/comm.o….
comm.c: In function `char* act_string(const char*, CHAR_DATA*, CHAR_DATA*, const void*, const void*)':
comm.c:2488: error: `MSL' undeclared (first use this function)
comm.c:2488: error: (Each undeclared identifier is reported only once for each function it appears in.)
comm.c:2590: error: `temp' undeclared (first use this function)
comm.c: At global scope:
comm.c:49: warning: 'rgObjNest' defined but not used
make[1]: *** [o/comm.o] Error 1
make: *** [all] Error 2


I'm unable to tell if this is a problem on my end or if it was just left like this by the fuss team on accident or what. But the MSL thing is obviously not something on my end, I fixed that one since it was such an easy fix, but then I've still got other errors to get past.

Someone please tell me what I'm doing wrong, or if it's not a mistake on my side, could the fuss team please release this without any errors? I'm not exactly the greatest coder to begin with, but I'm especially not good with smaug derivs so going to all this trouble fixing up a stock release isn't really that appealing to me.
12 Apr, 2009, Kayle wrote in the 2nd comment:
Votes: 0
Firstly, Before starting to work with any form of FUSS it's generally a good idea to grab the latest copy off the SmaugMuds.org site as we keep those fairly up-to-date on fixes where the ones available elsewhere might not be as up to date.

The issue you're having was a result of a premature check-in/packaging when SWRFUSS was undergoing it's update to use g++. The issue has sense be remedied along with several others. Actually, the fact that you managed to grab a copy of the codebase in the 15 minutes it was available for download before we realized what happened is rather astonishing. :P
12 Apr, 2009, Igabod wrote in the 3rd comment:
Votes: 0
Heh wow I have wonderful luck don't I. And I did get it from smaugmuds.org by the way. I'll go re-download it and see what my results are. Thank you Kayle.

[edit to add] Ok I just now downloaded the current release and got the exact same results so it's not because it's an old release. Any other ideas?
12 Apr, 2009, Kayle wrote in the 4th comment:
Votes: 0
I just double checked the repository and didn't get the errors, so I re-packaged it. Grab it once more and give it a try, if it doesn't work this time, I'm going to have to grab CYGWIN and see wtf is up.
12 Apr, 2009, Kayle wrote in the 5th comment:
Votes: 0
I traced the problem to a botched commit, that had accidentally left residual code from before the update in the file. The MSL thing was a my bad though, Maybe I'll add defines for those to SWRFUSS and SWFotEFUSS since I've developed a bad habit of short-handing everything. >.>
12 Apr, 2009, Igabod wrote in the 6th comment:
Votes: 0
repackaged version got further but then I got this:

make -s swreality
Compiling o/imc.o….
Compiling o/act_comm.o….
Compiling o/act_info.o….
Compiling o/act_move.o….
Compiling o/act_obj.o….
Compiling o/act_wiz.o….
Compiling o/boards.o….
Compiling o/bounty.o….
Compiling o/build.o….
Compiling o/clans.o….
Compiling o/color.o….
Compiling o/comm.o….
Compiling o/comments.o….
Compiling o/const.o….
Compiling o/db.o….
Compiling o/fight.o….
Compiling o/handler.o….
Compiling o/hashstr.o….
Compiling o/hotboot.o….
Compiling o/interp.o….
Compiling o/magic.o….
Compiling o/makeobjs.o….
Compiling o/mccp.o….
Compiling o/misc.o….
Compiling o/mud_comm.o….
Compiling o/mud_prog.o….
Compiling o/player.o….
Compiling o/reset.o….
Compiling o/save.o….
save.c: In function `void load_plr_home(CHAR_DATA*)':
save.c:2141: error: invalid conversion from `const char*' to `char*'
make[1]: *** [o/save.o] Error 1
make: *** [all] Error 2


This is almost certainly a cygwin problem, but since my server is down I still can't get on there and check.
12 Apr, 2009, Kayle wrote in the 7th comment:
Votes: 0
That actually appears to be the result of a bit of overzealous const application.

Not sure why the compiler didn't catch it before. It's easy enough to fix though.

- Mud.h
Right about line 4084
find:
const char *fread_word args( ( FILE * fp ) );
const char *fread_line args( ( FILE * fp ) );


change it to:
char *fread_word args( ( FILE * fp ) );
char *fread_line args( ( FILE * fp ) );


-db.c
Line 3233:
change:
const char *fread_line( FILE * fp )


to:
char *fread_line( FILE * fp )


And on line 3300:
change:
const char *fread_word( FILE * fp )


to:
char *fread_word( FILE * fp )
12 Apr, 2009, Igabod wrote in the 8th comment:
Votes: 0
Thank you Kayle, glad I could help point out some oversights. And the mud now compiles perfectly cleanly without any problems. I appreciate your assistance.
12 Apr, 2009, Kayle wrote in the 9th comment:
Votes: 0
I'm still stumped as to why Cygwin caught the const char thing, but AndLinux and the compiler on Arthmoor didn't.
15 Apr, 2009, Igabod wrote in the 10th comment:
Votes: 0
I don't know, but I'm glad it did. Here's what I have for my g++ version.

$ g++ –version
g++ (GCC) 3.4.4 (cygming special, gdc 0.12, using dmd 0.125)
Copyright (C) 2004 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


Now the only problem I'm running into is that retarded bug where you can't run around coruscant without being thrown into limbo. I'm wondering if anybody has actually found the solution for that. I asked a long time ago on here and on smaugmuds.org but got no real answers either place except that it has something to do with virtual rooms.

Of course the problem has to do with something I've never dealt with at all so I don't even know where to begin fixing this, but I'm pretty sure someone has fixed it since pretty much every swr I've ever played didn't have this problem. Somebody please either fix this or tell me how to go about it.
15 Apr, 2009, Kayle wrote in the 11th comment:
Votes: 0
Most SWRs rip out the stock Coruscant because it sucks. That's how they fixed it. We've never actually come up with a way to fix it. Though several have tried. The virtual rooms code is just a mess that no one has the patience to sort out and try and fix.
15 Apr, 2009, Igabod wrote in the 12th comment:
Votes: 0
I've been on several swr's with the stock coruscant (with slight modifications) that didn't have the problem. I guess I'll just have to log on to those and ask the imps what exactly they did.
19 Apr, 2009, Igabod wrote in the 13th comment:
Votes: 0
Ok, I figured out the problem and the solution to the limbo bug with swrfuss and swfotefuss with the assistance of Banner (he told me how to fix it and I did it). I have taken it upon myself to repair the problem file and it works.

The problem is that the coruscant_streets area uses exdistance in just about every room. Exdistance is used to make virtual rooms which are apparently not working like they were intended. I'm not skilled enough to tackle that end of the problem but simply removing the exdistance from every exit was suitable to cease the problems.

I may have missed a room here or there but if I did you can easilly fix that by using the redit exdistance <direction> 0 command.

I have the fixed coruscant_streets file on my website at http://www.evileyehosting.net/users/igab... in the downloads section. Just be sure to remove the .txt and it will slip right into your swr. The only differences between this area file and the stock one are that the exdistances have been removed.

I don't expect any credit for this at all so everybody can use it just like they would use the stock area file. I fervently hope the swrfuss team will take this and put it in the official release of swrfuss.
19 Apr, 2009, Kayle wrote in the 14th comment:
Votes: 0
Grabbed a copy of it. I'll look it over and make sure you got all the exdistance stuff, and it'll be in the next release. (I'm not making a new release just for the area since it doesn't fix the code portion of the problem.)
19 Apr, 2009, Igabod wrote in the 15th comment:
Votes: 0
I personally think the code portion of the problem can be mostly ignored, just remove exdistance from the options in redit and anywhere else it might be. No more making virtual rooms and as long as none exist in any of the current areas there should be no problem.
19 Apr, 2009, Kayle wrote in the 16th comment:
Votes: 0
Igabod said:
I personally think the code portion of the problem can be mostly ignored


This is exactly why the FUSS Project came about. The Devs were ignoring bugs because they didn't affect them, so we started fixing them. It's a bug. A flaw in the system. It will be fixed. It's not going to be ignored.
0.0/16