bzflag-dev — BZFlag Developers list

Re: BZFlag debs

[Nafees B. Z. <bin...@mu...>]

or turn 'em into mp3s, and play it through.....  It would kinda suck if you're
low end styling it.  Q3A does that I think......

-n

>
> Perhaps - I understand your reasoning (I myself did not have a sound
> card, the desire to hear what bzflag sound like what sufficient
> compulsion to get one though :) but perhaps a better solution would be
> to convert the audio files to 8 bit (halve the size) or provide
> alternatives.
>
> Also it might make sense for other systems packages to also break out
> the sound files (hence the CC to the dev mailing list). Thoughts?
>
> Anand
>
> _______________________________________________
> Bzflag-dev mailing list
> Bzf...@li...
> http://lists.sourceforge.net/mailman/listinfo/bzflag-dev

Re: BZFlag debs

[Anand K. <wil...@pr...>]

[ posted to bzflag-dev, Erik as this raises some issues ]

On Mon, 27 Mar 2000, Erik wrote:

> On Tue, Mar 28, 2000 at 09:23:27AM +1000, Anand Kumria wrote:
> > 
> > But first, why split out the sounds?
>
> Well, i thought we could split off sounds because the package is ~2M, 1.5M
> of which is sounds, and not all users will want sounds (i thought of
> this because personaly i don't own a soundcard, and thought others
> in the same position might not want to be downloading an extra 1.5M of
> stuff).

Perhaps - I understand your reasoning (I myself did not have a sound
card, the desire to hear what bzflag sound like what sufficient
compulsion to get one though :) but perhaps a better solution would be
to convert the audio files to 8 bit (halve the size) or provide
alternatives.

Also it might make sense for other systems packages to also break out
the sound files (hence the CC to the dev mailing list). Thoughts?

Anand

Re: the README file

[Tim R. <Ti...@Ca...>]

Erik,

Excellent work! Some comments:

Email references to me can be my home address: Ti...@Ri... please.
Web addresses that do not contain a page reference should end is a / as
in http://bzflag.sourceforge.net/ should have the trailing slash.

We should probably expand the section on submitting patches to include
more verbose instructions on creating a "diff" patch file. I emailed the
development list [last week?] with that kind of information. Perhaps I
should put that in web page? Thoughts?

Thanx for the effort!

Erik wrote:
> 
> Well, i was glancing at the README file and i noticed its references to
> the webpage, and its mention of the mailing lists and how to file bugs
> is outdated so i updated it, I'm attaching the fixed version. Any line
> starting with '<' means its a line that was orrigionaly in that i want to
> take out, and line starting with '>' means that the line is a line I added.
> Obviously i will remove the appropriate lines, and all the '<'s and '>'s
> before commiting. :)
> 
> Any corrections?  If i don't get any complaints i'll commit it tomorow night,
> which will probably be about 10PM PST(-0800 GMT)
> 
> I also pondered changing all occurances of the name "bzflag" in the file, not
> refering to the binary to BZFlag.  Does anyone mind if i do that too?
> 
> Erik Bernhardson
> jo...@jp...
-- 
Tim Riker - http://rikers.org/ - short SIGs! <g>
All I need to know I could have learned in Kindergarten
... if I'd just been paying attention.

the README file

[<jo...@jp...>]

Well, i was glancing at the README file and i noticed its references to
the webpage, and its mention of the mailing lists and how to file bugs
is outdated so i updated it, I'm attaching the fixed version. Any line
starting with '<' means its a line that was orrigionaly in that i want to
take out, and line starting with '>' means that the line is a line I added.
Obviously i will remove the appropriate lines, and all the '<'s and '>'s 
before commiting. :)

Any corrections?  If i don't get any complaints i'll commit it tomorow night,
which will probably be about 10PM PST(-0800 GMT)

I also pondered changing all occurances of the name "bzflag" in the file, not
refering to the binary to BZFlag.  Does anyone mind if i do that too?

Erik Bernhardson
jo...@jp...
--
It is better to remain silent and be considered a fool, than to speak and
remove all doubt.
	-- Mark Twain

Re: BZFlag development

[Nafees B. Z. <bin...@mu...>]

Thanks for keeping up the project Tim.  You've done a sweet job managing,
with setting up sourceforge, and migrating the lists.  I hope this
brings a
resurgence of bzflag development activity.

I'll volunteer to maintain bzflag under irix.

Also, can you please add me to the sourceforge bzflag development group.
 My username is: nafees

thanks!

-n

Tim Riker wrote:

> Thanx all for the replies! I am now the maintainer of Bzflag. Chris is
> still involved to whatever extent he wants to be. This means he has
> final word as far as I am concerned. I am looking for platform
> maintainers for those platforms I do not have direct access to. This
> includes Win32 and Irix as well as any others that are not now available
> (Mac anyone?)
>
> I changed the Reply-to: header to point back to the list as suggested by
> Nafees Bin Zafar <bin...@mu...>.
>
> I approved posts from na...@mu... (na...@ac...) and
> go...@lm... (ken...@lm...) which are not the listed
> email entries on the list. I then added these mail addresses with the
> nomail options set so you don't get two copies of the mail messages. ;-)
> This is the new list policy, subscribe with whatever email address you
> have in your From: or Reply-to: field. If you have more than one (as I
> do) subscribe from each one and set "nomail" for all but one. The lists
> are restricted to members only for posting, other mailings go to the
> admin (me at the moment) for approval.
>
> I've setup another mailing list jsut for developers:
>
> http://lists.sourceforge.net/mailman/listinfo/bzflag-dev
>
> To participate as a developer, just join the list, then place patches on
> the web site for review:
>
> http://sourceforge.net/patch/?group_id=3248
>
> I'd love to see the new feature patches up there! Then others will have
> the chance to review them. I'm basically planning to commit the popular
> patches into CVS when I or others have tested them. At some point I will
> be adding more active developers with direct CVS write access. All of
> you have CVS read access. See the CVS repository page for info on how to
> access it:
>
> http://sourceforge.net/cvs/?group_id=3248
>
> Ok, now for the trivia question: is the name bzflag, Bzflag, or BZFlag?
> ;-)
> --
> Tim Riker - http://rikers.org/ - short SIGs! <g>
> All I need to know I could have learned in Kindergarten
> ... if I'd just been paying attention.
>
> _______________________________________________
> Bzflag-users mailing list
> Bzf...@li...
> http://lists.sourceforge.net/mailman/listinfo/bzflag-users

Re: Debian CVS snapshots of bzflag

[Tim R. <Ti...@Ca...>]

Erik,

I copied the developemnt list. You should join... ;-)

Cool! I wonder how this could be hosted on SourceForge as well. We have
100M or so of space, but would need to scp the files probably.

I notice you build the server as a seperate package. Do you then make
the client dependant on the server? If the server is not there, the
client will fail to start the server. ;-)

This is a cron job then that checks out cvs source and rebuilds? Does it
check to see if there are any modifications actually in CVS before it
tries?

I can create a module for the debian package and set you up to check it
in, but I'd also like to support apt-get directly from SourceForge.
Anyone know what is involved in gettting this working?

Can you join SourceForge and mail me your nick there so I can add you to
the project and we'll try some options out?

http://lists.sourceforge.net/mailman/listinfo/bzflag-dev
http://bzflag.sourceforge.net/

Everyone: join journey and I on #bzflag on irc.openproject.net for live
chat sometime!

Erik wrote:
> 
> Hey, this is journey from openprojects :)  Got the cvs snapshots up, should
> update every day at 2am PST, its at http://table.jps.net/~mrosemanza/bzflag
> for now.  I'll see if i can get it moved to bzflag.entropy.net,  but that
> might be a few days.  If not, do you have someplace better to put it?
> the only problem with putting it here is i only have 20M of space to
> put things, so i'm only keeping the tarball for todays snapshot, instead
> of the source tarball for the last 7days(i have it set to keep the last
> 7 days worth of debs).  I dunno how fast development goes on bzflag though,
> so this may be a moot point :)
> 
> Erik Bernhardson
> jo...@jp...
> --
> It is better to remain silent and be considered a fool, than to speak and
> remove all doubt.
>         -- Mark Twain
-- 
Tim Riker - http://rikers.org/ - short SIGs! <g>
All I need to know I could have learned in Kindergarten
... if I'd just been paying attention.

Re: OpenGL bzfls

[Kenneth G. <ken...@lm...>]

Daniel Leonard wrote:

> :Blackened also suggested we add "reflectivity" to the standard teleport
> :gate so that users could see into them to see where they go before
> :entering. a 50/50 mix of black and the view through would be cool.

I don't know about that...  I mean, it's kind of cool to have no idea what's
going to be in front of you when you come out of a teleporter...

Re: OpenGL bzfls

[Daniel L. <le...@IR...>]

This sounds a lot like a feature in a new game from 3DRealms Prey

Let's get it out before they do :)

-------------
Daniel Léonard
Computer Science Student                  "Anything worthwhile takes time"
Université de Montréal                       -Phong in Enzo the Smart, Reboot
http://www.jsp.umontreal.ca/~leonard

:Blackened also suggested we add "reflectivity" to the standard teleport
:gate so that users could see into them to see where they go before
:entering. a 50/50 mix of black and the view through would be cool.

OpenGL bzfls

[Tim R. <Ti...@Ca...>]

Here's a project for someone:

I'd like to add OpenGL server abilities to bzfls such that one could
have a 3d room that had teleporters into all the listed gameservers. The
servers would then have an optional teleporter that went back to the
bzfls server room.

This requires adding player movement and messaging to bzfls. It also
requires the new intra-game teleport gate.

I would not recommend any weapon or flag handling in the game room. I
would recommend we continue to support the text interface as well. Use
that one for the menus and the graphical one for the teleport gates.

Sound cool? ;-)

Blackened also suggested we add "reflectivity" to the standard teleport
gate so that users could see into them to see where they go before
entering. a 50/50 mix of black and the view through would be cool.
-- 
Tim Riker - http://rikers.org/ - short SIGs! <g>
All I need to know I could have learned in Kindergarten
... if I'd just been paying attention.

Re: Posting patches...

[Tim R. <Ti...@Ca...>]

Patches are typically build by installing two source directories and
patching one of them and then running a recursive diff on them. The
command line could be:

diff -Naur bzflag.orig bzflag.my > bzflag.my.patch

where bzflag.my and bzflag.orig are clean, full source trees.

The new patch file will then have multiple sections like:

diff -Naur vnc-3.3.3r1.orig/vnc_unixsrc/vnc.conf
vnc-3.3.3r1/vnc_unixsrc/vnc.conf
--- vnc-3.3.3r1.orig/vnc_unixsrc/vnc.conf       Wed Dec 31 17:00:00 1969
+++ vnc-3.3.3r1/vnc_unixsrc/vnc.conf    Fri Feb 11 15:25:22 2000
@@ -0,0 +1,14 @@

and so on. (actual patch from VNC.. ;-) These are them applied by:

$ cd bzflag
$ patch -p1 < bzflag.my.patch

and then the build goes as normal.

Kenneth Gordon wrote:
> 
> Tim Riker wrote:
> 
> > I'd love to see the new feature patches up there!
> 
> Just out of curiosity, what exactly do you consider a "patch"?  If a
> developer adds a feature that affects a bunch of files, should he (or she!)
> submit just the files that have changed, all the files in a tarball file,
> etc?
> 
> >From the changes I've made, it seems like adding each new flag affects a
> minimum of six files:
> 
>    * include/global.h
>    * src/common/Flag.cxx
>    * src/bzflag/HUDRenderer.cxx
>    * src/bzflag/ShotPath.cxx
>    * src/bzflag/menus.cxx
>    * src/bzfs/bzfs.cxx
> 
> This is just to get everything up and running (including the help menus,
> right-clicking on a tank, the Flag Help that comes up, etc), and this
> doesn't even include adding the new functionality of the flag!!   With the
> number of files that would have to change, it seems to me that tarring
> everything up would certainly make life easiest, but I'm not sure how that
> will affect those poor Microsoft-users out there...  :-)
> 
> -- Ken
> 
> _______________________________________________
> Bzflag-dev mailing list
> Bzf...@li...
> http://lists.sourceforge.net/mailman/listinfo/bzflag-dev

-- 
Tim Riker - http://rikers.org/ - short SIGs! <g>
All I need to know I could have learned in Kindergarten
... if I'd just been paying attention.

Posting patches...

[Kenneth G. <ken...@lm...>]

Tim Riker wrote:

> I'd love to see the new feature patches up there!

Just out of curiosity, what exactly do you consider a "patch"?  If a
developer adds a feature that affects a bunch of files, should he (or she!)
submit just the files that have changed, all the files in a tarball file,
etc?

From the changes I've made, it seems like adding each new flag affects a
minimum of six files:

   * include/global.h
   * src/common/Flag.cxx
   * src/bzflag/HUDRenderer.cxx
   * src/bzflag/ShotPath.cxx
   * src/bzflag/menus.cxx
   * src/bzfs/bzfs.cxx

This is just to get everything up and running (including the help menus,
right-clicking on a tank, the Flag Help that comes up, etc), and this
doesn't even include adding the new functionality of the flag!!   With the
number of files that would have to change, it seems to me that tarring
everything up would certainly make life easiest, but I'm not sure how that
will affect those poor Microsoft-users out there...  :-)


-- Ken

[Bzflag-dev] Re: SourceForge

[Tim R. <Ti...@Ca...>]

Update:

I've copied over the web pages now from the tarball. There were quite a
few pages that sill had references to .html pages which did not exist.
Try clicking on the screenshot on the home page for example. I edited
the source for the pages and s/\.html/.${html}/g them so that the links
would work. That brought out a new problem, man-bzflag has a few ${HOME)
references in it. The first one stops any further macro replacement. I
s/\$(HOME)/$(HOME)/ which really just works around the bug.
Thoughts?

Have you signed up on SourceForge yet? I'd like to have these
conversations on the private development mailing list there. Just mail
me your SourceForge account name and I will add you as an admin.

I addde you to the private list and copied it with this message.
-- 
Tim Riker - http://rikers.org/ - short SIGs! <g>
All I need to know I could have learned in Kindergarten
... if I'd just been paying attention.