Ah, heck - that's where it breaks down - the tiff to postscript utils only make a non-searchable bitmap (I read that, and still wrote my method - I must be stupid today - my bad).
Of course, if such a program existed - tiff -> OCR'd postscript (searchable text), then my solution would work (I am not advocating the manual cutting and pasting of images - a piece of code would have to be written to that) to convert the stuff to html.
Of course, if one went ahead and built an OCR engine (converting tiff to PS), then they could go all the way and add the extra image stuff in and save all the steps I added...
Here is a possible solution (from scanned document to html pages), that could work as long as there weren't any funky symbols, etc. embedded in the text (heck, may even work with that if you are deft with a sharpie - as explained in step 1)...
Steps for conversion:
1. For pages with images, draw a colored border around each image on each page. Make the color something that will sharply stand out (like bright green).
2. Tricky part - process each tiff image (in a looped script) doing the following:
a. Scan each page to color tiff, with sequential filenames (001.tiff, 002.tiff).
b. Using a custom written utility, build two new tiff images - a tiff of the page without the color-bordered images, and a tiff of the color-bordered image(s) on the page. Number the page images like (p001.tiff, p002.tiff), and the images for each page (p001i001.tiff, p001i002.tiff), so that it is known which images go with what page.
c. Convert each page image to postscript, then to html (unless there is a tiff2html tool out there?) - preserve the filenames (p001.html, p002.html), modifying only the extension.
d. Convert each image for each page to a (gif, jpeg, png), preserving the filenames (p001i001.png, p001i002.png), with a new extension.
e. Add IMG tags for the images to the end (or beginning) of the html pages, for each page.
3. After batch conversion, go back and proofread/reformat pages (to position images where they should go, etc).
Everything to do this should exist in some form already - except for maybe step 2b - that might be a completely custom tool that needs to be written, but it shouldn't be very hard to code (loop through bytes of image, looking for the sharp color changes - kinda like edge detection code - saving/masking the areas in the outlines)...
I have been sick the past few days - but anyhow, if I understand you correctly, you are saying that by having this display somehow track where you (move/turn) your head, it tracks with it (kinda like if I turn my head to the right, the monitor in front of me moves to the right) - would increase the FOV?
If this is what you mean, then, in a word - no.
FOV is defined by the combined angular measument of a pair of imaginary "cones" radiating from the approximate center of each eye (one cone per eye). There are both horizontal and vertical FOV measurements (generally expressed in degrees) - so each "cone" can actually have an elliptical cross section (generally, vertical FOV is smaller than horizontal FOV in HMDs). Some HMD manufacturers are beginning to use a diagonal FOV measurment - muddling the issue further (kinda like diagonal measurments don't mean jack for a monitor, until you know about the 4:3 ratio - however, in the case of an HMD, you really have no clue what the ratio is)!
Generally, when speaking about FOV measurements for immersion, a horizontal measurement is used as the baseline. Most commercial, off the shelf HMDs, that are priced under $1000 (like the I-Glasses, or the Victormaxx Cybermaxx), have an FOV of around 30 degrees. Some of the good ones can go up to 45 degrees (I believe the Forte VFX-1 is around the area, maybe less). It takes a horizontal FOV of at least 60 degrees to be in the area of full immersion. An FOV of 65 or 70 degrees is better, in that at this point the FOV begins to extend into the peripheral vision areas, thus enhancing the immersion experience. A carefully built homebrew rig can approach (and with a lot of care in design, hit) the 60 degree mark. It takes patience, and a lot of skill, but it has been done before.
But tell me if my interpretation is wrong. What you seem to describe sounds more like a moving "window" on the virtual environment being viewed - not necessarily a bad thing - certainly something that could be utilized (imagine a gauzy "plane" in front of you in an HMD, that would show a cutaway "x-ray" view of the inside of an object in the VE, as you turned your head!) just not what I was describing...
I am sure not going to win any points for this POV, but I think these displays are DOA.
A limited FOV, the need to not move the head too much, and a high price tag - effectively puts it out of reach of consumers, and should even make the IS department of any company who might have a need for such a display to do a double-take.
One person here mentioned a CAVE solution, or an ImmersaDesk-style system. Such systems would be better for many of the same apps, but both are still quite pricey. This same poster thinks that such systems will become affordable for the home user (I imagine he was speaking of the ImmerasDesk system) in the near future, coming in at around $500.00! This person has never priced LCD projectors (and I think high-end CAVE systems use CRT projector systems, just to get the high refresh rates needed for the stereo shutter glasses) apparently - prices for these devices, which would be an intregral part of any such system - haven't come down much in the past 10 years. Indeed, what seems to be apparent is rather than keeping the older tech around from the early 90's (which would be more than adequate for home projector use), and charging less - projector companies tend to dump it, and only sell the latest, thus keeping prices high (an ok projector will run you a minimum of around $1000 - used, you might get away with $800).
So, what does that leave for the average consumer? CAVE/ImmersaDesk systems are out and this DTI tech is out. Both mainly from a cost standpoint - prices that are not likely to come down at all in the near future for either system (barring some breakthrough in display tech - and even then the price will be high because it is *NEW* and *EXCITING*).
Only two possible affordable solutions - Shutter Glasses, and HMD's.
Shutter glasses are available now, and supported by several graphics cards, and they are cheap - however, while they allow more freedom of movement of the head, they still only have a limited FOV - due to the monitor. They are, and will continue to be, the choice for most people - only due to cost and ease of use.
HMD's are still rather pricey - but one can get an HMD today for around $1000 dollars that works quite well. Still, this is rather expensive for most gamers, who have already shelled out this much and more for their system likely - and don't have much left over for exciting 3D. What to do, what to do...
Homebrew, anyone? Why has EVERYONE (ok, that's an exageration - but not by much) forgotten about homebrew VR? Once, way back in the early 90's - if we didn't have a custom 3D display tech, we built it ourselves, using cheap (and cheaper today!) Casio hand-held TVs and Fresnel lenses, cobbled together in a plastic frame. The PowerGlove allowed us to reach into our worlds, and a lightweight boom mounted system allowed us to look around (some of us got adventurous, and used strings, LED's, ultrasonics ripped from PG systems, and other tricks for tracking - but the boom arm was the most accurate).
Today, homebrew VR has all but died - a few people still play the game, but most went on to other things. But look at what is available! We have free, open-source, GPL'd display engines! Low, low cost HMDs on the used market (one can pick up a used Forte VFX-1 for about $400 on eBay - Victormaxx Stuntmasters can be had for around $50). One could buy a couple of StuntMasters and home-brew their own HMD, with good res and a 60 degree+ FOV (the point of immersion), for under $300. We have fast, low cost computers and extreme 3D cards only dreamed about by the pioneers of the early 90's. Heck, one can run Rend386 or Avril on a normal PC of today, rendering standard VGA, and see frame rates well over 150 FPS. The code to both of these tools is available, and other code is available to do similar tasks under Linux and other OS's - using today's graphics cards...
What has happened? Why aren't we satisfying the urge to explore our own 3D worlds?
In a way, we are - witness things like Q3A and UT - both are networked virtual environments - the only thing lacking is full immersion, with full tracking. I can't understand why these players aren't clammoring for a fully immersed experience, or at least why some of them haven't built their own HMD systems, or why they would rather sit in front of a monitor playing a game, rather than being *in* the game. Q3A and UT offer the possibility of extreme VE immersion only dreamed of in the Rend386 days - yet donning a homebrew HMD, reaching out with a PowerGlove, and catching a spinning bannana is still something that neither UT or Q3A can quite match...
On a final note I would like to offer a link to my website, where I am trying to inform the public about homebrew VR, and today's possibilities:
The last one (full 3D action - it did have the ability to go first person with a hot key, though it was far easier to play 3rd person)?
While not a game that revolved around fighting all the time, you did have to get into "sword fights" and crossbow fights as you went deeper into the game, as well as solve puzzles. True, the whole game didn't revolve around the fighting aspect (which the games you mentioned do), but in my mind it should still qualify.
Or, maybe it is a whole different genre - one that hasn't been fully explored yet. I don't know what to call it, but it goes beyond interactive fiction - it was almost a true interactive movie, in a sense - or maybe you could call it interactive Machinima (or however that is spelled)...
Virtual Motion and their MotionWare technology. They use a system of vestibular stimulation (look it up on Google and on the IBM Patent Server) to do what they say they are doing. Vestibular Stimulation is nothing new - it has been in use in the medical community for quite some time studying balance (or loss thereof). But the devices/systems used were crude affairs - whereas Virtual Motion claims the ability to control direction of perceived forces, etc.
A few years ago they were offering dev kits (and beta devices) to developers for around $2000 or so (maybe less - it has been awhile) - since then, I have seen nothing come out of them, though they still appear to be in business.
You are right, though - this would help combat simulator sickness...
Look at how sub cultures like Punk and Grunge have been co-opted and ultimately destroyed by the forces of marketing. Both cultures had at their core an ethos of self reliance and "do it yourself" that made them special and evolutionary. However, within a few years of their break through, marketers had identified the readily recognizable elements and packaged them into a ready to buy product. The young and would be hip could simply go into a store and buy the outfit rather than having to discover the scene and its ideals. If we're not careful the same things gonna happen to us.
I know I am preaching to the choir here, but the sad part is:
It is already happening!
That is, the corps have identified the " readily recognizable elements" of "our" (and I use the term meaning those of the Free Software movement - I am not implying that everyone on/. is of like ideas) culture - that we like to see the code.
Thus, they give us "Open Source" - which, while a part of the Free Software ethos, does not represent the whole idea - or ideal - of the movement. Yet it is something easily recognisable (and confusing enough) for the average person to be lulled into thinking Open Source will give them the same rights as Free Software - when it will assuredly not.
All you have said is very true - but one thing you left out (or maybe only hinted about, if you read between the lines, so to speak), is one of the main reason motion sickness occurs:
One set of senses are telling you one thing, while another is seeing (or perceiving, perhaps in the wrong way) another.
Case in point, for the poster: He is obviously well immersed in the game, but most of his body is motionless - however, his eyes are perceiving that he is in motion. These two conflicting inputs (that of the eyes seeing motion, but his inner ear telling him he's not moving) help cause the motion sickness he experiences.
How to help? Don't get immersed - have a frame of reference for your eyes that show them you aren't moving as well. Either sit farther away from your monitor, so that you see the edge of the screen, use a smaller monitor, or run the game in a window.
A similar way to get sick is to ride an amusement park ride with your eyes closed in the late evening. Kinda the reverse of what the poster is experiencing.
You talked about lag. In a fully immersed setup (High quality, 60 degree FOV or greater HMD, etc), lag can cause severe difference in inputs, if the lag is large enough. Say the screen is updating as you turn your head left, then you quickly turn your head to the right. The screen may still display the images of what you were doing when you were turning your head to the left, as you are really turning your head to the right (the Virtuality 1000 game system was notorious for this) - time to spew. Another problem with fully immersed systems can be sensor calibration - this would help cause motion sickness, either by say - an electrolic tilt sensor "sloshing" after physical movement has stopped - and hence displaying to the user they are still moving, or by the sensor being out of alignment with the users actual position - maybe in an extreme case giving the user the image of him looking up, when he is trying to look straight ahead.
From my personal experience, I don't have a problem with immersed or semi-immersed virtual environments, even ones with bad lag. Maybe I have just adjusted, or for some other reason it doesn't bother me. What is strange though, is that I find reading while in an automobile (as the passenger, of course) makes me feel a little queasy - at least enough where I don't like to do it...strange...
Here is a link to a paper done on simulator sickness for the U.S. Army Research Institute, by Eugenia M. Kolasinski:
Napster has been banned here at my work - not sure if it is an infrastructure ban (port blocking), or in word only...
All I know is that they "blamed" me for helping in a DOS via Napster preventing clients from getting in - which is far from the truth. Last time I used Napster was several weeks ago - I don't keep the thing running, and I don't keep the system I am on here at work running all the time, either.
At any rate, there goes Napster for me - not that it is a big deal - @Home (bleh) is coming to me this weekend, and there is always gnutella if I feel a real urge for filling up my drive with more pap. Or FTP. Or Usenet. Or maybe my own fucking service I'll write.
Here is an idea I just pulled outta my ass... Please don't moderate me down until you hear it...
The concept and requirement of a datahaven is the ability to store information, free from the tampering of others (including government), in a secure (both physically and virtually, as well as politically) environment.
The problem always arises that there is some way to either cut off or destroy access (by either destroying the links, or the location of the servers) to the haven.
So why not make the haven "alive"?
Imagine a virus, which replicates itself - and detects attempts to "find" it - so that it can relocate to another "server" (I use the term loosely, as it could be a desktop - I am looking at it from the virus' POV). It would also carry a payload "packet", which would be encrpyted, but relatively small. Many of these packets would make up the information - kinda like a distributed filesystem, but one that is always on the move, autonomously - think of it as gnutella meets melissa, but without the dumb user needed (you get the idea - I am not advocating the use of 'doze - but such a "virus" would do good to have various strains for each OS - and the virus should be packetized amongst itself, so that it can be "reborn"/repaired, as it needed).
The virus would do nothing malicious (except consume a bit of each system's resources) - however, I can't see that stopping someone making a rogue version, but maybe there is a way around this, too.
Such a data haven could not be stopped - not without bringing down the entire internet, and wiping every "infected" system - which isn't practical in the slightest. Maybe data redunancy and CRC could be used as a form of compression - providing the packet size is small enough (maybe only a few hundred bytes)? I am thinking the virus acts like a mini disk drive, only holding a small amount of info. Like ants building the hive (or whatever it's called when relating to ants), each ant may only carry a single pebble, but if you could pass a query back through the ant line (via the scent trail), you could collect back all of those specks to form a pile of dirt.
Does this idea seem as crazy as it sounds - or is it feasible?
However, what I think would matter far more than just teaching a child to program, would be to teach them to think logically about solving problems, and to use those solutions for similar, future problems. This style of thinking will help them in every area of life (and, regretably, possible stunt them in other areas - anyone who has tried to work logically with their non-logical SO knows what I mean).
Don't push them, if they don't like it - let them seek thier own level. You sound like that kind of individual already, noticing their clammoring for wanting to program.
Depending on their ages/interest - you might try starting them out with a Mindstorms set (I know others have suggested this) - let them play with the built in system/ide that it comes with, then progress them into something like LegOS or NQC - to teach them further coding fundamentals. Always answer thier questions, and if you don't know something, tell them so (they'll appreciate you honesty), but also tell them you'll find the answer - then go out and find it.
After playing with these languages on Lego - if they are still interested, you have a couple of ways to go - you could go the route of learning real robotics (progress by building a parallel relay box, hooking the Lego motors to that, then code in a regular languge, such as C/C++, to control it all - then after that, move to using a soldering iron and tools more to build real robotic devices), or take the "virtual" robotics route, and lead to small scale AI for game programming (game programming can teach a lot about many programming side areas - DB management, arrays, sound, graphics, etc).
If they enjoy tinkering and building their own stuff, Lego is especially the way to go...
The short answer is no, you don't even need a driver's license to drive on public roads, providing you are not a commercial driver. It is the Constitutionally protected "right-to-travel". Most people are unaware of such a thing - most judges are unaware of such a thing. I believe every case that has been brought before a court on these grounds has ended up being thrown out (yeah, you will get arrested or ticketed for driving without a license. But show up in court, and argue against it and, provided you have all the paperwork (the MSO is the big one - you have to buy your car outright in cash to even hope to get it, and even then it is a bitch to obtain), and no liens against your car (this won't happen if you paid cash, but if you had to get a loan, which most people have to, kiss that MSO goodbye - the MSO, along with the purchasing invoice and the title, form a complete bill-of-sale, proving you own the vehicle. Most of the time, the MSO gets "split" between the lien holder and the state for licensing, and thus, technically, you don't own your vehicle - the state does), and it will be thrown out, due to Constitutional protection.
Look into it - look at the various cases, read the Constitution and what it says regarding travel, and you will soon realize how we have let ourselves get screwed...
I think the MotionWare has turned out to be vaporware - it has been in the "about to be released" mode for about two or more years now (I remember them posting in the hombrew VR mailing list, back when it had real activity, asking if anyone wanted to buy dev/beta units for a grand or so). Not that the tech doesn't work in some regard - they have a patent on the tech, and it is on the IBM patent server (I am not sure if this is the patent, but it is very similar) - just go to the server, and look up the words "vestibular stimulation" - there are other patents available as well.
I also remember an old Ciarcia's Circuit Cellar article in an old issue of Byte magazine - late 70s/early 80s, IIRC - that dealt with building your own EEG machine. What I distinctly remember about the article was that the devices used for amplifying the brain's output, were special op-amps, with extreme isolation and extra-high amplification, with low noise. I remember that he wrote that the op-amps were expensive, around $50.00 a piece (and considering the time, that was damn expensive for a chip). The biggest concern was the isolation (of the skin contact vs. current in the system - essentially to keep you from being electrocuted in any manner), which these special op-amps were designed for. However...
It may be possible to homebrew the sucker using some standard op-amps, set up to perform infinite amplification (by eliminating the feedback resistor), and cascading them (2 or three, via caps probably). Get the sensor pads and gel from a medical supply house (or you might be able to build your own in some way). The problem is that you won't be isolated whatsoever from any current in the system - run the thing off of batteries (this probably won't help much, but it is better than even thinking about using a wall wart). Build a couple, and hook the outputs of the amps into a couple of high performance A/D convertor chips (16 or 24 bits should be enough res - actually, maybe you could use a high end sound card via the analog line-in/mic-in ports).
The output will be noisy as hell - time to write some code (probably a ton of FFT shit here - you will be in for a ride if you get this far) to pick out the details from the noise. If you do get meaningful output, then you just have to figure out what to DO with it (which is pretty much where everyone else is at).
So yeah, it is possible to homebrew it, but it won't be easy - or cheap.
This kind of "device" (actually, use of a device), comes out as "the next new thing" every now and then (I remember a similar story back when I was 10 or so - a good 15 years ago). What makes me really angry, is that they foist this off on us as "new", expecting us to forget the last 20 years - and you know what? The majority of people don't remember! They really do think that what they are shown is new, wonderful, and should be installed everywhere (at the same time, seeing this reaction, and seeing the "news" they sell in magazines, etc - how everyone is a smiley SOB - happy, happy! - look at Brad Pitt's hair - joy, joy! - feed us more - it makes me sick, and saddened - that people like this).
Ok, where was I... Oh yes!
Robotic burger flippers are not going to happen. We won't see a bunch of waving mechanical arms behind the counter any time soon. Even if we do get the fully automated burger joint, it won't consist of large industrial robots flipping burgers. This isn't cost effective, nor is it efficient.
It will likely consist of an assembly line style system - imagine a conveyor belt moving the bottom of a bun along. Under a spout - bloup!! - a dab of mayo. Another - bloup!! - a bit of ketchup. Under a tube - splat!! - a burger (side note: the burger would probably be cooked similar to the conveyor grills Burger King uses - for fried burgers, the system would probably use a similar thing, but with a rolled steel multi-segment tank tread-like belt, heated by gas flame). A little bit further - whir, whir, chop - splat!! - some lettuce and tomato. Then under another tube for the top bun. Maybe there is one worker stuffing the burger into a box (or maybe they can automatically wrap the sucker somehow).
Actually, we already have the automated burger making system (has to be at least semi-automated, anyhow) - look at the Hormel line of "frozen cheeseburger in a box" - as well as the microwavable fries in a box from other vendors. Look at just about any manufacturer of frozen foods. Just stop the system before freezing (but after cooking and assembly) and there you are.
A similar system could be come up with for pancakes, eggs and bacon. If the pancakes, eggs and bacon were in frozen form before cooking (think like the frozen Krusteaz brand of pancakes, and add a Swanson breakfast of eggs/sausage), it would be easy.
Excuse me, but I think if that is the future of fast food (can it really get worse!?), then I will go puke now...
Guys - think of it like the integrators used by Vannevar Bush in his Differential Analyzer built at MIT - you can see them in the third picture down. Now, these used a metal knife edge wheel turning a larger glass disk (set perpendicular to the knife edge wheel) to perform integration. The knife edge wheel could move radially in and out on it's shaft, varying the speed at which the glass disk turned (I think the knife edge wheel turned the glass disk - but it may have been the other way around, what with the torque amplifiers used on the shaft of the knife edge wheel - anyone know for sure?). To envision the flywheel system being imagined:
Replace the glass disk with the flywheel, and the knife edge wheel with a motor driven rubber wheel - allow it to move in/out via some mechanism (no need to move the motor, allow the motor to remain stationary, and move the rubber drive wheel along the shaft, radially to the center of the wheel).
The number of people I meet (and judging by various comments on/. - they are here, too) who don't understand Free Software.
As noted hundreds of times before by greater people than I, the word "Free" in Free Software isn't about monetary value. The "Free" should really be read as "Freedom", and thus "Freedom" Software.
People, don't you get it? Such software is better for everyone, corporations included. The main driving force behind Free(dom) Software is this idea:
Some companies today (most who sell large software packages, generally not shrink-wrapped systems) will allow the client to get the source code to the package, for a fee (generally a large fee). The code isn't open, and it isn't free, it definitely isn't Free(dom) - but it is available.
The problem comes if said software company goes under - where does the licensing stand? Many times, nowhere - the client can't modify and sell the code, or improve on it, or support other clients who have the code base or the bianry version - that is, nobody can fill the gap, and the clients may very well go out of business because of it (though I do know that in this business, code is stolen, reworked and sold all the time, with nary a hiccup).
Enter Free(dom) Software. Maybe the client still has to pay for the source code - but after they have paid, they can't be prevented from doing what they need to with it - the code can exist seperate from the parent company. The clients can possibly stay in business, even if the parent of the code dies.
One other side effect - if the code is always available, after the parent company goes out of business - it may be possible that the company could be reformed - if the business practices that caused the failure can be identified and fixed prior to the re-startup. If it was the immaturity of the code that caused the failure, then just wait until the code matures (or better yet, help it mature yourself), then restart...
I've worked with a bit of EDI myself - mainly the products from St. Paul Software - I don't know if these were the guys you worked with (it doesn't sound like them) or not (it wasn't the Gentran software from Sterling Commerce, was it? I've never used their products, so I can't comment on them).
I've had good luck with SPS's solutions in regards to EDI (first with spEDI*tran on a sco box, then with Evision on NT) - they had excellent tech support, which is one thing that has stood out in my mind. However, their product isn't cheap.
To be honest, portions of the standards for EDI (which come from the UCC, a company we all love, right?) are convoluted, while most of the others are straight forward (most of the warehousing/inventory/order forms are easy - but the insurance related forms can give you nightmares).
Good luck in finding a free project, or starting your own - the "standards" tend to be the issue. It seems like every year they change significantly, to the point where it is hard to keep up with the standard. On top of that, the fees to buy a copy of the standards (in order to code a solution) can be pretty high. Plus, anybody working with the system would need a copy of those standards as well.
Most of the EDI solutions offered by companies (such as SPS's Evision product) are actually development environments, that allow you to create the templates to do the translation (basically, all EDI comes down to is data translation from one obscure format to another "standard" format to interchange data). The company may also offer services to create these templates as well, for a fee (many times it is cheaper to do this than doing the templates in house with the software).
I looked into the possibility of creating my own EDI software at one point - a template development/translation environment. I realized pretty soon that such a task would be near impossible by myself. I figured to even have a hope, I would have to have about 10 programmers working and designing for about a year before we would even get something (this was before I heard of free software, open source, and the GPL). Maybe today it would be possible to do what you want - but it would be akin to creating a programming language (in fact, SPS's software started exactly that way back in the early 80's - as a form of interpreted BASIC - you essentially wrote BASIC code to do the translation - the tools that came later GUI'ized the system, but still, under the hood of Evision, lies BASIC code and interpreter, chugging away). With the head start the other companies already have (10-20 years in some cases, like SPS), it might be possible, but it would be an uphill battle.
Still, if you have the need and development time, and you are well versed enough in EDI to consider it, I say go for it - create a simple system to handle creation of simple forms, or the portions of the forms thereof (so you can combine the pieces to form full forms), then go from there.
BTW - if you get something going, anounce it on/. - I would love to follow it's progress.
If I have the phone, and don't answer, and don't return the call - I will get grilled as to why I didn't when I return home from at 2am.
Maybe I was out trashing, looking for that discarded Pentium box companies seem to leave out now and then? Gotta turn the phone off, to keep security off my back. It won't matter to the GF - she thinks you were cheating!
Or how about the boss that calls you on the weekend to come in - right now - or be fired! - while you are at the beach? Your boss can't reach you if you don't have one - "Sorry boss, I was at the beach with my family Saturday - I did get your answering machine message when I returned at 8pm, though!".
In other words, I know I am not the slave of the phone, and the people calling know that as well - they think you are their slave...
Pretty cool - I liked the SimCraft better, because he was at least offering plans - but the Rock n' Ride is a clean design (though I can't say much about the web page).
It appears to be a German built product, so it will probably be a quality device - does any of our German/.ers know of the source company?
They do give assembly instructions, so it might be possible to "roll your own" from that - maybe build some PVC air cylinder's ala SimCraft, attach it to a 2x4 frame, a bucket seat and some steel - one PIC - whammo! - instant homebrew Rock n' Ride!
So, for those who would like more sim plans, etc - here are some links:
I had another link with a circuit and such from some guy in Germany, but I am not sure where it is now - but between all of these links, you should be able to do it yourself pretty easily anyhow...
Ah, heck - that's where it breaks down - the tiff to postscript utils only make a non-searchable bitmap (I read that, and still wrote my method - I must be stupid today - my bad).
Of course, if such a program existed - tiff -> OCR'd postscript (searchable text), then my solution would work (I am not advocating the manual cutting and pasting of images - a piece of code would have to be written to that) to convert the stuff to html.
Of course, if one went ahead and built an OCR engine (converting tiff to PS), then they could go all the way and add the extra image stuff in and save all the steps I added...
And here I was thinking I was being smart...
Here is a possible solution (from scanned document to html pages), that could work as long as there weren't any funky symbols, etc. embedded in the text (heck, may even work with that if you are deft with a sharpie - as explained in step 1)...
Steps for conversion:
1. For pages with images, draw a colored border around each image on each page. Make the color something that will sharply stand out (like bright green).
2. Tricky part - process each tiff image (in a looped script) doing the following:
a. Scan each page to color tiff, with sequential filenames (001.tiff, 002.tiff).
b. Using a custom written utility, build two new tiff images - a tiff of the page without the color-bordered images, and a tiff of the color-bordered image(s) on the page. Number the page images like (p001.tiff, p002.tiff), and the images for each page (p001i001.tiff, p001i002.tiff), so that it is known which images go with what page.
c. Convert each page image to postscript, then to html (unless there is a tiff2html tool out there?) - preserve the filenames (p001.html, p002.html),
modifying only the extension.
d. Convert each image for each page to a (gif, jpeg, png), preserving the filenames (p001i001.png, p001i002.png), with a new extension.
e. Add IMG tags for the images to the end (or beginning) of the html pages, for each page.
3. After batch conversion, go back and proofread/reformat pages (to position images where they should go, etc).
Everything to do this should exist in some form already - except for maybe step 2b - that might be a completely custom tool that needs to be written, but it shouldn't be very hard to code (loop through bytes of image, looking for the sharp color changes - kinda like edge detection code - saving/masking the areas in the outlines)...
I have been sick the past few days - but anyhow, if I understand you correctly, you are saying that by having this display somehow track where you (move/turn) your head, it tracks with it (kinda like if I turn my head to the right, the monitor in front of me moves to the right) - would increase the FOV?
If this is what you mean, then, in a word - no.
FOV is defined by the combined angular measument of a pair of imaginary "cones" radiating from the approximate center of each eye (one cone per eye). There are both horizontal and vertical FOV measurements (generally expressed in degrees) - so each "cone" can actually have an elliptical cross section (generally, vertical FOV is smaller than horizontal FOV in HMDs). Some HMD manufacturers are beginning to use a diagonal FOV measurment - muddling the issue further (kinda like diagonal measurments don't mean jack for a monitor, until you know about the 4:3 ratio - however, in the case of an HMD, you really have no clue what the ratio is)!
Generally, when speaking about FOV measurements for immersion, a horizontal measurement is used as the baseline. Most commercial, off the shelf HMDs, that are priced under $1000 (like the I-Glasses, or the Victormaxx Cybermaxx), have an FOV of around 30 degrees. Some of the good ones can go up to 45 degrees (I believe the Forte VFX-1 is around the area, maybe less). It takes a horizontal FOV of at least 60 degrees to be in the area of full immersion. An FOV of 65 or 70 degrees is better, in that at this point the FOV begins to extend into the peripheral vision areas, thus enhancing the immersion experience. A carefully built homebrew rig can approach (and with a lot of care in design, hit) the 60 degree mark. It takes patience, and a lot of skill, but it has been done before.
But tell me if my interpretation is wrong. What you seem to describe sounds more like a moving "window" on the virtual environment being viewed - not necessarily a bad thing - certainly something that could be utilized (imagine a gauzy "plane" in front of you in an HMD, that would show a cutaway "x-ray" view of the inside of an object in the VE, as you turned your head!) just not what I was describing...
I am sure not going to win any points for this POV, but I think these displays are DOA.
A limited FOV, the need to not move the head too much, and a high price tag - effectively puts it out of reach of consumers, and should even make the IS department of any company who might have a need for such a display to do a double-take.
One person here mentioned a CAVE solution, or an ImmersaDesk-style system. Such systems would be better for many of the same apps, but both are still quite pricey. This same poster thinks that such systems will become affordable for the home user (I imagine he was speaking of the ImmerasDesk system) in the near future, coming in at around $500.00! This person has never priced LCD projectors (and I think high-end CAVE systems use CRT projector systems, just to get the high refresh rates needed for the stereo shutter glasses) apparently - prices for these devices, which would be an intregral part of any such system - haven't come down much in the past 10 years. Indeed, what seems to be apparent is rather than keeping the older tech around from the early 90's (which would be more than adequate for home projector use), and charging less - projector companies tend to dump it, and only sell the latest, thus keeping prices high (an ok projector will run you a minimum of around $1000 - used, you might get away with $800).
So, what does that leave for the average consumer? CAVE/ImmersaDesk systems are out and this DTI tech is out. Both mainly from a cost standpoint - prices that are not likely to come down at all in the near future for either system (barring some breakthrough in display tech - and even then the price will be high because it is *NEW* and *EXCITING*).
Only two possible affordable solutions - Shutter Glasses, and HMD's.
Shutter glasses are available now, and supported by several graphics cards, and they are cheap - however, while they allow more freedom of movement of the head, they still only have a limited FOV - due to the monitor. They are, and will continue to be, the choice for most people - only due to cost and ease of use.
HMD's are still rather pricey - but one can get an HMD today for around $1000 dollars that works quite well. Still, this is rather expensive for most gamers, who have already shelled out this much and more for their system likely - and don't have much left over for exciting 3D. What to do, what to do...
Homebrew, anyone? Why has EVERYONE (ok, that's an exageration - but not by much) forgotten about homebrew VR? Once, way back in the early 90's - if we didn't have a custom 3D display tech, we built it ourselves, using cheap (and cheaper today!) Casio hand-held TVs and Fresnel lenses, cobbled together in a plastic frame. The PowerGlove allowed us to reach into our worlds, and a lightweight boom mounted system allowed us to look around (some of us got adventurous, and used strings, LED's, ultrasonics ripped from PG systems, and other tricks for tracking - but the boom arm was the most accurate).
Today, homebrew VR has all but died - a few people still play the game, but most went on to other things. But look at what is available! We have free, open-source, GPL'd display engines! Low, low cost HMDs on the used market (one can pick up a used Forte VFX-1 for about $400 on eBay - Victormaxx Stuntmasters can be had for around $50). One could buy a couple of StuntMasters and home-brew their own HMD, with good res and a 60 degree+ FOV (the point of immersion), for under $300. We have fast, low cost computers and extreme 3D cards only dreamed about by the pioneers of the early 90's. Heck, one can run Rend386 or Avril on a normal PC of today, rendering standard VGA, and see frame rates well over 150 FPS. The code to both of these tools is available, and other code is available to do similar tasks under Linux and other OS's - using today's graphics cards...
What has happened? Why aren't we satisfying the urge to explore our own 3D worlds?
In a way, we are - witness things like Q3A and UT - both are networked virtual environments - the only thing lacking is full immersion, with full tracking. I can't understand why these players aren't clammoring for a fully immersed experience, or at least why some of them haven't built their own HMD systems, or why they would rather sit in front of a monitor playing a game, rather than being *in* the game. Q3A and UT offer the possibility of extreme VE immersion only dreamed of in the Rend386 days - yet donning a homebrew HMD, reaching out with a PowerGlove, and catching a spinning bannana is still something that neither UT or Q3A can quite match...
On a final note I would like to offer a link to my website, where I am trying to inform the public about homebrew VR, and today's possibilities:
PhoenixGarage.ORG
The last one (full 3D action - it did have the ability to go first person with a hot key, though it was far easier to play 3rd person)?
While not a game that revolved around fighting all the time, you did have to get into "sword fights" and crossbow fights as you went deeper into the game, as well as solve puzzles. True, the whole game didn't revolve around the fighting aspect (which the games you mentioned do), but in my mind it should still qualify.
Or, maybe it is a whole different genre - one that hasn't been fully explored yet. I don't know what to call it, but it goes beyond interactive fiction - it was almost a true interactive movie, in a sense - or maybe you could call it interactive Machinima (or however that is spelled)...
Virtual Motion and their MotionWare technology. They use a system of vestibular stimulation (look it up on Google and on the IBM Patent Server) to do what they say they are doing. Vestibular Stimulation is nothing new - it has been in use in the medical community for quite some time studying balance (or loss thereof). But the devices/systems used were crude affairs - whereas Virtual Motion claims the ability to control direction of perceived forces, etc.
A few years ago they were offering dev kits (and beta devices) to developers for around $2000 or so (maybe less - it has been awhile) - since then, I have seen nothing come out of them, though they still appear to be in business.
You are right, though - this would help combat simulator sickness...
Look at how sub cultures like Punk and Grunge have been co-opted and ultimately destroyed by the forces of marketing. Both cultures had at their core an ethos of self reliance and "do it yourself" that made them special and evolutionary. However, within a few years of their break through, marketers had identified the readily recognizable elements and packaged them into a ready to buy product. The young and would be hip could simply go into a store and buy the outfit rather than having to discover the scene and its ideals. If we're not careful the same things gonna happen to us.
/. is of like ideas) culture - that we like to see the code.
I know I am preaching to the choir here, but the sad part is:
It is already happening!
That is, the corps have identified the " readily recognizable elements" of "our" (and I use the term meaning those of the Free Software movement - I am not implying that everyone on
Thus, they give us "Open Source" - which, while a part of the Free Software ethos, does not represent the whole idea - or ideal - of the movement. Yet it is something easily recognisable (and confusing enough) for the average person to be lulled into thinking Open Source will give them the same rights as Free Software - when it will assuredly not.
Wolfenstein 3D? The last King's Quest (8? Can't remember the name...)? Or how about Gate Crasher for the CoCo 3 (don't believe me? Go here)?
OK, maybe that is stretching it - but you do seem to have played, by far, a great number of FPS's...
Actually, all I wanted to do was put in a comment that the CoCo could do an FPS (at 2 MHz and 512K of RAM - woohoo!)...
All you have said is very true - but one thing you left out (or maybe only hinted about, if you read between the lines, so to speak), is one of the main reason motion sickness occurs:
One set of senses are telling you one thing, while another is seeing (or perceiving, perhaps in the wrong way) another.
Case in point, for the poster: He is obviously well immersed in the game, but most of his body is motionless - however, his eyes are perceiving that he is in motion. These two conflicting inputs (that of the eyes seeing motion, but his inner ear telling him he's not moving) help cause the motion sickness he experiences.
How to help? Don't get immersed - have a frame of reference for your eyes that show them you aren't moving as well. Either sit farther away from your monitor, so that you see the edge of the screen, use a smaller monitor, or run the game in a window.
A similar way to get sick is to ride an amusement park ride with your eyes closed in the late evening. Kinda the reverse of what the poster is experiencing.
You talked about lag. In a fully immersed setup (High quality, 60 degree FOV or greater HMD, etc), lag can cause severe difference in inputs, if the lag is large enough. Say the screen is updating as you turn your head left, then you quickly turn your head to the right. The screen may still display the images of what you were doing when you were turning your head to the left, as you are really turning your head to the right (the Virtuality 1000 game system was notorious for this) - time to spew. Another problem with fully immersed systems can be sensor calibration - this would help cause motion sickness, either by say - an electrolic tilt sensor "sloshing" after physical movement has stopped - and hence displaying to the user they are still moving, or by the sensor being out of alignment with the users actual position - maybe in an extreme case giving the user the image of him looking up, when he is trying to look straight ahead.
From my personal experience, I don't have a problem with immersed or semi-immersed virtual environments, even ones with bad lag. Maybe I have just adjusted, or for some other reason it doesn't bother me. What is strange though, is that I find reading while in an automobile (as the passenger, of course) makes me feel a little queasy - at least enough where I don't like to do it...strange...
Here is a link to a paper done on simulator sickness for the U.S. Army Research Institute, by Eugenia M. Kolasinski:
Simulator Sickness in Virtual Environments
Napster has been banned here at my work - not sure if it is an infrastructure ban (port blocking), or in word only...
All I know is that they "blamed" me for helping in a DOS via Napster preventing clients from getting in - which is far from the truth. Last time I used Napster was several weeks ago - I don't keep the thing running, and I don't keep the system I am on here at work running all the time, either.
At any rate, there goes Napster for me - not that it is a big deal - @Home (bleh) is coming to me this weekend, and there is always gnutella if I feel a real urge for filling up my drive with more pap. Or FTP. Or Usenet. Or maybe my own fucking service I'll write.
<end of rant>
Here is an idea I just pulled outta my ass... Please don't moderate me down until you hear it...
The concept and requirement of a datahaven is the ability to store information, free from the tampering of others (including government), in a secure (both physically and virtually, as well as politically) environment.
The problem always arises that there is some way to either cut off or destroy access (by either destroying the links, or the location of the servers) to the haven.
So why not make the haven "alive"?
Imagine a virus, which replicates itself - and detects attempts to "find" it - so that it can relocate to another "server" (I use the term loosely, as it could be a desktop - I am looking at it from the virus' POV). It would also carry a payload "packet", which would be encrpyted, but relatively small. Many of these packets would make up the information - kinda like a distributed filesystem, but one that is always on the move, autonomously - think of it as gnutella meets melissa, but without the dumb user needed (you get the idea - I am not advocating the use of 'doze - but such a "virus" would do good to have various strains for each OS - and the virus should be packetized amongst itself, so that it can be "reborn"/repaired, as it needed).
The virus would do nothing malicious (except consume a bit of each system's resources) - however, I can't see that stopping someone making a rogue version, but maybe there is a way around this, too.
Such a data haven could not be stopped - not without bringing down the entire internet, and wiping every "infected" system - which isn't practical in the slightest. Maybe data redunancy and CRC could be used as a form of compression - providing the packet size is small enough (maybe only a few hundred bytes)? I am thinking the virus acts like a mini disk drive, only holding a small amount of info. Like ants building the hive (or whatever it's called when relating to ants), each ant may only carry a single pebble, but if you could pass a query back through the ant line (via the scent trail), you could collect back all of those specks to form a pile of dirt.
Does this idea seem as crazy as it sounds - or is it feasible?
A lot of good suggestions so far...
However, what I think would matter far more than just teaching a child to program, would be to teach them to think logically about solving problems, and to use those solutions for similar, future problems. This style of thinking will help them in every area of life (and, regretably, possible stunt them in other areas - anyone who has tried to work logically with their non-logical SO knows what I mean).
Don't push them, if they don't like it - let them seek thier own level. You sound like that kind of individual already, noticing their clammoring for wanting to program.
Depending on their ages/interest - you might try starting them out with a Mindstorms set (I know others have suggested this) - let them play with the built in system/ide that it comes with, then progress them into something like LegOS or NQC - to teach them further coding fundamentals. Always answer thier questions, and if you don't know something, tell them so (they'll appreciate you honesty), but also tell them you'll find the answer - then go out and find it.
After playing with these languages on Lego - if they are still interested, you have a couple of ways to go - you could go the route of learning real robotics (progress by building a parallel relay box, hooking the Lego motors to that, then code in a regular languge, such as C/C++, to control it all - then after that, move to using a soldering iron and tools more to build real robotic devices), or take the "virtual" robotics route, and lead to small scale AI for game programming (game programming can teach a lot about many programming side areas - DB management, arrays, sound, graphics, etc).
If they enjoy tinkering and building their own stuff, Lego is especially the way to go...
As if HOA's weren't bad enough!
How long before home builders/developers and content providers merge?
I can just imagine an AOL/Time Warner/Kaufman & Broad combo in the future...
Talk about a captive audience...
Look into the idea of Right to Travel:
h tml
7 /vehiclecertorig.html
http://www.cs.cmu.edu/~karl/govt/driver/driver.
http://www.geocities.com/CapitolHill/Senate/441
The short answer is no, you don't even need a driver's license to drive on public roads, providing you are not a commercial driver. It is the Constitutionally protected "right-to-travel". Most people are unaware of such a thing - most judges are unaware of such a thing. I believe every case that has been brought before a court on these grounds has ended up being thrown out (yeah, you will get arrested or ticketed for driving without a license. But show up in court, and argue against it and, provided you have all the paperwork (the MSO is the big one - you have to buy your car outright in cash to even hope to get it, and even then it is a bitch to obtain), and no liens against your car (this won't happen if you paid cash, but if you had to get a loan, which most people have to, kiss that MSO goodbye - the MSO, along with the purchasing invoice and the title, form a complete bill-of-sale, proving you own the vehicle. Most of the time, the MSO gets "split" between the lien holder and the state for licensing, and thus, technically, you don't own your vehicle - the state does), and it will be thrown out, due to Constitutional protection.
Look into it - look at the various cases, read the Constitution and what it says regarding travel, and you will soon realize how we have let ourselves get screwed...
I think the MotionWare has turned out to be vaporware - it has been in the "about to be released" mode for about two or more years now (I remember them posting in the hombrew VR mailing list, back when it had real activity, asking if anyone wanted to buy dev/beta units for a grand or so). Not that the tech doesn't work in some regard - they have a patent on the tech, and it is on the IBM patent server (I am not sure if this is the patent, but it is very similar) - just go to the server, and look up the words "vestibular stimulation" - there are other patents available as well.
I also remember an old Ciarcia's Circuit Cellar article in an old issue of Byte magazine - late 70s/early 80s, IIRC - that dealt with building your own EEG machine. What I distinctly remember about the article was that the devices used for amplifying the brain's output, were special op-amps, with extreme isolation and extra-high amplification, with low noise. I remember that he wrote that the op-amps were expensive, around $50.00 a piece (and considering the time, that was damn expensive for a chip). The biggest concern was the isolation (of the skin contact vs. current in the system - essentially to keep you from being electrocuted in any manner), which these special op-amps were designed for. However...
It may be possible to homebrew the sucker using some standard op-amps, set up to perform infinite amplification (by eliminating the feedback resistor), and cascading them (2 or three, via caps probably). Get the sensor pads and gel from a medical supply house (or you might be able to build your own in some way). The problem is that you won't be isolated whatsoever from any current in the system - run the thing off of batteries (this probably won't help much, but it is better than even thinking about using a wall wart). Build a couple, and hook the outputs of the amps into a couple of high performance A/D convertor chips (16 or 24 bits should be enough res - actually, maybe you could use a high end sound card via the analog line-in/mic-in ports).
The output will be noisy as hell - time to write some code (probably a ton of FFT shit here - you will be in for a ride if you get this far) to pick out the details from the noise. If you do get meaningful output, then you just have to figure out what to DO with it (which is pretty much where everyone else is at).
So yeah, it is possible to homebrew it, but it won't be easy - or cheap.
This kind of "device" (actually, use of a device), comes out as "the next new thing" every now and then (I remember a similar story back when I was 10 or so - a good 15 years ago). What makes me really angry, is that they foist this off on us as "new", expecting us to forget the last 20 years - and you know what? The majority of people don't remember! They really do think that what they are shown is new, wonderful, and should be installed everywhere (at the same time, seeing this reaction, and seeing the "news" they sell in magazines, etc - how everyone is a smiley SOB - happy, happy! - look at Brad Pitt's hair - joy, joy! - feed us more - it makes me sick, and saddened - that people like this).
Ok, where was I... Oh yes!
Robotic burger flippers are not going to happen. We won't see a bunch of waving mechanical arms behind the counter any time soon. Even if we do get the fully automated burger joint, it won't consist of large industrial robots flipping burgers. This isn't cost effective, nor is it efficient.
It will likely consist of an assembly line style system - imagine a conveyor belt moving the bottom of a bun along. Under a spout - bloup!! - a dab of mayo. Another - bloup!! - a bit of ketchup. Under a tube - splat!! - a burger (side note: the burger would probably be cooked similar to the conveyor grills Burger King uses - for fried burgers, the system would probably use a similar thing, but with a rolled steel multi-segment tank tread-like belt, heated by gas flame). A little bit further - whir, whir, chop - splat!! - some lettuce and tomato. Then under another tube for the top bun. Maybe there is one worker stuffing the burger into a box (or maybe they can automatically wrap the sucker somehow).
Actually, we already have the automated burger making system (has to be at least semi-automated, anyhow) - look at the Hormel line of "frozen cheeseburger in a box" - as well as the microwavable fries in a box from other vendors. Look at just about any manufacturer of frozen foods. Just stop the system before freezing (but after cooking and assembly) and there you are.
A similar system could be come up with for pancakes, eggs and bacon. If the pancakes, eggs and bacon were in frozen form before cooking (think like the frozen Krusteaz brand of pancakes, and add a Swanson breakfast of eggs/sausage), it would be easy.
Excuse me, but I think if that is the future of fast food (can it really get worse!?), then I will go puke now...
Guys - think of it like the integrators used by Vannevar Bush in his Differential Analyzer built at MIT - you can see them in the third picture down. Now, these used a metal knife edge wheel turning a larger glass disk (set perpendicular to the knife edge wheel) to perform integration. The knife edge wheel could move radially in and out on it's shaft, varying the speed at which the glass disk turned (I think the knife edge wheel turned the glass disk - but it may have been the other way around, what with the torque amplifiers used on the shaft of the knife edge wheel - anyone know for sure?). To envision the flywheel system being imagined:
Replace the glass disk with the flywheel, and the knife edge wheel with a motor driven rubber wheel - allow it to move in/out via some mechanism (no need to move the motor, allow the motor to remain stationary, and move the rubber drive wheel along the shaft, radially to the center of the wheel).
That should make it clearer...
The number of people I meet (and judging by various comments on /. - they are here, too) who don't understand Free Software.
As noted hundreds of times before by greater people than I, the word "Free" in Free Software isn't about monetary value. The "Free" should really be read as "Freedom", and thus "Freedom" Software.
People, don't you get it? Such software is better for everyone, corporations included. The main driving force behind Free(dom) Software is this idea:
Some companies today (most who sell large software packages, generally not shrink-wrapped systems) will allow the client to get the source code to the package, for a fee (generally a large fee). The code isn't open, and it isn't free, it definitely isn't Free(dom) - but it is available.
The problem comes if said software company goes under - where does the licensing stand? Many times, nowhere - the client can't modify and sell the code, or improve on it, or support other clients who have the code base or the bianry version - that is, nobody can fill the gap, and the clients may very well go out of business because of it (though I do know that in this business, code is stolen, reworked and sold all the time, with nary a hiccup).
Enter Free(dom) Software. Maybe the client still has to pay for the source code - but after they have paid, they can't be prevented from doing what they need to with it - the code can exist seperate from the parent company. The clients can possibly stay in business, even if the parent of the code dies.
One other side effect - if the code is always available, after the parent company goes out of business - it may be possible that the company could be reformed - if the business practices that caused the failure can be identified and fixed prior to the re-startup. If it was the immaturity of the code that caused the failure, then just wait until the code matures (or better yet, help it mature yourself), then restart...
I've worked with a bit of EDI myself - mainly the products from St. Paul Software - I don't know if these were the guys you worked with (it doesn't sound like them) or not (it wasn't the Gentran software from Sterling Commerce, was it? I've never used their products, so I can't comment on them).
/. - I would love to follow it's progress.
I've had good luck with SPS's solutions in regards to EDI (first with spEDI*tran on a sco box, then with Evision on NT) - they had excellent tech support, which is one thing that has stood out in my mind. However, their product isn't cheap.
To be honest, portions of the standards for EDI (which come from the UCC, a company we all love, right?) are convoluted, while most of the others are straight forward (most of the warehousing/inventory/order forms are easy - but the insurance related forms can give you nightmares).
Good luck in finding a free project, or starting your own - the "standards" tend to be the issue. It seems like every year they change significantly, to the point where it is hard to keep up with the standard. On top of that, the fees to buy a copy of the standards (in order to code a solution) can be pretty high. Plus, anybody working with the system would need a copy of those standards as well.
Most of the EDI solutions offered by companies (such as SPS's Evision product) are actually development environments, that allow you to create the templates to do the translation (basically, all EDI comes down to is data translation from one obscure format to another "standard" format to interchange data). The company may also offer services to create these templates as well, for a fee (many times it is cheaper to do this than doing the templates in house with the software).
I looked into the possibility of creating my own EDI software at one point - a template development/translation environment. I realized pretty soon that such a task would be near impossible by myself. I figured to even have a hope, I would have to have about 10 programmers working and designing for about a year before we would even get something (this was before I heard of free software, open source, and the GPL). Maybe today it would be possible to do what you want - but it would be akin to creating a programming language (in fact, SPS's software started exactly that way back in the early 80's - as a form of interpreted BASIC - you essentially wrote BASIC code to do the translation - the tools that came later GUI'ized the system, but still, under the hood of Evision, lies BASIC code and interpreter, chugging away). With the head start the other companies already have (10-20 years in some cases, like SPS), it might be possible, but it would be an uphill battle.
Still, if you have the need and development time, and you are well versed enough in EDI to consider it, I say go for it - create a simple system to handle creation of simple forms, or the portions of the forms thereof (so you can combine the pieces to form full forms), then go from there.
BTW - if you get something going, anounce it on
If I have the phone, and don't answer, and don't return the call - I will get grilled as to why I didn't when I return home from at 2am.
Maybe I was out trashing, looking for that discarded Pentium box companies seem to leave out now and then? Gotta turn the phone off, to keep security off my back. It won't matter to the GF - she thinks you were cheating!
Or how about the boss that calls you on the weekend to come in - right now - or be fired! - while you are at the beach? Your boss can't reach you if you don't have one - "Sorry boss, I was at the beach with my family Saturday - I did get your answering machine message when I returned at 8pm, though!".
In other words, I know I am not the slave of the phone, and the people calling know that as well - they think you are their slave...
Pretty cool - I liked the SimCraft better, because he was at least offering plans - but the Rock n' Ride is a clean design (though I can't say much about the web page).
/.ers know of the source company?
c adsoftusa.com/~kls/fltsim/ .acesim.com/main.htmlb simpson/jhbc~1.html
It appears to be a German built product, so it will probably be a quality device - does any of our German
They do give assembly instructions, so it might be possible to "roll your own" from that - maybe build some PVC air cylinder's ala SimCraft, attach it to a 2x4 frame, a bucket seat and some steel - one PIC - whammo! - instant homebrew Rock n' Ride!
So, for those who would like more sim plans, etc - here are some links:
http://www.senet.com.au/~dunkleyj/
http://www.
http://www
http://mypage.direct.ca/b/
Last but not least, my favorite - Omniscience Futureneering's JoyRider Plans - a homebrew 3-axis flight simulator.
Be sure to check out their other offerings - like the radio controlled, vid-cam rocket...
http://www.xs4all.nl/~marcmarc/bwl/index.html
Not Germany - the Netherlands...
Here's some more links!
e /~czesanne/pcm.html
http://www.soulinsight.com/
http://www.provi.d
I had another link with a circuit and such from some guy in Germany, but I am not sure where it is now - but between all of these links, you should be able to do it yourself pretty easily anyhow...
You get yelled at, or questioned, as to why you didn't answer your mobile phone. At least if you don't have one, you don't have to explain.
Personally, I think of cell phones and beepers as leashes - plain and simple. However, I don't think of myself as a slave...
I wish I could mod you back up - you were most certainly on topic (code is fine by me)...