Re: scorekeeping and materials

[mskala at ansuz dot sooke dot bc dot ca]

On Sat, 8 May 2004, Eric McDonald wrote:
> On Sat, 8 May 2004 mskala@ansuz.sooke.bc.ca wrote:
> > First issue: I can't find a nice way for combat to involve capturing
> > materials from the enemy unit.  The best I can do seems to be for failure
> > in combat to always result in being wrecked or captured instead of
> > destroyed, and then have wrecks automatically surrender, making their
> > materials available to the winner.
> 
> To clarify: you want to capture materials from a unit that is 
> still alive after a combat action in which it was hit?

Ideally, yes.  The combat hit might or might not also result in loss of HP
to the losing unit (which might then in turn result in it wrecking or
vanishing), but the main effect would be for some material from the loser
to be transferred to the winner.  Moe hits Calvin and steals his lunch
money.

If the thing being transferred is a single object (Gollum bites Frodo and
steals the Ring) then I think I can do it by having the thing be a unit
and setting up the combat so that it gets captured.  That's less good if
there are lots of them, though.

[bus crashing through fence]
> I take it you are not interested in wrecking the unit or making it 
> vanish, but merely want to damage it?

Well, I might switch to wrecking if that's the best implemented way to do
it, but the effect I'd prefer is that when you crash a bus through a
fence, you can still use it afterward, but it doesn't work quite as well,
and if you do that too many times, it eventually stops running completely.  
Losing HP seemed like the natural way to do that.  I think if I did it
with wrecking, I'd have to have five or six levels of "slightly dented
bus", "bus with lots of broken windows", "bus with exhaust system dragging
on the ground", on up to "smoking skeleton of bus with one flaming wheel
rolling slowly away".  That might actually be sort of cool, but it isn't
what I first thought I wanted.

> >  The damage should ideally come specifically from
> > *movement*.
> 
> I can't argue with that.

It occurs to me that many of my issues stem from the fact that I'm
interested in low-level tactical games; attrition due to merely being in
terrain might be more of a strategic effect ("don't camp your army there,
the soldiers will get malaria" - duration of exposure is key and movement
only secondary) and I think Xconq is more intended for strategic-level
games.  For sure I think the existing behaviour should be kept as well as
movement-based damage, because in some situations it *is* what's called for.

> >  Maybe it would be reasonable for this kind of damage to be
> > associated with border terrain? 
> 
> Why specifically border terrain? Border terrain is just a subset 
> of terrain, and I think that a change to these features would be 
> better left generalized. If I have an 18th cetury army moving 

I was fishing around for ways to do it in the existing structure and it
occurred to me that if it did already exist somewhere, it might already
exist as a border effect.  The specific example of a bus crashing through
a fence would logically map to a border, and so would things like falling
off cliffs (*), but it's easy to imagine other cases where other kinds of
terrain should have similar effects, so if it can be made generic, that's
definitely better.

(*) Falling off cliffs brings up another low-priority "wishlist" type of
item, because of course you can only do it in one direction, so it would
presumably require a new kind of terrain subtype, like a border but with
direction.  Alternatively, it could be tied into elevation somehow,
although that doesn't address other reasons a directional border might be 
nice.

> Thanks for the crash report.
> Do you have a stack trace? And can you send us the file in 
> question?

I don't have a stack trace; could generate one if you tell me just how to
do it.  A file demonstrating the problem is attached to this message; hope
the mailing list software doesn't mind.  I attempted to make it minimal
for triggering the problem.  In so doing, I found that the line "(set
see-terrain-always false)" seems to be a necessary condition for the
crash, so that might be a clue to what's wrong.  The existence of a border
terrain type is also necessary - regardless of whether any terrain of that
type actually exists.

If I start a game from this file and then try to save, I reliably get the
message "Warning: Should not be calling xmalloc (requested 34 bytes)  
This is not fatal, but may cause more serious problems later on.  Do you
want to continue playing this game?" and assuming I choose "continue"
that's followed by the same message with 36 bytes, then a segmentation
fault.  Also, if I load this file and then just play for a while without
saving, I eventually get "xconq: actions.c:3211: check_change_type_action:
Assertion `((u3) >= 0 && (u3) < numutypes)' failed. Aborted"

So it looks like it may actually be a bug related to see-terrain-always,
not to border terrain as such, but it was manifesting for me as "I can't
save files if I define border terrain".

> materials.... I won't be able to get to dealing with it right away 
> though. If you felt up to creating a patch in the interim, that 
> would be quite welcome.

Maybe once I get more familiar with the insides of Xconq... I'm still at
the stage where I don't know whether "My file doesn't do what I wanted!"
is caused by my not understanding the intended behaviour of GDL, or Xconq
not implementing the intended behaviour.
-- 
Matthew Skala
mskala@ansuz.sooke.bc.ca                    Embrace and defend.
http://ansuz.sooke.bc.ca/

Attachment: crasher.g
Description: Text document