This is the mail archive of the xconq7@sources.redhat.com mailing list for the Xconq project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

More terrain coating issues


I've been working on a test module that demonstrates how omniterr.g
might be used in a game that someone might actually want to play. 
However, I've run into two problems:

1. I created "engineer" units that can theoretically add and remove
terrain coatings, thus allowing a side to alter its environment
(essential if the map has no environment to start with!).  However, when
I try to have an engineer add a coating, the "add terrain" command
appears to complete with no errors (thus burning an ACP, probably would
also burn materials if I had enabled consumption-per-add-terrain). 
However, the map is unchanged!

When I run Xconq with the -D option, I get the following output from the
"add terrain" command:

Moving s1 e 2 (6,24) (0/1, buzz 0) with plan type Passive <null goal> waiting supply_alarm no tasks
s1 e 2 (6,24) doing [add-terrain 6 24 1 31 (#2)] with 2 acp left
s1 e 2 (6,24) action [add-terrain 6 24 1 31 (#2)] result is action-done, 1 acp left


2. The code for advanced units seems to get confused if none of the cell
terrain within its reach can produce any materials.  If the cell has
several coatings that produce materials, those coatings are completely
ignored.


3. I can't figure out how to make terrain consume materials.  Usually
such a thing is unnecessary, but if a game is set up to track soil
nutrients, it would be a good way to prevent players from trying to
place vegetation in an inappropriate area (e.g. tropical rain forest in
a polar ice cap).


4. Xconq doesn't complain if an illegal edge terrain, such as a coating,
is specified.  It proceeds as if the terrain type was legal, apparently
by treating it as cell terrain.  Fortunately, the consequences of the
bug seem to be harmless.


Finally, I have a new version of omniterr.g, plus the current pre-alpha
version of my test module (loosely based on empire.g), should it be
helpful for reproducing the aforementioned bugs (it exhibits #1 and #2):

http://homepage.mac.com/lmpeters/omniterr.g
http://homepage.mac.com/lmpeters/imperium.g

---
Lincoln Peters
<sampln@sbcglobal.net>

I don't know anything about music.  In my line you don't have to.
		-- Elvis Presley


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]