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] |
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
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |