Crossfire Archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: CF: Changes?



In article <9709101536.AA24797@spiff.Tymnet.COM>, you wrote:
>I hope you meant to say "play" instead of "crash" or are you already that
>cynical?  I am not sure if protecting players from other spamming players
>would be needed if you have better admin stuff (so you boot offensive
>player off).

The point is that you can't!!! If somebody binds "shout <realbigmessage>"
to "A" and then just keeps pressing that, *nothing* else happens because
the game lags so much! Not Nice (tm).

>Also, sometimes the game itself floods out messages.  I
>wonder if CF's UI would be better if it had a small window where player's
>commands were enterred. 

It doesn't flood that much, I don't care about flooding if it doesn't slow
the game down. Users can ignore stupid players then.

>> 3) Admin race, which could be used only if the name of the character is in
>>    file called "admins", this race could do anything the current DM can
>>    do. I absolutely hate to do addexp, abil, ... thingies on the character
>>    just to test something!
>I don't like how that could interfer with the game since is that character
>Human and Admin or just Admin?  Seems to me it would be far better if you
>had a file (player_DM_cmds?) which had entries listing player names and
>whatever DM commands they are allowed to use.  So you could allow a player
>to add_exp, but nothing else.  You might want enter_dm and leave_dm cmds
>so player would enter and leave DM mode and thus prevent cases where it
>isn't clear if player is playing or DMing.

Hey, this is actually much nicer idea than what I had, thanks!

>> 4) Ban for specific players, not on usernames anyone can fake. Wildcards
>>    used of course, so you could deny entrance from all but a few persons.
>So only people with existing characters could enter the game?  Which means
>the DM would be only one to create characters and would then tell friend
>the character name and password. 

Idea was that when you've just done a code change what possibly could be
incorrect and be abused, you maybe want to have a small, selected team
(maybe of cheat characters) to test it, not to allow every player to find
out that "ooh, I can get tons of exp by abusing this bug XXX" :)

>> 5) Different classes of players (for partying) so you couldn't be a
>>    wizard-priest-fighter. An option, ie. a #define.
>There was a discussion on player classes a while back.  It pretty much
>ended up on the idea that skill based exp means a player is what he does.
>With spell encumberance and spell failure and Gods system then a player 
>must actively be working at being multi-class in order to be good at
>several things.  At least that is how I remember how that discussion
>ended.

It's too easy. You usually do a good fighter with some mage spells (large
fireball/snowball, create bomb, dimension door) and with some priest
spells (summon avatar, WoR, immunity to fire, restoration). Then who wants
to party, everybody has best abilities of every class? Or what about doing
something else than a primary fighter, secondary priest-wizard, when that
type is just the best one one can create?

>Though, it does raise the question of how skills based exp is shared
>if doing partying exp and is exp being given to chars in skills that
>don't really deserve it (such as a wizard fireballing a monster, does
>the fighters of the party get wizard exp or fighter exp?  (by wizard or
>fighter I mean the role those players are fulfilling as part of the
>group)).

You would want to fix bombs too, then. They give you exp to whatever skill
you currently have on. Or did give a few versions ago, haven't tested
lately :)

>> In 3) I would also include more power for admins, such as having "zap
>> <player>" or "(dis)allow_save <player>" so the admin could change a player
..
>I think adding more admin commands would be fine and generally welcome.
>I suggest that care be taken to be sure each command does something useful
>and isn't really just slight variations of other commands.  I worked on a
>program that ended up with 5 different ways to display basically the same
>info.  That happened since management kept saying add new command (really
>just a few fields) without changing old command.  That was a pain to
>maintain.

Last time people thought that admins are a cheat and nobody should be
allowed to cheat, thus admins are a no-no.

>> Who thinks these are good/bad ideas? Let's get some discussion here, it's
>> so painfully quiet ;)

Phew, finally got some discussion which is not about a java client or how
do I find this and that and..
[to unsubscribe etc., send mail to crossfire-request@ifi.uio.no]


References: