The system actually dates from 1985 or so. I'm aware it isn't "the first" however it is one of the first BBS systems that:
* Was privately owned (not Compuserve or a university computer) * Had 5 simultaneous dial-up connections. * Was designed for and used mainly by non-computer people.
There were plenty of single-line BBSs at the time but very few multi-line ones that were available to the general public.
This system used the general BBS structure made popular by the CDC Plato system back in the early 1970's.
The biggest problem I've seen with GPL is that static linking your (completely NON GPL) code with a GPL library seems to make the entire program subject to the GPL. While dynamic linking to DLL's doesn't. This has always been the biggest sticking point with using libraries under full GPL (not LGPL) as part of a piece of software. I've had to avoid using many useful GPL libraries simply because the platform I'm on required static linking.
If they would straighten this out in the license I think GPL software and GPL licenses would see a LOT more use. Having a distinction between static and dynamic linking (particularly given all the different ways you can link code these days) makes usage rules much more confusing. A non GPL program shouldn't be subject to GPL unless it's source code actually contains stuff copied from GPL sources. Simply static linking with a GPL library shouldn't make you GPL too.
This is really the only objection I have to GPL, all the other terms don't bother me at all.
Sorry, I guess I missed a few details about what I was looking for. The main thing I was interested in was some library that would autogenerate the http/xml code necessary to display a variable inspection/modification GUI in a web browser. It would be nice if it was already integrated in a library that also did the minimal web-browser stuff needed to send the page to the browser, fill in the data and then manage getting the data back.
Specifically, each object in the app has metadata describing the class members it wanted to appear on this interface, their names, types, pointers...etc. All this info is used internally by the app for other things like delivering network messages, state saving and such. I'd like a library I could hand this metadata to which would then algorithmicly layout a simple GUI, send it to a browser, possiblly update the data if it changes on the app side, then accept changed values back from the user. The functionality is somewhat similar to a remote debugger, but without execution control and with the target app controlling what the user can see and tweek.
Can't really use curses or X directly because the embedded platform doesn't have them. It has an open GL driver/screen and I want to reserve that for actual app output so the UI for displaying/tweeking data needs to be on some other machine. Yes, I could whip-up a windows/linux network app that would talk to the embedded platform and display the data using a native widget set, but using an (already written) web browser seemed easier.
Forgive me if I'm describing something that sounds stupidly easy to do, I just haven't spent a ton of time coding up web-apps (I mostly do embedded stuff) so I'm not all that familiar with all the web standards and tools for doing forms & such. I could write the minimal http server, it's generating the stuff to serve up that I was more sketchy about.
So this is news? It's not like I'm working for the CIA or something. I'm just looking for background on a game feature that I did a lot of work on back in the early 90's. If I get enough data a timeline of will eventually appear on my website.
By the way, it's "Nexialist" which comes from an old A.E. Van Vougt book and is basically just a tech version of "jack of all trades"
Way back in 90-91 I wrote several replay systems for the Virtual World Entertainment multiplayer cockpit simulator games "BattleTech" and "Red Planet". One replayed the game on a 2d scrolling map (overhead view), another generated a play-by-play description of the game (text plus a map with highlight points marked), a third did a cinimatic 3d view that could either be live or a recorded game. You could manually control the cameras or let the computer do it.
I was thinking about this the other day and decided I needed to look into the history of this feature. I'm pretty sure other people had 3d replay before me, but couldn't remember if anyone had tried to do the cinematic-style with automatic AI camera control.
>No offense intended, but why didn't you just do a google search rather than asking 1.5million slashdotters
No offense intended here either, but why is it that every time someone posts an "ask slashdot" question someone else feels compelled to complain (and occasionally get downright rude) about why the user didn't just "google it"?
Google will get you articles and advertisements, true, but most of the time what the questioner is really after is peoples OPINIONS and EXPERIENCES.
If I post a question like "what's the best backup program you've used on linux" I'm looking for 1.5 million slashdotters EXPERIENCES with backup programs...a google search will get me a list of programs and some reviews if I'm lucky, but that's no substitute for hearing from a bunch of people who've actually DONE or USED something.
Hearing from a few hundred or thousand responders is a better recommendation than a "C-NET" review anyday!
Americas Army (www.americasarmy.com) is great in an office. Particularly because it is totally FREE and runs on Linux, Mac and Windows.
It's an up-to-date engine (unreal 2003) and seems to work fine even with older cards and laptops that have graphics accelerators. It has lots of adjustments to sound and graphics quality to tune performance for slower machines.
If you run your own server you can relax the playbalancing requirements so people can get any weapon they want.
I've found it's kind of a pain sometimes to download, with all the primary sites being slow but if you search for it on Google you can usually find a secondary site or bittorrent server for it.
There is also a self configuring linux bootable CD of it for people who don't want to install it on their hard drives.
I remeber Battletech, I wrote the darned thing (or a goodsized piece of it anyway) I was the Chief Engineer at the company that made the games and simulators.
A good portion of the company was swallowed by Microsoft in '97 to become the MechWarrior development team but what's left of the original company (Virtual World Entertaniment) continues to operate quite a few sites.
True, it's not as nice looking as today's games but considering that the hardware hasn't been updated since '95 I'd expect that. What's really surprising is that this game has been in continuous play since 1990! How many games hold people's interest for that long?
I understand they are going through a hardware/software upgrade right now.
For some time I've been interested in starting up a new company to do something like this but haven't found anyone interested in putting up the money.
There's more info on the BattleTech cockpits on my website (which is a mess right now, look here and also here). And don't forget about Red Planet, the less popular (but in many people's opinion) more exciting second game we had.
During the mid '80s I brought up one of the first privately owned multi-line BBS systems. It ran some software I developed called "The Connection". The computer was an Altos 586 with 5 dial-up lines (2400 baud! WooHoo!) under the Xenix OS.
The main difference between this board and most of the others around at the time was that the community of people were largely NOT computer geek types (like me) but more-or-less normal folks who just happened to have computers. It was designed following the model of the CDC "Plato" system to be extremely easy to use.
At the time I was trying to use it to convince investors to put money into making a large scale national E-Mail/bulletin board service but was (of course) told I was crazy, the average person would NEVER buy their own computer or use E-Mail.
Still got the computer laying around here somewhere, but would have to figure out the right way to wire up a serial cable to make it talk to my PC if I want to use it;-)
This site is strange, every time I connect to it with a different machine, I'm redirected to a different site. My (linux) PC sent me to www.lmp3.net, my (windows) laptop went to www.listen4ever.com and my home (windows) machine went to www.mp3mediaworld.com. Maybe this is why they are having trouble tracking the thing down!
Take a piezo buzzer or Sonaralert (if you want something LOUD) and wire it to a standard-issue microswitch. You can get microswitches with actuators that are a short piece of metal about the size of a ball-point-pen clip. Actuation force can be VERY tiny (grams) with motion as little as 1/8 to 1/4 inch.
Some versions with cat-whisker actuators are also avaiable, just a bit of wire sticking straight up that you give a push in any direction. You can build something similar out of a couple of paper clips if you want REAL cheap.
You could add a latch/time circuit so you wouldn't have to keep the switch depressed, ie: a quick press would sound the alarm for some set period of time.
There are also preassembled photosensors with a light source and sensor and a gap between the two, stick a finger between them and it triggers, zero force required.
I've also seen the microswitch thing work as a blink/squint sensor. You stick the wire actuator to the skin above/below the eye and a good squint will trigger it.
One last idea, shine a low-power IR led at the corner of the eye, read the reflection brightness with a photocell. Now looking to that side causes the colored part of the eye to reduce the reflected light, triggering the sensor.
The biggest problem with running something off the eyebrow or eye look/blink is usually preventing it from going off by accident, or if the person goes to sleep.
There are also devices that actuate by sucking/blowing on a straw or pushing with the toung or chin...though these don't work so well if you're on a respirator.
I used to put together computers for industrial applications in Steel Mills, an environment that I think is even harsher in terms of heat, corosives and vibration that most of what's been talked about so far. Anyway, our approach was to purchase what is called a NEMA enclosure and put all the hardware inside. NEMA is a standard (followed by a number) that indicates how sealed it is. Depending on the amount of stuff in the box, you can get heat exchangers or actual active air conditioning units that keep the inside of the box cool without letting in ANY outside air at all. Stick on a clear plastic front so you can see the monitor inside, and you're pretty much set for the harshest environment.
The only real hook is what to do for a keyboard and mouse which must be outside the box. You can get rugged keyboards and sealed joystick/mouse devices but they tend to be VERY pricy. I would only go for one of these if you think the keyboard is likely to be immersed or pressure-washed regularly. In a lot of cases we just used a cheap standard keyboard, possiblly inside a plastic bag, and kept a few spares around for when they finally broke.
I was constantly surprised by how much abuse a keyboard would take wihtout breaking. I once saw one in a mill, covered with (conductive) carbon black so thick you couldn't see the letters on the keys...but the darned thing still worked!
There are actually several grades of NEMA enclosures, some more protective, some less. They vary from a simple dust-tight box to one that's indoor/outdoor water, dust, oil and corrosion proof. They come in all sizes from lunchbox-size to full 19" racks.
Here's some clarifications regarding my problems with "traditional" modeling packages that I am looking for solutions to.
1. EXPENSIVE--I realize they are selling to a small market but it is very pricy to give a large team of artists their own copies of Max, Maya or whatever. It would be nice if these companies at least offered a version without the film-quality renderer, which game artists rarely use (ok, cutscenes maybe, but other than that who needs it?)
2. Lets you do things that don't translate to hardware well: - non-power-of-two textures (no way to force the modeler to reformat the textures to a sensable size) - inefficient primitives (no way to remove interior polygons in many cases) - no way to lock out features that hardware can't reproduce, like some procedural textures.
3. Poor support for things hardware DOES support. - Triangle strips/fans, no way to generate, see or edit them IN the modeler, particularly editing-in points to corner-turn strips. - Hardware shaders, no way to see them in the preview windows - Poor support for baking lighting info into textures/vertices - Hard to preview art in different rendering modes (bilinear, trilinear, AA, ansitropic filtering...etc) to determine what looks best.
4. Poor capabilities for optimizing models. - need tools for removing invisible (interior) polygons - need tools for turning texture res up and down to quickly find the resolution that looks the best and resampling/filtering textures. - better support for generating Levels of Detail - No good way to track the texture/polygon budget of the model you're working on. - Poor support for making multiple versions of the same model (ie: when you want to make varients for cards that do rendering/shading in different ways, want to do high/low performace versions of a model...etc.
I certainly don't expect the modeler companies to produce something where the preview output will be an exact match for my engine. But it would be nice if they had a lot more "hardware friendly" modes so you don't have to spend a lot of time training artists what features of their tools work and what don't, or teaching them to "guess" what a particular effect will look like when done on the hardware.
I've had to write a LOT of different kinds of exporters/postprocessors to do these kinds of things and it's quite a bit more difficult to do, for example, triangle strip/fan generation in an exporter than to have the modeler generate properly stripped/faned primitives in the first place. (ie: make a cylinder as one strip and two fans PLEASE)
Sure, you can fix some of these problems with plugins, post processors, exporters...etc, but almost all of them are ten times easier to fix if you do it in the modeler itself.
I think any legislation to attempt to include copy protection in all hardware is doomed. Mainly because computers are advancing so quickly that by the time you had figured out a standard for encrypting content, the typical high-end computer would be able to brute-force break it in a few hours.
One piece of legislation I think is REALLY needed though, would be to actually give a clear definition of what "fair use" actually is. I've read some of the copyright law and lots of opinions on what various people think it means and all it's done is convince me that nobody, lawyer or layperson really understands what constitutes fair use.
Some sort of plain-and-simple law that spells it out would solve a multitude of problems currently in the legal system. People can't obey a law if they don't understand what is and isn't legal.
The main reason we wanted to go with an 802.11 wireless ethernet was because it would have enough speed to send back video, and it would work anywhere in our offices that has the net setup. And by high-gain antenna, I just ment a high-gain omindirectional one...the antennas on most wireless cards are far from optimal.
We did try the thing with X10-wireless cam which is what got us started on this whole thing. It was TONS of fun but the problem was the X10 cam gets a pretty poor quality picture when the car is moving and bouncing around.
I work at Sony R&D and have been asked questions like this A LOT. The PS2 hardware and developer program is currently geared for commercial developers and can present a hobbiest/academic project with some serious hurdles.
1. You need to sign an NDA to get a full developer kit and all the hardware details.
2. The consumer version of the PS2 is only capable of booting disks produced by Sony and will not boot a CDR.
3. To load up your own code, a development system is required, which is expensive
4. PS2 programming requires good knowledge of the hardware, writing code for multiprocessor machines and experience programming "close to the metal" (dealing with DMA...etc). It's not hard to write code for, but if you've never done any of the stuff I just mentioned before, it can take a bit of getting used to.
Assuming you can get around these hurdles somehow, as previous people have mentioned, writing a good game on ANY platform is not a small undertaking if you've never done it before. A typical commercial game takes 18 months to two years to create, and often has quite a large team of people doing it. On top of that, people (including those grading your project) are pretty used to professional quality games these days, which is a tough yardstick to be measured against. Something that is not a game might be a better choice
All this being said, the situation could change. If you read this old Slashdot article you will see that there is a PS2 Linux kit available in Japan and that Sony is at least considering releasing it in the US. The web site mentioned in that article is still open, so if you haven't registered your interest yet, go do it!
If I'm not mistaken, the $200 for the Linux kit in Japan included a 40gb hard disk, keyboard, mouse and network adaptor. It's NOT just the distro alone.
I'm out here on the 24. network of @home in San Francisco and just saw a HUGE flood of ARP requests. It's quieted down now but a few minutes ago it was running somewhere around 50-100 a second or so. Not really sure how long it was going on, at least half an hour. Is this likely related to code-red scanning machines on the same net as me?
The best one of these I remember was when Nolen Bushnel's "Androbots" company was demoing at the Consumer Electronics Show. They wanted to show how their robot could be used in an average home and had setup a mock-up living room and kitchen. The kitchen was equipped with a "robot fridge" which could dispense cans of beer down a chute and into special "arm" attached to the robot's shoulder that could hold about 4 cans.
So the demo is, the guy is watching the superbowl and wants a cold beer. Instead of getting up he sends his trusty robot to get it for him. The robot trundles through the door to kitchen and rolls up to the fridge which obediently dispenses a can of beer. The can rolls down the chute and BREAKS THE ROBOT'S ARM CLEAN OFF at the shoulder. The second beer is dispensed, bouncing off the robot's body and rolling across the kitchen floor.
The poor spokesman is still sitting in his easy chair and wondering why the crowd is laughing so hard...then the robot rolls back into the living room and the guy reaches for his beer.....
Setting up your memory allocators to flood RAM with the NAN (not a number) value will catch uninitialized floating point data instantly. To catch other missed initializers, flooding RAM with a different value each time you run can help smoke them out.
Built in test code that periodically checks structures to make sure the values in them make sense is also very useful and easy to do in C++
Also, having a few "signature" fields in your structures (essentially, unused data items that are initialized to a specific value and never changed) can help locate tough-to-find memory overwrites. Just check the signature field of a structure before using the other data in that structure. If the signature isn't right, the memory has been overwritten
It can also be helpful to have a pointer check routine that looks at the value of a pointer and determines if it is legal for the platform you are on. For example, checking to make sure it falls in a range where the hardware actually has memory, or making sure it doesn't overlap system reserved areas
Just to answer a few questions that various people have brought up.
1. Why not just use standard wire/radio based intercoms? Basically for the same reasons that Disney is using ethernet to distribute audio
throughout their new Tokyo theme park. The location I'm looking at will already have Ethernet drops EVERYWHERE and wireless Ethernet as
well. Parallel wiring some other system is a lot of extra work, and in a high electrical noise environment a digital system will be much cleaner.
Radio systems don't (usually) allow everyone on a channel to talk at once. Most commercial wired systems don't allow computers to control
how people are linked together on channels.
2. Why not use Gamevoice or other PC programs? A couple of reasons, first, the games I'm running will probably not be windows based, and
most of these systems are windows. Second, all the ones I've tried are pretty poor quality, and don't allow party-line style mixing. Third, they
don't provide any way for another program to control what channels you get assigned to...etc.
3. Wouldn't other systems be cheaper? It's doubtful that any other setup would be cheaper in this instance. The cost of pulling extra cable
everywhere would most likely kill it right there. Just about everywhere an intercom might be needed, there's already a Ethernet drop or wireless
coverage.
4. Worried about script kiddies? Not really, the site will be a high profile target anyway, so it will need to be be pretty well protected.
If I describe a bit more this may make more sense. The place I'm talking about will have a variety of "cockpits" that players play games from.
These can be on-the-fly grouped into multiplayer games of any size, number of teams...etc. ie: you might have one 32 player game with two
teams one moment, then have 4 eight player games with two teams each the next. All this is setup from a central control console, which needs
to be able to setup the channels for the intercom at the same time. Also, if someone has trouble while playing and hits a "help" button, we want
to be able to switch them to a private channel with one of the site's operators, then switch back on the fly. At various times you would want to
switch an intercom into the house PA system as well to make announcements or let people listen to a game. Another reason for wanting to use Ethernet is that occasionally, we may want to route intercom traffic between two sites via the Internet, so if the system was already all digital, it would make this easier.
When I first saw the CobraNet stuff Disney was using, it looked pretty cool, but I quickly found that their audio in/out boxes typically have in's
and out's only in groups of 8 or 16. This if fine if you're running a theme park, but for smaller setups you need something that can drive a single
speaker.
Ideally, I'd like a little beltpack-like box you could plug headphones/ethernet into for intercoms, a similar box designed to drive a speaker
(including a power amp) and a central PC to handle all the mixing/control. There will be a ton of bandwidth available in this place, so it would be perfectly fine to send uncompressed audio like CobraNet does
As much as I'd hate to do it, I get the feeling I may have to build the thing myself...anyone got any good suggestions for a small, cheap, single board computer with audio in/out, 100Base T Ethernet and just enough CPU horsepower to keep up with sending/receiving uncompressed audio?
The cockpits you see in Dave & Busters, Jillians and some other places are the ones I helped design and write software for and yes, they were quite expensive to make!
Actually, the priciest bit was the flight-simulator-style infinity optics system which makes the display seem like looking out a window, but that's another story.
I don't think what I'm asking for is exactly a "magic answer" (note I'm looking for less than $400 PER SMALL SCREEN, not for the whole thing)...I mean, I could buy PDA's off-the-shelf (wholesale, quantity) for under $400 each and come up with a way to mount them on the panel. I was hoping someone would have seen something similar but easier to mount/use...considering I don't need a super-compact design with batteries, touch screen...etc. you would think there MIGHT be a cheaper solution out there than buying a PDA.
I have looked into multi-head video cards (which are expensive because not a lot are sold) but seeing as how I want to drive 5-6 of these little screens by the time you deal with (Linux) driver integration, cost of card, monitors and a motherboard with enough slots it can easily come to around $400 per monitor. A little programmable box has the potential to work so much better, and it moves all the drawing overhead off of the main CPU.
I used to work in factory automation and had to solve this problem a lot. There are quite a few industrial automation places like Allen Bradley (http://www.ab.com) that sell this stuff. The problem is they sell it at a very high price.
The solutions range from flat membrane keyboards to the rubber "keyboard condoms" mentioned earlier.
The main problem is that you can usually buy a dozen or more cheap keyboards for the cost of one of these industrial ones. So when we did a factory we frequently put a stock keyboard in a covered drawer, unless it was going to be used a lot.
I have seen standard keyboards survive SURPRISING things...one metalurgy lab in a detroit steel mill had a thick layer of carbon-black powder (conductive!) on every keyboard and monitor in the shop and they were all STILL working!
My advice would be to consider the covered drawer or just replacing the keyboard frequently unless your environment is super hostile or the keyboard working is very critical.
If you need a keyboard that works in a corrosive or explosive environment, then spend the money on the industrial ones.
Milo
Some people have suggested just using NFS or other file sharing setups to share the MP3 drives between multiple machines. I don't think this would work too well if some of the machines wern't on the same physical LAN (say, one at home on cable modem, several at work on a T1). It also might expose you to potential security holes. This is why I was hoping to find a networkable jukebox, it would seem a jukebox software with a very limited streaming/copy system would be less likely to be a security problem.
Having a jukebox with some serving ability makes it easier to control load, like how many streams you send at a time. Also, I was hoping for something that was (or could be made) cross-platform and nearly transparent to the user so users don't have to go through setting up NFS or other filesharing stuff.
It seemed like the best approach would be to have a jukebox with a batch of "local" songs and a web-style cache of popular "non-local" songs and the ability to send/receive realtime playable streams between jukeboxes. Hook that up to a database of what's on other people's machines with an automatic transfer to your local cache and you've got something that can cheaply serve huge amounts of content, without a central site.
Slashdot Mirror
The system actually dates from 1985 or so. I'm aware it isn't "the first" however it is one of the first BBS systems that:
* Was privately owned (not Compuserve or a university computer)
* Had 5 simultaneous dial-up connections.
* Was designed for and used mainly by non-computer people.
There were plenty of single-line BBSs at the time but very few multi-line ones that were available to the general public.
This system used the general BBS structure made popular by the CDC Plato system back in the early 1970's.
The biggest problem I've seen with GPL is that static linking your (completely NON GPL) code with a GPL library seems to make the entire program subject to the GPL. While dynamic linking to DLL's doesn't. This has always been the biggest sticking point with using libraries under full GPL (not LGPL) as part of a piece of software. I've had to avoid using many useful GPL libraries simply because the platform I'm on required static linking.
If they would straighten this out in the license I think GPL software and GPL licenses would see a LOT more use. Having a distinction between static and dynamic linking (particularly given all the different ways you can link code these days) makes usage rules much more confusing. A non GPL program shouldn't be subject to GPL unless it's source code actually contains stuff copied from GPL sources. Simply static linking with a GPL library shouldn't make you GPL too.
This is really the only objection I have to GPL, all the other terms don't bother me at all.
Sorry, I guess I missed a few details about what I was looking for. The main thing I was interested in was some library that would autogenerate the http/xml code necessary to display a variable inspection/modification GUI in a web browser. It would be nice if it was already integrated in a library that also did the minimal web-browser stuff needed to send the page to the browser, fill in the data and then manage getting the data back.
Specifically, each object in the app has metadata describing the class members it wanted to appear on this interface, their names, types, pointers...etc. All this info is used internally by the app for other things like delivering network messages, state saving and such. I'd like a library I could hand this metadata to which would then algorithmicly layout a simple GUI, send it to a browser, possiblly update the data if it changes on the app side, then accept changed values back from the user. The functionality is somewhat similar to a remote debugger, but without execution control and with the target app controlling what the user can see and tweek.
Can't really use curses or X directly because the embedded platform doesn't have them. It has an open GL driver/screen and I want to reserve that for actual app output so the UI for displaying/tweeking data needs to be on some other machine. Yes, I could whip-up a windows/linux network app that would talk to the embedded platform and display the data using a native widget set, but using an (already written) web browser seemed easier.
Forgive me if I'm describing something that sounds stupidly easy to do, I just haven't spent a ton of time coding up web-apps (I mostly do embedded stuff) so I'm not all that familiar with all the web standards and tools for doing forms & such. I could write the minimal http server, it's generating the stuff to serve up that I was more sketchy about.
So this is news? It's not like I'm working for the CIA or something. I'm just looking for background on a game feature that I did a lot of work on back in the early 90's. If I get enough data a timeline of will eventually appear on my website.
By the way, it's "Nexialist" which comes from an old A.E. Van Vougt book and is basically just a tech version of "jack of all trades"
No lawsuits or patents going on here...
Way back in 90-91 I wrote several replay systems for the Virtual World Entertainment multiplayer cockpit simulator games "BattleTech" and "Red Planet". One replayed the game on a 2d scrolling map (overhead view), another generated a play-by-play description of the game (text plus a map with highlight points marked), a third did a cinimatic 3d view that could either be live or a recorded game. You could manually control the cameras or let the computer do it.
I was thinking about this the other day and decided I needed to look into the history of this feature. I'm pretty sure other people had 3d replay before me, but couldn't remember if anyone had tried to do the cinematic-style with automatic AI camera control.
>No offense intended, but why didn't you just do a google search rather than asking 1.5million slashdotters
No offense intended here either, but why is it that every time someone posts an "ask slashdot" question someone else feels compelled to complain (and occasionally get downright rude) about why the user didn't just "google it"?
Google will get you articles and advertisements, true, but most of the time what the questioner is really after is peoples OPINIONS and EXPERIENCES.
If I post a question like "what's the best backup program you've used on linux" I'm looking for 1.5 million slashdotters EXPERIENCES with backup programs...a google search will get me a list of programs and some reviews if I'm lucky, but that's no substitute for hearing from a bunch of people who've actually DONE or USED something.
Hearing from a few hundred or thousand responders is a better recommendation than a "C-NET" review anyday!
Americas Army (www.americasarmy.com) is great in an office. Particularly because it is totally FREE and runs on Linux, Mac and Windows.
It's an up-to-date engine (unreal 2003) and seems to work fine even with older cards and laptops that have graphics accelerators. It has lots of adjustments to sound and graphics quality to tune performance for slower machines.
If you run your own server you can relax the playbalancing requirements so people can get any weapon they want.
I've found it's kind of a pain sometimes to download, with all the primary sites being slow but if you search for it on Google you can usually find a secondary site or bittorrent server for it.
There is also a self configuring linux bootable CD of it for people who don't want to install it on their hard drives.
I remeber Battletech, I wrote the darned thing (or a goodsized piece of it anyway) I was the Chief Engineer at the company that made the games and simulators.
A good portion of the company was swallowed by Microsoft in '97 to become the MechWarrior development team but what's left of the original company (Virtual World Entertaniment) continues to operate quite a few sites.
True, it's not as nice looking as today's games but considering that the hardware hasn't been updated since '95 I'd expect that. What's really surprising is that this game has been in continuous play since 1990! How many games hold people's interest for that long?
I understand they are going through a hardware/software upgrade right now.
For some time I've been interested in starting up a new company to do something like this but haven't found anyone interested in putting up the money.
There's more info on the BattleTech cockpits on my website (which is a mess right now, look here and also here). And don't forget about Red Planet, the less popular (but in many people's opinion) more exciting second game we had.
During the mid '80s I brought up one of the first privately owned multi-line BBS systems. It ran some software I developed called "The Connection". The computer was an Altos 586 with 5 dial-up lines (2400 baud! WooHoo!) under the Xenix OS.
;-)
The main difference between this board and most of the others around at the time was that the community of people were largely NOT computer geek types (like me) but more-or-less normal folks who just happened to have computers. It was designed following the model of the CDC "Plato" system to be extremely easy to use.
At the time I was trying to use it to convince investors to put money into making a large scale national E-Mail/bulletin board service but was (of course) told I was crazy, the average person would NEVER buy their own computer or use E-Mail.
Still got the computer laying around here somewhere, but would have to figure out the right way to wire up a serial cable to make it talk to my PC if I want to use it
This site is strange, every time I connect to it with a different machine, I'm redirected to a different site. My (linux) PC sent me to www.lmp3.net, my (windows) laptop went to www.listen4ever.com and my home (windows) machine went to www.mp3mediaworld.com. Maybe this is why they are having trouble tracking the thing down!
Take a piezo buzzer or Sonaralert (if you want something LOUD) and wire it to a standard-issue microswitch. You can get microswitches with actuators that are a short piece of metal about the size of a ball-point-pen clip. Actuation force can be VERY tiny (grams) with motion as little as 1/8 to 1/4 inch.
Some versions with cat-whisker actuators are also avaiable, just a bit of wire sticking straight up that you give a push in any direction. You can build something similar out of a couple of paper clips if you want REAL cheap.
You could add a latch/time circuit so you wouldn't have to keep the switch depressed, ie: a quick press would sound the alarm for some set period of time.
There are also preassembled photosensors with a light source and sensor and a gap between the two, stick a finger between them and it triggers, zero force required.
I've also seen the microswitch thing work as a blink/squint sensor. You stick the wire actuator to the skin above/below the eye and a good squint will trigger it.
One last idea, shine a low-power IR led at the corner of the eye, read the reflection brightness with a photocell. Now looking to that side causes the colored part of the eye to reduce the reflected light, triggering the sensor.
The biggest problem with running something off the eyebrow or eye look/blink is usually preventing it from going off by accident, or if the person goes to sleep.
There are also devices that actuate by sucking/blowing on a straw or pushing with the toung or chin...though these don't work so well if you're on a respirator.
I used to put together computers for industrial applications in Steel Mills, an environment that I think is even harsher in terms of heat, corosives and vibration that most of what's been talked about so far. Anyway, our approach was to purchase what is called a NEMA enclosure and put all the hardware inside. NEMA is a standard (followed by a number) that indicates how sealed it is. Depending on the amount of stuff in the box, you can get heat exchangers or actual active air conditioning units that keep the inside of the box cool without letting in ANY outside air at all. Stick on a clear plastic front so you can see the monitor inside, and you're pretty much set for the harshest environment.
The only real hook is what to do for a keyboard and mouse which must be outside the box. You can get rugged keyboards and sealed joystick/mouse devices but they tend to be VERY pricy. I would only go for one of these if you think the keyboard is likely to be immersed or pressure-washed regularly. In a lot of cases we just used a cheap standard keyboard, possiblly inside a plastic bag, and kept a few spares around for when they finally broke.
I was constantly surprised by how much abuse a keyboard would take wihtout breaking. I once saw one in a mill, covered with (conductive) carbon black so thick you couldn't see the letters on the keys...but the darned thing still worked!
There are actually several grades of NEMA enclosures, some more protective, some less. They vary from a simple dust-tight box to one that's indoor/outdoor water, dust, oil and corrosion proof. They come in all sizes from lunchbox-size to full 19" racks.
Here's some clarifications regarding my problems with "traditional" modeling packages that I am looking for solutions to.
1. EXPENSIVE--I realize they are selling to a small market but it is very pricy to give a large team of artists their own copies of Max, Maya or whatever. It would be nice if these companies at least offered a version without the film-quality renderer, which game artists rarely use (ok, cutscenes maybe, but other than that who needs it?)
2. Lets you do things that don't translate to hardware well:
- non-power-of-two textures (no way to force the modeler to reformat the textures to a sensable size)
- inefficient primitives (no way to remove interior polygons in many cases)
- no way to lock out features that hardware can't reproduce, like some procedural textures.
3. Poor support for things hardware DOES support.
- Triangle strips/fans, no way to generate, see or edit them IN the modeler, particularly editing-in points to corner-turn strips.
- Hardware shaders, no way to see them in the preview windows
- Poor support for baking lighting info into textures/vertices
- Hard to preview art in different rendering modes (bilinear, trilinear, AA, ansitropic filtering...etc) to determine what looks best.
4. Poor capabilities for optimizing models.
- need tools for removing invisible (interior) polygons
- need tools for turning texture res up and down to quickly find the resolution that looks the best and resampling/filtering textures.
- better support for generating Levels of Detail
- No good way to track the texture/polygon budget of the model you're working on.
- Poor support for making multiple versions of the same model (ie: when you want to make varients for cards that do rendering/shading in different ways, want to do high/low performace versions of a model...etc.
I certainly don't expect the modeler companies to produce something where the preview output will be an exact match for my engine. But it would be nice if they had a lot more "hardware friendly" modes so you don't have to spend a lot of time training artists what features of their tools work and what don't, or teaching them to "guess" what a particular effect will look like when done on the hardware.
I've had to write a LOT of different kinds of exporters/postprocessors to do these kinds of things and it's quite a bit more difficult to do, for example, triangle strip/fan generation in an exporter than to have the modeler generate properly stripped/faned primitives in the first place. (ie: make a cylinder as one strip and two fans PLEASE)
Sure, you can fix some of these problems with plugins, post processors, exporters...etc, but almost all of them are ten times easier to fix if you do it in the modeler itself.
I think any legislation to attempt to include copy protection in all hardware is doomed. Mainly because computers are advancing so quickly that by the time you had figured out a standard for encrypting content, the typical high-end computer would be able to brute-force break it in a few hours.
One piece of legislation I think is REALLY needed though, would be to actually give a clear definition of what "fair use" actually is. I've read some of the copyright law and lots of opinions on what various people think it means and all it's done is convince me that nobody, lawyer or layperson really understands what constitutes fair use.
Some sort of plain-and-simple law that spells it out would solve a multitude of problems currently in the legal system. People can't obey a law if they don't understand what is and isn't legal.
We did try the thing with X10-wireless cam which is what got us started on this whole thing. It was TONS of fun but the problem was the X10 cam gets a pretty poor quality picture when the car is moving and bouncing around.
1. You need to sign an NDA to get a full developer kit and all the hardware details.
2. The consumer version of the PS2 is only capable of booting disks produced by Sony and will not boot a CDR.
3. To load up your own code, a development system is required, which is expensive
4. PS2 programming requires good knowledge of the hardware, writing code for multiprocessor machines and experience programming "close to the metal" (dealing with DMA...etc). It's not hard to write code for, but if you've never done any of the stuff I just mentioned before, it can take a bit of getting used to.
Assuming you can get around these hurdles somehow, as previous people have mentioned, writing a good game on ANY platform is not a small undertaking if you've never done it before. A typical commercial game takes 18 months to two years to create, and often has quite a large team of people doing it. On top of that, people (including those grading your project) are pretty used to professional quality games these days, which is a tough yardstick to be measured against. Something that is not a game might be a better choice
All this being said, the situation could change. If you read this old Slashdot article you will see that there is a PS2 Linux kit available in Japan and that Sony is at least considering releasing it in the US. The web site mentioned in that article is still open, so if you haven't registered your interest yet, go do it!
If I'm not mistaken, the $200 for the Linux kit in Japan included a 40gb hard disk, keyboard, mouse and network adaptor. It's NOT just the distro alone.
Kangaroo Koncepts
The best one of these I remember was when Nolen Bushnel's "Androbots" company was demoing at the Consumer Electronics Show. They wanted to show how their robot could be used in an average home and had setup a mock-up living room and kitchen. The kitchen was equipped with a "robot fridge" which could dispense cans of beer down a chute and into special "arm" attached to the robot's shoulder that could hold about 4 cans.
So the demo is, the guy is watching the superbowl and wants a cold beer. Instead of getting up he sends his trusty robot to get it for him. The robot trundles through the door to kitchen and rolls up to the fridge which obediently dispenses a can of beer. The can rolls down the chute and BREAKS THE ROBOT'S ARM CLEAN OFF at the shoulder. The second beer is dispensed, bouncing off the robot's body and rolling across the kitchen floor.
The poor spokesman is still sitting in his easy chair and wondering why the crowd is laughing so hard...then the robot rolls back into the living room and the guy reaches for his beer.....
Built in test code that periodically checks structures to make sure the values in them make sense is also very useful and easy to do in C++
Also, having a few "signature" fields in your structures (essentially, unused data items that are initialized to a specific value and never changed) can help locate tough-to-find memory overwrites. Just check the signature field of a structure before using the other data in that structure. If the signature isn't right, the memory has been overwritten
It can also be helpful to have a pointer check routine that looks at the value of a pointer and determines if it is legal for the platform you are on. For example, checking to make sure it falls in a range where the hardware actually has memory, or making sure it doesn't overlap system reserved areas
1. Why not just use standard wire/radio based intercoms? Basically for the same reasons that Disney is using ethernet to distribute audio throughout their new Tokyo theme park. The location I'm looking at will already have Ethernet drops EVERYWHERE and wireless Ethernet as well. Parallel wiring some other system is a lot of extra work, and in a high electrical noise environment a digital system will be much cleaner. Radio systems don't (usually) allow everyone on a channel to talk at once. Most commercial wired systems don't allow computers to control how people are linked together on channels.
2. Why not use Gamevoice or other PC programs? A couple of reasons, first, the games I'm running will probably not be windows based, and most of these systems are windows. Second, all the ones I've tried are pretty poor quality, and don't allow party-line style mixing. Third, they don't provide any way for another program to control what channels you get assigned to...etc.
3. Wouldn't other systems be cheaper? It's doubtful that any other setup would be cheaper in this instance. The cost of pulling extra cable everywhere would most likely kill it right there. Just about everywhere an intercom might be needed, there's already a Ethernet drop or wireless coverage.
4. Worried about script kiddies? Not really, the site will be a high profile target anyway, so it will need to be be pretty well protected. If I describe a bit more this may make more sense. The place I'm talking about will have a variety of "cockpits" that players play games from. These can be on-the-fly grouped into multiplayer games of any size, number of teams...etc. ie: you might have one 32 player game with two teams one moment, then have 4 eight player games with two teams each the next. All this is setup from a central control console, which needs to be able to setup the channels for the intercom at the same time. Also, if someone has trouble while playing and hits a "help" button, we want to be able to switch them to a private channel with one of the site's operators, then switch back on the fly. At various times you would want to switch an intercom into the house PA system as well to make announcements or let people listen to a game. Another reason for wanting to use Ethernet is that occasionally, we may want to route intercom traffic between two sites via the Internet, so if the system was already all digital, it would make this easier.
When I first saw the CobraNet stuff Disney was using, it looked pretty cool, but I quickly found that their audio in/out boxes typically have in's and out's only in groups of 8 or 16. This if fine if you're running a theme park, but for smaller setups you need something that can drive a single speaker.
Ideally, I'd like a little beltpack-like box you could plug headphones/ethernet into for intercoms, a similar box designed to drive a speaker (including a power amp) and a central PC to handle all the mixing/control. There will be a ton of bandwidth available in this place, so it would be perfectly fine to send uncompressed audio like CobraNet does
As much as I'd hate to do it, I get the feeling I may have to build the thing myself...anyone got any good suggestions for a small, cheap, single board computer with audio in/out, 100Base T Ethernet and just enough CPU horsepower to keep up with sending/receiving uncompressed audio?
Hope this helps clarify things
Actually, the priciest bit was the flight-simulator-style infinity optics system which makes the display seem like looking out a window, but that's another story.
I don't think what I'm asking for is exactly a "magic answer" (note I'm looking for less than $400 PER SMALL SCREEN, not for the whole thing)...I mean, I could buy PDA's off-the-shelf (wholesale, quantity) for under $400 each and come up with a way to mount them on the panel. I was hoping someone would have seen something similar but easier to mount/use...considering I don't need a super-compact design with batteries, touch screen...etc. you would think there MIGHT be a cheaper solution out there than buying a PDA.
I have looked into multi-head video cards (which are expensive because not a lot are sold) but seeing as how I want to drive 5-6 of these little screens by the time you deal with (Linux) driver integration, cost of card, monitors and a motherboard with enough slots it can easily come to around $400 per monitor. A little programmable box has the potential to work so much better, and it moves all the drawing overhead off of the main CPU.
The solutions range from flat membrane keyboards to the rubber "keyboard condoms" mentioned earlier.
The main problem is that you can usually buy a dozen or more cheap keyboards for the cost of one of these industrial ones. So when we did a factory we frequently put a stock keyboard in a covered drawer, unless it was going to be used a lot. I have seen standard keyboards survive SURPRISING things...one metalurgy lab in a detroit steel mill had a thick layer of carbon-black powder (conductive!) on every keyboard and monitor in the shop and they were all STILL working! My advice would be to consider the covered drawer or just replacing the keyboard frequently unless your environment is super hostile or the keyboard working is very critical. If you need a keyboard that works in a corrosive or explosive environment, then spend the money on the industrial ones. Milo
Having a jukebox with some serving ability makes it easier to control load, like how many streams you send at a time. Also, I was hoping for something that was (or could be made) cross-platform and nearly transparent to the user so users don't have to go through setting up NFS or other filesharing stuff.
It seemed like the best approach would be to have a jukebox with a batch of "local" songs and a web-style cache of popular "non-local" songs and the ability to send/receive realtime playable streams between jukeboxes. Hook that up to a database of what's on other people's machines with an automatic transfer to your local cache and you've got something that can cheaply serve huge amounts of content, without a central site.