smile@mhuxd.UUCP (Edward Barlow) (11/12/87)
*****************************************************************
* CONQUEST NEWSLETTER. volume 2. *
* *
* by (The) Ed Barlow -- author of conquest *
* {ihnp4}!homxc!smile <- note new preferred mailing address *
* *
* Format: 1) Personal Stuff *
* 2) bug fixes *
* 3) outstanding modification requests *
* 4) discussion of ehancements *
*****************************************************************
It has just come to my attention that there is another game named conquest out
there, and the author said that it was copyrighted. It is a shame -- I thought
long and hard for this name. The other conquest is a real-time space war game.
My conquest is obviously not. The author did not say that I needed a new name,
but as a precaution, I am calling the "great conquest renaming contest".
The prize will be a mention in the conquest newsletter...
If you have not received a personal copy of the newsletter, they you
are not on the mailing list!!! It could be due to invalid paths.
Just to remind you... I read everything and take all kinds of input. I
try to get a personal response where appropriate, but do not have the
time to respond to every letter
On a personal note, I need a new housemate, starting December 1st, to share
my townhouse. I live in Middletown, New Jersey (nice area), and am
convenient to most of Momouth County. If you know anybody that might be
interested, have them call me at 201-671-2896 (please do not call conquest
stuff to me -> I will get my mail).
OOPS... I got one bug fix backwards in the last newsletter...
You should have been able to figure that out tho (and if you couldn't...)
THIS IS THE CORRECT CODE:
> /*place a new Nomad army*/
>> x=(rand()%(MAPX-8))+4;
>> y=(rand()%(MAPY-8))+4;
The Ed
Wed Nov 11 23:19:04 EST 1987
************************
BUG FIXES
===================
!!!!!!!!!HERE IS THE FIX TO THE BSD INPUT PROBLEM!!!!!!!
THE FOLLOWING FIX WAS POSTED TO ME. I TESTED IT AND IT LOOKS OK.
Some guy posted a fix to "comp.sources.bugs" but he was wrong.
You put the terminal into raw mode when starting. Under BSD, this turns
off the mapping of return -> line feed which means that input can only
be terminated by a line feed (^J). An associated problem is that you
have disabled job control for us BSD types who have it. (You have
probably disabled sxt control on System V).
The trick is not to use raw mode at all, but to use cbreak mode instead.
This is almost the same except return mapping is done and terminal signals
are still delivered.
NOTE YOU MUST INCLUDE THE FOLLOWING LINE IN THE INCLUDE SECTION
#include <signal.h>
Thus replace calls to
raw(); /* 2 of them in main.c */
with
crmode(); /* cbreak mode */
signal(SIGINT,SIG_IGN); /* disable keyboard signals */
signal(SIGQUIT,SIG_IGN);
ALSO YOU SHOULD PROBABLY REPLACE CALLS TO
noraw() /* 1 in main.c */
with
nocrmode().
BUT THIS IS ONLY A STYLISTIC CONSIDERATION.
Also remove the calls to savetty() and resetty() in "main.c". This
functionality is provided by initscr() and endwin() and, in fact,
by calling savetty() after initscr() you are subtly messing up the
saved characteristics. This is very annoyingly obvious on our system
after CONQUEST is exited. I DO NOT KNOW WHAT THE SIGNAL ROUTINE DOES,
BUT I ASSUME THEY DISABLE EXTERNAL INTERUPTS AND QUIT SIGNALS.
I HAD ANOTHER PERSON WITH A PROBLEM RECEIVING MULTIPLE ^S/^Q CHARACTERS
DUE TO FLOW CONTROL ON HIS MACHINE. HIS QUICK FIX WAS TO DEFINE getch()
TO A ROUTINE newch() defined here. (UNTESTED)
>newch() {
> int i;
> for(i = getch(); (i == '\021') || (i == '\023'); i = getch());
> return(i);
>}
>This should fix the problem with beeping at odd times, and the
>"return key doesn't work, but new line does" problem. raw turns off the
>mapping of return to newline, causing the problem. The random beeping
>problem seems to be caused by the fact that getch returns something
>immediately if you call it in raw mode, whether the user pressed a key
>or not. The random beeps are the program beeping for a bad input command.
THERE IS A GOOD POSSIBILITY THAT RANDOM BEEPING GOES AWAY WITH THE CRMODE
FIX. IF NOT, YOU MIGHT WISH TO TRY NEWCH.
ALL RIGHT -- I JUST PLAY TESTED CONQUEST ON THE LOCAL MAINFRAME. WHY
DOES THE MACHINE BUFFER BEEPS UNTIL A VALID MOVE IS MADE??? IT NEVER
DID THAT ON MY UNIX PC...
#################
HERE IS DISCUSSION ON A BSD SPECIFIC PROBLEM OF RECORD LOCKING.
CONQUEST SEEMS TO THROW AWAY WHOLE MOVES...
I open the ".execute" file with a line something like:
fexe = fopen (...., "a");
intending all writes to be appended to the file. In our system,
this actually opens the file and lseeks to the end.
If two concurrent invocations of conquest open the file,
and one writes out when exiting all is as expected. But when the
second conquest writes it starts at the same offset in the file
as the first invocation. The result is that the first conquest
to finish has its execute data overwritten.
The fix:
#ifndev SYS5
#include <fcntl.h>
#endif
/* fopen execute file here */
#ifndev SYS5
if (fcntl (fileno(fexe),F_SETFL,FAPPEND) == -1){
perror ("fcntl");
exit (1);
}
#endif
THE ABOVE DID NOT WORK ON MY SYSTEM V SYSTEM BECAUSE FAPPEND DID NOT
EXIST. fcntl DOCUMENTATION REVEALED A VARIABLE O_APPEND WHICH SEEMS
TO BE THE SAME THING, BUT I *BELIEVE* THAT SYS V DOES NOT HAVE THE
ABOVE PROBLEM, AND THUS DOES NOT NEED THE FIX.
This guarentees that all writes will be true appends.
In general, the whole idea of using the standard i/o package
for writing out complete lines of data where multiple processes
access a file with no locking mechanism is bad.
Although write(2) is atomic, there is no requirement that
fprintf, say, should output lines in an atomic fashion.
Since record locking is non standard in a big way between unices,
you will have to use write(2) and read(2) to ensure truely portable code.
GREAT...SOMETHING TO LOOK FORWARD TO...
===================
#Mail sent to god doesn't appear when he tries to read it. This is because
# the name field in ntn[0] isn the name "god". This is easy to fix.
#
#in file commands.c
542d541
---
old
char name[12];
int temp=(-1);
new
char name[12];
char realname[12];
int temp=(-1);
---
561
old
> if(strcmp(name,ntn[nationid].name)==0) temp=nationid;
>
> if(strcmp(name,"god")==0) temp=0;
>
> if (temp==(-1)) {
---
new
< if(strcmp(name,ntn[nationid].name)==0) temp=nationid;
<
< if(strcmp(name,"god")==0) {
< temp=0;
< strcpy(realname,"unowned");
< }
< else strcpy(realname,name);
<
< if (temp==(-1)) {
591,592
old
> fprintf(fp,"%s Message to %s from %s\n",name,name,ntn[country].name);
> fprintf(fp,"%s \n",name);
> y=6;
> x=0;
---
new
< fprintf(fp,"%s Message to %s from %s\n",realname,name,ntn[country].name);
< fprintf(fp,"%s \n",realname);
< y=6;
< x=0;
623
old
> if(x<=1) done=1;
> /*write to file*/
> fprintf(fp,"%s %s\n",name,line);
> x=0;
---
new
< if(x<=1) done=1;
< /*write to file*/
< fprintf(fp,"%s %s\n",realname,line);
< x=0;
===================
# Under diplomacy (command 'S') , change of status it asks for input,
# but doesn't echo input. Following should correct:
# file: forms.c near line 195
# now reads:
mvaddstr(12,0,"INPUT:");
refresh();
scanw("%hd",&temp);
if((temp<1)||(temp>7)){
mvprintw(23,0,"SORRY, Invalid inputs -- hit return");
# should read:
mvaddstr(12,0,"INPUT:");
refresh();
echo();
scanw("%hd",&temp);
noecho();
if((temp<1)||(temp>7)){
mvprintw(23,0,"SORRY, Invalid inputs -- hit return");
*****
# there is a similar problem in changing status under adjust army (command 'a')
# file: reports.c near line 106
# now reads:
case '1':
mvaddstr(21,0,"1=MARCH, 2=SCOUT, 3=ATTACK, 4=DEFEND, 5=GARRISON");
clrtoeol();
refresh();
scanw("%d",&chg);
if(chg<1) return;
# should read:
case '1':
mvaddstr(21,0,"1=MARCH, 2=SCOUT, 3=ATTACK, 4=DEFEND, 5=GARRISON");
clrtoeol();
refresh();
echo();
scanw("%d",&chg);
noecho();
if(chg<1) return;
*****
# there is a small typo under the redesignate command
# file: commands.c line 65
# now reads:
mvprintw(LINES-1,0,"hit space to not redesignate anyting");
# should read:
mvprintw(LINES-1,0,"hit space to not redesignate anything");
===================
#If an army runs across an enemy army, you get a HIT RETURN TO CONTINUE
# prompt although the game neither needs nor wants a RETURN.
#old -- about line 314 of move.c
> if(ASOLD < 2 * total){
> AMOVE=0;
> AADJMOV;
> mvprintw(LINES-3,0,"Zone Of Control -- hit return");
> beep();
#new -- about line 314 of move.c
< if(ASOLD < 2 * total){
< AMOVE=0;
< AADJMOV;
< mvprintw(LINES-3,0,"Zone Of Control ");
< beep();
======================================================================
#below is a BSD shell script that runs updates 3pm and 12 midnight
#every weekday. I hope this helps.
#!/bin/csh -f
set log = /mip/usr/games/lib/conquest/runlog
setenv SHELL /bin/csh
setenv USER mwp
setenv HOME /f/hons/mwp
/bin/date >>&! $log
/mip/usr/games/conquest -x >>&! $log
set day = `/bin/date | /bin/awk '{ print $1 }'`
set hour = `/bin/date | /bin/awk '{ print $4 }' | /bin/awk -F: '{ print $1 }'`
switch ($day)
case Sat:
set nextday = mon
breaksw
default:
set nextday =
breaksw
endsw
switch ($hour)
case 00:
set nexthour = 1500
breaksw
default:
set nexthour = 0000
breaksw
endsw
/usr/bin/at $nexthour $nextday /mip/usr/games/lib/conquest/run >>&! $log
==================
You cant raise an army in a sector with a single *SELECTED* navy in it.
The workaround is obvious, and the fix forthcoming. Go to a sector with
no armies at all. When you move back into the original sector, no
army will be selected.
==================
ENOUGH FOR NOW...
REMAINING OUTSTANDING MR's
Command 'S' has been causing core dumps. This is due to arbitrary values in
ntn[31].dstatus[*]. The fix is in makeworld.c....
(command: 'f'). If one tries to split fleets there are problems.
Cannot split a fleet a group of warships without merchant ships
off a mixed fleet of warships and merchant ships (gives to many
ships as an error).(Note: may split off fleet of 1 merchant and
0 war ships).
Can split off negative numbers of ships, which creates ships(some examples are:
a: fleet of 0 warships, 4 merchant and split off 0 war, -1 merchant
gave me fleet of 1 war, 3 merchant (notation: fleet of (1,3))
b: fleet of (0,1) split (-1,-1) get (1,2)
c: fleet of (6,6) split (3,-3) get (3,9)
WE SHOULD HAVE FULL PATH NAMES FOR THINGS LIKE "mv" and "date" in commands.c
and update.c respectively.
Your method for players reading messages is **BAD**. If two or more
players do so simultaneously the messages file gets munged. This is
actually quite a tough problem to solve in such a manner that the
result is portable to many Unices. Good luck.
If you want to easily avoid this problem, why not use the UNIX mail
facilities for this part of the game. You can easily allow the players
to edit a temporary file in "/tmp" (get the name via mktemp(3)) and
then use system(3) to mail it. Much more elegant than the current
system! You could extend this and allow the player to use the editor
named in the EDITOR environment variable (accessable via getenv(3))
with a default of, say, /bin/ed.
===============
THE FOLLOWING IS A LIST OF ENHANCEMENTS. SEVERAL HAVE ALREADY BEEN IMPLEMENTED
AND CODE WILL BE FORTHCOMING. SOME HAVE NOT.
Major Spelling Error: vegitation should be vegetation throughout.
I need to add trap handling so that when the game breaks, I can restore
the terminal state before exiting. I have no clue how to do this.
A check on a -x run that the effective uid is the administrators
would probably help security.
A choice of quit ( ignore commands issued ) or exit ( record commands
for execution ) would be a help. It would also reassure the player
that his commands have not gotten lost.
on the first turn of the game if someone tries to read the newspaper or
read (or maybe send) messages, I have been getting core dumps.
The score screen (command 's') (in my opinion) gives too much information
to all the players about any one player. It should probably not display
the gold, #military, #civilians, #ships (and maybe not race), of each
nation as the players would have no way of knowing this.
WHAT SHOULD THIS BE????
with the move civilians command ('Z'), it is possible to move civilians into
sectors where movecost() is -1, at which point they seem to vanish
from your control. This needs to be fixed.
DEITY redesignating sea should eliminate all people iron...
DEITY redesignating sea should eliminate player redesignations in .execute
Q and q should both quit. They should be documented as saving the game.
THE Screen needs to be cleaned up... This is an impossible process so
I accept any suggestions.
YOU SHOULD ALWAYS BE ABLE TO SET UP MINES IN TERITORY? NO MATTER THE VEGITATION
This brings up an enhancement request. You might find it more
useful to put your "^L" screen redraw function into newch. That
way, the user could redraw at *any* time.
When selecting the army number, and the number of civilians to move,
the numbers you type are not echoed.
If you are transporting armies/civilians by ship, and you stop the
fleet somewhere out in open water, the passengers are put back where
you picked them up.
FIX -- YOU SHOULD NOT BE ABLE TO STOP ON OPEN AREAS (ONLY WARSHIPS?)
IN FACT SHIPS SHOULD NEVER BE ABLE TO LEAVE COASTAL AREAS. I SHOULD
IMPROOVE SHIP MOVEMENT RATES TO COMPENSATE.
A "goto x,y" command would be really useful.
A command to goto the locations of each of your armies or navies
in order would also be very useful.
I'd like to be able to maintain multiple campaigns without having to have
multiple versions of CONQUEST floating around. People around here
have been making noises about a quick death weekend tournament
in which updates are run every 10-15 minutes (!!). If this is
not to affect the more serious day to day campaign, I will have to
recompile another version... I'm sure you see the problem.
CIAO FOR NOW...
HAVE A NICE DAY
Wed Nov 11 23:06:24 EST 1987pokey@well.UUCP (Jef Poskanzer) (11/14/87)
In the referenced article, smile@mhuxd.UUCP (Edward Barlow) wrote:
>but as a precaution, I am calling the "great conquest renaming contest".
Considering the quality of the code, how about calling it "bugquest"?
Considering the apparent reason for posting it in this deplorable
state, how about calling it "egoquest"?
Just how much time did you spend on this game, anyway? Craig and I
worked for *two years* before we released the first version of Conquest.
---
Jef
Jef Poskanzer {hoptoad,hplabs,lll-lcc,ptsfa}!well!pokeydarrylo@hpsrlc.HP.COM (Darryl Okahata) (11/15/87)
In comp.sources.bugs, pokey@well.UUCP (Jef Poskanzer) writes: > In the referenced article, smile@mhuxd.UUCP (Edward Barlow) wrote: > >but as a precaution, I am calling the "great conquest renaming contest". > > Considering the quality of the code, how about calling it "bugquest"? > > Considering the apparent reason for posting it in this deplorable > state, how about calling it "egoquest"? > > Just how much time did you spend on this game, anyway? Craig and I > worked for *two years* before we released the first version of Conquest. > --- > Jef > > Jef Poskanzer {hoptoad,hplabs,lll-lcc,ptsfa}!well!pokey > ---------- Jeez. Give the guy a break. It's his first real C program. Postings like this will only discourage him and others. -- Darryl Okahata {hplabs!hpccc!, hpfcla!} hpsrla!darrylo CompuServe: 75206,3074 Disclaimer: the above is the author's personal opinion and is not the opinion or policy of his employer or of the little green men that have been following him all day.
farren@gethen.UUCP (Michael J. Farren) (11/16/87)
darrylo@hpsrlc.HP.COM (Darryl Okahata) writes: >In comp.sources.bugs, pokey@well.UUCP (Jef Poskanzer) writes: >> >> Just how much time did you spend on this game, anyway? Craig and I >> worked for *two years* before we released the first version of Conquest. > > Jeez. Give the guy a break. It's his first real C program. Postings >like this will only discourage him and others. > I don't want to discourage postings like conquest, or the person that posted it. Anyone who puts a lot of work into something and wishes to see others benefit from that work is to be admired. But... There is never an excuse for posting source for a program which crashes and burns during normal operation, as conquest does. Never. The fact that this was his first real C program exacerbates the situation, it does not excuse it; anyone new to a language or programming environment should make damn sure he's doing things right before letting his creations loose on an unsuspecting outside world. Posting a program that hasn't been tested to death just tends to make things that much more frustrating and unpleasant for us all. The fact that this has happened many times before, and will undoubtedly happen many times more, doesn't excuse it. -- ---------------- Michael J. Farren "... if the church put in half the time on covetousness unisoft!gethen!farren that it does on lust, this would be a better world ..." gethen!farren@lll-winken.arpa Garrison Keillor, "Lake Wobegon Days"
smile@mhuxd.UUCP (11/16/87)
>Considering the quality of the code, how about calling it "bugquest"? >Considering the apparent reason for posting it in this deplorable >state, how about calling it "egoquest"? > CHILL OUT MAN!!! I dare you to comment on the deplorable condition of the code I posted!!! There were a few serious operating system dependant (ie for BSD systems) bugs, ***1*** serious code bug (in the flee routing -> it dumped core on updates), and a few stupid bugs (Netnews can not transmit a control-G and a few lines were too long). I have at least 15 letters from users who installed conquest, are using the code, and are quite happy with it. I mention quite prominently in the code that I am not a hacker (I learned C on my own), and that this was a beta-version. >Just how much time did you spend on this game, anyway? Craig and I >worked for *two years* before we released the first version of Conquest. I spent *well over* two years on the code (started February, 1985) and have played a full game 4 times before I posted it (for about 9 months). All major bugs appeared fixed prior to posting (the one serious bug came from a last minute code fix). Perhaps your comment is due to the fact that you are annoyed at my use of the name "conquest" (your earlier mail to me said as much). It is obvious that you do not have a copy of the source, and if you do, it is obvious that you have never played it. I tried to be reasonable by offering to rename the game, but maybe your ego is the one injured. There is *no* legal reason for me to wish to rename it --> you do not have a trademark on the name, only a copyright on your code. So I ask you to refrain from talking about stuff you know nothing about. The (quite annoyed) Ed PS. The one thing I would appologize for is not knowing about "patch" -- once I figure out how to use it, code fixes will be "patch"able. (It does not exist on my system though? any hints?). PPS. Followup discussion should only be in rec.games.empire, not in comp.sources.bugs.
leres@ucbarpa.Berkeley.EDU (Craig Leres) (11/18/87)
Relax, Ed. It would appear you've become confused in your rage. For example, you've confused me with Jef. I was the one who pointed that you created a conflict when you named your new game Conquest. Jef is the one who criticized your posting of shoddy, buggy code. There are several aspects to the name conflict. Since our game was submitted to DECUS in 1983 (and 1986) with the name of Conquest, it is not possible for you to submit your game to DECUS without changing the name. (But in any case, you'd also have to substantiality improve the quality of the code before they'd accept it.) Also, many more people know about our game than yours. Just imagine the poor soul who gleefully thinks he has aquired a new version of the great multi-player real-time screen-oriented space war game only to discover that he got your game instead. And of course, there's no legal reason for you to change the name of your game. But hopefully you'll see that there are some other reasons. My annoyance at your use of our name is slight. It's about equivalent to seeing someone make a lane change without using their turning signals. In both cases, I just say to myself, "Gee, I'll bet that guy doesn't know or care about the problems he's creating for others." Some people enjoy creating conflicts and confusion; maybe you are one of these. Well, I certainly hope your confusion (and rage) subsided quickly. I also hope you change the name of your game, but we'll all survive if you decide not to. (But things will sure get interesting when we release a Unix version of Conquest...) Craig
crs@cpsc6b.UUCP (11/18/87)
In article <353@gethen.UUCP>, farren@gethen.UUCP (Michael J. Farren) writes: < darrylo@hpsrlc.HP.COM (Darryl Okahata) writes: < >In comp.sources.bugs, pokey@well.UUCP (Jef Poskanzer) writes: < >> < >> Just how much time did you spend on this game, anyway? Craig and I < >> worked for *two years* before we released the first version of Conquest. < > < > Jeez. Give the guy a break. It's his first real C program. Postings < >like this will only discourage him and others. < < I don't want to discourage postings like conquest, or the person that < posted it. Then don't. < Anyone who puts a lot of work into something and wishes to < see others benefit from that work is to be admired. But... < < There is never an excuse for posting source for a program which crashes < and burns during normal operation, as conquest does. Never. The fact < that this was his first real C program exacerbates the situation, it < does not excuse it; anyone new to a language or programming environment < should make damn sure he's doing things right before letting his creations < loose on an unsuspecting outside world. Posting a program that hasn't < been tested to death just tends to make things that much more frustrating < and unpleasant for us all. The fact that this has happened many times < before, and will undoubtedly happen many times more, doesn't excuse it. < -- < Michael J. Farren A couple of questions: 1) Did the author make any claims as to the fitness of the software, or any guarantees that it *wouldn't* 'crash and burn'? I doubt it. 2) Did the author make any request for monetary compensation? Ditto. The readers of the net make up one of the largest sources of information and assistance that 'beginners' can find. Anywhere. There is much to be learned from the postings and cross postings, especially regarding programming techniques. Perhaps a part of the author's reason for posting was to take advantage of that forum. Please, do not attempt to restrict postings to 'finished' products. If you do, the net (at least the sources and binaries groups) will dry up in a *real* hurry. -- Chris Seaman | o\ /o crs@cpsc6a.att.com <or> | || See "Attack of the Killer Smiley"! ..!ihnp4!cpsc6a!crs | \vvvvvv/ Coming Soon to a newsgroup near you! | \____/
paul@tut.UUCP (11/21/87)
In article <353@gethen.UUCP> farren@gethen.UUCP (Michael J. Farren) writes:
< There is never an excuse for posting source for a program which crashes
< and burns during normal operation, as conquest does. Never. ...
Oh get a grip. Real programs *ALLWAYS* have bugs. Sometimes they are
small ones, sometimes large. I defy you to name ONE single program,
of non-trival size, that did not have a single bug in it's first
version. It never happens, not even for commercial programs.
Besides, you expect this person to bullet proof his program to the
level of software that is sold, and then give it to you for FREE?
Some programmers happen to have the support of some company to do
whatever they want to, others not. If you think that everyone can be
so generous, you are dreaming...
-- Paul Placeway
...!cbosgd!osu-cis!tut!paul
paul@ohio-state.arpa, paul@cis.ohio-state.edulmm@labsms.UUCP (11/24/87)
> (But things will sure get interesting when > we release a Unix version of Conquest...) > > Craig Please do! - - and I hope it is curses driven, for use with regular terminals I'm tired of finding a bunch of games written for Sun's on here.