

y2kiah
Members-
Posts
418 -
Joined
-
Last visited
Content Type
Profiles
Forums
Events
Everything posted by y2kiah
-
Hi guys, That.... isn't quite right. I'll see if I can clear things up. lua.dll and lua-socket.dll are the images most responsible for the implementation of Lua and the socket interface used for external communication from Lua script. dcs.exe has embedded Lua to use as a scripting language, there is no polling of files going on at all. dcs.exe loads the images (dll's) at runtime and makes calls to Lua to control it at a high level, like write to its state(s) and read from its state(s). Lua is an interpreted scripting language, the code that you write into export.lua is literally running pre-compiled code at runtime. Lua was implemented with C++, just like DCS. The Lua interpreter parses your commands in real time and decides which code path to take. No data is written to any file and then later read back in, everything is in memory until you explicitly tell Lua to write something to a file. I would recommend against that though. There is no need for polling a file for changes, your script should be complete when it is loaded at startup, because changes to it will *probably* not be picked up at runtime. The DCS programmers have control over the embedded Lua engine, and have determined the hooks that they create to interface with the sim. export.lua, and the specific functions within it, are the hooks that we are given to run our code within the context of the simulation. They give us some data objects and functions to call to interface with the sim. What we do with it is completely up to us.
-
Great work, your modelling skills are very good. Take another look at the steps on the front panel, there are more variations in height than you have in there now. You probably know and haven't gotten to that yet though.
-
ah ok thanks for the clarification, from DM's post I thought he said the can was 5 wide and the bezel was .25 wider. My steps are 5.25 wide so this will leave 1/8" on each side, maybe a bit too much but it will work out without a redesign. Thanks!
-
I've figured 5.25W x 5.5H for the ADI and 5.25W x 4.25H for the HSI from sketches of the instruments. Are those dimensions accurate? I'm also looking to be as accurate as possible on these. Thanks for your help, I'm sure others will appreciate this information too.
-
Hope this helps, for starters anyway. I would assume everything is wrong until proven otherwise, but it's close to the eye. If anyone knows real dims please post corrections to this. Oh and sketchup rounds everything to 1/64 or 1/32 fractions so some of the labels are not exactly what I have, but they are close.
-
Did I have a problem with the grammar? No! I only mentioned spelling. Drop it people. BTW: Lange, you are standing up for a guy that called ED scammers, and negative repping a guy that quoted the forum rules. What a stand-up individual you are.
-
Sorry :music_whistling: Which dimensions would you like? You can check out http://www.strandedduckling.com/ for panel layouts
-
says the guy that recently said this: nice try though :thumbup:
-
Lighten up? Look at his posting history. I don't need to say more. And maybe take your own advice.
-
Exactly what in his profile leads you to that assumption? If he was using a translator, the spelling would be correct, and I would forgive irregular grammar. To me, this looks like blatant troll-type.
-
Do you go out of your way to misspell words, or do you really not know how to spell? 4.6 http://forums.eagle.ru/rules.php#en
-
That makes two of us :megalol: My new CNC is nearly ready, I can't wait to start cutting again.
-
new renders I'm learning a new renderer so in the future my renders will be more photo real. These are default renders with absolutely no work put into materials or lighting, and already a big improvement over Sketchup's stock renderer.
-
Wow great work. These are just prototypes?? Your final versions will be stunning
-
http://www1.futureelectronics.com/doc/AVAGO%20TECHNOLOGIES/HCMS-2903.pdf This is about the only display type that I've found that will work for the CMSP and CMSC panels. They are 5x7 dot matrix 8 character displays, and actually fit perfectly for those panels. There is a slightly larger and smaller version for the top and bottom row of the CMSP panel. They are not cheap, but I was not able to find any character LCDs or VFDs that would fit. For the radios and ILS panel I'm using HDSP-F503 7-segs, and multiplexing them with a MAX-7219. The TACAN panel needs an X or Y in the last digit, so I'm going to use a 14-seg for that, and the equivalent MAX IC for multiplexing 14 segs. For the CDU I'm using a 3.5" TFT LCD. Of course, we still have no way to interface it, but if push comes to shove we can try to do some memory hacking to find static pointers to extract all of the data. It's spread all around in memory and won't be easy. Hopefully ED will save us the trouble and just make it a viewport display like the MFDs.
-
pretty cool Gadroc, look forward to seeing what you've come up with. I have seen that V-USB library before but forgot all about it. I'm thinking about making the CDU a HID keyboard and that would work nicely.
-
Thanks for your input Colin, I haven't had any problems doing this with rotary switches, I debounce input not only for each pin, but also across all switch positions, so it resolves the issue with break-before-make switches. Granted it's only 1 pin saved but it's an easy fix. I think 1 micro per panel is the right solution for the more complicated panels, but a lot of panels are nothing more than a few toggles and rotaries, and a dedicated micro just seems overkill for those. It's really a give and take. One one side, you complicate the wiring to each panel, on the other side you complicate your communication network back to the PC.
-
guys I think it's probable that you are already looking at "the new graphics engine" in A-10C. The map you're flying on was last updated for BS and then put into FC2. The A-10C module has new graphics features that BS did not have, however it still uses the old map, hence the old map cannot "utilize" the new features without being updated. I think if you are expecting "the new graphics engine" to be some DX11 upgrade to the current A-10C engine, you will be disappointed. edit: oh btw, I hope this is proven wrong because I would love to see a more substantial update
-
Warthog throttle back and firmware 20
y2kiah replied to Blackrat_UK's topic in PC Hardware and Related Software
Pretty sure the microcontroller in the throttle would be the only component with direct access to eeprom, if it even uses eeprom or some other persistent storage in the throttle. The only thing I can think of on the PC side is TARGET or the firmware update utility because they probably interface more deeply with the firmware, whereas vanilla windows only sees a USB HID device and can't flash new firmware or send configuration to the throttle or things like that. But I still don't think the PC is responsible at all, this seems to happen at random and as long as the thing is running, meaning the green lights are lit, it could brick at any time. This is just a gut feeling though... I'm in the dark like everyone else, I just don't see how external interfacing could cause the issue. It seems more likely that the problem exists completely within the throttle itself. Everyone wants to correlate the problem to external forces like what brand of MB or when do you plug/unplug it because those things are known to them and they have "control" over them. TM's initial reaction was a firmware update would take care of the issue. Well that didn't seem to pan out, but doesn't mean their intuition was wrong. -
Warthog throttle back and firmware 20
y2kiah replied to Blackrat_UK's topic in PC Hardware and Related Software
Do we really think components are dieing? I honestly don't know because thankfully mine has not bricked. I've been thinking it's more like EEPROM or flash memory being wiped, or something else along those lines that can be fixed by re-flashing the firmware. But maybe I missed something, did anyone who got it back from TM notice new electronics inside? -
Sitting at the center of gravity and spinning in place is not the same thing as simulating the G forces on a pilot's body in flight. That's why a G force centrifuge puts the cabin out on an arm away from the pivot point. The idea of a motion platform is not to match the attitude of the aircraft in flight one for one. The idea is to simulate the sensations experienced by the pilot in flight using the motion of the platform and the earth's natural force of gravity. If the pilot pulls positive G, he/she feels pinned down and back into the seat. The pilot does not feel as if they are tumbling backwards (as it would feel with this motion platform).
-
puke machine man... why is it that literally every single "home built" platform implements motion completely wrong? It's a shame to see all that impressive work fall short because they take the easy way out when it comes to simulating motion. If the cues that your eyes are getting does not match up with the cues your inner ear is getting, you're gonna frikin puke.
-
Another idea for lighting besides discrete LEDs or EL sheet would be LED light strips http://store.makerbot.com/1-meter-led-stripe-green.html These have a self adhesive back so I'm picturing just routing out a channel in the back of the light plate where you would route your strip, and sticking the strip directly onto the back plate.
-
I'm using the Seeeduino Mega which basically has more of everything for cheaper, and it's really small. Price-per-pin it's the best Arduino deal going, but shipping from them took a month and one never arrived at all (they did send another though). Of course, if you're going to build your own PCBs anyway, Arduino being open source you could always use their design and maybe produce it cheaper, not sure on the economics of that though. To increase my effective number of pins, I use an "off" position for each digital switch so the absence of an active signal on all other switch pins indicates that the "off" position must be active, and I send that event. So I only need 1 pin for a two position toggle, 2 for a 3-position toggle... and so on, I'm sure you get the point. You can use shift registers or a matrix setup to increase effective pins as well. For the CDU keyboard I plan on using one or the other. For LEDs I'm multiplexing them, so I only need 3 pins (SPI interface) to work with the MAX7219/21 chip for 8 x 7-segs or up to 64 individual LEDs in a matrix. The biggest limitation I see so far is for rotary encoders. There are a lot of them in the pit and you need real-time interrupt pins to read encoders (again unless you build a separate circuit for those). Those are the most limited pin types on the Arduino board, only a few, maybe 4 on the mega, can't remember. I have looked for a good encoder shield that could for example read up to 8 encoders on 3 SPI pins. I haven't found one yet, that would be a great thing to design. Without a shield like that, you basically need one board per panel with encoders anyway. I was thinking about doing self contained panels vs. a central box for the boards, honestly if money were no object I'd give every panel its own micro and that would simplify things a lot. With the mega being overkill for most panels, I thought it would be better to let panels share a single board so I plan to have a few per side and a few for the front, however many are required - kind of a semi-distributed setup.
-
BTW one of the things I'm kind of waiting on is the release of a new board that the Arduino guys are working on with a built-in ethernet connection instead of a USB connection. Read about it here. Right now I use a Wiznet ethernet shield for connectivity, so I would save around $30 per board when the new one is released. The TFTP feature is very interesting because I'll be able to upload new firmware via ethernet, so making updates to the firmware will be much easier, and could even be automated.