March 1998
- Describe Concept Stephen Zepp
- Describe Concept Jon A. Lambert
- Describe Concept J C Lawrence
- Describe Concept Jon A. Lambert
- Describe Concept J C Lawrence
- Describe Concept Vadim Tkachenko
- Tutorial: Let's build a Compiler! - Part XI: Lexical Scan Revisited Jon A. Lambert
- Tutorial: Let's build a Compiler! - Part XII: Miscellany Jon A. Lambert
- Tutorial: Let's build a Compiler! - Part XIII: Procedures Jon A. Lambert
- Tutorial: Let's build a Compiler! Chris Gray
- VEIL Network Protocol Brandon Gillespie
- Tutorial: Let's build a Compiler! - Part XIV: Types Jon A. Lambert
- Tutorial: Let's build a Compiler! - Part XV: Back to the Future Jon A. Lambert
- Tutorial: Let's build a Compiler! - Part XVI: Unit Construction Jon A. Lambert
- For Ling's FAQ Koster, Raph
- MUD Ratings jlsysinc.ix.netcom.com@ix.netcom.com
- Random Generation Tools Ling
- ANNOUNCE: DB Robin Carey
- THE DARKWHOLE TESTS J C Lawrence
- Magic as Metaphor J C Lawrence
- Magic as Metaphor J C Lawrence
- Magic as Metaphor Jon A. Lambert
- Magic as Metaphor J C Lawrence
- CT - A Hypothetical Session (mid 1995) J C Lawrence
- 2Cyberconf: An article J C Lawrence
- (long) AnarchyMOO Primary Log J C Lawrence
- (short) AnarchyMOO parting salute J C Lawrence
- AnarchyMOO purpose J C Lawrence
- (fwd) CODE RELEASE: [client] Spod! (Java mud client) J C Lawrence
- (fwd) CODE RELEASE: [client]: lyntin (hacker's client) 1.1b Released J C Lawrence
- DarkWhole Test #1 J C Lawrence
- DarkWhole Test #2 J C Lawrence
- DarkWhole test #3 J C Lawrence
- DarkWhole test #4 J C Lawrence
- DarkWhole test #5 J C Lawrence
- DarkWhole test Identity Crisis J C Lawrence
- The Craft of Adventure J C Lawrence
- What in THE Hell was that? Stephen Zepp
- What in THE Hell was that? Ben Greear
- What in THE Hell was that? J C Lawrence
- What in THE Hell was that? Jon A. Lambert
- (fwd) Varying Time Commitment Levels: what's an admin to do? J C Lawrence
- Hello, and a brief intro cimri
- Hello, and a brief intro Ben Greear
- (no title) Time limits? s001gmu@nova.wright.edu
- (no title) Time limits? Justin McKinnerney
- (no title) Time limits? J C Lawrence
- Speaking of Avatars Jon A. Lambert
- Speaking of Avatars Jon A. Lambert
- Speaking of Avatars J C Lawrence
- Speaking of Avatars Jon A. Lambert
- Re: Vadim Tkachenko
- META: Broken mail headers coder@ibm.net
- META: Broken mail headers Alex Oren
- META: Broken mail headers J C Lawrence
- META: Broken mail headers Alex Oren
- META: Broken mail headers J C Lawrence
- META: Broken mail headers Chris Gray
- META: Broken mail headers J C Lawrence
- META: Broken mail headers Caliban Tiresias Darklock
- META: Broken mail headers Chris Gray
- Turn-based MU*'s Sauron
- Balancing Addicts -> soft vs. hard enforcement cimri
- Balancing Addicts -> soft vs. hard enforcement Justin McKinnerney
- Balancing Addicts -> soft vs. hard enforcement J C Lawrence
- Balancing Addicts -> soft vs. hard enforcement Jon A. Lambert
- Balancing Addicts -> soft vs. hard enforcement Ling
- Balancing Addicts -> soft vs. hard enforcement Jon A. Lambert
- Balancing Addicts -> soft vs. hard enforcement Matt Chatterley
- Balancing Addicts -> soft vs. hard enforcement J C Lawrence
- Balancing Addicts -> soft vs. hard enforcement Jon A. Lambert
- Balancing Addicts -> soft vs. hard enforcement Matt Chatterley
- Balancing Addicts -> soft vs. hard enforcement Adam Wiggins
- Balancing Addicts -> soft vs. hard enforcement Joel Dillon
- SfD: Clientside Caching Nathan F Yospe
- SfD: Clientside Caching Jon A. Lambert
- SfD: Clientside Caching Nathan F Yospe
- SfD: Clientside Caching Chris Gray
- SfD: Clientside Caching Jon A. Lambert
On 18 Mar 98 at 15:31, Nathan F Yospe wrote:
> On Tue, 17 Mar 1998, Jon A. Lambert wrote:
> :On 16 Mar 98 at 17:20, Nathan F Yospe wrote:
>
> :I find the heavy use of native methods intriguing. Certainly it's
> :possible to write a great deal of client code in C/C++ that's highly
> :portable. And let the Java VM handle the OS dependencies. While it
> :might not give you the highest performance gains in the areas you
> :probably need, it is attractive from a maintenance standpoint.
>
> This is a big part of it, and something I wouldn't mind doing. It isn't
> what I meant, precisely; on the Mac, for example, I have my own version
> of the awt that taps into a couple of the newer drawing methods and even
> quicktime 2.5 or 3.0, if present. I'm planning to do this for Windows in
> time, and eventually possibly for other machines. I haven't learned enough
> about BeOS to do this effectively yet, and frankly, don't like the stuff
> available with X or Motif, and would prefer to leave that to Java.
This is exactly the code I also want to leave to "third-party"
widely available libraries, VMs, APIs. I have no desire to delve
into the inner workings of gadgets, components, toolboxes, windows,
buttons, etc. However one expects that the performance and methods
available to do complex graphics within these windows has a level of
"industrial" or "commercial" strength behind it. These types of
components are tightly coupled to their OS APIs, contain the vast
majority of errors, and are difficult to maintain. This is exactly
the level of coding I want to leave to my vendor, whether it be a
Java VM, Motif, whatever.
Quicktime, as you mention IS an industrial strength option that I
trust to perform and be maintained/supported on a wide variety of
platforms. It's a proven technology, as it is heavily used by Win
and Mac graphical game producers.
> However...
> a lot of the biggest stuff in the client, background graphics display aside,
> is text parsing and generation. The neural net code for that is all native,
> for good reason; it also happens to be nearly 100% portable. I'm still
> working on the portability of the tables associated with it.
Yes this is exactly the the type of code you should expect 100% C/C++
portability out of. 99% of this code is ADTs and pure C. One would
expect even standard library calls are infrequent and could be
limited to minimal ANSI compliance. An OS dependent call would
be a rarity indeed.
The point I was trying to make is that when someone decides to sit
down a write a Java client, they might not pay very much attention to
the use of native methods. One tends to think of using a native
method when a problem is encountered that appears to be intractable
or difficult in the parent language or has an obvious performance
problem. When you are using Java, you are likely to find yourself
writing code that is as elegant, easy and "to the point of the
problem" as when writing C/C++. Yet performance problems in Java are
not as readily obvious from looking at the code. There are loads of
subtleties in the way that "Java does things" that make performance
profiling infuriating. Most of the time you find it way up the Class
tree in code you can't and don't want screw with, or buried behind
the black hole of the VM.
The summary of my rant is thusly:
Use native methods in Java liberally with code that is non-trivial
and OS independent. Then follow your normal instincts with the
rest of the code.
> Watercolors within a short range of the background color (which does change,
> and the text color with it for contrast), or, to be more precise, so far
> pieces of art based on ... well, check my web page in a week or two, under
> the gallery. I'll announce the reopening of my page, as there is going to
> be a major mud related section on it. In any case, so far I have a few
> hundred pieces of suggestive background, none of which has anything to
> indicate specificity, but all designed to suggest a certain mood, clime,
> and atmosphere. Day and night, storm and calm, of city, desert, jungle,
> forest, town, space, caves, corridors, habitats, suburban towns human and
> alien, oceans, islandias, rivers, ice, bunkers, warzones... most of the art
> is not production quality yet, but it ought to be VERY effective.
I'm looking forward to it. The philosophy (if there is one) behind
web wallpaper likely parallels this. You don't want the backdrop
to distract you from the text, you want it to gently suggest moods or
sensations while reading it. BTW don't look at my web pages for any
good examples yet. I'm as clumsy and direct as the typical net nerd.
Yet, I know what I like when I see it on others' pages.
Mental Note: Enlist well-fed artist.
>I wanted
> to use it for Singularity, back when I first tried to tie that old Rom into
> a web based plugin server... but it will be a lot more effective with the
> dynamic text of Intergalactic War: The Singularity Myth. (The name is a lot
> more accurate, and should have been kept as the name for the original. I
> have done a lot of going back to original concept with this, and am glad of
> that.)
What are the current running titles of your projects? You've had
several name changes since I've been on the list. ;)
> :Most of these images could be included in the client download and my
> :guess(?) is they would be highly compact of their light pixel
> :density.
>
> I can get an extremely effective 640x480 gif into 6k on average. :) And yes,
> an original set would come with the client.
This is so cheap, and zero bandwidth to boot. I'm beginning to
feel guilty about it. :~
> :> 1) What are we going to cache?
>
[snip]
> :Fixed or mostly static text like help, documentation, histories,
> :stories would seem to be good candidates, as well as mud mail and
> :bulletin boards. Having the above items client-side would allow the
> :user to utilize mechanisms for off-line reading and study.
>
> There's a good point I hadn't thought of. Well, in a sense I had. Direct
> mail doesn't even have to go through the server, if both clients are on. I
> have allowed client to client communication in the design.
Didn't think of client-to-client. With that in place you could shift
ALL user communication off-server, even in-game chat, tell, whisper,
emotes. Possible player security issues here? Then again, the
server need not acknowledge or process communications "spam".
> (I have yet to
> finish implementing this, and have no idea how well it will work. I based it
> on DCC to some degree...) Large amounts of text (the dictionary and
> thesaurus) would be built into the client, in rewriteable files that will be
> periodicly brought up to date. This might allow easy translation to other
> languages. (The grammar is a totally modular component.)
Hmmm, also a potential savings of string memory.
> :[snip - security issues]
>
> :Nod. Lots of potential for client-side programming or preference
> :storage. In my case, and some others I'd imagine, there would be
> :a couple of levels to this user-memory data. I would make a
> :separation of user memory and character memories since multi-play
> :and simultaneous multi-play is a desirable option.
>
> *nod* This is a good point. At the moment, I have several items that are
> character specific. Memories of names, a cross-ref for the language files (I
> scan the character lexfile first, then the character's jargon lexfiles, then
> the global lexfile), preference files (these are models, and not so much a
> character specific thing as a set of preferences that can be applied to more
> than one character, loaded or unloaded for a given character, split for some
> introduced difference (this is my standard preferences WITH prediction on,
> this is my standard preferences WITHOUT...), and so on.
Another possibility is to ship compiling of an internal mud language
off to a builder client. Late bind the code to server side objects
in the final compile phase. Client-side offline coding and
syntax-level compiles are possible. This might be a high CPU item
for some online programmed servers.
> Again, a good point. At the moment, none of my models distinguish much
> between the nature of objects... this presents some problems with the idea
> of seperating storage method... but backgrounds alone are easy enough to
> deal with. If not cached, they are grabbed in sets (climactic) that tend to
> be grouped together.
On second thought, it would probably increase complexity of the
client enough that any benefits are undermined. KISS and a common
method of caching might be more prudent.
> :I can't understand the need (or desire) for this much backward
> :compatability (back to telnet terminals and 286s). It's not
> :even reflective of the current mud playerbase. This is more a
> :reflection of the administrative userbase.
>
> And your point? _I_ want to be able to use this thing myself, you know, and
> it isn't that hard to make a UI change in Java, which is all that is being
> done here. Think of it like this: how hard is it to write the text output
> UI? How hard to write the GUI UI? OK, now, which one is more effective for
> a quicky test case?
I agree; for testing - yes, for server-side administration - yes.
But for player use definitely NOT. Why do I feel this way? I don't
want to make commonly available an otherwise inferior presentation to
an unsuspecting playerbase as compared to my desired or ideal
presentation. It would be unthinkable, if someone running an
capable machine got hold of this text-only client and absolutely
awful if they introduced their mud-skeptical friends to it.
OK, I exaggerate a bit. :P I think first impressions are lasting
though.
> I'm not saying I'm going to use the remote hosted dumb
> terminal model much, but... come on, how many of you prefer lynx to Netscape
> when just doing a quick check of deja-news? How many prefer vi to Word when
> just making a quick edit to a source file? And if I'm going to write it for
> myself, why not make it available for others who use telnet access accounts
> regularly?
I can guess at the poll results.
Mud Design List - Lynx - 75% Netscape - 25%
VI - 95% Word - 5%
And my target audience would say...
FRPG Convention - Lynx - 5% Netscape - 70% Huh?! 25%
VI - 5% Word - 60% Huh?! 35%
--
--/*\ Jon A. Lambert - TychoMUD Internet:jlsysinc@ix.netcom.com /*\--
--/*\ Mud Server Developer's Page <http://www.netcom.com/~jlsysinc> /*\--
--/*\ "Everything that deceives may be said to enchant" - Plato /*\--
- (subject missing) J C Lawrence
- Balancing Addicts Ling
- Balancing Addicts Richard Woolcock
- Balancing Addicts Ling
- Balancing Addicts J C Lawrence
- Transport layer (UDP vs TCP) Ben Greear
- Transport layer (UDP vs TCP) Niklas Elmqvist
- Transport layer (UDP vs TCP) Jon Leonard
- Transport layer (UDP vs TCP) Ben Greear
- Transport layer (UDP vs TCP) Jon Leonard
- Transport layer (UDP vs TCP) Ben Greear
- Transport layer (UDP vs TCP) Chris Gray
- Transport layer (UDP vs TCP) Niklas Elmqvist
- Transport layer (UDP vs TCP) Jon A. Lambert
- Transport layer (UDP vs TCP) Ben Greear
- Time Limits? Jon A. Lambert
- META: topic and thread culling (was Balancing Addicts -> soft vs. hard enforcement ) J C Lawrence
- (subject missing) J C Lawrence
- XShipWars J C Lawrence
- (fwd) INFO: [client] Chaco looking for new parent for Pueblo J C Lawrence
- SIMULATING FUTURE HISTORIES: THE NAU SOLAR SYSTEM SIMULATION & MARS SETTLEMENT J C Lawrence
- (fwd) Functional Security J C Lawrence
- (fwd) Functional Security Ling
- (fwd) Functional Security Chris Gray
- (fwd) Functional Security Matt Chatterley
- (fwd) Functional Security Miroslav Silovic
- (fwd) Functional Security Felix A. Croes
- (fwd) Functional Security J C Lawrence
- SIMULATING FUTURE HISTORIES s001gmu@nova.wright.edu
- Character development [was ] Matt Chatterley
- Character development [was ] J C Lawrence
- Character development [was ] Matt Chatterley
- Character development [was ] Travis Casey
- Character development [was ] J C Lawrence
- Character development [was ] Travis S. Casey
- Character development [was ] Marian Griffith
- Character development [was ] Travis S. Casey
- Character development [was ] Vadim Tkachenko
- Character development [was ] Travis Casey
- Character development [was ] Vadim Tkachenko
- Character development [was ] Travis Casey
- Character development [was ] Vadim Tkachenko
- Character development [was ] Marian Griffith
- Character development [was ] Vadim Tkachenko
- Character development [was ] Marian Griffith
- Character development [was ] s001gmu@nova.wright.edu
- Character development [was ] Marian Griffith
- Character development [was ] J C Lawrence
- Character development [was ] Cimri
- Character development [was ] J C Lawrence
- Character development [was ] s001gmu@nova.wright.edu
- Character development [was ] Caliban Tiresias Darklock
- Character development [was ] Caliban Tiresias Darklock
- Character development [was ] Vadim Tkachenko
- Character development [was ] Ben Greear
- Character development [was ] Matt Chatterley
- Character development [was ] J C Lawrence
- Character development [was ] Matt Chatterley
- Character development [was ] Travis S. Casey
- Character development [was ] J C Lawrence
- Character development [was ] Koster, Raph
- Character development [was ] J C Lawrence
- Character development [was ] Koster, Raph
- Character development [was ] Alex Bertoglio
- Character development [was ] J C Lawrence
- Character development [was ] J C Lawrence
- Character development [was ] John Bertoglio
- 3D engines for MUDs Niklas Elmqvist
- 3D engines for MUDs Chris Gray
- 3D engines for MUDs J C Lawrence
- 3D engines for MUDs Niklas Elmqvist
- 3D engines for MUDs Chris Gray
- 3D engines for MUDs Ling
- 3D engines for MUDs Koster, Raph
- 3D engines for MUDs Mike Sellers
- 3D engines for MUDs Niklas Elmqvist
- 3D engines for MUDs Koster, Raph
- 3D engines for MUDs Ling
- 3D engines for MUDs s001gmu@nova.wright.edu
- Dynamic Loading of Modules Niklas Elmqvist
- Dynamic Loading of Modules Greg Munt
- Dynamic Loading of Modules J C Lawrence
- Parlez vous NPC? Matt Chatterley
- Parlez vous NPC? Vadim Tkachenko
- Parlez vous NPC? Matt Chatterley
- Parlez vous NPC? Chris Gray
- Parlez vous NPC? Matt Chatterley
- Parlez vous NPC? Nathan F Yospe
- Parlez vous NPC? Matt Chatterley
- Dynamic Loading of Modules Niklas Elmqvist
- Dynamic Loading of Modules Chris Gray
- Dynamic Loading of Modules Jon A. Lambert
- World Persistence, flat files v/s DB v/s ?? Ben Greear
- World Persistence, flat files v/s DB v/s ?? Chris Gray
- World Persistence, flat files v/s DB v/s ?? Jon A. Lambert
- World Persistence, flat files v/s DB v/s ?? Greg Munt
- World Persistence, flat files v/s DB v/s ?? Chris Gray
- World Persistence, flat files v/s DB v/s ?? Matt Chatterley
- World Persistence, flat files v/s DB v/s ?? s001gmu@nova.wright.edu
- World Persistence, flat files v/s DB v/s ?? Vadim Tkachenko
- World Persistence, flat files v/s DB v/s ?? Vadim Tkachenko
- World Persistence, flat files v/s DB v/s ?? Matt Chatterley
- World Persistence, flat files v/s DB v/s ?? Ben Greear
- World Persistence, flat files v/s DB v/s ?? Vadim Tkachenko
- World Persistence, flat files v/s DB v/s ?? Joel Dillon
- World Persistence, flat files v/s DB v/s ?? Joel Dillon
- World Persistence, flat files v/s DB v/s ?? Vadim Tkachenko
- World Persistence, flat files v/s DB v/s ?? Matt Chatterley
- World Persistence, flat files v/s DB v/s ?? Chris Gray
- World Persistence, flat files v/s DB v/s ?? Ross Nicoll
- World Persistence, flat files v/s DB v/s ?? Ross Nicoll
- World Persistence, flat files v/s DB v/s ?? Matt Chatterley
- World Persistence, flat files v/s DB v/s ?? Vadim Tkachenko
- World Persistence, flat files v/s DB v/s ?? s001gmu@nova.wright.edu
- World Persistence, flat files v/s DB v/s ?? Joel Dillon
- World Persistence, flat files v/s DB v/s ?? Matt Chatterley
- World Persistence, flat files v/s DB v/s ?? Vadim Tkachenko
- World Persistence, flat files v/s DB v/s ?? J C Lawrence
- World Persistence, flat files v/s DB v/s ?? Chris Gray
- World Persistence, flat files v/s DB v/s ?? J C Lawrence
- World Persistence, flat files v/s DB v/s ?? Vadim Tkachenko
- World Persistence, flat files v/s DB v/s ?? Chris Gray
- World Persistence, flat files v/s DB v/s ?? J C Lawrence
- World Persistence, flat files v/s DB v/s ?? Jon A. Lambert
- World Persistence, flat files v/s DB v/s ?? J C Lawrence
- World Persistence, flat files v/s DB v/s ?? Ben Greear
- World Persistence, flat files v/s DB v/s ?? Matt Chatterley
- World Persistence, flat files v/s DB v/s ?? Ben Greear
- World Persistence, flat files v/s DB v/s ?? Jon A. Lambert
- World Persistence, flat files v/s DB v/s ?? J C Lawrence
- World Persistence, flat files v/s DB v/s ?? Joel Dillon
- World Persistence, flat files v/s DB v/s ?? Matt Chatterley
- World Persistence, flat files v/s DB v/s ?? Joel Dillon
- World Persistence, flat files v/s DB v/s ?? J C Lawrence
- World Persistence, flat files v/s DB v/s ?? Joel Dillon
- World Persistence, flat files v/s DB v/s ?? J C Lawrence
- World Persistence, flat files v/s DB v/s ?? Matt Chatterley
- World Persistence, flat files v/s DB v/s ?? J C Lawrence
- World Persistence, flat files v/s DB v/s ?? Adam Wiggins
- World Persistence, flat files v/s DB v/s ?? Ben Greear
- World Persistence, flat files v/s DB v/s ?? Orion Henry
- World Persistence, flat files v/s DB v/s ?? Ben Greear
- World Persistence, flat files v/s DB v/s ?? Nathan F Yospe
- World Persistence, flat files v/s DB v/s ?? Ben Greear
- World Persistence, flat files v/s DB v/s ?? Vadim Tkachenko
- World Persistence, flat files v/s DB v/s ?? J C Lawrence
- World Persistence, flat files v/s DB v/s ?? J C Lawrence
- World Persistence, flat files v/s DB v/s ?? Greg Munt
- World Persistence, flat files v/s DB v/s ?? Ben Greear
- World Persistence, flat files v/s DB v/s ?? Jon A. Lambert
- World Persistence, flat files v/s DB v/s ?? J C Lawrence
- World Persistence, flat files v/s DB v/s ?? J C Lawrence
- World Persistence, flat files v/s DB v/s ?? Chris Gray
- World Persistence, flat files v/s DB v/s ?? J C Lawrence
- Jukebox Vadim Tkachenko
- Another recruit for the list? Joel Dillon
- OT: Martin Keegan J C Lawrence
- Old code Joel Dillon
- Old code Michael Hohensee
- UML/Commercial v Free Muds Greg Munt
- UML/Commercial v Free Muds Nathan F Yospe
- UML/Commercial v Free Muds Jon A. Lambert
- Heightfield Terrain Rendering Paper Niklas Elmqvist
- (subject missing) J C Lawrence
- (fwd) Roleplaying J C Lawrence
- (fwd) Roleplaying s001gmu@nova.wright.edu
- (fwd) Roleplaying Katrina McClelan
- (fwd) Roleplaying Ling
- (fwd) Roleplaying J C Lawrence
- (fwd) Roleplaying Travis Casey
- Predicting future motion intelligently J C Lawrence
- META: New Mail server and ISP J C Lawrence
- (rec.games.mud.admin) Roleplaying (fwd) Nathan F Yospe
- Persistant storage.... My current idea. Ben Greear
- Persistant storage.... My current idea. Jon A. Lambert
- Persistant storage.... My current idea. Ben Greear
- Persistant storage.... My current idea. J C Lawrence
- Persistant storage.... My current idea. Ben Greear
- Persistant storage.... My current idea. J C Lawrence
- Persistant storage.... My current idea. Ben Greear
- Persistant storage.... My current idea. Chris Gray
- Persistant storage.... My current idea. Ben Greear
- Persistant storage.... My current idea. J C Lawrence
- Persistant storage.... My current idea. Ben Greear
- UML & CORBA Greg Munt
- [MUD-Dev]: smoothing J C Lawrence
- [MUD-Dev]: smoothing J C Lawrence