CF: Fixing things

[Anthony Thyssen <anthony@cit.gu.edu.au>]

scott on  wrote...
| > I second this.  Mark, how about a CVS repository for Crossfire?
| 
| > I think Mark provides an extremely valuable service as maintainer/reviewer:
| > is there any way to have submissions to the CVS tree held pending his
| > approval?
| 
| As for the bugs, seems to me that most are a case where it is noticed
| than an existing behaivor is not really correct and it should be improved,
| but something else was dependent on it working *exactly* as it does now.
|
It is vital for better documentation of EXACTLY what a object is suposed
to do.

A lot of the current problems is because the crossfire.doc fire is very
incomplete.  Either the doc assumes you know what an object does,
generally because they think a pit or gate is obvious is its job.

But as we can see with gates that is not the case.  Are gates suposed to
`roll' floor? Making them suddenly visible? What if you put two gates on
top of each other.

Another example which we will probably see more and more off.
Multiple buttons on top of each other! How should you calculate the
trigger weight? A buttons trigger weight IS also its weight!

As such if you want to add say 3 `plate buttons' on top of each other
to activate three posibably seperate gates, you will need
to set the weight of each carfully to include the weight of the
`plate buttons' above it (any any other objects). Hmm 3 plate buttons
on top of each would probably get so heavy you start geting 16 bit int
over flows -- Black Holes anyone?

If this changes (and techniquely, trigger weight should NOT equal button
weight) then of course a lot of maps will currently break. Though it
would make multi-button stacks a LOT simpler. I'd myself like to see
this properly defined, `fixed' and all maps corrected.

Movers is another case in point.  They are documented in "crossfire.doc"
but they don't say they it only effects ``alive'' objects. One map in
pupland abuses this by actually making an `icecube' alive!

If you want a mover to also allow moving `non-alive' objects (prehaps
any rollable object), or maybe only rollable objects and not people
(A Indiana Jones boulder trap anyone?). Then they should make a request
for a server expandsion. Not try an fudge a `mis-use'.

Actually allowing movers to move other objects, particular with some
`trigger' ability, and timing functions, could make map event
coordination a lot easier, than the current `boulder cascade' method.

In future I would like to see ALL these special objects properly and
diffinativally defined, and some scripts which will fix any map
changes accociated.  BEFORE the version 1 release.

Better to define, fix, break maps and fix maps NOW than latter.

Keep up the good work Mark!

Ignore ``you should not have fixed that'' comments. 
Define and fix it properly and get the rest of us slobs to fix the maps
to match the correct behaviour.

  Anthony Thyssen ( System Programmer )    http://www.sct.gu.edu.au/~anthony/
- --------------------------------------------------------------------------- -
    A kite is a thing that, when you show it to the wind, 
       dances and makes you smile.    -- Chuck Henderson <coh@i-2000.com>
- --------------------------------------------------------------------------- -
     PGP Public Key available -- finger -l anthony@lyrch.cit.gu.edu.au
-
[you can put yourself on the announcement list only or unsubscribe altogether
by sending an email stating your wishes to crossfire-request@ifi.uio.no]