The issue of mob health in batclient is due to a mistake on
our side. It will be fixed so that the 'scan' command also
reflects the 5% accuracy.

Then a brief comment on the topic of providing features for
the batclient only. If we come up with a good feature that
due to technical reasons is only feasable in the batclient,
we will not scrap implementing it just because it cannot
be replicated in telnet. We will do our best to make sure that
all content is equally enjoyable no matter what client you use,
but it would be foolish to NOT implement good ideas just
because there isnt a standardized protocol for MUD communication.

++ Gore

It could be made toggleable for pure telnet, yes. Don't see why not, although
hard to imagine why one would use that info for if you don't know how
coordinates are working on the actual maps. Those coordinates are developed
for maps built into client. We could give em to you, but without information
on how they are used, you'll find them useless. If you can come up with a use
for those, I'd consider making a toggler for those.

^o^

I'm taking this newspost to address some of the issues written about the
Batclient related issue on target health statistics by our concerned
players. It will hopefully shear some light into the fundamentals behind
our Batclient development -project.

First of all, the main purpose of Batclient is to make it easier for people
to start playing a text-based game, BatMUD. So what we are doing here is
that we're aspiring to eliminate the 'gap between' or at least considerably
'lower the bar' of being able to 'play' BatMUD, versus the ease of getting
in on the commercially produced multi-million dollar behemoth MMOs.

So, it's primarily for new players (and newbies). Yes, this means all of
those folks that aren't inspired of playing games from the good old unix-
shell or an otherwise fully text-based environment, but who would otherwise
be very keen on getting familiar to the Realm of BatMUD.

While it could perhaps be seen as very intriguing for the development team
to get Everyone behind Batclient (playing BatMUD with Batclient), there is
little reason (in truth) behind such kind of thought. This isn't our goal.
Our secondary goal is to make it as great as a client can be.

Currently, a good portion (20%) of our active players use Batclient. Most
of the newcomers do, even though we do not and will not require for them to
do so. Neither are we going to force our current players to use Batclient
who enjoy to play by whatever means they're used to, be it raw telnet,
tf, ZMUD or whatnot. Of course we want to spread the word about the client,
but there hasn't been any real "campaigns" for people to give up their
preferred habits.

Sure, we love to talk about our client because we do Believe in it,
otherwise we wouldn't be making it-- "and especially not with Java." Many
of us used to breathe Assembler on C-64 or hauled ass with 300bps modems in
the old VAX/VMS environments, or had challenging talks of object oriented C
back in the day with the likes of Lars and Amylaar. Let's face it, Java
just cuts it for this project, Today.

What B.A.T. ry would like to see, is more people involved-- also in the
development of Batclient, at least on the level of helping to sketch new
ideas & features and to inform us of any problems they see or may
encounter. This kind of enthusiastic people; people who have been actively
interested in the development of Batclient so far, have also been responded
to, to the best of our abilities. Many of the wishes we're now seeing in
the threads related to this issue published today are and have been in our
plans all along; while we may lack the resources to pull out everything,
we've performed quite well so far.

Personally, as the Lead dev of the project, I've been balancing between
"adding new features" vs. "player requested enhancements" vs. "getting
bugs or minor fixes in existing functionality sorted out" -type of
prioritization. There's a list for features accepted into development,
which is affectionately labeled as the Feature Track. And yes, it includes
many items that hopefully can be seen alluring by our seasoned players,
too - Why not.

That said, besides that we've already proclaimed the client as "mature
enough" to be used to play BatMUD on a daily basis, we've also reached a
level where our client has become 'pretty good', all in modest terms -
and we're almost constantly improving, or trying our best to do so. It's
always up to Balanced Alternative Techniques ry board for to decide upon
the continuation or possible discontinuation of the project. So far, it
has always given a green light.

Now, one of the features included what emerged as the target health bar
on Batclient, (as a by-product, a kind of "Hey, how cool would this be.")
This feature has been "in-game" since the version v1.50 was released in
November, 2007. If you look back at the Changelog(s) or the web forum for
Batclient, you can see that there is a tremendous amount of new Features
that we have added since the first release of Batclient to attending
players during the BatMUD convention in Las Vegas, Nevada in 2006.

As we develop new Features in the game-client, we are Bound to hit this
kind of problematic situations. We're adding new enhancements to the
client which we hope to make as great as we possibly can with whatever
small resources we have available. One day, we happen to add something
which isn't actually available in-game; which can be seen as an
essential feature. Now the lack of such in-game is bad - and it will be
addressed properly.

Like as said by some of our enlightened players, we're not going to enable
the features of our beloved client for "all the other optional clients", as
we're not going to do free work for the likes as ZMUD, for instance. But as
in this case, we recognize that the data in question should be available
from the game server to all players (who are, naturally, free to do whatever
tunes or tweaks they please to any and all of their favourite clients).

At the same time, we also introduced a different kind of problem which
resulted in us giving HP information out of some encounters that were
designed not to. Also this is being addressed to. Besides that, we had some
issues with the mudside communication due to a difference between belief and
truth behind the code: yes, the accuracy and steps were at 5%.

However, as we develop more we'll also stumble upon more. I'll give you a
couple of examples: for instance, there's some neat @selectedTarget,
@partyTarget and @lastTarget -functionality built into Batclient which
gives the player an opportunity to utilize the function keys (F1-..) or
other bound keys very effectively mixed with other client-side assignations,
or with even more imaginative solutions. Then there's the fact that you can
see and center to your location on the Realm map; and even see your party
members' locations in the outworld as well.

But, it's certainly not our intention to deprive players from using whatever
solution they prefer to play Bat with. At the same time, Gore's comments in
his newspost hit the nail - to be able to evolve, we need to have our
options open rather than restrict ourselves to what is traditional. All the
input you give concerning these matters is valuable and we do want to make
the best out of it as we can. But be reminded, as with most small projects,
we're a bit thin on our resourcing (especially on the spinning-into-motion
-part).

And don't take me wrong, while we're working on Batclient, you're not
obliged to "live with it", you're even entitled to boycott the client, and
flame it; who knows, maybe this will make us work harder for it to find
acceptance...even if, as the end result you'd never install it - it's up to
you, and again principally, your gaming shouldn't suffer for not playing
with Batclient.

...

Maybe this aids to clear the apparent confusion that has been troubling
people for the last couple of days.


Regards,

Amarth Shadowstring