Re: [BTMux-General] Re: What is the biggest obstacle/confusion?

[Greg T. <gt...@CL...>]

On Wednesday 17 August 2005 1:25 pm, Wayne Scott wrote:
> Greg wrote:
> I"m curious to hear what the biggest obstacles are to would-be BTMux
> wizards out there. What intimidates you most about trying to learn
> softcode or start  a MUX? What do you think could be done to improve
> these things? I"m more interested in particular aspects or areas of
> BTMux, not the "I don"t have enough time" type stuff :)
>
>
> Sorry about the delayed reply - I only just subscribed. And sorry for
> the long message - but I figure I'd best make my first post a good
> answer. <g>
>
No problem, better late than never.

> I can't speak for anyone else, obviously, but for what it's worth I'd
> say documentation is a serious problem. More accurately - a lack thereof.
>
Indeed, we're the first group in BTMux to really work towards getting some=
=20
documentation out there and available mainstream. Before now you could lear=
n=20
most of it by word of mouth, but there are only a few code-capable BT admin=
s=20
left and if we should disappear we'd like to make sure there will be others=
=20
to take our place.

> Case in point - I can get the source, compile it, and get a mux running.
> I have done, purely for the purposes of playing around.
>
> I can softcode (adequately - but not well) and began writing a parts
> factory ... just because I wanted to. It wasn't a bad effort (for me).
> THEN I discovered a whole pile of functions which are undocumented
> within the mux. Ooops -  I didn't need to figure out how to do this, or
> that, because there are functions that already do those things.
>
Yes, there actually is now an almost complete list of functions in the=20
softcode section of the wiki. I have not started on the BT functions yet, b=
ut=20
those will also be documented in due time.

> BUT - I know that there is a documentation project underway, which will
> cover that sort of thing, so that aspect is already covered.
>
> What isn't addressed, as far as I know, is the need for HOWTO's and FAQ's.
>
> Here are some examples:
>
> A really amusing one is the fact that the Head Wizard character comes
> with 30/50 bruise 'out of the box'. I haven't devoted any serious time
> to 'healing' that character - but off the bat I have no idea where that
> particular bit of data is stored.
>
That's an oversight on my part. I'll fix this in the next release. But to d=
o=20
it yourself:

think btsetcharvalue(#2,bruise,0,0)

> Or there is wiznews build - Try looking at it as if you had NO previous
> idea on how to setup a hangar or bay. And wiznews hangars refers to a
> command (+movemech), yet grep doesn't find that command in ANY file
> except for wiznews.txt ... which would seem to imply that it doesn't
> exist. <g>
>
That's a leftover from Null's Exile wiznews.txt. This will be rewritten=20
entirely eventually but for now your best bet is always the Wiki.

> Or the intricacies of xcode. How about this one: go into an RB (that's
> the only bay I've set up at the moment) and try to change the value of
> mapwidth for it - it seems that @setxcode mapwidth <num> should do the
> job ... but when I do it I get:
>
> Error: No matching xcode value for this type of object found.
>
> That's something else I haven't looked into yet. But to someone who's
> trying to figure things out - that's kinda confusing.
>
Actually, you'll want to make a map and put the file in your /maps director=
y,=20
then:

loadmap <filename>

I believe this is case sensitive. If you wanted a larger blank map, make a=
=20
larger blank map via Thump/Musemap and use that rather than using @setxcode=
=20
or @setmap.

> Hell - even the critical tasks of (a) setting your RS map and (b)
> creating mechs aren't discussed in wiznews. Certainly those things can
> be figured out - but if you've never been a wiz before they are pretty
> major hurdles to overcome.
>
Indeed, this is a bit down the line though, I am working my way from the=20
foundation up. Documenting commands, functions, and flags, then config=20
parameters, then going into FAQs/HOWTOs. It's a chicken before the egg deal.

> Now this is not meant to be an attack, or a diatribe - I know about
> documentation: it's a lot less interesting than making things work, and
> fixing things that SHOULD work.
>
> It may be that, with the intention of creating a system which can be
> deployed 'out of the box' you guys figure that examples of everything
> will be present and everyone will be able to suss stuff out simply by
> looking and fiddling.
>
> But (and here's my final point, which I'm sure will please everyone who
> got this far <g>) consider just how complex a system a btmux is. If you
> want to get more mux's running, then the complexity needs to be
> explained to the new generation as it were. With only 2 muxes
> operational, serving as an apprentice and learning on a functional mux
> isn't really an option. Better to provide the basics (as btmux in a box
> is working towards) and the distilled knowhow for anyone who cares to
> jump in and see what he can build.
>
Documentation is the single biggest obstacle in our development path at=20
present. Even more so since I'm pretty much the only one writing it. Despit=
e=20
me asking for help from all sorts of sources, I just really never get it. I=
=20
can work hours a day on it (as I often do) and balance that with BTMux in a=
=20
Box and get a relatively little amount of work done each day considering th=
e=20
time invested. The best way to see documentation growing is to get people=20
involved.

It's an extremely easy process for the most part. Just create an account an=
d=20
hit the 'Edit' button for various pages to see how to do things. Read up on=
=20
the MediaWiki editing documentation and dive right in. There's even a chann=
el=20
on the Frontiers for Documentation cleverly named 'Documentation'.

I really want to see some sturdy docs since they've been so lacking in the=
=20
past, but it's going to take me years at the current pace. If people want t=
o=20
step up, we can obviously shorten this by leaps and bounds. But one way or=
=20
another, it will be in good shape some day.