geneb

I wasn't aware of the idle gate function of the A-10. Neat! If you like, I can photograph the A-10C Warthog throttle quadrant grip next to my post-MSIP-II grip. That may help highlight the differences a bit more clearly. g.

ralfidude: I'm in the "do it right or don't do at all" club. deadman: The grips are only superficially the same. For one, the A-10 grip lifts in order to get it past the idle cut off gate. That's it's only function. The finger lifts on the F-15 grip is how you start the engines AND acts as the idle gate bypass. The picture above shows my pre-MSIP II grip. The post-MSIP II throttle is what is used in Lockon. The grip above is missing the four way multi-function switch (mounted next to the TDC cursor controller, where the push-button is now) as well as the missile reject switch. The antenna elevation control is similar to the A-10C post-MSIP II. The one above is potentiometer that remains where you leave it. The A-10C throttle has other features that aren't present on the F-15C throttle. Also, the "radar slew" isn't a slew of any kind. It controls the elevation scanning limits of the radar. g.

Here you go, BubbaMc. http://www.geneb.org/a10/wharthog-2400x1200-sheets.zip Has anyone cut a set of parts from the drawings I provided? g.

Ah, cool. You'll need to do a little bit of finish sanding to the SLA parts, but it should give you a good mold. Don't forget to account for shrinkage if you're going to cast in aluminum. (I'd cast in resin, the original isn't metal) g.

He doesn't have some mouth-breathing, MBA wielding derp trying to constantly step on his d*ck. :D You'd be amazed at what you can accomplish without an MBA around. :) g.

Um, the A-10 quadrant is only superficially like the F-15C quadrant. Trust me on this. :D (One huge issue is the lack of fingerlifts. Without those, you're going to going to have a hell of a time starting the engines. The fingerlifts engage the running JFS to the AMAD and from there to the selected engine.) g.

You're going to have a difficult time printing that with an FDM printer. The parts are going to need a lot of support structure in order to print properly. It's also going to take a long time - the Spitfire Mk V grip I printed took over 11 hours to finish and that was a single-piece grip. Beware of any overhangs that are over 40 degrees or so - that can be problematic for most FDM printers. The model design looks fantastic though. Great job! You might want to consider making one that will use an SFS box too. That way people that use stick extenders can have a more accurate grip system. If you need any FDM printer help, just yell! I'd be happy to help. g.

Here's a question - is there any reason a rear-projected display cube couldn't be built to a very small scale? Say 60" to a side? 48"? As long as your head is in the physical center of the cube, it should work. Correct? g.

Pixel counts and FOV don't go hand in hand. There's no reason a scene generator couldn't provide that same FOV with a resolution of 640x480. You'd have a massive "screen-door" problem (from the pixel sizes), but it could be done. g.

BHawthorne, the problem with using Mylar as a fold mirror is getting it _perfectly_ flat. The best method is to try a regular mirror to test the concept and then replace it with an acrylic first surface mirror for "production" use. However, if the take-off angle is narrow enough, you won't see the ghosting caused by a second surface mirror and can continue to use that. g.

Brad & I (anyone else?) have the unique problem of having to design a cube that's got to fit around 2,000lbs of un-hackable airframe. Rob & I were checking again yesterday and we may end up building a 12' cube to ensure that we clear everything we need to. Even then, the forward screen will have a seam through the middle of it so I can still open the avionics doors in the nose barrel. I'm sure Brad has similar issues. g.

I wasn't aware warping software was even required for this kind of display. Is "Warp" still $ABSURD per channel? g.

Are you referring to NThusim+ or another product? g.

There's a number of different things I'm going to try in the process of building the cube frame. Having the cockpit rail be over six feet off the floor doesn't help things a whole lot either. My first order of business is getting the flight controls re-connected and wired in properly. I'm delayed by having a pair of critical parts missing from my C model throttle quadrant. Hopefully they'll be here soon. g.

It looks like my cube may end up being 10 or 11 feet to a side. The distance from the eye-point to the extent of the windscreen is going to require it. :( I may have issues with the canopy bow throwing a shadow on the forward view if I don't get the projector located in the right spot. Projectors and new video card arrived yesterday! g.

This is one of those threads you read with your jaw hanging open and a look of disbelief on your face. You guys rock. :) I'm very curious to see how this will work with FC3. My VSD has a 5" green monochrome VGA display in it that operates a 640x480. I've got a Sapphire 7950 coming and I'm hoping to be able to run my VGA-only displays on the one analog port of the Sapphire and the two analogs on the NVidia GTX260 that's in the machine now.. Is there any news on whether or not the MPCD will be exportable? (and it just kills me that it's still GREEN. Hey Wags! It's a COLOR display! *laughs*) Between this and the Display Cube, I just may get the F-15 done sooner than I expected. \o/ g.

Where did you find the equation that allowed you to derive the airspeed based on the position of the airspeed needle? If calculations are required, I can handle those on the computer running the hardware interface. Thanks! g.

The problem is that the Lo* functions appear to work - at least they don't "crash" the script. The %.2f mask is what I used in LOMAC v1, using the same function call.... g.

This is what I've got in my example: function LuaExportActivityNextEvent(t) local tNext = t local MainPanel = GetDevice(0) local hsi_heading = MainPanel:get_argument_value(34) local airspeed = LoGetIndicatedAirSpeed() socket.try(c:send(string.format("102,%s\n100,%.2f\n", LoGetPilotName(),LoGetModelTime()))) --socket.try(c:send(string.format("201,%.2f\n", 251.0))) socket.try(c:send(string.format("201,%.2f\n", airspeed))) tNext = tNext + 1.0 return tNext end As it sits now, it goes through a single iteration and the uncommented send is never executed. If I change it so it sends out the literal value instead of the variable version, it works without issue. No error.log is produced, ever. Other people are doing this all the time, so I know that there's got to be something specific to what I'm doing that's making this not work, I just don't know what because I'm not getting any feedback from the runtime system. Is there an issue with the 1.1.1.1 version I'm using? Is there a way to get DCS World to recognize I've already purchased A-10C so I can use it from there (with the potential of a fixed bug or two?) Help! g.

I do. I stopped using the LoGetIndicatedAirspeed() and it works fine now. The issue I have now is where do I find the equivalent call to use with the get_argument_value() calls. What I've found (for example, IAS), isn't giving me sensible values. The example I'm trying is: local MainPanel = GetDevice(0) local ias = MainPanel:get_argument_value(61) socket.try(c:send(string.format("201,%.2f\n", ias))) Is there any single place where these interfaces are documented? It appears to be scattered all over the place, willy nilly. It's especially frustrating that the given function calls in Export.lua don't work. tnx. g.

Honestly, the last time I used LoGetIndicatedAirSpeed() was 2003 and LockOn v1. I'd already tried the code in SciTE to make sure I wasn't doing something obviously stupid. This leaves the non-obviously stupid. :) tnx. g.

When I execute this line in LuaExportActivityNextEvent(t), it works repeatedly: socket.try(c:send(string.format("102,%s\n100,%.2f\n", LoGetPilotName(),LoGetModelTime()))) I've got my cycle time set to one second, so I see a packet every second. However, if I add another line: socket.try(c:send(string.format("201,%.2f\n", LoGetIndicatedAirSpeed()))) The Lua code executes only a single time, and the "201" packet is never sent. I can only assume that the interpreter doesn't like the second send for some reason. However, NO "error.log" file is being created. I've searched the entire drive that I've got A-10C installed on as well as all the directories under my user account (Windows 7). Any suggestions? tnx.

I'm using straight DCS A-10C v1.1.1.1. I've got DCS World installed, but I'm not using it for my current development work. (DCS World doesn't seem to know I've already got A-10C and I'm not buying it twice. :) ) g.

That's really interesting - I've not seen that behavior on my system. I'll have to do further testing, but I'm not seeing code changes until I complete quit the application and re-start it. The lack of error logging really bothers me too. Thanks! g.

Is there a way to force DCS A-10C to reload Export.lua without having to completely exit out of the software each time? I'm using v1.1.1.1 - I've also noticed that it never creates error logs when I _know_ there are errors in the code. Thanks. g.