Aleph One: Marathon Open Source

Drew:

B&B was just a quick hack - and those are words from Ian himself. You took 
it for granted and now you're dissapointed because it's not going to happen. 
That's no good reason for trashing your scenario. I think I talk for 
everyone else when I say that we'll play Flatline whenever it got B&B on it 
or not.

REB

>From: SigfriedXX@...
>To: marathon-devel@...
>Subject: [M-dev]A request that no one cares about anyways
>Date: Mon, 16 Dec 2002 19:48:40 EST
>
>well, for about the past five mails I've sent to the list I have asked that
>someone make a build of the current AO source, and the old B&B code so that
>bridges can be made.
>
>Obviously no one cares aboutB&B anymore and frankley I'm getting slightly
>tired at waiting for AO to update or for anyone to respond to my mails.
>
>Many will be rejoiced to hear that the 200 hi-res textures, new weapons and
>new enemies and music made for my scenario FLATLINE will go to waste, for 
>is
>no one replies to this or is willing to take inios old source of B&B and 
>put
>it into a new build with all the currewnt features, then I'm just gonna 
>kill
>the project.
>
>I hate to rant but I just dont want to wait anymore, since everything is
>done, except for AO.
>
>if your interested in helping, please mail me.
>
>-Drew


_________________________________________________________________
The new MSN 8: smart spam protection and 2 months FREE*  
http://join.msn.com/?page=features/junkmail

I'm confused. B&B a quick hack-so what!? Why was it removed? I don't understand why everyone speaks of it as a long-gone feature that everyone would absolutely HATE to see re-implemented. I know that it's a lot of trouble to use MML scripting to add 3D elements to a level (which aren't even true 3D type stuff anyway... no slanted polys, for example)-so what? Why shouldn't they have the option to add these elements to their maps anyway? Isn't anyone interested in adding this feature again? What's with everybody?

James Smith


>Drew:
>
>B&B was just a quick hack - and those are words from Ian himself. You took 
>it for granted and now you're dissapointed because it's not going to happen. 
>That's no good reason for trashing your scenario. I think I talk for 
>everyone else when I say that we'll play Flatline whenever it got B&B on it 
>or not.
>
>REB
>
>>From: SigfriedXX@...
>>To: marathon-devel@...
>>Subject: [M-dev]A request that no one cares about anyways
>>Date: Mon, 16 Dec 2002 19:48:40 EST
>>
>>well, for about the past five mails I've sent to the list I have asked that
>>someone make a build of the current AO source, and the old B&B code so that
>>bridges can be made.
>>
>>Obviously no one cares aboutB&B anymore and frankley I'm getting slightly
>>tired at waiting for AO to update or for anyone to respond to my mails.
>>
>>Many will be rejoiced to hear that the 200 hi-res textures, new weapons and
>>new enemies and music made for my scenario FLATLINE will go to waste, for 
>>is
>>no one replies to this or is willing to take inios old source of B&B and 
>>put
>>it into a new build with all the currewnt features, then I'm just gonna 
>>kill
>>the project.
>>
>>I hate to rant but I just dont want to wait anymore, since everything is
>>done, except for AO.
>>
>>if your interested in helping, please mail me.
>>
>>-Drew
>
>
>_________________________________________________________________
>The new MSN 8: smart spam protection and 2 months FREE*  
>http://join.msn.com/?page=features/junkmail
>
>
>
>-------------------------------------------------------
>This sf.net email is sponsored by:
>With Great Power, Comes Great Responsibility 
>Learn to use your power at OSDN's High Performance Computing Channel
>http://hpc.devchannel.org/
>_______________________________________________
>Marathon-devel mailing list
>Marathon-devel@...
>https://lists.sourceforge.net/lists/listinfo/marathon-devel
>

__________________________________________________________________
The NEW Netscape 7.0 browser is now available. Upgrade now! http://channels.netscape.com/ns/browsers/download.jsp 

Get your own FREE, personal Netscape Mail account today at http://webmail.netscape.com/

On Tuesday, December 17, 2002, at 08:20  PM, James Smith wrote:

> I'm confused. B&B a quick hack-so what!? Why was it removed? I don't  
> understand why everyone speaks of it as a long-gone feature that  
> everyone would absolutely HATE to see re-implemented. I know that it's  
> a lot of trouble to use MML scripting to add 3D elements to a level  
> (which aren't even true 3D type stuff anyway... no slanted polys, for  
> example)-so what? Why shouldn't they have the option to add these  
> elements to their maps anyway? Isn't anyone interested in adding this  
> feature again? What's with everybody?
>
> James Smith

B&B was never removed from the main source tree. It was never worked in  
to begin with.

This is why it's been so hard to reimplement. And with the way  
AlephOne's code was reorganized into it's current directory structure,  
it lost all of the historical ties to the files. So I can't exactly say  
'Show me the B&B code, show me the current code and show me the point  
in time when the files split.'

It's one of the reasons I'm trying to be real anal with how  
AlephModular's CVS hierarchy is handled, especially at the time when  
the files will need to be reorganized. I actually did try to work some  
of Inio's code into the A1 code base, only to later learn that it  
wasn't the B&B code. D'oh!

-Jeremy Parsons
--------------------- 
+------------------------------------------------------
Br'fin               |      TIMSter, MU*er, Web Programmer, ... Insane?
The Denim Warrior    |                  You be the judge...
brefin@...       |
--------------------- 
+------------------------------------------------------

On 18-12-02 05:18, "Br'fin" <brefin@...> wrote:

> 
> On Tuesday, December 17, 2002, at 08:20  PM, James Smith wrote:
> 
>> I'm confused. B&B a quick hack-so what!? Why was it removed? I don't
>> understand why everyone speaks of it as a long-gone feature that
>> everyone would absolutely HATE to see re-implemented. I know that it's
>> a lot of trouble to use MML scripting to add 3D elements to a level
>> (which aren't even true 3D type stuff anyway... no slanted polys, for
>> example)-so what? Why shouldn't they have the option to add these
>> elements to their maps anyway? Isn't anyone interested in adding this
>> feature again? What's with everybody?
>> 
>> James Smith
> 
> B&B was never removed from the main source tree. It was never worked in
> to begin with.
> 
> This is why it's been so hard to reimplement. And with the way
> AlephOne's code was reorganized into it's current directory structure,
> it lost all of the historical ties to the files. So I can't exactly say
> 'Show me the B&B code, show me the current code and show me the point
> in time when the files split.'
> 
> It's one of the reasons I'm trying to be real anal with how
> AlephModular's CVS hierarchy is handled, especially at the time when
> the files will need to be reorganized. I actually did try to work some
> of Inio's code into the A1 code base, only to later learn that it
> wasn't the B&B code. D'oh!
> 
> -Jeremy Parsons
> ---------------------

I don't know much about programming, but what about actually trying. I'm
sorry for being rude, but I've got a scenario on hold just waiting for B&B.
I was hoping to get B&B actually working. Or do I have to use another
engine? The reason I'm into Aleph One is because I love marathon. And I
would love it even more with B&B.

-GSchjetne, Norway

On Wednesday, December 18, 2002, at 10:30  AM, GSchjetne wrote:

> On 18-12-02 05:18, "Br'fin" <brefin@...> wrote:
>
>> B&B was never removed from the main source tree. It was never worked in
>> to begin with.
>
> I don't know much about programming, but what about actually trying. I'm
> sorry for being rude, but I've got a scenario on hold just waiting for 
> B&B.
> I was hoping to get B&B actually working. Or do I have to use another
> engine? The reason I'm into Aleph One is because I love marathon. And I
> would love it even more with B&B.

I think each developer here brings his (her) own interests and expertise 
to the show.  B&B is a sizeable endeavor, not to be undertaken lightly.  
AFAIK the only person with the combination of interest and expertise to 
try it was Ian Rickard, and he didn't manage to finish it.  I have a 
feeling it will probably be absent until some other (probably new) 
developer comes along and feels it would be fun to do for him (her).

I think it's clear that many scenario authors would be excited to see 
B&B support, but it's also clear that none of the current developers is 
currently sufficiently interested in working through the weeks of 
planning and coding to implement it, no matter how many people write in 
and request it how many times.

OTOH I've been excited to see recently that maybe I'm not the only one 
who thinks netplay is important to Marathon - so I think it's good that 
people have been talking about that; it's definitely an encouragement to 
check into it.  After the IP-LAN stuff I was disappointed that only a 
couple people ever seemed to use it.  But as I've noted this is probably 
because there are apparently some problems with netplay support in A1 on 
the Mac platform at the moment.  (Certainly, it doesn't work in Classic, 
and probably won't anytime soon, but it "ought" to work in Carbon, at 
least, though it seems there are some problems even with that.  Seems to 
work fine on Windows (except Win2k apparently), A1/SDL for Mac OS X, and 
Linux, as I understand it...)

I think efforts like AlephModular will help make sure that netplay is 
free of sync-errors (the type of errors we're seeing these days with 
Carbon and apparently with Windows 2000).  In the meantime, I was 
excited to see some progress toward AlephOne/SDL on Mac OS X again.  I'm 
pretty sure netplay works fine in that version - it was one of the 
platforms I tested on in the development of IPring.  Now we just need to 
see an official release.  Sure, there are some rough edges GUI-wise etc. 
compared to A1/Carbon, but if it works for netplay, I think folks would 
probably want to be able to fire it up for a netgame, and use A1/Carbon 
for their single-player games.  This is not to suggest that netplay 
shouldn't be fixed in A1/Carbon, but as a workaround in the meantime.....

I *would* like to hunt down the source of the sync-errors in the current 
Win2k and Carbon versions (especially now that it seems people actually 
*care*), but am pretty busy what with the holiday season and also 
another project taking most of my coding time.  I don't have any Win2k 
machines around, but I do have a couple Carbon machines, and one of them 
has 10.2 and now the 10.2 dev tools so I might actually be able to build 
the Carbon from CVS.  So just maybe.......

Woody

"Br'fin" <brefin@...> wrote:

>
>On Tuesday, December 17, 2002, at 08:20  PM, James Smith wrote:
>
>> I'm confused. B&B a quick hack-so what!? Why was it removed? I don't  
>> understand why everyone speaks of it as a long-gone feature that  
>> everyone would absolutely HATE to see re-implemented. I know that it's  
>> a lot of trouble to use MML scripting to add 3D elements to a level  
>> (which aren't even true 3D type stuff anyway... no slanted polys, for  
>> example)-so what? Why shouldn't they have the option to add these  
>> elements to their maps anyway? Isn't anyone interested in adding this  
>> feature again? What's with everybody?
>>
>> James Smith
>
>B&B was never removed from the main source tree. It was never worked in  
>to begin with.
>
>This is why it's been so hard to reimplement. And with the way  
>AlephOne's code was reorganized into it's current directory structure,  
>it lost all of the historical ties to the files. So I can't exactly say  
>'Show me the B&B code, show me the current code and show me the point  
>in time when the files split.'
>
>It's one of the reasons I'm trying to be real anal with how  
>AlephModular's CVS hierarchy is handled, especially at the time when  
>the files will need to be reorganized. I actually did try to work some  
>of Inio's code into the A1 code base, only to later learn that it  
>wasn't the B&B code. D'oh!
>
>-Jeremy Parsons

Thanks Jeremy! Now I understand. You see, I never used B&B to begin with... it just sounded like a cool feature to me-and it is, but if it's hard to implement, then maybe time shouldn't be devoted to it. Hmmm.. now that I think of it, perhaps B&B should be ressurected in a re-written form? Is this way too much trouble to deal with? I'd like to know the group's opinions on this.


James Smith

Cyber Aug: The Conspiracy

First Quarter 2003

__________________________________________________________________
The NEW Netscape 7.0 browser is now available. Upgrade now! http://channels.netscape.com/ns/browsers/download.jsp 

Get your own FREE, personal Netscape Mail account today at http://webmail.netscape.com/

>... no slanted polys, for  
> >> example)-so what? Why shouldn't they have the
> option to add these  
> >> elements to their maps anyway? Isn't anyone
> interested in adding this  
> >> feature again? What's with everybody?
> >>
> >> James Smith
> >
> >B&B was never removed from the main source tree. It
> was never worked in  
> >to begin with.
> >
> >This is why it's been so hard to reimplement. And
> with the way  
> >AlephOne's code was reorganized into it's current
> directory structure,  
> >it lost all of the historical ties to the files. So
> I can't exactly say  
> >'Show me the B&B code, show me the current code and
> show me the point  
> >in time when the files split.'
> >
> >It's one of the reasons I'm trying to be real anal
> with how  
> >AlephModular's CVS hierarchy is handled, especially
> at the time when  
> >the files will need to be reorganized. I actually
> did try to work some  
> >of Inio's code into the A1 code base, only to later
> learn that it  
> >wasn't the B&B code. D'oh!
> >
> >-Jeremy Parsons
> 
> Thanks Jeremy! Now I understand. You see, I never
> used B&B to begin with... it just sounded like a
> cool feature to me-and it is, but if it's hard to
> implement, then maybe time shouldn't be devoted to
> it. Hmmm.. now that I think of it, perhaps B&B
> should be ressurected in a re-written form? Is this
> way too much trouble to deal with? I'd like to know
> the group's opinions on this.

We could build something like the exlusion zone for
the models that would act 3D, so you could walk on
slopes where the visual part would be created by 3D
models.  I don't know about the monster AI with
this...
I just recently looked at the exlusion zone code in
"map.cpp", and it is vast and difficult to understand,
so this idea might not go over to well...

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

On Wednesday, December 18, 2002, at 07:48 , AP wrote:

> We could build something like the exlusion zone for
> the models that would act 3D, so you could walk on
> slopes where the visual part would be created by 3D
> models.  I don't know about the monster AI with
> this...
> I just recently looked at the exlusion zone code in
> "map.cpp", and it is vast and difficult to understand,
> so this idea might not go over to well...

Kill the exclusion zones.  Exclusion zones are brain-damaged.  Best to 
rewrite that part from scratch if you ask me.

I must confess my ignorance in some of these matters,
but I think there may be a way to get B&B'ish stuff. 
There are several senery objects that have physical
space.  There once was a map (I wish I could find it)
that exployted this to make a balcony.  In profile it
looked something like this (you will need a
mono-spaced font to see this):

       |
     0 |
    -+-|
  =  | |
  = / \|
      ++
    0 |  
   -+-|  
    | |  
   / \|  

Where the "=="s is the scienery object.  Everything
else is players and walls.  The scenery object keeps
the player up agains a very narrow toe-hold ledge that
keeps him suspended above the floor.  Now if we could
take the same idea but use it vertically we could do
something like this:

         0        
        -+-       
         |        
        / \       
--+ ========== +--
  |      0     |  
  |     -+-    |  
  |      |     |  
  |     / \    |  

Where the "=="s are again a scenery object that is
very long and not very tall.  Getting wall textures on
it might be difficult, but something like this would
be a good start.  This idea wont work with the
existing code.  The existing code only does collitions
horizontally with scenery objects, but if vertical
collisions were added then it would work.  Rendering
wise it would be little cost, I think the existing
rendering code works, just the physics code would need
to be tweaked.

So in summary let me ask: How hard would it be to add
virtical collition to scenery objects?  It doesn't
have to be anything fancy ("true" 3D scenery objects
need not apply) just a cylinder, box or prisim (floor
poly + top/bottom) collition would work.

Personally, I've always wanted to be able to jump on
top of a Juggernaut and ride it.  It would make for
some interesting possibilities in net play.

Michael D. Adams
mdmkolbe@...

Other musings that may be relavent or not:
The A1 map is basicly addative in nature.  Every
polygon adds to the occupiable space.  What is
proposed above is basically a substractive extention. 
Is specifies a space that you *can't* occupy.  OTOH,
maybe a better way would be to make it so that a poly
can have two or more sets of ceiling and floor
heights.  OTOOH, that would require changing the map
format or adding some map data to MML.  I really don't
like the idea of having map data split up into both
the MML and the WAD file.  I don't know.  The
developers would know better how easy what choice
would be.


--- AP <daedheadap9@...> wrote:
> >... no slanted polys, for  
> > >> example)-so what? Why shouldn't they have the
> > option to add these  
> > >> elements to their maps anyway? Isn't anyone
> > interested in adding this  
> > >> feature again? What's with everybody?
> > >>
> > >> James Smith
> > >
> > >B&B was never removed from the main source tree.
> It
> > was never worked in  
> > >to begin with.
> > >
> > >This is why it's been so hard to reimplement. And
> > with the way  
> > >AlephOne's code was reorganized into it's current
> > directory structure,  
> > >it lost all of the historical ties to the files.
> So
> > I can't exactly say  
> > >'Show me the B&B code, show me the current code
> and
> > show me the point  
> > >in time when the files split.'
> > >
> > >It's one of the reasons I'm trying to be real
> anal
> > with how  
> > >AlephModular's CVS hierarchy is handled,
> especially
> > at the time when  
> > >the files will need to be reorganized. I actually
> > did try to work some  
> > >of Inio's code into the A1 code base, only to
> later
> > learn that it  
> > >wasn't the B&B code. D'oh!
> > >
> > >-Jeremy Parsons
> > 
> > Thanks Jeremy! Now I understand. You see, I never
> > used B&B to begin with... it just sounded like a
> > cool feature to me-and it is, but if it's hard to
> > implement, then maybe time shouldn't be devoted to
> > it. Hmmm.. now that I think of it, perhaps B&B
> > should be ressurected in a re-written form? Is
> this
> > way too much trouble to deal with? I'd like to
> know
> > the group's opinions on this.
> 
> We could build something like the exlusion zone for
> the models that would act 3D, so you could walk on
> slopes where the visual part would be created by 3D
> models.  I don't know about the monster AI with
> this...
> I just recently looked at the exlusion zone code in
> "map.cpp", and it is vast and difficult to
> understand,
> so this idea might not go over to well...
> 
> __________________________________________________
> Do you Yahoo!?
> Yahoo! Mail Plus - Powerful. Affordable. Sign up
> now.
> http://mailplus.yahoo.com
> 
> 
>
-------------------------------------------------------
> This SF.NET email is sponsored by: Order your
> Holiday Geek Presents Now!
> Green Lasers, Hip Geek T-Shirts, Remote Control
> Tanks, Caffeinated Soap,
> MP3 Players,  XBox Games,  Flying Saucers,  WebCams,
>  Smart Putty.
> T H I N K G E E K . C O M      
> http://www.thinkgeek.com/sf/
> _______________________________________________
> Marathon-devel mailing list
> Marathon-devel@...
>
https://lists.sourceforge.net/lists/listinfo/marathon-devel


__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

>I'm confused. B&B a quick hack-so what!? Why was it removed?
>>B&B was just a quick hack - and those are words from Ian himself. You
>>took 

this brings up a question I've been meaning to ask for a while, B&B was
dead before I found aleph, so everything I know about it has come in
bits and pieces...

exactly what _was_ B&B anyway? what features did it add to the engine,
or what restrictions did it remove? it obviously had something to do
with bridges (hence the title), but to what extent?

and to repeat james' question: why was it removed?

-- 
Quartz
--
"It's been a strange day... 
 it wasn't even a '2+2=5' kind of day,
 more like '2+2= ...fish'."
--
http://www.sneakertech.com
--

On Thursday, December 19, 2002, at 06:58  AM, Quartz wrote:

>> I'm confused. B&B a quick hack-so what!? Why was it removed?
>>> B&B was just a quick hack - and those are words from Ian himself. You
>>> took
>
> this brings up a question I've been meaning to ask for a while, B&B was
> dead before I found aleph, so everything I know about it has come in
> bits and pieces...
>
> exactly what _was_ B&B anyway? what features did it add to the engine,
> or what restrictions did it remove? it obviously had something to do
> with bridges (hence the title), but to what extent?
>
> and to repeat james' question: why was it removed?
>

B&B, bridges and balconies.

It allowed you to have multiple portals on one side of a polygon. thus  
allowing you to have on that side low wall+adjacent polygon+middle  
wall+adjacent polygon+high wall. Instead of the typical marathon trick  
of inserting a pillar in one room so another could overlook it, you  
could just have a free standing bridge.

Does source.marathon.org still have the screen shots showing off B&B?  
Some amazing looking things. Honestly, it's easy to see the promise B&B  
had.

B&B was never removed. Inio coded it, and I even believe his source may  
still be around somewhere for the 'hacked' version of B&B. It used an  
earlier checkout of AlephOne though, before one of the reorganizations,  
which makes it difficult to integrate. (I don't know which code is  
Marathon, which code are AO's fixes to the marathon code and which are  
B&B's code changes very well)

In general, the onus of submitting code lies in the code's originator  
to integrate it with the main CVS tree and then offer a patch to those  
who check it in. In this case I think the originator wanted to redo B&B  
right instead of hacked, and then lost interest for whatever reason. So  
no B&B in AO proper, alas.

--------------------- 
+------------------------------------------------------
Br'fin               |      TIMSter, MU*er, Web Programmer, ... Insane?
The Denim Warrior    |                  You be the judge...
brefin@...       |
--------------------- 
+------------------------------------------------------

On Wednesday, December 18, 2002, at 11:43  PM, Michael Adams wrote:
> There once was a map (I wish I could find it)
> that exployted this to make a balcony.  In profile it
> looked something like this (you will need a
> mono-spaced font to see this):
  ...
>   The scenery object keeps
> the player up agains a very narrow toe-hold ledge that
> keeps him suspended above the floor.

Actually I think there was a tiny overhang on the "outer" side of the 
top player. It kept him from moving outwards. The scenery objects did 
nothing. It's been a while since I saw that map tutorial (the author 
explained how he did it, I think it's about two links away from s.b.o's 
mapmaking info page), but I think it was something like this, indicated 
by >>>
(monospace)

     +---+
 >>> | 0 |
      -+-|
    =  | |
    = / \|
        ++
      0 |
     -+-|
      | |
     / \|

However, it COULD have been done with solid scenery objects. But there 
were no solid scenery objects sufficiently short to make the effect 
look cool.

Joe Auricchio ~ avarame@...

On Thursday, December 19, 2002, at 06:12 , Br'fin wrote:

> B&B, bridges and balconies.
>
> It allowed you to have multiple portals on one side of a polygon. thus  
> allowing you to have on that side low wall+adjacent polygon+middle  
> wall+adjacent polygon+high wall. Instead of the typical marathon trick  
> of inserting a pillar in one room so another could overlook it, you  
> could just have a free standing bridge.

Not precisely, and I would like to clarify.  You could stack polygons, 
essentially giving them more than one set of floor and ceiling, but each 
polygon so stacked must be of the same geometry of those above or below 
it.

>It allowed you to have multiple portals on one side of a polygon. thus 

ok, that's what I thought.

>B&B was never removed. Inio coded it, and I even believe his source may

assuming I understand this right, it wasn't that there was an inherent
problem in the B&B code that prevented it from working properly, just
that it was never integrated into the codebase and therefore is
difficult to work with post-hence?

-- 
Quartz
--
"It's been a strange day... 
 it wasn't even a '2+2=5' kind of day,
 more like '2+2= ...fish'."
--
http://www.sneakertech.com
--

On Tue, 17 Dec 2002, Br'fin wrote:

> On Tuesday, December 17, 2002, at 08:20 PM, James Smith wrote:
>
> > I'm confused. B&B a quick hack-so what!? Why was it removed? I don't
> > understand why everyone speaks of it as a long-gone feature that
> > everyone would absolutely HATE to see re-implemented. I know that it's
> > a lot of trouble to use MML scripting to add 3D elements to a level
> > (which aren't even true 3D type stuff anyway... no slanted polys, for
> > example)-so what? Why shouldn't they have the option to add these
> > elements to their maps anyway? Isn't anyone interested in adding this
> > feature again? What's with everybody?

> B&B was never removed from the main source tree. It was never worked in
> to begin with.
>
> This is why it's been so hard to reimplement. And with the way
> AlephOne's code was reorganized into it's current directory structure,
> it lost all of the historical ties to the files. So I can't exactly say
> 'Show me the B&B code, show me the current code and show me the point in
> time when the files split.'

OK, her's what I don't get: B&B is a quick hack, right? In fact, Inio said
he did the first version in a day, right? So why doesn't someone just
re-implement it?!?! It seems to be one of the most-requested features, and
it also seems more feasible than fixing networking or one of the other
"core" featuers. I think getting some sort of B&B working would really do
a lot for the project's image, which is not that hot in the Marathon
community.
-- 
    __                        __
   /  )                      /  )
  /--/ __.  __  ________    /  / __. , __o  _  _
 /  (_(_/|_/ (_(_) / / <_  /__/_(_/|_\/ <__</_/_)_

On Saturday, December 21, 2002, at 10:37 , Aaron Guy Davies wrote:

> OK, her's what I don't get: B&B is a quick hack, right? In fact, Inio 
> said
> he did the first version in a day, right? So why doesn't someone just
> re-implement it?!?! It seems to be one of the most-requested features, 
> and
> it also seems more feasible than fixing networking or one of the other
> "core" featuers. I think getting some sort of B&B working would really 
> do
> a lot for the project's image, which is not that hot in the Marathon
> community.

<abestos>

Basic B&B was a quick hack... emphasis on *hack*, doubly and trebly so.  
Hack means lack of elegance.  The B&B "hack" code was ugly and didn't 
work as well as you might think.  A working version required a total 
rewrite of the collision code.  Read that again: total rewrite.  We nead 
a friggin FAQ.

Inio's code had a complete rewrite.  Yes, but it was a rewrite of old 
code, which is incombatable with new code, which is all C++ & STL which 
is possibly the worst widely-spread language in use today.  Apologies to 
Loren et al., but although the new code is more flexible and adds many 
features, the STL bits are brain-damaged, and the concept of template 
classes is even more so, and I hope I'm not the only one who thinks so 
(else computerdom descends the abyss).

</abestos>

> We nead a friggin FAQ.

This is what source.bungie.org is for, right? Is Jesse watching?

> Inio's code had a complete rewrite.  Yes, but it was a rewrite of old 
> code, which is incombatable with new code, which is all C++ & STL 
> which is possibly the worst widely-spread language in use today.  
> Apologies to Loren et al., but although the new code is more flexible 
> and adds many features, the STL bits are brain-damaged, and the 
> concept of template classes is even more so, and I hope I'm not the 
> only one who thinks so (else computerdom descends the abyss).

You're not the only one... Objective-C is so much better than C++ it's 
not funny. Too bad Cocoa is not cross-platform at all.

--Mark

"I would feel infinitely more comfortable in your presence if you would 
agree to treat gravity as a law, rather than one of a number of 
suggested options."

On Sunday, December 22, 2002, at 09:57 , Mark Levin wrote:

>> We nead a friggin FAQ.
>
> This is what source.bungie.org is for, right? Is Jesse watching?
>
>> Inio's code had a complete rewrite.  Yes, but it was a rewrite of old 
>> code, which is incombatable with new code, which is all C++ & STL 
>> which is possibly the worst widely-spread language in use today.  
>> Apologies to Loren et al., but although the new code is more flexible 
>> and adds many features, the STL bits are brain-damaged, and the 
>> concept of template classes is even more so, and I hope I'm not the 
>> only one who thinks so (else computerdom descends the abyss).
>
> You're not the only one... Objective-C is so much better than C++ it's 
> not funny. Too bad Cocoa is not cross-platform at all.

Heard of GNUStep?  There are many applications that will run on Cocoa as 
well as Linux with little to zero modification.  Plus, Objective C isn't 
anything more than a language really (except you're crippled without 
runtime libraries, of course).

> Heard of GNUStep?  There are many applications that will run on Cocoa 
> as well as Linux with little to zero modification.  Plus, Objective C 
> isn't anything more than a language really (except you're crippled 
> without runtime libraries, of course).

Cocoa left GNUStep (and OpenStep/WebObjects) in the dust a long time 
ago. I don't know the specifics, but that's what I gather from 
everywhere else.

--Mark

"In the beginning, there was nothing, which exploded."

On Sunday, December 22, 2002, at 11:57  AM, Mark Levin wrote:
> You're not the only one... Objective-C is so much better than C++ it's 
> not funny. Too bad Cocoa is not cross-platform at all.

http://www.gnustep.org/

On Sunday, December 22, 2002, at 05:09  PM, Alexander Strange wrote:

>
> On Sunday, December 22, 2002, at 11:57  AM, Mark Levin wrote:
>> You're not the only one... Objective-C is so much better than C++ 
>> it's not funny. Too bad Cocoa is not cross-platform at all.
>
> http://www.gnustep.org/

OK, I was wrong about how advanced GNUstep was, but still, without a 
mature nib file equivalent or Carbon it is still significantly less 
powerful than Mac OS X-specific ObjC.

--Mark

"There is nothing so absurd that some philospher has not said it."

On Sunday, December 22, 2002, at 05:30 , Mark Levin wrote:

>
> On Sunday, December 22, 2002, at 05:09  PM, Alexander Strange wrote:
>
>>
>> On Sunday, December 22, 2002, at 11:57  AM, Mark Levin wrote:
>>> You're not the only one... Objective-C is so much better than C++ 
>>> it's not funny. Too bad Cocoa is not cross-platform at all.
>>
>> http://www.gnustep.org/
>
> OK, I was wrong about how advanced GNUstep was, but still, without a 
> mature nib file equivalent or Carbon it is still significantly less 
> powerful than Mac OS X-specific ObjC.

Still, GNUStep is no toy.  Although not as advanced as Cocoa, many 
applications can be ported with little hassle from one to the other.

I suggest a compromise implementation of B&B: keep it, but only as a 
rendering feature. One can see it, but one cannot walk on it, one can 
pass through it, and the same will be true of all the NPC's.

>   I suggest a compromise implementation of B&B: keep it, but only as a 
>rendering feature. One can see it, but one cannot walk on it, one can 
>pass through it, and the same will be true of all the NPC's.

define "pass through it" and "cannot walk on it".

is this like what would happen if you tried to fake a catwalk by using
the surface of a liquid? do you mean that, of any stacked 'floors' in a
poly cluster, that only the bottom-most floor would be somethign you
could walk on?

or is this somethign where you'd be prevented from even entering those
polys in the first place? that all lines bordering this area would
automatically become solid?


how 'bout this- what would happen in these given situations:

1) I take 'waldo world arena' and add a bridge that connects the upper
ledges together. what would happen if I tried to walk across this
bridge? what would happen if I tried to walk under it?

2) I have an tall wall on some level, and there's a hallway with a low
ceiling connected to this wall. I add an awning/overhang above the
opening, sticking out from the wall. what would happen if I tried to
walk under this overhang and into the hall?

3) I have a room with a fence in it, stretching across the room from
opposite walls. the fence is a wide slat about a foot off the floor and
a foot from the ceiling. what would happen if I tried to walk through
this?

4) I have any of these situations (the bridge, overhang, fence) and I
take out my rocket launcher. what would happen if I fired some rockets
at these?



I have another question re:b&b-
I know, originally, all polys in a stack had to be the same shape and
size.. what was the reason fo this, and would we still have that
limitation?

-- 
Quartz
--
"It's been a strange day... 
 it wasn't even a '2+2=5' kind of day,
 more like '2+2= ...fish'."
--
http://www.sneakertech.com
--

> define "pass through it" and "cannot walk on it".

The suggestion appears to be that only the rendering part of B&B be 
added, without updating the physics and AI systems, so that it would be 
impossible to interact with it.

> 1) I take 'waldo world arena' and add a bridge that connects the upper
> ledges together. what would happen if I tried to walk across this
> bridge? what would happen if I tried to walk under it?

You'd be able to walk under the bridge fine, but you'd fall through it 
if you tried to walk over it.

> 2) I have an tall wall on some level, and there's a hallway with a low
> ceiling connected to this wall. I add an awning/overhang above the
> opening, sticking out from the wall. what would happen if I tried to
> walk under this overhang and into the hall?

Nothing, that would work fine.

> 3) I have a room with a fence in it, stretching across the room from
> opposite walls. the fence is a wide slat about a foot off the floor and
> a foot from the ceiling. what would happen if I tried to walk through
> this?

You'd probably pass right through it.

> 4) I have any of these situations (the bridge, overhang, fence) and I
> take out my rocket launcher. what would happen if I fired some rockets
> at these?

The rocket would pass right through it as well.

> I have another question re:b&b-
> I know, originally, all polys in a stack had to be the same shape and
> size.. what was the reason fo this, and would we still have that
> limitation?

I don't completely understand it, but it had to do with the way it was 
integrated into the existing code and map format (B&B was done by 
adding MML to a forge-made map). I guess that requirement allowed Inio 
to take some shortcuts and made his job easier. Remember that B&B was 
not a complete upgrade to true 3D geometry specification, it added some 
very specific and limited (although quite flexible and powerful when 
used by a creative human author) features to the existing 2.5D map 
system.

--Mark

"I would feel infinitely more comfortable in your presence if you would 
agree to treat gravity as a law, rather than one of a number of 
suggested options."

>> I have another question re:b&b-
>> I know, originally, all polys in a stack had to be the same shape and
>> size.. what was the reason fo this, and would we still have that
>> limitation?

Oh, come on, that's obvious even to a wannabe-coder like me! Think how 
much work it would be to munge with the map format to allow truly 
stacked polys and build a new level editor that can deal with it (I 
haven't tried, but I bet Forge can't even in 2D mode.) Now compare how 
little work it is to stick in an extra set of floor and ceiling 
information for a polygon. Inio did it this way because it was the only 
way it would get *done* without completely rewriting the remainder of 
the engine to be "truer" 3D. With Inio's way, I *think* we avoid the 
whole two-openings-on-a-side problem, or at least we deftly sidestep 
it. With truly 3D polys, it all gets very very bad. I say this from a 
very limited knowledge of the Marathon engine, 3D engines in general, 
and working with them. I say this mostly from gut feeling and briefly 
visualizing in my head what exactly a truly stacked 3D map could look 
like. Sorry if I'm completely off base here. =)

Joe Auricchio ~ avarame@...

>stacked polys and build a new level editor that can deal with it (I 
>haven't tried, but I bet Forge can't even in 2D mode.)

it can, and it doesn't crash. it just doesn't draw right in visual mode
and you have problems walking through it.

>Now compare how 
>little work it is to stick in an extra set of floor and ceiling 
>information for a polygon.

but that's not what B&B was....


>I *think* we avoid the 
>whole two-openings-on-a-side problem,

no, you'd actually be using it. portal rendering allows for stuff like
this automatically AFAIK. also AFAIK, inio did it his way to simplify
the colision code or something... but if we're throwing collisions out
the window anyway, then why not allow for non-similar polys in a
stack?

I guess this asks another question- assuming this psuedo-B&B is
implmented as loren invisions, would it be a step towards full B&B (i.e;
someone would eventually write all the code needed) or a permanent
visual-only hack?

if the former, then it shoudl be done in a way to make it easy for
future development, whereas if the latter, then it should exploit
whatever tricks are available right now with no mind for expansion.



-- 
Quartz
--
"It's been a strange day... 
 it wasn't even a '2+2=5' kind of day,
 more like '2+2= ...fish'."
--
http://www.sneakertech.com
--

On Sunday, December 29, 2002, at 12:01 , Quartz wrote:

>
>> stacked polys and build a new level editor that can deal with it (I
>> haven't tried, but I bet Forge can't even in 2D mode.)
>
> it can, and it doesn't crash. it just doesn't draw right in visual mode
> and you have problems walking through it.

Um... the file format has no place to put that data... It's like saying 
"BBEdit let me connect a link to more than one web page, but when I 
preview it in Netscape only one of them works."  No, only one polygon 
may be on each side of the line.

>> Now compare how
>> little work it is to stick in an extra set of floor and ceiling
>> information for a polygon.
>
> but that's not what B&B was....

Almost.

>>> stacked polys and build a new level editor that can deal with it (I
>>> haven't tried, but I bet Forge can't even in 2D mode.)
>>
>> it can, and it doesn't crash. it just doesn't draw right in visual mode
>> and you have problems walking through it.
>
>Um... the file format has no place to put that data... 

ok, you're right. I thought I tried this in forge, but now that I think
about it, it was in pfhorte or mia or something. (and I never actually
saved btw, so I'm not saying that it could do that)


>>> Now compare how
>>> little work it is to stick in an extra set of floor and ceiling
>>> information for a polygon.
>>
>> but that's not what B&B was....
>
>Almost.

well? what was it then?

argh.. people keep giving vague descriptions of how B&B worked... can
anybody actually describe it in detail without any "maybe", "IIRC", or
"I think"? we know what the end result looked like, but how did it
operate internally?


-- 
Quartz
--
"It's been a strange day... 
 it wasn't even a '2+2=5' kind of day,
 more like '2+2= ...fish'."
--
http://www.sneakertech.com
--