time.g weirdness

time.g weirdness

[Robert Goulding]

[-- Attachment #1: Type: text/plain, Size: 568 bytes --]

Twice I've been playing time.g using the new Mac OSX binaries; and in 
both games something weird has happened to one of my triremes.  Having 
developed tech to the City level, I've sent off an unneeded trireme to 
explore uncharted territory by clicking at random on a black section of 
the map.  Each time, the boat has reached the place I clicked - but 
that place was inland, so that the trireme is now stuck!  I've attached 
a little snapshot from my most recent game.  Here, the trireme is 
awaiting orders, having reached the position I sent it to...

Robert.


[-- Attachment #2: weird-trireme.png --]
[-- Type: image/png, Size: 70896 bytes --]

Re: time.g weirdness

[Hans Ronne]

>Twice I've been playing time.g using the new Mac OSX binaries; and in
>both games something weird has happened to one of my triremes.  Having
>developed tech to the City level, I've sent off an unneeded trireme to
>explore uncharted territory by clicking at random on a black section of
>the map.  Each time, the boat has reached the place I clicked - but
>that place was inland, so that the trireme is now stuck!  I've attached
>a little snapshot from my most recent game.  Here, the trireme is
>awaiting orders, having reached the position I sent it to...

Now, that is a strange bug, indeed. I could not reproduce it, but I presume
that is because it appears at City level, as you said, and I did not have
time to play the game that long. Could you send me a saved game where this
bug is "enabled" so that I can study it in more detail?

Hans

Re: time.g weirdness

[Hans Ronne]

>Twice I've been playing time.g using the new Mac OSX binaries; and in
>both games something weird has happened to one of my triremes.  Having
>developed tech to the City level, I've sent off an unneeded trireme to
>explore uncharted territory by clicking at random on a black section of
>the map.  Each time, the boat has reached the place I clicked - but
>that place was inland, so that the trireme is now stuck!  I've attached
>a little snapshot from my most recent game.  Here, the trireme is
>awaiting orders, having reached the position I sent it to...

OK, I have managed to reproduce this now, and I think I know what is going
on. The ship is actually behaving as it should, since ships can move along
rivers in time.g:

(table mp-to-traverse
  (ship river 2)
  (ground road 1)
  )

This is called a "border slide" in Xconq terminology.

Now, the real problem is that Xconq fails to set a move task that requires
a border slide when you try to do this manually. This is because the move
command pre-flight code doesn't know about border slides. I think that
Peter Garrone added some code that addressed this problem, but it was
probably removed with his path-finding code.

Anyway, the command pre-flight also has other problems, as I mentioned
earlier, so it is probably due for an overhaul.

Hans

Re: time.g weirdness

[Jim Kingdon]

> Now, the real problem is that Xconq fails to set a move task that
> requires a border slide when you try to do this manually. This is
> because the move command pre-flight code doesn't know about border
> slides.

Ah, OK, that explains why I never could make sense of that border
slide stuff.

It also might be nice if the online help said something a bit more
than just:

  Needs MP to enter terrain: 99 by default, 1 into sea, shallows, 0 into
  river.
  Needs MP to traverse terrain: -1 by default, 2 across river.

although I'm not really sure how to express this best.  I guess the
"99 by default" could be turned into "cannot enter other terrain" (if
the help code can figure out that 99 is never possible).  Something
similar for the "-1 by default".

Although I suppose the real problem here is that the online help
doesn't know about the user interface, so it can't just say "to travel
along a river, click ....".  Maybe the user interface could have some
kind of mouseover (I could threaten to make it a tooltip for Xconq
Office) when you are on a unit which has a border slide possible.  Or
something along these lines...

Of course, all this is predicated on making border slides work from
the user interface in the first place.

Re: time.g weirdness

[Hans Ronne]

>It also might be nice if the online help said something a bit more
>than just:
>
>  Needs MP to enter terrain: 99 by default, 1 into sea, shallows, 0 into
>  river.
>  Needs MP to traverse terrain: -1 by default, 2 across river.
>
>although I'm not really sure how to express this best.  I guess the
>"99 by default" could be turned into "cannot enter other terrain" (if
>the help code can figure out that 99 is never possible).  Something
>similar for the "-1 by default".

Heh, that makes me recall the long and at the end almost metaphyscial
discussion I had with Peter Garrone last year about the meaning of the
number "99" :-).

>Although I suppose the real problem here is that the online help
>doesn't know about the user interface, so it can't just say "to travel
>along a river, click ....".  Maybe the user interface could have some
>kind of mouseover (I could threaten to make it a tooltip for Xconq
>Office) when you are on a unit which has a border slide possible.  Or
>something along these lines...
>
>Of course, all this is predicated on making border slides work from
>the user interface in the first place.

Right. I'm looking into this. Even more important, however, is to fix the
"map the unknown by clicking in it" exploit, which sneaked back in when we
removed Peter's pathfinding.

Hans

Re: time.g weirdness

[Eric McDonald]

On Wed, 11 Aug 2004, Jim Kingdon wrote:

> It also might be nice if the online help said something a bit more
> than just:
> 
>   Needs MP to enter terrain: 99 by default, 1 into sea, shallows, 0 into
>   river.
>   Needs MP to traverse terrain: -1 by default, 2 across river.
> 
> although I'm not really sure how to express this best.  I guess the
> "99 by default" could be turned into "cannot enter other terrain" (if
> the help code can figure out that 99 is never possible).  Something
> similar for the "-1 by default".

I have been strongly considering the idea of introducing the 
concept of relative infinities. So, if a game designer says that 
he/she is going to use 9999 to represent an impossible action, 
then he/she could write:
  (set relative-infinity 9999)
as a global, and then help system would do special interpretation 
with it. I am still not sure if this is the best way to proceed. 
As far as certain defaults that mean impossible (0 or -1), they 
could also be handled as such on a case-by-case basis. This is 
something I definitely plan to do.

(The relative infinity stuff could come in handy in the actual 
Xconq action logic as well, since then we would no longer be 
divining the intent of the designer wrt a number, but would have 
his/her explicitly stated intention that the number should be 
treated as indicating an impossiblility, unlimited capacity, 
etc... of some sort.) 

I also intend to make it possible to list off several related 
values in the same listing, such as with the adjacent terrain 
changing stuff that I added a while back ago.

So, yes, I do plan to do more with the online help system (the 
changes which will also be automatically reflected in the help 
file output), and I have been thinking about these very issues. 
But, I have been doing so much coding at work lately that I 
haven't felt like writing any code for Xconq. Hence my   
image-related work.

> kind of mouseover (I could threaten to make it a tooltip for Xconq
> Office) when you are on a unit which has a border slide possible.  

This isn't such a bad idea. (I notice that the IMFApp Office 
thread has thus far failed to lure Stan out onto the list again. 
He must be on vacation, only reading the monthly list digests, or 
something....)

> Of course, all this is predicated on making border slides work from
> the user interface in the first place.

Right. It is true that Peter had some border slide logic in his 
code. However, it was deeply rooted into one of the functions 
which I had to surgically remove, and I didn't see any easy way of 
saving that part of the logic. The other thing is, _I have no idea 
whether it actually worked. It seemed reasonable, but, given all 
the other brokenness that came with his code, I don't think we 
should assume that it actually worked, unless someone has proof 
that it did.

Eric

Re: time.g weirdness

[Eric McDonald]

On Wed, 11 Aug 2004, Hans Ronne wrote:

> Right. I'm looking into this. Even more important, however, is to fix the
> "map the unknown by clicking in it" exploit, which sneaked back in when we
> removed Peter's pathfinding.

As I recall, it was also in the early version of Peter's 
pathfinder, and we ended up with all that CMD_EXPLORE and 
PND_UNMAPPED stuff and whatnot as part of the fix. (After he 
hacked over my initial hack, which just assigned unexplored hexes 
a value of 1 or 2.) 

Eric

Re: time.g weirdness

[Hans Ronne]

>On Wed, 11 Aug 2004, Hans Ronne wrote:
>
>> Right. I'm looking into this. Even more important, however, is to fix the
>> "map the unknown by clicking in it" exploit, which sneaked back in when we
>> removed Peter's pathfinding.
>
>As I recall, it was also in the early version of Peter's
>pathfinder, and we ended up with all that CMD_EXPLORE and
>PND_UNMAPPED stuff and whatnot as part of the fix. (After he
>hacked over my initial hack, which just assigned unexplored hexes
>a value of 1 or 2.)

Well, the problem in that case was actually the opposite: it was impossible
to move into the unknown because the early version of Peter's pathfinder
always returned false. I think the problems we see now are due to
subsequent changes in the command pre-flight code which were in prompted by
and in part depended on Peter's code. Some of these changes were kept when
the pathfinding was removed.

I have just checked out the November 12 sources. My intention is to try to
restore command processing as closely as possible to how it worked back
then. With no path-finding algorithm, some of these pre-flight checks make
little sense.

Hans

Re: time.g weirdness

[Eric McDonald]

Hans Ronne wrote:

>>On Wed, 11 Aug 2004, Hans Ronne wrote:

> Well, the problem in that case was actually the opposite: it was impossible
> to move into the unknown because the early version of Peter's pathfinder
> always returned false. 

Oh, right. I did flip things around.

>I think the problems we see now are due to
> subsequent changes in the command pre-flight code which were in prompted by
> and in part depended on Peter's code. Some of these changes were kept when
> the pathfinding was removed.
> 
> I have just checked out the November 12 sources. My intention is to try to
> restore command processing as closely as possible to how it worked back
> then. With no path-finding algorithm, some of these pre-flight checks make
> little sense.

Well, just for the record, removing the pathfinding code was not an easy 
exercise once things had started to become entangled as they had. 
However, it was not a blind one either; the code surgery would have been 
completed much sooner than it was, if I hadn't given each reverse patch 
a fair amount of consideration and determined what needed to be cut out 
of the reverse patch (in order to keep it in the code repository). It is 
certainly possible that with so many different little pieces of code 
being touched over a period spanning half a year, and with the 
application of an occasional patch hunk failing (and thus needing 
further editing), that something slipped through the cracks. It could 
also be that I misjudged how a piece of machinery would behave after the 
alteration. I did try to pay attention to such things, but, like I said, 
it was not an easy task by any means. I also think that, when I 
completed the operation, I admonished ourselves to be on the lookout for 
breakage, knowing that it would almost certainly be found.

Eric

Re: time.g weirdness

[Jim Kingdon]

> (set relative-infinity 9999)

Is this better than adding infinity to the lisp object system (with
infinity getting its own value in enum lisptype)?  I guess for the
latter you'd need to figure out comparisons, arithmetic, etc, anew,
which might be a bit of a pain.  And of course there would be the
problem of when it is brought into C code, does it turn into TABHI, or
does the code need to check for it specifically, or what?

What I had in mind was something much less deep.  If
mp-to-enter-terrain says you need 99 movement points, and
acp-per-turn, free-mp, etc, say that a unit can never get 99 movement
points in a turn, then have the help report it as infinite.  The big
problem with that is that it is very case-by-case, and it would be
easy for this computation to be out of sync with the action code.  So
maybe one of the infinity variants would make more sense anyway.

Re: time.g weirdness

[Hans Ronne]

>What I had in mind was something much less deep.  If
>mp-to-enter-terrain says you need 99 movement points, and
>acp-per-turn, free-mp, etc, say that a unit can never get 99 movement
>points in a turn, then have the help report it as infinite.  The big
>problem with that is that it is very case-by-case, and it would be
>easy for this computation to be out of sync with the action code.  So
>maybe one of the infinity variants would make more sense anyway.

In fact, I did something very similar to supply_desc last year:

/* Don't print out storage space if it is set to arbitrarily large
(9999, 999 or 99) as in many games. */
if (um_storage_x(u, m) == 9999
    || um_storage_x(u, m) == 999
    || um_storage_x(u, m) == 99) {
          tprintf(buf, "%s %d  ",
	m_type_name(m), unit->supply[m]);
} else {
          tprintf(buf, "%s %d/%d  ",
	m_type_name(m), unit->supply[m], um_storage_x(u, m));
}

This is what the subsequent discussion with Peter Garrone was about. He
thought (based on a less than perfect documentation) that 9999 really meant
infinite storage space.

Hans

Re: time.g weirdness

[Hans Ronne]

>>I think the problems we see now are due to
>> subsequent changes in the command pre-flight code which were in prompted by
>> and in part depended on Peter's code. Some of these changes were kept when
>> the pathfinding was removed.
>>
>> I have just checked out the November 12 sources. My intention is to try to
>> restore command processing as closely as possible to how it worked back
>> then. With no path-finding algorithm, some of these pre-flight checks make
>> little sense.
>
>Well, just for the record, removing the pathfinding code was not an easy
>exercise once things had started to become entangled as they had.

You did a great job with the path-finding rollback. I'm not blaming you for
this bug since it was not easy to anticipate.

Hans

Re: time.g weirdness

[Hans Ronne]

I have now checked in fixes that re-enable border slides and at the same
time block the the click-in-unseen exploit.

The border slide issue raises some interesting questions, though. I'm not
sure that the way it now works in time.g (and possibly in other games)
really makes sense.

Here is how border slides are supposed to work, according to the manual:

	\	land	    /
	  \		  /
	    \	river	/
       A sea	       -------------        B sea
	    /		\
	  /		  \
	/	land	    \


Ships in the sea cell A can slide along the river to reach the sea cell at
B. In some low resolution maps, "rivers" are used to implement straits,
such as Gibraltar or Kattegatt. All of which makes sense.

However, in time.g, ships can also move on land using border slides along
rivers. The reason for this is that ships are allowed to occupy land cells.
So why, in that case, is it not possible to just move the ship onto a beach
by clicking on it? The answer is mp-to-enter-terrain.

There are three ways to restrict access of a unit to a specific terrain in
Xconq:

1. By volume restrictions (terrain capacity and unit-size-in-terrain).
2. By move restrictions (mp-to-enter-terrain and mp-to-leave-terrain).
3. By survival restrictions (vanishes-on and wrecks-on).

Most games use volume restrictions or a combination of volume restrictions
and other restrictions. However, time.g relies exclusively on move
restrictions to prevent access of land units to sea cells and vice versa.
This scheme breaks down when border slides are used.

So is this a feature or a bug? I think the latter. If border slides were
supposed to enable navigation of rivers in general, it should be possible
for a ship to move along the river to any cell that borders on it (or
contains it in the case of connection-type rivers).

However, this is not how things now work in time.g. Instead, the ship is
limited to jumping back and forth between a limited number of non-adjacent
cells along the river that happen to fit the border slide scheme. It ends
up moving somewhat like a knight in chess. I doubt that this is what Stan
had in mind when he wrote the code.

It is of course easy to fix this by adding volume restrictions in time.g.
However, I am not sure how many other games also rely on move restrictions,
and would have to be changed accordingly.

Hans

Re: time.g weirdness

[Jim Kingdon]

> /* Don't print out storage space if it is set to arbitrarily large
> (9999, 999 or 99) as in many games. */

Well, that's more problematic, in that it doesn't check storage
against consumption, production, etc.

Certainly in the standard game, 99 is nowhere near "infinite" for
storage space.

It does seem like an argument for some more real form of infinity
(maybe just TABHI).

Re: time.g weirdness

[Jim Kingdon]

> 1. By volume restrictions (terrain capacity and unit-size-in-terrain).
> 2. By move restrictions (mp-to-enter-terrain and mp-to-leave-terrain).
> 3. By survival restrictions (vanishes-on and wrecks-on).

This has always seemed confusing to me.

The game designer, to get things to work consistently, seemingly has
to set a bunch of these properties.

Maybe the number of properties controlling which units can go where
can be reduced?  Not that I've looked through the existing games
trying to figure out what combinations are in use (and whether they
are doing so intentionally or unintentionally).

Re: time.g weirdness

[Eric McDonald]

On Thu, 12 Aug 2004, Jim Kingdon wrote:

> > (set relative-infinity 9999)
> 
> Is this better than adding infinity to the lisp object system (with
> infinity getting its own value in enum lisptype)?  

I don't know. I haven't forgotten that you have suggested adding 
an actual infinity quantity before, but I have some qualms about 
that too, some of which you bring up below.

>I guess for the
> latter you'd need to figure out comparisons, arithmetic, etc, anew,
> which might be a bit of a pain.  And of course there would be the
> problem of when it is brought into C code, does it turn into TABHI, or
> does the code need to check for it specifically, or what?

In the case of tables, the only storage type that they currently 
support is 'short'; even TABDICE are just shorts. Even in the case 
of properties, assignments of varying types are not supported, and 
so if there is an integer property it could not be bound to an 
'Obj* lispinf' or whatever.

> What I had in mind was something much less deep.  If
> mp-to-enter-terrain says you need 99 movement points, and
> acp-per-turn, free-mp, etc, say that a unit can never get 99 movement
> points in a turn, then have the help report it as infinite.  The big
> problem with that is that it is very case-by-case, and it would be
> easy for this computation to be out of sync with the action code.  

Exactly. This is not such a big deal as long as one writes 
functions that are common to both.

>So
> maybe one of the infinity variants would make more sense anyway.

The relative infinity idea would be the easiest to code, in my 
estimation, but it is also the crudest. The case-by-case logic 
probably makes the most sense in the long run. I have already been 
heading in this direction with the common ACP and MP arithmetic 
functions that I have been written (with more to come). Hans has 
already created some fairly decent volume checking functions that 
can be used rather ubiquitously as well.

Eric

Re: time.g weirdness

[Eric McDonald]

On Thu, 12 Aug 2004, Jim Kingdon wrote:

> > /* Don't print out storage space if it is set to arbitrarily large
> > (9999, 999 or 99) as in many games. */
> 
> Well, that's more problematic, in that it doesn't check storage
> against consumption, production, etc.

I agree. This is one of the pieces of code I had in mind when I 
suggested that relative infinity would be useful beyond just the 
help system.

> It does seem like an argument for some more real form of infinity
> (maybe just TABHI).

I agree.

Eric

Re: time.g weirdness

[Hans Ronne]

>> 1. By volume restrictions (terrain capacity and unit-size-in-terrain).
>> 2. By move restrictions (mp-to-enter-terrain and mp-to-leave-terrain).
>> 3. By survival restrictions (vanishes-on and wrecks-on).
>
>This has always seemed confusing to me.
>
>The game designer, to get things to work consistently, seemingly has
>to set a bunch of these properties.
>
>Maybe the number of properties controlling which units can go where
>can be reduced?  Not that I've looked through the existing games
>trying to figure out what combinations are in use (and whether they
>are doing so intentionally or unintentionally).

We could hardly do without either terrain capacities or movement costs. And
the wreck-unit code also serves its own purpose. The question is rather
what the best way is to restrict access to certain terrain types. I usually
use capacities, but I'm not sure it's a good idea to enforce them in all
games.

FWIW, volume restrictions appear to be more robust than move restrictions,
where all sorts of complicated situations can arise due to units entering
or leaving other units etc. Perhaps you remember the "tank sitting in water
bug"? (see last year's mail archive). That was another case of move
restrictions failing to work the way they were supposed to.

Hans

Re: time.g weirdness

[Eric McDonald]

On Thu, 12 Aug 2004, Jim Kingdon wrote:

> > 1. By volume restrictions (terrain capacity and unit-size-in-terrain).
> > 2. By move restrictions (mp-to-enter-terrain and mp-to-leave-terrain).
> > 3. By survival restrictions (vanishes-on and wrecks-on).
> 
> This has always seemed confusing to me.
> 
> The game designer, to get things to work consistently, seemingly has
> to set a bunch of these properties.

Hans and I had a thread about this before (I don't remember if it 
was public or not), but, generally speaking, the move restrictions 
should be used to limit whether or not an unit can enter a given 
terrain. Using survival restrictions is not reliable, especially 
since deliberate movement in wreck/vanish situations should not 
necessarily be prohibited (even though the AI should try to avoid 
them).

Eric

Re: time.g weirdness

[Hans Ronne]

>On Thu, 12 Aug 2004, Jim Kingdon wrote:
>
>> > 1. By volume restrictions (terrain capacity and unit-size-in-terrain).
>> > 2. By move restrictions (mp-to-enter-terrain and mp-to-leave-terrain).
>> > 3. By survival restrictions (vanishes-on and wrecks-on).
>>
>> This has always seemed confusing to me.
>>
>> The game designer, to get things to work consistently, seemingly has
>> to set a bunch of these properties.
>
>Hans and I had a thread about this before (I don't remember if it
>was public or not), but, generally speaking, the move restrictions
>should be used to limit whether or not an unit can enter a given
>terrain. Using survival restrictions is not reliable, especially
>since deliberate movement in wreck/vanish situations should not
>necessarily be prohibited (even though the AI should try to avoid
>them).

I would modify that to say that either move or volume restrictions, but not
the wreck-unit code, should be used to limit access. And I would in fact
recommend volume restrictions to somebody who is writing his first game,
since they are less likely to produce unexpected results (like the one we
are discussing). Move restrictions are more versatile, but also trickier to
use.

Hans

Re: time.g weirdness

[Eric McDonald]

On Thu, 12 Aug 2004, Hans Ronne wrote:

> I would modify that to say that either move or volume restrictions, but not
> the wreck-unit code, should be used to limit access. And I would in fact
> recommend volume restrictions to somebody who is writing his first game,
> since they are less likely to produce unexpected results (like the one we
> are discussing). Move restrictions are more versatile, but also trickier to
> use.

You now seem much more comfortable with the volume restrictions 
than you did a year ago. I guess haven't found any good volume 
checking bugs in a while. ;-)

Eric

Re: time.g weirdness

[Hans Ronne]

>On Thu, 12 Aug 2004, Jim Kingdon wrote:
>
>> > /* Don't print out storage space if it is set to arbitrarily large
>> > (9999, 999 or 99) as in many games. */
>>
>> Well, that's more problematic, in that it doesn't check storage
>> against consumption, production, etc.
>
>I agree. This is one of the pieces of code I had in mind when I
>suggested that relative infinity would be useful beyond just the
>help system.
>
>> It does seem like an argument for some more real form of infinity
>> (maybe just TABHI).
>
>I agree.

I also agree that a real infinite instead of the bogus ones (99 etc) would
be nice, so if any of you want to give it a try, I'm all for it.

There was one other consideration with the above code, though, and that was
to save space and reduce the clutter in the unit info box (and Mac unit
closeup popup). This is what they would look like in most games before the
change:

Food: 4 / 9999    Minerals: 6 / 9999    Fuel:  2 / 9999    Ideas:  12 / 9999

Typically, the right half of this line would be truncated in the closeups
(which are smaller than the unit info boxes). Now it  says instead:

Food: 4    Minerals: 6    Fuel: 2    Ideas: 12

which is much neater.

Now, if the game designer sets capacity to a bogus infinite, it usually
means that he doesn't expect the ceiling to be hit in a real game. If 99 is
too low, he would use 999 or 9999 instead. This, in turn, means that the
player has no interest in knowing about the capacity. All he needs to know
is that there is no ceiling that he has to worry about. Which is why I
suppressed the printing of bogus infinites.

The weak point here is of course that the game designer may deviate from
this rule, by intention or mistake. Having a relative infinite that
defaults to TABHI, and which is suppressed in most outputs, is therefore a
superior solution.

Hans

Re: time.g weirdness

[Hans Ronne]

>On Thu, 12 Aug 2004, Hans Ronne wrote:
>
>> I would modify that to say that either move or volume restrictions, but not
>> the wreck-unit code, should be used to limit access. And I would in fact
>> recommend volume restrictions to somebody who is writing his first game,
>> since they are less likely to produce unexpected results (like the one we
>> are discussing). Move restrictions are more versatile, but also trickier to
>> use.
>
>You now seem much more comfortable with the volume restrictions
>than you did a year ago. I guess haven't found any good volume
>checking bugs in a while. ;-)

Well, volume checking is a problem for anyone who is writing kernel code.
But to a newbie game designer, volume restrictions are easier to use. That
was my whole point. No need to worry about border slides, ferry costs etc.

Hans

Re: time.g weirdness

[Eric McDonald]

On Thu, 12 Aug 2004, Hans Ronne wrote:

> Well, volume checking is a problem for anyone who is writing kernel code.
> But to a newbie game designer, volume restrictions are easier to use. That
> was my whole point. No need to worry about border slides, ferry costs etc.

If the newbie game designer just sticks to using 
'mp-to-enter-terrain', and doesn't worry about traversal, ferry, 
and leave costs, then I would argue that that is just as simple as 
volume restrictions, if not simpler.

Eric

Wrecked-Type Doesn't Apply to Detonating Units

[Elijah Meeks]

It seems that the wrecked-type-if-destroyed table
doesn't apply to units destroyed by detonating units. 
Is this by intention?


	
		
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - 100MB free storage!
http://promotions.yahoo.com/new_mail 

Re: Wrecked-Type Doesn't Apply to Detonating Units

[Eric McDonald]

Elijah Meeks wrote:

> It seems that the wrecked-type-if-destroyed table
> doesn't apply to units destroyed by detonating units. 
> Is this by intention?

I don't recall intentionally setting it up that way. I suppose it could 
be made to do so, but I am not sure whether that would be a good idea or 
not. What if a detonating unit can also destroy another unit through 
conventional means? I guess we could pretend that this is never a real 
game design possiblility, and let the 'wrecked-type-if-destroyed' table 
handle detonation deaths as well. If we don't, then probably YANT (yet 
another new table) is called for: 'wrecked-type-if-blown-up', perhaps?

Eric

Re: Wrecked-Type Doesn't Apply to Detonating Units

[Hans Ronne]

>Elijah Meeks wrote:
>
>> It seems that the wrecked-type-if-destroyed table
>> doesn't apply to units destroyed by detonating units.
>> Is this by intention?
>
>I don't recall intentionally setting it up that way. I suppose it could
>be made to do so, but I am not sure whether that would be a good idea or
>not. What if a detonating unit can also destroy another unit through
>conventional means? I guess we could pretend that this is never a real
>game design possiblility, and let the 'wrecked-type-if-destroyed' table
>handle detonation deaths as well. If we don't, then probably YANT (yet
>another new table) is called for: 'wrecked-type-if-blown-up', perhaps?

How about simply wrecked-type, a default table to catch everything that is
not further specificed? There are other cases as well, such as
WRECK_TYPE_TERRAIN, that are not covered right now. Ideally, the code
should also check wrecked-type if wrecked-type-if-destroyed et al. are
missing, so that the game designer can use one table for everything if he
wants to make things simple.

Hans

Re: Wrecked-Type Doesn't Apply to Detonating Units

[Eric McDonald]

Hans Ronne wrote:

> How about simply wrecked-type, a default table to catch everything that is
> not further specificed? 

There is already the 'wreck-type' unit property.

>There are other cases as well, such as
> WRECK_TYPE_TERRAIN, that are not covered right now. Ideally, the code
> should also check wrecked-type if wrecked-type-if-destroyed et al. are
> missing, 

It does. The default wrecked type for any sort of wreckage is still 
'wreck-type', both in the case where there the default value is found in 
a special wreckage table, and in the case where there is no special 
wreckage table.

I believe I mention this in the documentation and/or announcement of the 
the special wreckage tables.

>so that the game designer can use one table for everything if he
> wants to make things simple.

Yes, the code should already do that, and I made the behavior that way 
for precisely this reason.

Eric

Re: Wrecked-Type Doesn't Apply to Detonating Units

[Eric McDonald]

Eric McDonald wrote:

> Hans Ronne wrote:
> 
>> How about simply wrecked-type, a default table to catch everything 
>> that is
>> not further specificed? 
> 
> 
> There is already the 'wreck-type' unit property.

'wrecked-type', not 'wreck-type'

Also, the table that we were discussing earlier is 
'wrecked-type-if-killed' and not 'wrecked-type-if-destroyed'.

(Just setting the record straight in case a new game designer is reading 
this.)

Eric

Re: Wrecked-Type Doesn't Apply to Detonating Units

[Elijah Meeks]

> I don't recall intentionally setting it up that way.
> I suppose it could 
> be made to do so, but I am not sure whether that
> would be a good idea or 
> not. What if a detonating unit can also destroy
> another unit through 
> conventional means? I guess we could pretend that
> this is never a real 
> game design possiblility, and let the
> 'wrecked-type-if-destroyed' table 
> handle detonation deaths as well. If we don't, then
> probably YANT (yet 
> another new table) is called for:
> 'wrecked-type-if-blown-up', perhaps?

I think it's forseeable that you could want different
wreck-types depending on whether a unit destroys
another unit conventionally (In this case I'm thinking
of ships or battlemechs with nuclear engines, which
when destroyed or self-destructed perhaps cause
different effects than their regular attacks) but, for
now, I think it would be fine to just default the
wrecked-type-if-killed table to apply to detonating
units.  As far as I'm aware, there are no current
games that would be adversely affected by this and
there are a couple cute things I want to do with this
feature in Opal.




		
__________________________________
Do you Yahoo!?
Yahoo! Mail - Helps protect you from nasty viruses.
http://promotions.yahoo.com/new_mail

Re: Wrecked-Type Doesn't Apply to Detonating Units

[Eric McDonald]

Elijah Meeks wrote:

> but, for
> now, I think it would be fine to just default the
> wrecked-type-if-killed table to apply to detonating
> units.  

The problem is that later on, if we want to separate out the detonation 
damage from the conventional attack damage, it might be troublesome, and 
will add to the complexity. If we make the 'wrecked-type-if-killed' 
provide the wrecked types for units killed by explosion, and if you 
start using it for that purpose, then we would have to make 
'wrecked-type-if-blown-up' default to the value of 
'wrecked-type-if-killed' rather than directly to the value of 
'wrecked-type'. But, maybe this is how it should behave anyway. I 
haven't thought it through completely.

Until I get around to making 'wrecked-type-if-killed' apply to explosion 
casualties as well, or making a new 'wrecked-type-if-blown-up' table, 
could you just assign the blown up types using the 'wrecked-type' 
properties of the units? Or are your needs more complicated than that?

Eric

Re: Wrecked-Type Doesn't Apply to Detonating Units

[Elijah Meeks]

> Until I get around to making
> 'wrecked-type-if-killed' apply to explosion 
> casualties as well, or making a new
> 'wrecked-type-if-blown-up' table, 
> could you just assign the blown up types using the
> 'wrecked-type' 
> properties of the units? Or are your needs more
> complicated than that?


As I understand it, what you're saying is set the unit
property 'wrecked-type' to one setting and then
override it with the wrecked-type-if-killed for all
normal units?

Example:

(unit city (wrecked-type nuked-city))

(table wrecked-type-if-killed
   (city u* ruined-city)
)

I'll check this at home, but my understanding of the
wreck-typing code is that the result would be what I'm
looking for, a different wreck-type as a result of an
exploding unit which ignores the
wrecked-type-if-killed table but does call the
wrecked-type unit property.

That would work.




	
		
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - 100MB free storage!
http://promotions.yahoo.com/new_mail 

Re: Wrecked-Type Doesn't Apply to Detonating Units

[Eric McDonald]

Elijah Meeks wrote:

> Example:
> 
> (unit city (wrecked-type nuked-city))
> 
> (table wrecked-type-if-killed
>    (city u* ruined-city)
> )

Yes. This is what I had in mind.

> I'll check this at home, but my understanding of the
> wreck-typing code is that the result would be what I'm
> looking for, a different wreck-type as a result of an
> exploding unit which ignores the
> wrecked-type-if-killed table but does call the
> wrecked-type unit property.
> 
> That would work.

OK, good. If it doesn't do what you need, let me know, and I will try to 
work out a better arrangement in the fairly near future.

Eric