Re: Table Request: Accident-Occupant-Effect

[Eric McDonald <mcdonald at phy dot cmich dot edu>]

On Thu, 23 Sep 2004, Elijah Meeks wrote:

> (unit college-student (auto-upgrade-to dropout)
> (auto-upgrade-to wageslave) (auto-upgrade-to
> engineer))

The way Xconq parses things is such that the final value of the 
'auto-upgrade-to' property would be 'engineer', as the other 
previously assigned values would be clobbered.

I did consider making 'auto-upgrade-to' a table rather than an 
unit property when I was first implementing that stuff. But, I 
opted for a property so that there would be no ambiguities. If it 
was a table, then there would be the possibility of multiple 
auto-upgrade paths, and if certain material and size conditions 
were fulfilled simultaneously, then how would the code be able to 
tell which upgrade path to take? Since the auto-upgrade code is 
kernel-level, it cannot (should not) make subjective decisions, 
and so I thought it better to restrict auto-upgrade paths to be 
completely predetermined. 

> Though the example's meant to be funny (dropout is
> probably a wreck-type), 

:-)

> Sure, sounds great, but before you leave...

Uh oh. At least your message didn't end in "and, and, and...".

Eric