October 2001
- (no subject) J C Lawrence
- Lum the Mad is closing--sort of Koster, Raph
- Questing (was: Request for ideas) Eli Stevens
- Questing (was: Request for ideas) Joe Andrieu
- Questing (was: Request for ideas) Matt Mihaly
- Questing (was: Request for ideas) Sellers, Mike
- Questing (was: Request for ideas) Vincent Archer
- contract games/markets (was: Request for ideas) Bruce Mitchener
- DEV: Peer-to-Peer MUD Phil O'Donnell
- DEV: Peer-to-Peer MUD Dan MacDonald
- DEV: Peer-to-Peer MUD Robin Lee Powell
- DEV: Peer-to-Peer MUD Justin Rogers
- DEV: Peer-to-Peer MUD Adam Martin
- DEV: Peer-to-Peer MUD Frank Crowell
- Psychology and game design (Was Geometric content generation) John Hopson
- Psychology and game design (Was Geometric content generation) Ola Fosheim Grøstad
- Psychology and game design (Was Geometric content generation) Dave Rickey
- Psychology and game design (Was Geometric content generation) Ola Fosheim Grøstad
- Psychology and game design (Was Geometric content generation) Matt Mihaly
- Psychology and game design (Was Geometric content generation) Ola Fosheim Grøstad
- Psychology and game design (Was Geometric content generation) rayzam
- in-game vs web-based boards (was: Geometric content generation) Freeman, Jeff
- State of the RP: Verant's attempt at a RP Server Eric Rhea
- New MMP Networking Architecture Lee Sheldon
- New MMP Networking Architecture Adam Martin
- New MMP Networking Architecture Bruce Mitchener
- New MMP Networking Architecture Ling Lo
- New MMP Networking Architecture Norman Nunley, Jr.
- Mucking about in time Eli Stevens
- Mucking about in time Travis Casey
- Mucking about in time Adam Martin
- Mucking about in time John Robert Arras
- Many MUDs in one? (was: Geometric content generation) Ian Collyer
- Many MUDs in one? (was: Geometric content generation) Matt Mihaly
- Many MUDs in one? (was: Geometric content generation) Robin Lee Powell
- Pueblo still kicking Jon Lambert
- FWD: Call for papers: AAAI symposium on AI and Interactive Entertainment Robert Zubek
- Game Theory Introduction Ling Lo
- MUD-Dev digest, Vol 1 #438 - 22 msgs Phil O'Donnell
- Uniqueness of Games Adam Martin
- Uniqueness of Games Ling Lo
- Psychology & Player Motivation (was Geometric Content Generation) Sasha Hart
- Simulation, just how much? (was: Uniqueness of Games) Derek Licciardi
- Laws of Competition Matt Mihaly
- UDP Revisted Daniel.Harman@barclayscapital.com
- UDP Revisted Brian Hook
- UDP Revisted Bobby Martin
- UDP Revisted Brian Hook
- UDP Revisted Dave Rickey
- UDP Revisted Daniel.Harman@barclayscapital.com
- UDP Revisted Dave Rickey
- UDP Revisted Travis Nixon
- UDP Revisted Amanda Walker
- UDP Revisted Brian Hook
- UDP Revisted Ben Greear
- UDP Revisted amanda@alfar.com
- UDP Revisted Brian Hook
- UDP Revisted Travis Nixon
- UDP Revisted Daniel.Harman@barclayscapital.com
- UDP Revisted Travis Nixon
- UDP Revisted David H. Loeser Jr.
- UDP Revisted Adam Martin
- UDP Revisted Bobby Martin
- UDP Revisted Bobby Martin
- UDP Revisted Kwon Ekstrom
- UDP Revisted Bruce Mitchener
- UDP Revisted Bobby Martin
- UDP Revisted Bruce Mitchener
Bobby,
Thanks for the response. :)
Bobby Martin wrote:
>> From: Bruce Mitchener <bruce@puremagic.com>
>> I was curious as to what sorts of advanced features you had in
>> ARMI and the documentation didn't really go into much detail
>> beyond some usage notes.
>> Do you have any support for pipelining of requests?
> No, although TCP (which I currently use) buffers packets for up to
> 200 ms before it sends the buffer.
Mmmm, this isn't quite what I was thinking about when I wrote that.
If I fire off 3 message sends in a row, and TCP is the transport in
use, what happens? Do all 3 get sent to the remote end right after
each other and then responses are returned, tagged with some request
identifier as they happen? Is there an ordering imposed on the
return of requests? (Say that you send off messages 1 and 3 to
object A, and message 2 to object B. Object B takes a long time in
responding. Does that delay the return of the result for #3?)
Or, similar to that, what happens if one method call returns a very
large bunch of data. Will that hold up following method sends, or
do you break data into chunks similar to what BEEP and HTTP/1.1 can
do to multiplex a single channel?
Finally (for now :)), do you share the transport connection, or do
you establish new ones frequently (like per-object, per-method send,
etc)?
But, on the point that you brought up, do you have control over that
200 ms buffering from Java? (To turn off nageling or whatever you
might want to change.) Is the 200ms delay proving troublesome at
all? That seems like a fairly high penalty to pay in terms of
latency for any distributed communication.
>> How about for monitoring message traffic or requests for
>> debugging, checking load balancing, etc?
> Currently in the works, but not there right now.
What sort of stuff is in the works? :)
>> What sorts of security or authentication do you support?
> Currently, none :( It is fairly trivial to add an encrypting
> message filter, though. You can filter messages that you send any
> way you like.
What sort of model are you thinking about though? Is this mainly for
communication between trusted peers? Or might it be used in a more
hostile environment with foreign (or user-written) code involved?
>> Can you compare your packing overhead to that of RMI or other
>> systems? Do you compress your datastreams?
> We don't currently formally compress data streams. I have done
> some sampling of RMI throughpuut versus ARMI throughput; ARMI was
> about 10 times smaller for the method calls I tested. This
> definitely needs more formal testing.
and later in your post, but moved here for ease in replying ...
> I have implemented production compression systems before, and I
> can tell you that you will almost certainly need tailor made
> compression (i.e. just write clever serialization code) for any
> significant gains. Lots of small information packets are hard to
> compress, unless you take large production runs and analyze them,
> then compress assuming the usage patterns don't change too much.
> Most compression mechanisms require that every block of data you
> compress has a table describing how to decompress it, and for
> small blocks the table takes up more space than the amount you
> gain by compressing. If you analyze large production runs of
> data, the tables can be static and just sit on either end of the
> connection.
With respect to serialization strategy being more important than a
traditional compression algorithm, I definitely agree. Brad Roberts
and I made some changes to Cold about 2-3 months ago that changed
how we serialized some bits of data and objects for storage into the
DB. Those changes managed to take a DB that was roughly 2G and drop
it to about 1.6G in size, which was quite nice. (It also had the
interesting impact of reducing our fragmentation of free space on
disk as more objects were now small enough to fit in the minimum
block size, consuming more of bits of free space floating about that
previously used to just contribute to wasted space. Those gains
aren't accounted for in the numbers that I gave above.)
Regarding throughput, you say that messages were smaller. Were the
round-trip times also less? Or roughly similar?
>> Any more information to explain in more detail how/why ARMI is
>> great is welcome. :)
> Offhand I don't know what I can tell you about why ARMI is great
> that isn't listed on the web site. Main attributes are:
> 1) Your method calls can be asynchronous (your app doesn't stop
> and wait for the return value from a method call until you need
> the return value.)
Will you provide some higher level support to be used by a caller of
an asynchronous method to help deal with the failure cases that
might result, or any sort of syntactic sugar/glue to help deal with
the complexities that arise from a more asynchronous model?
Some cool work in this that has been done is in the E programming
language. (Disclaimer: that work probably is from predecessors to E,
but that was my first exposure to this and I can't credibly cite
which predecessor it might have been.)
Taking from the E in a Walnut draft book, and the chapter on
Distributed Co
mputing, located at http://www.skyhunter.com/marcs/ewalnut.html#SEC18:
-- begin quote --
All distributed computing in E starts with the eventually
operator, "<-":
# E syntax
car <- moveTo(2,3)
println("car will eventually move to 2,3. But not yet.")
The first statement can be read as, "car, eventually,
please moveTo(2,3)". As soon as this eventual send has
been made to the car, the program immediately moves on
to the next sequential statement. The program does not
wait for the car to move. Indeed, as discussed further
under Game Turns below, it is guaranteed that the
following statement (println in this case) will execute
before the car moves, even if the car is in fact running
on the same computer as this code.
--- end quote ---
and ....
-- begin quote --
When you make an eventual send to an object (referred to
hereafter simply as a send, which contrasts with a call
to a local object that waits for the action to complete),
even though the action may not occur for a long time, you
immediately get back a promise for the result of the action:
# E syntax
def carVow := carMaker <- new("Mercedes")
carVow <- moveTo(2,3)
In this example, we have sent the carMaker object the
"new(name)" message. Eventually the carMaker will create
the new car on the same computer where the carMaker
resides; in the meantime, we get back a promise for
the car. We can make eventual sends to the promise
just as if it were indeed the car, but we cannot make
immediate calls to the promise even if the carMaker
(and therefore the car it creates) actually live on
the same computer with the program. To make immediate
calls on the promised object, you must set up an action
to occur when the promise resolves, using a when-catch
construct:
# E syntax
def temperatureVow := carVow <- getEngineTemperature()
when (temperatureVow) -> done(temperature) {
println("The temperature of the car engine is: " + temperature)
} catch prob {
println("Could not get engine temperature, error:" + prob)
}
println("execution of the when-catch waits for resolution
of the promise,")
println ("but the program moves on immediately to these printlns")
We can read the when-catch statement as, "when the promise
for a temperature becomes done, and therefore the temperature
is locally available, perform the main action block... but
if something goes wrong, catch the problem in variable
prob and perform the problem block". In this example,
we have requested the engine temperature from the
carPromise. Eventually the carPromise resolves to a
car (possibly remote) and receives the request for
engine temperature; then eventually the temperaturePromise
resolves into an actual temperature. The when-catch
construct waits for the temperature to resolve into
an actual (integer) temperature, but only the when-catch
construct waits (i.e., the when catch will execute
later, out of order, when the promise resolves). The
program itself does not wait: rather, it proceeds on,
with methodical determination, to the next statement
following the when-catch.
Inside the when-catch statement, we say that the promise
has been resolved. A resolved promise is either fulfilled
or broken. If the promise is fulfilled, the main body of
the when-catch is activated. If the promise was broken,
the catch clause is activated.
Notice that after temperatureVow resolves to temperature
the when clause treats temperature as a local object. This
is always safe to do when using vows. A vow is a reference
that always resolves to a local object. In the example,
variable names suffixed with "vow" remind us and warn
others that this reference is a vow. We can reliably
make eventual sends on the vow and immediate calls
on what the vow resolves to, but we cannot reliably
make immediate calls to the vow itself. A more detailed
discussion of these types of warnings can be found in
the Naming Conventions section later.
--- end quote ---
E takes a very thought out and considered approach to distributed
computing (especially of the variety where untrusted code may be
involved). But, were you looking at providing any similar sort of
mechanism for simplifying working with asynchronous method sends?
I've found that the addition of syntactic sugar for handling
asynchronous operations can even be useful when distributed
computations aren't being used. In TEC, we've got a scripting
language that GMs use for some things that compiles to ColdC. I've
taken advantage of that to provide some fairly high level approaches
to solving problems that then compile into the lower-level, messy
code. (And we lack a lot of the complexity of the environment that
E is designed for, but some of the same principles are paying off
well for us.)
> 2) I use ids for the class and method instead of the huge
> descriptors that RMI uses.
Does that change the security profile of your protocol at all? (Is
there a good reason that RMI uses large descriptors?)
> 4) <not implemented yet> You can choose whether a method call is
> guaranteed or not. Currently you either use UDP for transport
> and all method calls are non-guaranteed but fast, or you use TCP
> for tranport and all method calls are guaranteed but slower (but
> still much faster than RMI).
How will you do this? Will it be something that is decided at a
method call site? Or will it be per-method (and globally decided)?
If the latter, will you have some sort of IDL that provides that
info, a registration process, or something else?
That sort of thing is where I think that a language with
extensible parsing/keywords is really useful. Taking it back to
persistence for a moment, you might invent your own keywords to
specify persistence behaviors. Or for distributed computing, you
might just tag your source with directives on how that variable
should be updated over the network.
I'm not a big fan of requiring a whole new IDL or something for
stuff like that, or a specialized program like OpenSkies uses for
their object definitions. But, then, I guess not many mainstream
programming languages have an extensible grammar
- Bruce - UDP Revisted Daniel.Harman@barclayscapital.com
- UDP Revisted Bruce Mitchener
- Procedural content generation Brian Hook
- Procedural content generation John Buehler
- Procedural content generation Brian Hook
- Procedural content generation John Buehler
- Procedural content generation Hans-Henrik Staerfeldt
- Procedural content generation lhulbert@hotmail.com
- Procedural content generation Travis Nixon
- Procedural content generation Ola Fosheim Grøstad
- Procedural content generation Daniel.Harman@barclayscapital.com
- Procedural content generation Daniel.Harman@barclayscapital.com
- Procedural content generation Freeman, Jeff
- Procedural content generation Matt Mihaly
- Procedural content generation Ola Fosheim Grøstad
- Simulation, Christopher Allen
- Simulation, Travis Casey
- MMORPG Comparison (UO, EQ, AC, AO, DAoC) Dave Kennerly
- MMORPG Comparison (UO, EQ, AC, AO, DAoC) Robin Lee Powell
- MMORPG Comparison (UO, EQ, AC, AO, DAoC) Dave Rickey
- MMORPG Comparison (UO, EQ, AC, AO, DAoC) John Buehler
- MMORPG Comparison (UO, EQ, AC, AO, DAoC) Dave Rickey
- MMORPG Comparison (UO, EQ, AC, AO, DAoC) John Buehler
- MMORPG Comparison (UO, EQ, AC, AO, DAoC) Brian Hook
- MMORPG Comparison (UO, EQ, AC, AO, DAoC) John Buehler
- MMORPG Comparison (UO, EQ, AC, AO, DAoC) Daniel.Harman@barclayscapital.com
- MMORPG Comparison (UO, EQ, AC, AO, DAoC) Vincent Archer
- MMORPG Comparison (UO, EQ, AC, AO, DAoC) Derek Licciardi
- MMORPG Comparison (UO, EQ, AC, AO, DAoC) John Buehler
- MMORPG Comparison (UO, EQ, AC, AO, DAoC) Dave Rickey
- MMORPG Comparison (UO, EQ, AC, AO, DAoC) Dan Burke
- Simulation, Adam Martin
- UDP Revisited Daniel.Harman@barclayscapital.com
- UDP Revisited Brian Hook
- UDP Revisited Mats Lidstrom
- UDP Revisited Jeremy Gaffney
- Simulation Revisited Dave Rickey
- TCP Vegas Adam Martin
- Procedural content generation, randomness Adam Martin
- Procedural content generation, randomness Brian Hook
- Content authorship Adam Martin
- Content authorship Ola Fosheim Grøstad
- Content authorship Travis Casey
- DAoC dev team (was: MMORPG Comparison (UO, EQ, AC, AO, DAoC)) Eli Stevens
- DAoC dev team (was: MMORPG Comparison (UO, EQ, AC, AO, DAoC)) Dave Rickey
- DAoC dev team (was: MMORPG Comparison (UO, EQ, AC, AO, DAoC)) Ola Fosheim Grøstad
- DAoC dev team (was: MMORPG Comparison (UO, EQ, AC, AO, DAoC)) Robin Lee Powell
- DAoC dev team (was: MMORPG Comparison (UO, EQ, AC, AO, DAoC)) Brian Hook
- DAoC dev team (was: MMORPG Comparison (UO, EQ, AC, AO, DAoC)) Daniel.Harman@barclayscapital.com
- DAoC dev team (was: MMORPG Comparison (UO, EQ, AC, AO, DAoC)) Neufeld, Don
- DAoC dev team (was: MMORPG Comparison (UO, EQ, AC, AO, DAoC)) Brian Hook
- DAoC dev team Dave Rickey
- SSL vs. SASL (was: UDP Revisted) Bruce Mitchener
- MUD-Dev digest, Vol 1 #445 - 27 msgs Paul Schwanz
- MUD-Dev digest, Vol 1 #445 - 27 msgs Travis Nixon
- Proposed Law John Buehler
- Proposed Law Matt Mihaly
- Proposed Law John Buehler
- Proposed Law Freeman, Jeff
- Proposed Law John Buehler
- Proposed Law Matt Mihaly
- Proposed Law John Buehler
- Proposed Law Matt Mihaly
- Proposed Law John Buehler
- Proposed Law Matt Mihaly
- Proposed Law Koster, Raph
- Proposed Law Matt Mihaly
- Proposed Law John Buehler
- Proposed Law Koster, Raph
- Proposed Law Ola Fosheim Grøstad
- Proposed Law Jon Lambert
- Proposed Law Paul Schwanz
- Proposed Law Matt Mihaly
- Proposed Law Paul Schwanz
- Proposed Law Paul Schwanz
- Proposed Law Madman Across the Water
- Proposed Law Travis Nixon
- Proposed Law Mark Eaton
- Proposed Law Sami Kosonen
- Proposed Law Madman Across the Water
- Proposed Law Andrew Hefford {Coregen}
- Proposed Law Dan Burke
- Proposed Law Matt Mihaly
- Proposed Law John Buehler
- Proposed Law Matt Mihaly
- Proposed Law Paul Schwanz
- Proposed Law Ian Collyer
- Proposed Law Matthew Estes
- Proposed Law Matt Mihaly
- Proposed Law Ola Fosheim Grøstad
- Proposed Law John Buehler
- Proposed Law Ola Fosheim Grøstad
- Proposed Law John Buehler
- Proposed Law Adam Martin
- Proposed Law Matt Mihaly
- Proposed Law Adam Martin
- Proposed Law Matt Mihaly
- Proposed Law Paul Schwanz
- Quality Testing Michael Tresca
- Quality Testing John Buehler
- Quality Testing Michael Tresca
- Quality Testing Dave Rickey
- Quality Testing Nathan F. Yospe
- Quality Testing Michael Tresca
- Quality Testing Koster, Raph
- Quality Testing Dave Rickey
- Quality Testing Dave Rickey
- Quality Testing Derek Licciardi
- Quality Testing Dave Rickey
- Quality Testing Michael Tresca
- Quality Testing Dave Rickey
- Quality Testing Jeff Cole
- Quality Testing Robin Lee Powell
- Quality Testing Daniel.Harman@barclayscapital.com
- Quality Testing J C Lawrence
- Quality Testing Daniel.Harman@barclayscapital.com
- Quality Testing Dave Rickey
- Quality Testing Daniel.Harman@barclayscapital.com
- Quality Testing Michael Tresca
- Quality Testing Daniel.Harman@barclayscapital.com
- Quality Testing Paul Dahlke
- Quality Testing Dave Rickey
- Players Controlling Monsters rayzam
- High Level Architecture Adam Martin
- Networking architecture overview Brian Hook
- Networking architecture overview Dave Rickey
- Networking architecture overview Brian Hook
- Networking architecture overview Amanda Walker
- Networking architecture overview Brian Hook
- Networking architecture overview Bobby Martin
- Networking architecture overview Daniel.Harman@barclayscapital.com
- Connection Stats Ben Tolputt
- MUD-Dev digest, Vol 1 #443 - 12 msgs Dr. Cat
- Fourteen forms of fun Ola Fosheim Grøstad
- Fourteen forms of fun rayzam
- Fourteen forms of fun Sasha Hart
- Fourteen forms of fun Jon Lambert
- Fourteen forms of fun David H. Loeser Jr.
- Fourteen forms of fun Matt Mihaly
- Fourteen forms of fun Ola Fosheim Grøstad
- Incorporating Plot/Backstory/Scenario Design Tools Nathan F. Yospe
- Extreme Programing Ling Lo
- DAoC dev team Lars Duening
- Documentation Adam Martin
- Documentation Brian Hook
- English grammar thoughts Par Winzell
- English grammar thoughts Kylotan
- English grammar thoughts Travis Casey
- English grammar thoughts Jasper McChesney
- English grammar thoughts Marian Griffith
- English grammar thoughts Travis Casey
- English grammar thoughts Jasper McChesney
- English grammar thoughts bruce@puremagic.com
- English grammar thoughts Marian Griffith
- English grammar thoughts Travis Casey
- English grammar thoughts Robert Zubek
- English grammar thoughts Robert Zubek
- English grammar thoughts Travis Casey
- English grammar thoughts Chris Gray
- English grammar thoughts Jon Leonard
- ADMIN: The code documenting/commenting thread J C Lawrence
- Players Controlling Monsters David H. Loeser Jr.
- Players Controlling Monsters Brian Hook
- Players Controlling Monsters John Buehler
- Expectations of in-game reality Matt Mihaly
- Expectations of in-game reality Freeman, Jeff
- Expectations of in-game reality J C Lawrence
- Expectations of in-game reality Freeman, Jeff
- Expectations of in-game reality Travis Casey
- Expectations of in-game reality Lars Duening
- Expectations of in-game reality Marian Griffith
- Expectations of in-game reality Derek Licciardi
- Expectations of in-game reality Lars Duening
- Expectations of in-game reality Paul Schwanz
- Expectations of in-game reality Nip
- Expectations of in-game reality Ian Collyer
- Expectations of in-game reality Adam Martin
- Expectations of in-game reality Michael Tresca
- Expectations of in-game reality J C Lawrence
- Expectations of in-game reality Matt Mihaly
- Expectations of in-game reality Daniel.Harman@barclayscapital.com
- Expectations of in-game reality Eli Stevens
- Expectations of in-game reality Marian Griffith
- Expectations of in-game reality Travis Casey
- Expectations of in-game reality Sami Kosonen
- Respecting NPCs Lee Sheldon
- Respecting NPCs J C Lawrence
- Respecting NPCs Lee Sheldon
- Respecting NPCs J C Lawrence
- Respecting NPCs Sami Kosonen
- Respecting NPCs Travis Nixon
- Respecting NPCs Matthew Estes
- Respecting NPCs Chris Gray
- Respecting NPCs Michael Tresca
- Respecting NPCs Freeman, Jeff
- Respecting NPCs Michael Tresca
- Respecting NPCs Freeman, Jeff
- Respecting NPCs Travis Nixon
- Respecting NPCs Michael Tresca
- Respecting NPCs Adam Martin
- Respecting NPCs Michael Tresca
- Respecting NPCs Daniel.Harman@barclayscapital.com
- Respecting NPCs rayzam
- Respecting NPCs Joe Andrieu
- Respecting NPCs Bruce Mitchener
- Respecting NPCs Joe Andrieu
- Respecting NPCs Michael Tresca
- Respecting NPCs Adam Martin
- Respecting NPCs Lee Sheldon
- Respecting NPCs T.A.J.BARTON
- Respecting NPCs Bruce Mitchener
- Respecting NPCs Adam Martin
- Respecting NPCs Madman Across the Water
- Respecting NPCs Travis Nixon
- Respecting NPCs J C Lawrence
- Respecting NPCs John Buehler
- Respecting NPCs lazarus@ourplace.org
- Respecting NPCs Colin Coghill
- Respecting NPCs gamaiun@yahoo.com
- Respecting NPCs J C Lawrence
- Respecting NPCs Phillip Lenhardt
- Respecting NPCs gamaiun@yahoo.com
- Respecting NPCs Ola Fosheim Grøstad
- Respecting NPCs J C Lawrence
- Respecting NPCs Ola Fosheim Grøstad
- Respecting NPCs Bruce Mitchener
- Respecting NPCs Norman Nunley, Jr.
- Respecting NPCs J C Lawrence
- Respecting NPCs Brian Hook
- Respecting NPCs J C Lawrence
- Respecting NPCs gamaiun@yahoo.com
- Respecting NPCs Ola Fosheim Grøstad
- Respecting NPCs Matthew D. Fuller
- Respecting NPCs Timothy Dang
- Respecting NPCs gamaiun@yahoo.com
- TECH : RMI (was UDP Revisted) Daniel.Harman@barclayscapital.com
- TECH : RMI (was UDP Revisted) Bobby Martin
- Chatbots Adam Martin
- TECH: UDP Revisted Bobby Martin
- The function of NPCs in novels versus MUDs Ola Fosheim Grøstad
- RE: Koster, Raph
- RE: Joe Andrieu
- RE: Marian Griffith
- RE: gamaiun@yahoo.com
- RE: Daniel.Harman@barclayscapital.com
- Violence Matt Mihaly
- Quality Testing (and community) Ola Fosheim Grøstad
- ADMIN: Recent outages J C Lawrence
- [ECOSYSTEMS] Fishing in the real world Adam Martin
- [ECOSYSTEMS] Fishing in the real world Daniel.Harman@barclayscapital.com
- [ECOSYSTEMS] Fishing in the real world Hans-Henrik Staerfeldt
- [ECOSYSTEMS] Fishing in the real world Ian Collyer
- [ECOSYSTEMS] Fishing in the real world Dave Rickey
- Statistics Ben Chambers
- Statistics Eli Stevens
- Statistics Adam Martin
- Statistics Hans-Henrik Staerfeldt
- Statistics John Buehler
- Statistics Ben Chambers
- Statistics Ben Chambers
- Statistics Travis Casey