Table Request: Accident-Occupant-Effect

Table Request: Accident-Occupant-Effect

[Elijah Meeks]

Not really related to GIS, well, maybe a little, it
does kind of involve terrain...

So in the current system, the accident-hit-chance
affects all units in a terrain, except occupants.  It
makes sense when we think of these accidents to be
terrain-related, but I've used the table as a random
monster generator (In Opal) and now I want to use it
to simulate starship crews trying to get their systems
on-line.  Here's how it works:

In battles.g, occupants represent ships' systems.  So
your Enterprise Class unit has Phaser Bank units,
Photon Torpedo Launcher units, Shields units, et
cetera.  It works pretty well.

But now I'm writing a Wrath of Khan scenario, and I'm
trying to represent the Enterprise being caught
off-guard by the Reliant.  I tried to manually set acp
using '(acp 0)' or '(acp -2)' but it looks like this
is only accounted for in saved games (.xcq).  So I
built more units (Surprise) all of them being
'Offline' versions of the various systems.  If hit,
they're immediately knocked out, but of course the
crew's trying to get them on-line as soon as possible,
so I figured if I set:

(table accident-hit-chance 
   (offline-systems-types t* 2500)
)

and

(table accident-damage
   (offline-systems-types t* 9999)
)

and set the wrecked-type to their working equivelent,
then I'd see a 25% chance per turn that the systems
would come on-line.  The player, of course, would be
frantically trying to maneuver out of range, waiting
for his shields to come up or phasers to come on-line
(And, of course, use the Command Prefix Code unit to
do the same to the Reliant).  It sounds like fun.

Only accidents don't affect occupants.  So, if anyone
can think of a better solution to this problem, let me
know, otherwise, if somebody in the know gets the
chance, I think it's worthwhile to see accidents
affect occupants.

Elijah


		
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages!
http://promotions.yahoo.com/new_mail 

Re: Table Request: Accident-Occupant-Effect

[mskala]

On Wed, 22 Sep 2004, Elijah Meeks wrote:
> Only accidents don't affect occupants.  So, if anyone
> can think of a better solution to this problem, let me
> know, otherwise, if somebody in the know gets the
> chance, I think it's worthwhile to see accidents
> affect occupants.

I don't know if this is better, but you could probably do it by giving
each "offline" unit a material which, once fully consumed, will cause the
unit to wreck into its "online" form.  For randomness you could give it
just one point of the material and use a sufficiently small fractional
consumption rate (we do support fractional consumption rates, right?).

While we're wishlisting for terrain accidents, I would like to be able to
set accidents or attrition for *movement through*, as opposed to *presence
in*, terrain.  I wanted to model a school bus which can be driven over
hostile terrain, but which takes damage if you do that.  Well, if I use
"attrition" then you can drive over rocks and broken glass with impunity
as long as you make sure to end the turn on the road; and if I use
"wrecking" then you pay the penalty as soon as you move into a
hostile-terrain hex, but the wrecked form can't also be vulnerable to
wrecking on that terrain, because wrecking repeats recursively until it
hits a form that won't wreck in the hex.

Neither of those solutions addresses the fact that if you park on hostile
terrain you shouldn't take any additional damage just sitting there,
beyond the damage you took getting there - it is movement in particular
that causes the damage.  The ideal solution would be to be able to set a
(possibly fractional and probabilistic) hit point cost paid every time,
and as soon as, the unit moves into (or maybe out of) a hex of the hostile
terrain..
-- 
Matthew Skala
mskala@ansuz.sooke.bc.ca                    Embrace and defend.
http://ansuz.sooke.bc.ca/

Re: Table Request: Accident-Occupant-Effect

[Eric McDonald]

Elijah Meeks wrote:

> Only accidents don't affect occupants.  So, if anyone
> can think of a better solution to this problem, let me
> know, otherwise, if somebody in the know gets the
> chance, I think it's worthwhile to see accidents
> affect occupants.

Or how about a new unit property, 'auto-upgrade-chance'? By default this 
would be 100%, so as to not interfere with the regular auto-upgrade 
mechnaism. However, you could set it to 25%, and make sure that no 
materials, advances, size, etc... are required for the auto-upgrade. 
This feels less hackish than using accidents for such purpose, and may 
prove useful in other situations as well.

Eric

P.S. Between you and Lincoln, it sounds like I am going to be doing 
kernel hacking rather than SDL UI hacking this weekend. I guess I'll 
have to cloister myself in a monastery somewhere with a laptop and no 
access to the outside world, if I ever want to stay on track. :-)

Re: Table Request: Accident-Occupant-Effect

[Eric McDonald]

mskala@ansuz.sooke.bc.ca wrote:

> While we're wishlisting for terrain accidents, I would like to be able to
> set accidents or attrition for *movement through*, as opposed to *presence
> in*, terrain.  

Yeah, you've mentioned this before.

I was thinking about photorps today, since Elijah had mentioned to me 
that he wanted to make them units instead of fired manterials. One 
problem I saw with photorp units is that they would not be attrited out 
of existence until the beginning of the next turn, and that it would 
probably be better to create a range/lifetime restriction based on 
attriting per movement rather than per turn. That reminded me of our 
previous discussion on this subject. Given the time, perhaps that is 
another thing to work on this weekend....

Eric

Re: Table Request: Accident-Occupant-Effect

[Elijah Meeks]

--- mskala@ansuz.sooke.bc.ca wrote:

> On Wed, 22 Sep 2004, Elijah Meeks wrote:
> > Only accidents don't affect occupants.  So, if
> anyone
> > can think of a better solution to this problem,
> let me
> > know, otherwise, if somebody in the know gets the
> > chance, I think it's worthwhile to see accidents
> > affect occupants.
> 
> I don't know if this is better, but you could
> probably do it by giving
> each "offline" unit a material which, once fully
> consumed, will cause the
> unit to wreck into its "online" form.  For
> randomness you could give it
> just one point of the material and use a
> sufficiently small fractional
> consumption rate (we do support fractional
> consumption rates, right?).

That would work, also, but units that starve don't
wreck, they vanish.  So it would still need a change
to the code.




		
__________________________________
Do you Yahoo!?
Yahoo! Mail is new and improved - Check it out!
http://promotions.yahoo.com/new_mail

Re: Table Request: Accident-Occupant-Effect

[Elijah Meeks]

> Or how about a new unit property,
> 'auto-upgrade-chance'? By default this 
> would be 100%, so as to not interfere with the
> regular auto-upgrade 
> mechnaism. However, you could set it to 25%, and
> make sure that no 
> materials, advances, size, etc... are required for
> the auto-upgrade. 
> This feels less hackish than using accidents for
> such purpose, and may 
> prove useful in other situations as well.

I do like that, but is it possible to give a unit
multiple (auto-upgrade-to) properties?  You know,
like:

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

(table auto-upgrade-chance
   (college-student dropout 5000)
   (college-student wageslave 3000)
   (college-student engineer 2000)
)

Though the example's meant to be funny (dropout is
probably a wreck-type), the point is that you could
give units multiple paths based on the new table.
 

> P.S. Between you and Lincoln, it sounds like I am
> going to be doing 
> kernel hacking rather than SDL UI hacking this
> weekend. I guess I'll 
> have to cloister myself in a monastery somewhere
> with a laptop and no 
> access to the outside world, if I ever want to stay
> on track. :-)


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


		
_______________________________
Do you Yahoo!?
Declare Yourself - Register online to vote today!
http://vote.yahoo.com

Re: Table Request: Accident-Occupant-Effect

[Eric McDonald]

On Thu, 23 Sep 2004, Elijah Meeks wrote:

> > just one point of the material and use a
> > sufficiently small fractional
> > consumption rate (we do support fractional
> > consumption rates, right?).

Ugh, I would have to check on that one. My sense is that 
those tables are interpreted as strict integers, and not 
"stochastic values".

> That would work, also, but units that starve don't
> wreck, they vanish.  So it would still need a change
> to the code.

I implemented a 'wrecked-type-if-starved' table when I did the 
other 'wrecked-type-*' tables. Unless something got broken, this 
should still work; I think I tested it, and so I believe that it 
worked to begin with.

Eric 

Re: Table Request: Accident-Occupant-Effect

[Eric McDonald]

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

Re: Table Request: Accident-Occupant-Effect

[Elijah Meeks]

> I implemented a 'wrecked-type-if-starved' table when
> I did the 
> other 'wrecked-type-*' tables. Unless something got
> broken, this 
> should still work; I think I tested it, and so I
> believe that it 
> worked to begin with.

Oh.  Well, in that case I can get my offline weapons
working right now, and if we decide to implement
auto-upgrade-chances, then I can add a degree of
randomness to it (Which isn't a big deal, of course). 
In fact, I can set up the current wrath-khan.g so that
some of the systems come on-line faster than others by
reducing their starvation materials.

You know you've got good support when requested
features are implemented so fast that they're already
there.




		
__________________________________
Do you Yahoo!?
Read only the mail you want - Yahoo! Mail SpamGuard.
http://promotions.yahoo.com/new_mail