Crossfire Archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: CF: Changes?
> There are a few things I would like to have in crossfire:
>
> 1) Niceties, such as "ignore <player>" and working "bind summon <player>"
> 2) Protecting users from other users by having things like flood
> protection (can't bind "say foo" and then press the key a lot),
> making the CF impossible (or nearly) to crash,...
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). 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. After command was completed then it would also
be shown in messages windows along with all other messages. That would
make it less bothersome to be trying to type a command when you are
receiving lots of messages (either from annoying player or game action).
> 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.
> 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. Much like how one sets up a system
account? That sounds like a solid way of having a private game. Or
have I missed what you are suggesting. I am not sure how else to keep
out a very persistent unwelcome person.
> 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.
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)). Maybe the game for partying players should remember the actions
of each player (ie count hit, wizard spells cast, priest spells, and
so on) and then allocate the player's exp by his activity. So a
player casting wizards spells get wiz exp even as other player fighting
monster gets physical exp.
> 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
> and let him save. Then some nice commands such as "shutdown", "force", and
> such. It's quite nice to have these commands if you happen to need them,
> and you can find lots of bugs by disallowing players to save, addexping
> them, creating monsters and let 'em crush anything that moves :)
> While I did this I found 2 bugs, one of being the "gravestone of logon"
> bug..
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.
> I would be willing to code most, of these, it's just that if
> they won't be included in the official CF I probably won't bother.
> Maintaining patches not in the main tree is a real pain in the..
>
> Who thinks these are good/bad ideas? Let's get some discussion here, it's
> so painfully quiet ;)
sdw
[to unsubscribe etc., send mail to crossfire-request@ifi.uio.no]
Follow-Ups: