Hi all. I think I'm finally getting to grips (thanks especially to a
couple of people around here) with media. Having now sussed to what
degree (approximately) media is affected by scaling I'm about to try
and put together my own "gaseous explosion" macro.

However, were I to simply adjust one of the eamples I've been using to
learn, I'd like to add comments about what I've done and possibly
contact the author. Since most of us don't document what's put up in
these groups tracking down the author responsible can be.. work. How
about including simple documentation in .inc and .mcr files? E.G. a
header along the following lines:
=====================================================
/*---------------------------------------------------------------------------------------------
Title:Asteroid.mcr
Description:Asteroid macro using blobs
Originator:Aubouin <jau### [at] club-internetfr>
Date:22 April 1999

Modified:16 May 1999
Modifier:Cliff Bowman, e-mail address
Modification(s):
Altered macro to use predefined texture if present.

---------------------------------------------------------------------------------------------*/
=====================================================

While the above example is largely fictitious (although it's based on
actual recent experiments I don't plan to use this as more than a
testing ground, and I've excluded e-mail addresses - do e-mail
harvesters frequent these locales?) it might prove useful from time to
time to be able to look up who wrote what of what I'm using.

Of course, one could go further - we could include version numbers in
maco/include files (including a standard way of indicating whether
this is an approved new version or *just* a third party hack), and
allsorts. There would probably come a time, however, where such
documentation would be overbearing - possibly even exceeding the size
of the 'active' portion of the code.

Thoughts and comments please - would I be alone in desiring some brief
"standardised" documentation for macro/include files? If not, what do
you think ought to be included - and how should it be presented?

While I'm at it - who do I ask about adding the ".mcr" extension to
the list of POV files for opening/saving/colour-encoding when editing?


Cheers,

Cliff Bowman
Why not pay my 3D Dr Who site a visit at
http://www.geocities.com/Area51/Dimension/7855/
PS change ".duffnet" to ".net" if replying via e-mail

Post a reply to this message

Macros usually come in two flavours, the Fully Developped Macro and the Quickly-made
Hack.
It seems that the writers of the first type tend to document them already (see Chris
Colefax for
the best example available). Now many people may make some quick & dirty macros as an
answer to
someone's question, and these macros may be very interesting but difficult to document
due to their
on-the-fly, short-lived status. Personnally I document my "big" macros,  give them
version numbers,
try to credit the people who wrote some code I'm using (though I have no standard way
to do it). I
also provide working examples whenever possible, which could be another requirement
for macro
diffusion.

Gilles Tran

Cliff Bowman wrote:

> Of course, one could go further - we could include version numbers in
> maco/include files (including a standard way of indicating whether
> this is an approved new version or *just* a third party hack), and
> allsorts. There would probably come a time, however, where such
> documentation would be overbearing - possibly even exceeding the size
> of the 'active' portion of the code.
>
> Thoughts and comments please - would I be alone in desiring some brief
> "standardised" documentation for macro/include files? If not, what do
> you think ought to be included - and how should it be presented?
>
> While I'm at it - who do I ask about adding the ".mcr" extension to
> the list of POV files for opening/saving/colour-encoding when editing?
>
> Cheers,
>
> Cliff Bowman
> Why not pay my 3D Dr Who site a visit at
http://www.geocities.com/Area51/Dimension/7855/
> PS change ".duffnet" to ".net" if replying via e-mail

Post a reply to this message

On Tue, 25 May 1999 20:16:01 +0200, Gilles Tran <tra### [at] inapginrafr>
wrote:

>Macros usually come in two flavours, the Fully Developped Macro and the Quickly-made
Hack.
>It seems that the writers of the first type tend to document them already (see Chris
Colefax for
>the best example available).

Aren't they just though? Especially since he started providing HTML
docs for the files. The next step on would (I'd have thought) be to
supply sample code that generates images used by the documenting HTML
code (so the docs could *show* what they're talking about but without
having to bloat the .zip files with lots of images).

> Now many people may make some quick & dirty macros as an answer to
>someone's question, and these macros may be very interesting but difficult to
document due to their
>on-the-fly, short-lived status. Personnally I document my "big" macros,  give them
version numbers,
>try to credit the people who wrote some code I'm using (though I have no standard way
to do it). I
>also provide working examples whenever possible, which could be another requirement
for macro
>diffusion.
>
I think the two macros which prompted my comments were halfway houses
- an asteroid macro and H.E.Day's explosion macro. Maybe not as fully
developed as Chris Colefax's stuff - more llike Micro$oft "final
release candidate" stage" <eg>. Which reminds me - I really must peek
at the asteroid code and learn a bit from it.


Cheers,

Cliff Bowman
Why not pay my 3D Dr Who site a visit at
http://www.geocities.com/Area51/Dimension/7855/
PS change ".duffnet" to ".net" if replying via e-mail

Post a reply to this message