Iso Crossfire

I've been working on the artwork quite a bit. I recently uploaded some new marble tiles. I also went and made a whole bunch of chairs a couple days ago. I will be finishing them from the other reversed perspective and uploading them soon. I also worked some on the classes.

I always hated the fact that it feels like I am working on iso-crossfire, and not the Wograld project that I really want. This game has my new graphics, and a new, yet lousy, user interface. Yet I can't help feeling like I am only playing crossfire in 45 degree isometric. That is because none of the game mechanics have changed including ones I hate, such a experience loss, dying from getting hit with a normal swinging wooden door, stat loss diseases everywhere, and a combat system that seem to consist of run into things and watch them die. At least they die relatively quickly compared to some boring games, so you get a chance to go through the exciting loot.

Well, horror of horrors, my wonderful lead developer actually likes that something like iso-crossfire exists. So before we fix any of the glaring game mechanic problems, take out the extra races from the start area and add a male/female of each of orc, human elf and undead, we have to trudge through and actually fork our own project into a useless, unremarkable, not in demand game. After all, if I really wanted to play crossfire, I would just play it, and not this abomination, halfway between crossfire and Wograld with missing graphics.

I'm not quite sure what is the point of useless sourceforge projects and dead branches. Frankly, I think it is a waste of disk space. After all, given a choice between Wograld and iso-crossfire, I would gladly chose Wograld. In fact, for years thinking about how I would actually have to play test some of my changes using the horrid Crossfire kept me from working more on Wograld.

Developers arn't easy to come by though, so if he wants to waste some time forking the project so what. I wonder if that is what will happen to most game projects eventually, there will be the number of game projects >= the number of game developers on the project with all the forks.
Happy forking and fork you!

Fixxed CFLAGS with a script

I fixed the CFLAGS problem, not by changing the configure or Make process at all, but by running a shell script, after the ./configure, but before the make in order to change one like in each Makefile, notably, the CFLAGS =


I changed CFLAGS = to CFLAGS = -g using a couple shell scripts and a sed naming file. I sent these scripts to everyone who has been active on the wograld project. I thought about posting the scripts here. I suppose I could, but if newbies mess up with them, they could end up deleting the files on the list they created instead of changing one thing about the file, like if they don't have cflagsname in the proper folder.
Maybe I should post them up along with the directions I had. Newbies, you have been warned. These files can also be used to fork projects, but it is suggested you test them before messing up all your files.


Okay, since I guess you have been duly warned now, here are the files. Author is not responsible for use, misuse or abuse of the following. Use at your own risk.


find -name Makefile -type f -print | sed "s#^.#$(pwd)#" > maout.txt


(have mklist.sh mkdebug.sh and cflagsname in the server(or client) subfolder, then type sh ./mklist.sh maout.txt)



cflagsname


# sed comment - This script changes CFLAGS = to CFLAGS = -g
s/^CFLAGS =/CFLAGS = -g/g

mkdebug.sh

#!/bin/sh
file=$1
echo $file
sfile='ug2'
echo $sfile
#!/bin/sh
more $file | sed -f cflagsname > $sfile
more $sfile > $file
touch $sfile
exit 0;

mklist.sh

#!/bin/sh
bfile='ug5'
gfile='ug7'
wc $1 | awk '{print $1}' > $bfile;
count=$(more $bfile);
echo hello newbies;
while [ $count -gt 0 ]
do
echo hi, I got here;
wc $1 | awk '{print $1}' > $bfile;
count=$(more $bfile);
echo $count;
count=`expr $count - 1`
#a="$a-1";
head -n 1 $1 > $bfile;
b=$(more $bfile);
echo $b;
echo $count;
tail -n $count $1 >> $gfile;
sh mkdebug.sh $b;
rm $1;
#rename $gfile $1 $gfile;
#baddwords7 is the proper file
mv $gfile $1;
touch $gfile;
done

Adventures in CFLAGS

For those who don't know what CFLAGS is, it is a variable in Makefile, that is the file that appears in every directory of your program that lists the flags gcc uses, such as -Wall or -g . In this case, I want the debugger flag -g, but unfortunetly, I have to go and edit the 25-30 or so different Makefiles by hand to change the CFLAGS. I figure there has to be a better way to get the debugger to work, but every time I run ./configure even when I try to change the enviroment variable by adding something like ./configure $CFLAGS = "-g" or something, it doesn't work. I tried it forwards, backwards, with export, and still the configure keeps giving me the same makefiles with nothing added for the CFLAGS. I'm going to read through the entire autoconf and automake file. I've already been looking through them trying to understand what the various macros do in the configure.ac, I'm still not 100% sure what all those different configure files do yet. I'll probably have to run autotools and rebuild the configure again. I was hoping there would be some simple command line thing I could do, but for some reason this does not appear to be the case. I've also heard about changing enviroment variables, but I have no idea how to do that.

Script Frenzy and Perl

What did I do with the month of April? I decided to just work on the quest dialog for Script Frenzy.. I figured some time to get out 100 pages of dialog would help me with the writing of the quest engine. I did get my 100 pages of dialog, but it was really hard and only managed to finish on the last day of the month. I do other things other than just work on the project, like sleep and eat and go to the bathroom. I really don't remember how I spent the rest of march, however. I can not say I ended up working on the project all that much, but probably I continued to work on the shell script. Of course, I thought that going to the libre planet conference would help my project more than it actually did. I am still having trouble finding people who want to commit the kind of time and effort this project needs to get finished before we all die of old age.

Starting yesterday night, I decided to go through all the files in the project and figure out what ever it is that they are for. In the server/utils folder is a bunch of perl scripts I did not write. I am not even sure we need some of them in that folder. I have decided to learn perl so I can figure out what they are used for. I know there are some that need to be used every time you add arches. I feel that running a server is an ordeal in itself, just figuring out how to use the software is not as easy as I hoped it would be.

Shell script - almost got it.

I have been reading this book called "Linux Shell Scripting with Bash" by Ken O Burtch. Shell Script Book I have also been reading a sed tutorial and the Gnu Awk Manual. I think I am getting closer to making a shell script. Already, I have figured out how to use pipes. In order to user pipes to pipe the input to the next command you type more nameoffile.txt | stupidcommand. where nameoffile.txt is the big list of text you want to run through the stupidcommand. The stupidcommand is a stupid shell script. It took me a while to figure this out, like several years. I do not expect it to go any faster. Either people already know it and they go too fast for me, or they still have not figured it out yet because it is hard. I like how you can substitute one word for another with sed. I also found a sed command that allows you to get the path names for everything recursivly, so that way I could get the names of all the files I need to change with sed.

Since I am going to the libre planet conference tommarow and Sunday, I will try to either finish it there (since I have a laptop now) Or when I get back. I do not really have memorized how the sed command works though.

Shell Scripts part 2

I know in my last blog I said that I only needed the Makefile.am in the directories. Well, I found out I was wrong. Makefile.in is what is needed to make the configure create the Makefile without all the autotools. This is a better way to go in case someone has a different version of autotools. Old versions of autotools do not work with new versions of scripts, and you can not use different versions of autotools for the configure and then another for the make.
I'm still somewhat confused as to how all the autoscripts work. It is better than having to write an install program from scratch. I hate to think of what is involved in making binary packages for a distro, but since we do not have a release yet, I do not think we need to worry about it. I have found that binary distro packages are not that great anyway, because only the old version is packaged up, and not the latest version that you invariably need if you want to play a multi-player game with other people. Often, you all need the same version.

I am also still no expert on shell scripts although I have learned some things. In all honesty, I would rather be writing quests/dialog or creating artwork than trying to figure out all the arcane meanings of funny script terms. Once I know how it works, I do not mind creating scripts, it is the learning part I detest. In fact, that is a big part of what I spent November on rather than just working on the shell script. I have been writing a novel about a guy who starts a free software project.

Shell Scripts

The title of my post will be Shell Scripts, yet again. I am still learning the unix commands and how to put them together. It should be simple to write a script to systimatically go through all the wograld directories and delete the Makefile and Makefile.in that do not need to be there. I'm pretty sure now that it is only supposed to be Makefile.am in each directory. This is something I did not realize before. Also, I need to write a script that goes through every file and then replaces every instance of crossfire with wograld. I know that one is probably going to be a pain. How am I going to like it when every file asks me if it is okay to overwrite it. On the other hand, I do not see how else to do a true fork of the project, and I do not think doing every single line by hand would be less tedious, it would probably be more tedious. Even if I have to confirm every instance of mv, it would still be faster than replacing every instance of crossfire in every file with wograld by hand.
I would not be surprised though if I never figure it out or if it is 100 years before the shell script gets written. It just seems like something that is too complex for any mortal being to do. Ironically, neither of the other team members are capable of doing it even though both of them made a living in computers and programming. Shell scripters are probably pretty rare and value able.

Learning Gnu Autotools

I recently began learning more about how to use Gnu-Autotools. I found out that unfortunately, we filled up the CVS with stuff that should not be there, including makefiles. Now that I understand Autotools better, I see how we did not know what we were doing. It took me a while to figure out how to use autotools and what they were good for. I got so wrapped up in learning how to program in C, that I did not realize that the things I really wanted to change were in the shell script for compiling and running. The scripts have what the program is named and where it is installed. It took me a long time to understand what all the configure and makefiles are. Including but not limited to config.ac config.guess, Makefile, Makefile.am Makefile.in etc. I had a book on Gnu Make, but did not realize that what I really needed was the books on Autoconf and Automake. You can download them from www.gnu.org .

Shell Hell

I like the title Shell Hell because it rhymes. It describes my feelings about trying to fork a free software project by using shell script to rename every instance of "crossfire" to "wograld". I thought, oh, free software project, what more do you need to know besides how to program in the language the project is written in right? Wrong. I did not know all the stuff I would have to learn, and as embarrassing as it is now to admit it, I didn't even know THAT MUCH, when I began the project. But, still even with that one little problem, I didn't let it stop me from creating a project. I figured if someone could design without knowing how to program at some of these big game companies (or rather they programed or something for a few years and then moved into management), why couldn't I do the same thing? Besides I did start out with a couple programmers, one of whom didn't do very much work, and the other decided grad school was more important
Mostly I struggled with the other aspects of the project, learning how to properly use the source forge website was an undertaking in itself. First I needed to learn CVS version control. Then I had to learn other things like website uploading, html etc. I made foolish errors like thinking I need a fancier website than I actually did, using Drupal rather than plain html or html with css. I just found ways to make things hard on myself, trying to do everything myself.

Even though the lead developer seemed to be enjoying himself writing C code, the shell script was something he “didn't want to learn.” Now, I've heard stories of people trying to contribute to a project, but if you don't want to learn something like that, it is not tolerated. I now know the reason for that. You can't get away with “just writing the code” or thinking that you can somehow avoid learning things that you don't think are interesting at first glance, even though they are needed to get the project done. Sometimes things don't seem like very much fun to begin with, but that is because we go about them all wrong, not because they are inherently uninteresting. It took me a while to find a C programming book I could actually read and understand.