Hard Light Productions Forums
Modding, Mission Design, and Coding => The Scripting Workshop => Topic started by: Daboule on April 24, 2012, 11:25:55 am
-
Hi all,
After 4 hours playing with the scripting engine (wow!!! Really powerful!) and roaming around this forum, I still have some questions.
Is it possible to capture the ETS value (energy distributed between weapons/shields/engine)
Is it possible to capture the state of the Match speed and Auto Targetting systems?
I've search in all the documentation I can found and it seems that nothing has been implemented for that?
Am I missing something?
Thanks a lot.
Daboule
-
You are correct, these values are currently not accessible by the scripting engine.
-
Hi The E,
Thanks for your answer.
Daboule.
-
heres the breakdown of what i think can and cannot be done with scripting as far as the hud goes
(http://i213.photobucket.com/albums/cc103/Emperor_of_Nihil/hud.jpg)
actually thats years out of date. there looks to be some things that ive solved since then.
i suggested a feature to allow you to run hud gauge scripts based on entries in the hud_gauges.tbl, and have the hud system deal with all the complex stuff, placement, size, resolution handling, rtt, color scheme, etc. in script you would be provided with hooks for running and rendering the hud gauges. you could deal with that in the same way as ships or weapons, iterate over an indexer for gauge instances, if the gauge is a scripted gauge, run the script functions appropriate for that gauge, using the instance of the gauge configuration data for information about how the gauge should be setup.
-
*cough* yeah there's been a few things I've been asking about since the HUD scripting was released... still haven't
gotten answers to...
-
Thanks a lot Nuke.
The goal is to interface a Microcontroller electronic board to create "real" cockpit (ok real is a strange word for a space fighter simulation...). It is an old idea I had and I already talked about that one or two years ago on this forum. I've finally found time to really start to work on it now and started to create a prototype yesterday.
What I'm doing at the moment is trying to get as much information as possible and send them via UDP to another program running on my computer.So I use LuaSocket and scripting to send the collected information to my service. Then this service sends the updated information to the board via USB.
I've got a running prototype for that and I can interact with LEDS, buttons or buzzer to indicate on my board for example if I'm out of countermeasures or if a subsystem has been destroyed.
I think i've found a way (but didn't tested it yet) to display the status of my wingmen and to indicate if I'm targetted by somebody (will implement that this week-end)
I'm quite experienced in programming but I'm really new to Lua and Freespace scripting and started to look at that only yesterday, so I'm probably missing a lot of concepts.
I've got a lot of things running correctly and ideas for most of my problems but I'm still looking for a way to get at least the Energy Transfert System values... I would really like to have a led bargraph on my cockpit indicating the energy distribution between the different systems.
Of course I could make changes to the Freespace source code but I would really like to avoid that. I want to use the offcial releases and not a custom build, because it would be to messy to maintain my custom version at each new official release... So as long as I can solve my problems through scripting I prefer using this way than making changes to Freespace and compiling my own version.
For the ETS gauge you said "doesn't look like it" on your schema. I apologize for my bad English, so I probably misunderstand something, but for me that means: "I successfully get that working, but it has a different look". If it's the case, how do you managed that please?
Another interesting thing for me is this part of your post :
i suggested a feature to allow you to run hud gauge scripts based on entries in the hud_gauges.tbl, and have the hud system deal with all the complex stuff, placement, size, resolution handling, rtt, color scheme, etc. in script you would be provided with hooks for running and rendering the hud gauges. you could deal with that in the same way as ships or weapons, iterate over an indexer for gauge instances, if the gauge is a scripted gauge, run the script functions appropriate for that gauge, using the instance of the gauge configuration data for information about how the gauge should be setup.
Is there a script on this forum that illustrates this concept or at least illustrates how to script "something" based on a "something.tbl", or how to access the gauge instances? Because into the scripting.html file I've seen nothing related to gauges... but once again, I'm really new to Lua and Freespace scripting and may be missing something.
Thanks a lot.
Daboule.
-
thats easy! you need an arduino an ethernet shield, the lua socket library and a crossover cable. im sure you can figure out the rest :D
my problem was i have one of those cheep ethernet shields, not the "official" ethernet shield. my problem up to this point was that the library it came with didnt work, there was another library that sorta worked, but was alpha. and it only supported tcp server. but i was able to get the led on the arduino to dim in relation to the ships weapon energy. it was pretty sweet. but i shelfed the project pending the completion of the library i started using. this kinda thing requires a monetary investment to get off the ground, and im kinda poor. but the proof of concept works, because ive see it work. some interfaces may require threading to work, like if you use a serial interface, you need to run that in its own thread for timing purposes, but i dont think i had that problem when using tcp/ip (the library seemed to do this for me).
probibly wouldnt be hard to do 7 segment dispays, bargrphs, led matrices, even drive lcd displays or talk to arm devices (raspberry pi comes to mind) for creating mfds.
the idea i had was mostly just that. and it would require some code changes, as would getting the data from an ets gauge. i was intrested in getting at the ets data but i had a hard time figuring out how the data structure behind it worked. so i never did it. one of these days i want to do an external radar using the tv out library (or maybe a video game shield). tomorrow i can check and see what code if written and were all my posts on the subject are at.
-
Hi Nuke,
Yes, I've got some experience with microcontroller (Microchip PIC). That's not really a problem, as I work in industrial automation and I deal with those problem every single day :D(by the way if you need help on this side feel free to ask :nod:). I'm also kinda poor :(, but I've got the chance to have access to a lot of old and unused hardware parts. It's a funny way to recycle them :p
I've searched yesterday how it can be possible to use Luasocket to send the captured data over the network. I've finally made UDP work (it was not really easy I must confess...)
Now I've got a small program that act as a gateway between Luasocket and my usb card. I've created a small protocol to send data to the microcontroller and everything is working fine on this side.
I'm using UDP, because it is light and you can send datagram over the network without taking care if they are correctly received or not. Moreover, the gateway can run on the same computer than Freespace and if needed I can also run it on another computer, I've just to change the destination IP address. That's pretty cool.
At this point I send data 4 times per second, it seems to be enough. If my gateway doesn't receive anything or if it receives corrupted data it just doesn't update anything and wait for the next packet (with the performances of the current networks, it is really rare to lose packet on a local network and when it arrive, that means I just have to wait for a quarter of second to have the updated data).
And yeeeeees that's great to hear a buzzer ringing and to see a light going from green to red when you're out of counter measure or when a subsytem is destroyed...
So my problem is not how to send data to the board, but how to extract the data from Freespace :banghead:
If somebody already found a solution to get the ETS values please let me know, I'm still searching for it.
one of these days i want to do an external radar using the tv out library (or maybe a video game shield). tomorrow i can check and see what code if written and were all my posts on the subject are at.
That sounds really really really interesting. Because, this is the next step for me: I'm planning to hack two old Wifi PDAs and use them as MFDs. The idea I've got now is to create on the fly JPG files based on the extracted data and send them through the network to an application running on each PDA.
And I'm happy to see that I'm not the only guy who's silly enough to try to create a simpit for freespace ;7
Daboule
-
tomorrow i can check and see what code if written and were all my posts on the subject are at.
I've found the post you're talking about... this is funny, because I've tryied the same things (first RS232, then finally a UDP interface) and made the same technical choices exactly one year after you... It would have saved me a lot of experiencing time if I've seen those posts before.
By the way, I'm not sure that this thread should stay in the scripting section anymore, because even if I started to ask question on scripting, it is a bit a different subject now.... (Moderators?)
Daboule
-
As you obviously have the required coding experience it would probably be quite easy for you to write the necessary interface functions yourself. Take a look at this article (http://www.hard-light.net/wiki/index.php/Scripting_API) if you want to know how to add new functions to the engine.
-
As you obviously have the required coding experience it would probably be quite easy for you to write the necessary interface functions yourself. Take a look at this article (http://www.hard-light.net/wiki/index.php/Scripting_API) if you want to know how to add new functions to the engine.
I know I started by saying that I did not want to modify the source code, but what you just send me is really interesting (and too tempting ...).
I think I know now what I will do the next weekend :D
Thanks a lot.
Daboule
-
As you obviously have the required coding experience it would probably be quite easy for you to write the necessary interface functions yourself. Take a look at this article (http://www.hard-light.net/wiki/index.php/Scripting_API) if you want to know how to add new functions to the engine.
I know I started by saying that I did not want to modify the source code, but what you just send me is really interesting (and too tempting ...).
I think I know now what I will do the next weekend :D
Thanks a lot.
Daboule
if your code does not mess with the rest of the engine, i see no reason why it wouldnt be included in the engine. talk with some of the coders around here and see their take on it.
-
modifying the source to say, expose the ets variables, is probibly a good thing that many people can use. this kind of change to the source usually can be committed to the repo pretty quickly.
as for learning the scripting api. you need to go to the dev tool section and check output scripting to scripting html. this outputs a scripting.html file in your root fs dir for the current build, this file contains the complete reference for all the structures and functions for getting access to some of freespace's vars.
-
Hi,
I've started modifying the code and things are running :)
I've modified a bit the lua.cpp files and recompile
I've successfully managed to add the following things to the scripting language
WeaponRechargeRate > return 0 in case of an error, return a value between 1 and 13 if correct
EngineReachargeRate > return 0 in case of an error, return a value between 1 and 13 if correct
ShieldRechargeRate > return 0 in case of an error, return a value between 1 and 13 if correct
IsMatchingSpeed() > return NIL in case of an error, true if the player is matching target speed, false if not
IsAutoMatchingSpeed() > return NIL in case of an error, true if the player is auto-matching target speed, false if not
IsAutoTargetting() > return NIL in case of an error, true if the player is auto targetting, false if not
In fact the source code is really well commented and self explanatory, congrats to the coders (I must confess I'm not as good as you guys...).
I won't have time to finish all I want to do tonight (I've also a "real" job and a wife who doesn't really understand the beauty of programming :D) but I look forward to finish that this week-end, because now I've started to change the code I've plenty of ideas for the variables I need to expose :D
I will update this post and try to post a video somewhere of all the stuff (Freespace, LuaSocket and the PIC developement board) working together.
See you later and big big thanks to all of you!!
Daboule
-
another lua tip that is relevant to you: learn to use the lpack library. lua does everything with double precision floats, so it doesnt know what an integer is. the lpack library handles that for you. it helps do conversions to and from common c data types, very useful for serialization necessary for communications dealing with microcontrollers. lua 5.2 will have a built in bitmask library, but until that is upgraded in the engine freespace has its own system, or you can use luabitops library. i use lua for windows for all my non-frespace lua needs. i think it may also play nice with freespace's lua interpreter, giving you access to the libraries it provides, and handles paths for you. so you just need to require the libraries in your scripting.tbl.
i was looking at hardware for panel systems. i figure the best way to go about everything is to use i2c port expander for most of the led gauges and buttons, and i2c adcs for analog inputs, microcontrollers may also be used for more complicated gauges or mixed gauges with both analog and digital i/o. mcu to mcu networking over i2c is fairly straightforward. also support for 112 devices per bus, and only requires 2 wires plus power/ground. its easier to run an i2c bus between devices than try to run everything off a single mcu directly. a 16 bit i/o expander could easily drive an entire led (7 segment/alphaneumeric/matrix/bargraph/etc) array with only an i2c interface. i2c only gives you about a meter of bus length, so you may need more than one bus in the panel. a powerful mcu can run the show. i have an atmega1284 somewhere that would make a good bus master. it only has one i2c bus though, others might be bitbanged, but the chip does have dual uarts and an spi interface as well.
pretty soon im gonna be building a 7 segment array, which i intended to use debugging parallel buses. but i suppose i could use it as a general purpose display device as well. i can make the bus i/o a separate module that i can remove when i only want to use it for output. i will also be building a 20 button keypad to go with it. it will use a serial interface and merely output scancodes. parts for this are on their way.
another idea i had with reguards to cockpit monitors , was that most video cards come with extra video ports, composite,vga,etc. so it would be possible to write some graphics generating software on the pc and use named pipes or tcp/ip loopback to talk to them from freespace. you could then put these applications into fullscreen on the extra monitors and run the game on your main display. i do this a lot when playing orbiter. its cool to have your orbit display on its own little screen. you can get good screens from dead portable dvd players (where screens work but the dvd players dont), or those cheep rearview camera monitors. these usually have composite interfaces. which are easy to work with.
-
Hi,
All this stuff seems ok :
- WeaponRechargeRate > return 0 in case of an error, return a value between 1 and 13 if correct
- EngineReachargeRate > return 0 in case of an error, return a value between 1 and 13 if correct
- ShieldRechargeRate > return 0 in case of an error, return a value between 1 and 13 if correct
- IsMatchingSpeed() > return NIL in case of an error, true if the player is matching target speed, false if not
- IsAutoMatchingSpeed() > return NIL in case of an error, true if the player is auto-matching target speed, false if not
- IsAutoTargetting() > return NIL in case of an error, true if the player is auto targetting, false if not
Here is an example script that uses those variables and functions
#Global Hooks
$HUD:
[
ship = hv.Player
isMatching = ship:isMatchingSpeed()
isAutoMatching = ship:isAutoMatchingSpeed()
isAutoTargetting = ship:isAutoTargetting()
if isMatching then
gr.drawString("Matching Speed",150,80+20)
else
gr.drawString("Not matching Speed",150,80+20)
end
if isAutoMatching then
gr.drawString("Auto Matching Speed",150,80+40)
else
gr.drawString("Not auto matching Speed",150,80+40)
end
if isAutoTargetting then
gr.drawString("Auto Targetting",150,80+60)
else
gr.drawString("Not Auto Targetting",150,80+60)
end
gr.drawString("Weapon recharge rate: "..ship.WeaponRechargeRate,150,80+80)
gr.drawString("Shield recharge rate: "..ship.ShieldRechargeRate,150,80+100)
gr.drawString("Engine recharge rate: "..ship.EngineRechargeRate,150,80+120)
]
#End
And this is the amazing result of this incredibly powerful script :doubt:
(http://www.notilis.com/ScriptingTest.png)
Now, the next step are:
- directives
- monitor
- inspected ships
- wingmen status
More news later :)
See you.
Daboule
-
Great work! :yes: If you are finished with the new functions then you can post the patch here on the forums so it can be reviewed and committed to trunk so everyone can use these cool new feature.
I'm also not sure on how it's handled by the engine but it would be useful if you could expose IsMatchingSpeed(), IsAutoMatchingSpeed() and IsAutoTargetting() as VIRTVARs so they can be modified by a script.
If you want to implement new HUD functions then you can take a look at the hud folder in the code as the implementations of all the HUD gauges is located there but also in other parts of the code. The directives gauge is implemented in mission/missiontraining.cpp if you can't find it.
-
:)
Great work! :yes: If you are finished with the new functions then you can post the patch here on the forums so it can be reviewed and committed to trunk so everyone can use these cool new feature.
I'm also not sure on how it's handled by the engine but it would be useful if you could expose IsMatchingSpeed(), IsAutoMatchingSpeed() and IsAutoTargetting() as VIRTVARs so they can be modified by a script.
Thanks :)
I won't have time to work on the code before before this week-end and I would prefer having a better look at what I've made, because I must confess that I was not really prepared to learn Lua, the scripting functions, investigate the FreespaceOpen code, add functiunnalities (and have them working :D) when I posted my first question two days ago. So I will review it and test it in multiplayer mode with my friends this week-end (and it's a 4 days week-end for most of French people :pimp: so I will have plenty of time for that)
Also I agree with you when you say it would be better to have VIRTVARs instead of the targetting, matching and auto matching speed functions...
I was thinking the same thing will having my shower this morning :D so if it's possible without impacting the engine I will try to modify my code in this way.
I will also change the names of the ETS variables, something like ETSWeapon, ETSEngine and ETSShield, because the engine does not really has a recharge rate.
Finally I will modifiy the ETS vars to have a return value between 0-12 (it is really counter intuitive to have a return value of 1 when there is no energy at all), in case of an error the return value will be -1. It will be better that way.
It should be easy to do that.
Thanks a lot for the information related to the HUD and the directive gauges, it will probably save me a lot of time of search in this big big code :D
Once again thanks to everybody. This forum rocks!!!
Daboule
-
another lua tip that is relevant to you: learn to use the lpack library. lua does everything with double precision floats, so it doesnt know what an integer is. the lpack library handles that for you. it helps do conversions to and from common c data types, very useful for serialization necessary for communications dealing with microcontrollers. lua 5.2 will have a built in bitmask library, but until that is upgraded in the engine freespace has its own system, or you can use luabitops library. i use lua for windows for all my non-frespace lua needs. i think it may also play nice with freespace's lua interpreter, giving you access to the libraries it provides, and handles paths for you. so you just need to require the libraries in your scripting.tbl.
i was looking at hardware for panel systems. i figure the best way to go about everything is to use i2c port expander for most of the led gauges and buttons, and i2c adcs for analog inputs, microcontrollers may also be used for more complicated gauges or mixed gauges with both analog and digital i/o. mcu to mcu networking over i2c is fairly straightforward. also support for 112 devices per bus, and only requires 2 wires plus power/ground. its easier to run an i2c bus between devices than try to run everything off a single mcu directly. a 16 bit i/o expander could easily drive an entire led (7 segment/alphaneumeric/matrix/bargraph/etc) array with only an i2c interface. i2c only gives you about a meter of bus length, so you may need more than one bus in the panel. a powerful mcu can run the show. i have an atmega1284 somewhere that would make a good bus master. it only has one i2c bus though, others might be bitbanged, but the chip does have dual uarts and an spi interface as well.
pretty soon im gonna be building a 7 segment array, which i intended to use debugging parallel buses. but i suppose i could use it as a general purpose display device as well. i can make the bus i/o a separate module that i can remove when i only want to use it for output. i will also be building a 20 button keypad to go with it. it will use a serial interface and merely output scancodes. parts for this are on their way.
another idea i had with reguards to cockpit monitors , was that most video cards come with extra video ports, composite,vga,etc. so it would be possible to write some graphics generating software on the pc and use named pipes or tcp/ip loopback to talk to them from freespace. you could then put these applications into fullscreen on the extra monitors and run the game on your main display. i do this a lot when playing orbiter. its cool to have your orbit display on its own little screen. you can get good screens from dead portable dvd players (where screens work but the dvd players dont), or those cheep rearview camera monitors. these usually have composite interfaces. which are easy to work with.
Hi Nuke,
Thanks for the tips :)
Yes I will also use I2C i think.
Currently I'm running my tests on an EasyPIC v6 board from Mikroelctronika.
(http://www.mikroe.com/img/development-tools/pic/easypic6/gallery/easypic6_550_1.jpg)
I love this board it's really easy to test functionnalities and when you've validated them, the circuit diagram of the board can be used to create your own... and there are also plenty of extension boards.
You could also have a look at this website http://www.fscockpit.com/specialinterfacesolutions.html (http://www.fscockpit.com/specialinterfacesolutions.html) they are plenty of really interesting links on various hardware interface boards.
Daboule
-
thats a nice dev board. looks like it has a little of everything you may need.
im doing everything with avr and arduino though. cant really afford to switch over to pic right now. they have some good mcus and they have really good documentation i hear. i want to at some point switch over, but all my dev tools are for avr. arduino is a good cheap way to get into microcontrollers for the uninitiated, and my electronics know how had really shot through the roof because of it.
-
i was looking at things to use for panel components and i found this thing:
http://www.sparkfun.com/products/10595
this would make a good shield gauge. though a small lcd might look better.
and 3 of these and some keyswitches would make a fairly good ets gauge:
http://www.sparkfun.com/products/9936
ive been sourcing most of my parts off of ebay, i just got a bag of 100 signal diodes (good for button scan matrices) for a buck and free shipping to boot. and my collection of 7400 series gates is ever increasing. microcontrollers are harder for me to get, usually just go digikey for those, but i order a bunch at once and only when i have money.
it would be pretty cool to make an oshw archive of gauge schematics, pcb sources, parts lists, and files for producing parts on cnc machines (laser cutters, 3d printers). you can use with manufacturing services to get all the parts needed to build a complete panel, or you can build it yourself if you had the right equipment. even with oshw there are ways to make money, like by selling completed gauges, or manufacturing parts.
-
this would make a good mfd screen
http://www.sparkfun.com/products/8799
its close to square and so would accommodate 3 good rows of buttons. it also has that white on blue color you see on a lot of mfd displays. its just a little pricy. i still want to find a squareish color lcd that is around 4" x 4". perhaps also with an interface you can just plug into your video card. then its just a matter of running the mfd application on that display. though you would probibly need a separate interface for the ring-o-buttons.
-
Hi Nuke,
I'ts great to see you guys are making progress on this. I have been lurking for years waiting to see if FSO would ever be modified to send out its data for cockpit builders. I have always wanted to build a cockpit around this game.
Were you ever able to export textures from the engine? There was a thread from almost exactly a year ago where it was being discussed. It looks like sending simple data packets out via UDP is simple enough, but it would still be really cool to just let the game render the radar like it is now and display that exact image on a small LCD/MFD panel.
-
my problem has always been sourcing parts. this problem has been 2 fold, i am poor for one, and live in the ass end of nowhere and a lot of places gouge me on shipping for it. i get a lot of parts off ebay from semi-reputable gray market chinese sellers who will sell you 10 of anything for a buck and free shipping. microcontrollers i still need to buy through digikey, and last time i ordered from them their shipping rates were sane. my other source for parts is junk. ive gotten really good at desoldering.
another thing i have trouble with is chemicals for board etching. most chemicals can be shipped ground only, and i live on an island go figure. i found a hackish recipe (peroxide, vinegar and salt) for pcb etchant and im not even sure it will work. transfer paper is another thing i have trouble getting, but i found out how to make my own (cook cornstarch till it turns brown, add water and paint sheets of paper with it). i have not tested this yet at all. i should have everything, so its just a matter of designing gauges. copper clad pcbs are kind of expensive. i got 4 8-10 sheets for $20, and so far is the most expensive thing yet. and i got me a free laser printer. i still dont have a means for cutting the boards, you can dremel but thats messy and imprecise. i hear an office guillotine would work, and ive been watching garage sales and thrift stores like a hawk to try and obtain one. i could run a test etch but given my zero budget approach id want to produce something useful. all i need is a board design that i think will work. though i think i may just do a bunch of breakout boards for various components that i have on stock for prototyping. get a good precision test out of it, see how wide i can make traces and **** like that.
3rd thing you need is materials to built the cockpit. the inlaws have a saw mill, and im sure they would let me walk off with a couple of 2x4s if i put a few nails in the house they are building. i also like to raid the trash piles at local construction sites at 3am. hardware store has acrylic in stock, its ****ing expensive, but i figure it would make a pretty good panel material if you spraypaint the back of it some kind of metallic shade or black. its easy to work too. thinking about getting a laser cutter/engraver machine off of ebay, which makes quick work of acrylic. tools are really the main thing im lacking. also seeing as i live in an apartment i dont think the neighbors would appreciate me building something like that. i wanted to get my brother in law in on the project but he isnt a big fan of freespace.
Hi Nuke,
I'ts great to see you guys are making progress on this. I have been lurking for years waiting to see if FSO would ever be modified to send out its data for cockpit builders. I have always wanted to build a cockpit around this game.
Were you ever able to export textures from the engine? There was a thread from almost exactly a year ago where it was being discussed. It looks like sending simple data packets out via UDP is simple enough, but it would still be really cool to just let the game render the radar like it is now and display that exact image on a small LCD/MFD panel.
nah its over my head. youd probibly need an arm device (raspberry pi looks promising) to keep up with the required throughput, and at least 100mbps ethernet. however im starting to consider an alternative. i started a game engine written entirely in lua. my 3d renderer sort of works, and supports textured models, quads, sprites, and text. i could fork the code and create an mfd application with the exiting engine. im thinking of using tcp/ip loopback to do ipc between this mfd software and freespace. then you could control the rendering of 2d/3d graphics over the connection. this would allow you to design mfds where video output to a small lcd screen which is driven by the same computer the game runs on, and saves you a lot of dev time. flipside is this eats up valuable monitor connections, if you ever wanted to do a multi monitor setup. im ok with this however. still need to do some hardware design, like some kind of usb hid device for interactive buttons, or you can buy off the shelf joystick controllers to save a little time.
you can do things with mfds or you can do things with a network of stand alone gauges. i figure prototyping either of these will cost about $50 each in parts. im considering it would be a good idea to sell units back to the community to help cover some of the expense. i want to make it oshw, but other oshw people are making a killing selling completed units and kits of their products to lazy foos and hobbyists, respectively (and the schematics, boars ssources and source code would all be there for the adventurous do it your selfers). i figure that 80% of the workload will be software though. ive already proven you can load lua modules in freespace, like luasocket, and ive been able to do ipc with that, so im certain its possible. the fact that i have the potential to make some money selling hardware to the community might turn out to be a motivating factor. im gonna post a poll in general fs to see how many people would be willing to buy panel elements for a freespace cockpit simulator, should give us an idea for a market.
-
right now i'm building an home cockpit BSG Viper Replica, with an interface for binding switches and toggles as i want...if will be possible put in other screens HUD gauges would be awesome.
Looking forward to those features! Keep it up guys!
-
I can't wait to get my cockpit-type area set up in my new house. Haven't been able to use the X45, the Pro Yoke, or the racing wheel and pedals since 2008!
-
im thinking of using tcp/ip loopback to do ipc between this mfd software and freespace. then you could control the rendering of 2d/3d graphics over the connection. this would allow you to design mfds where video output to a small lcd screen which is driven by the same computer the game runs on, and saves you a lot of dev time. flipside is this eats up valuable monitor connections, if you ever wanted to do a multi monitor setup.
If we just use a second computer, passing data via UDP packets, we would have 3 to 4 more monitor connections. That’s what many of the flight sim guys do.
As for pre-made cockpit controls, I would definitely be interested. I am also a fan of the Arduino and might be able to make my own controls someday, but I am always willing buy instead of build if it saves me time!
Seems like this thread if getting WAY off the original topic. :) Should we start a new one around building a simpit? Seems like we are gathering some interest here. Which forum would be the most appropriate? This will probably require work in both the Scripting (Freespace Modding) and C++ (The Freespace Source code Project) areas.
-
It's coming ;)
It has been a bit longer than expected because of a big overload in my job.
Hope to release something soon, I'm working in both windows and linux (haven't got a Mac...) and testing everything in the EasyPic board.
It's cool to have the ETS on a small screen or to have a Biiiip Biiiip Biiiip when you've have been locked by missile
I will post a video of the running MFD asap.
I love it :D
-
It coming ;)
Hope to release something soon.
Tell us more! haha
-
It coming ;)
Hope to release something soon.
Tell us more! haha
ETS is working
Auto match speed is working
Match speed is working
Auto targetting is working
Inspected cargo/ship is almost working
Directives is working
Wingmen status is working
The mfd prototype is already able to display all those informations
I'm working on a way to display the radar information on the MFD.
Hope to be able to post a video pretty soon.
Daboule
PS : The good news is the next week-end is another 4 days week-end ;)
-
Nice! I am looking forward to seeing the video. Getting radar on the MFD will be incredible. Are you re-implementing the radar code outside of FSO and just using the data passed in or are you using FSO for the image generation? I was thinking that using the radar code in an external application and just supplying the data from FSO would be a viable option.
-
There's a guy running an arcade in California who would be very interested to talk to you I imagine.
-
can't wait to see it! AMAZING FEATURE INCOMING! :D
-
Hi all,
- Dumbfire threat indicator
- Missile threat indicator
have been added (the buzzer in my cockpit will love that :D)
Radar is a bit more complicated, but almost working...
Daboule
-
Nice! I am looking forward to seeing the video. Getting radar on the MFD will be incredible. Are you re-implementing the radar code outside of FSO and just using the data passed in or are you using FSO for the image generation? I was thinking that using the radar code in an external application and just supplying the data from FSO would be a viable option.
Hi ABetterWay...
In fact the radar is an impressive piece of maths and trigonometry (at least for me) and I had to reopen my classroom books...
To make things simple let's say that the code transforms the 3D coordinates of the blips into 2D coordinates used by the render engine to display the related bipmaps on the radar.
I've search a lot to find a way to have the radar working.
The easiest one seemed to be that one: extracting the "flat" (2D) coordonnates of the blips and use that coordinates to generate a new image... it is not really easy but it is working (ok... almost working) for the ships only for the moment.
I send the coordinates through UDP to a dedicated application, and this application uses the coordinates to create a new image each time the new coordinates are received...
I have to polish that a bit and find a way to have the same thing for the other objects...
I will let you know as soon as I have something finished
Daboule
-
my problem has always been sourcing parts. this problem has been 2 fold, i am poor for one, and live in the ass end of nowhere and a lot of places gouge me on shipping for it. i get a lot of parts off ebay from semi-reputable gray market chinese sellers who will sell you 10 of anything for a buck and free shipping. microcontrollers i still need to buy through digikey, and last time i ordered from them their shipping rates were sane. my other source for parts is junk. ive gotten really good at desoldering.
another thing i have trouble with is chemicals for board etching. most chemicals can be shipped ground only, and i live on an island go figure. i found a hackish recipe (peroxide, vinegar and salt) for pcb etchant and im not even sure it will work. transfer paper is another thing i have trouble getting, but i found out how to make my own (cook cornstarch till it turns brown, add water and paint sheets of paper with it). i have not tested this yet at all. i should have everything, so its just a matter of designing gauges. copper clad pcbs are kind of expensive. i got 4 8-10 sheets for $20, and so far is the most expensive thing yet. and i got me a free laser printer. i still dont have a means for cutting the boards, you can dremel but thats messy and imprecise. i hear an office guillotine would work, and ive been watching garage sales and thrift stores like a hawk to try and obtain one. i could run a test etch but given my zero budget approach id want to produce something useful. all i need is a board design that i think will work. though i think i may just do a bunch of breakout boards for various components that i have on stock for prototyping. get a good precision test out of it, see how wide i can make traces and **** like that.
3rd thing you need is materials to built the cockpit. the inlaws have a saw mill, and im sure they would let me walk off with a couple of 2x4s if i put a few nails in the house they are building. i also like to raid the trash piles at local construction sites at 3am. hardware store has acrylic in stock, its ****ing expensive, but i figure it would make a pretty good panel material if you spraypaint the back of it some kind of metallic shade or black. its easy to work too. thinking about getting a laser cutter/engraver machine off of ebay, which makes quick work of acrylic. tools are really the main thing im lacking. also seeing as i live in an apartment i dont think the neighbors would appreciate me building something like that. i wanted to get my brother in law in on the project but he isnt a big fan of freespace.
Hi Nuke,
I'ts great to see you guys are making progress on this. I have been lurking for years waiting to see if FSO would ever be modified to send out its data for cockpit builders. I have always wanted to build a cockpit around this game.
Were you ever able to export textures from the engine? There was a thread from almost exactly a year ago where it was being discussed. It looks like sending simple data packets out via UDP is simple enough, but it would still be really cool to just let the game render the radar like it is now and display that exact image on a small LCD/MFD panel.
nah its over my head. youd probibly need an arm device (raspberry pi looks promising) to keep up with the required throughput, and at least 100mbps ethernet. however im starting to consider an alternative. i started a game engine written entirely in lua. my 3d renderer sort of works, and supports textured models, quads, sprites, and text. i could fork the code and create an mfd application with the exiting engine. im thinking of using tcp/ip loopback to do ipc between this mfd software and freespace. then you could control the rendering of 2d/3d graphics over the connection. this would allow you to design mfds where video output to a small lcd screen which is driven by the same computer the game runs on, and saves you a lot of dev time. flipside is this eats up valuable monitor connections, if you ever wanted to do a multi monitor setup. im ok with this however. still need to do some hardware design, like some kind of usb hid device for interactive buttons, or you can buy off the shelf joystick controllers to save a little time.
you can do things with mfds or you can do things with a network of stand alone gauges. i figure prototyping either of these will cost about $50 each in parts. im considering it would be a good idea to sell units back to the community to help cover some of the expense. i want to make it oshw, but other oshw people are making a killing selling completed units and kits of their products to lazy foos and hobbyists, respectively (and the schematics, boars ssources and source code would all be there for the adventurous do it your selfers). i figure that 80% of the workload will be software though. ive already proven you can load lua modules in freespace, like luasocket, and ive been able to do ipc with that, so im certain its possible. the fact that i have the potential to make some money selling hardware to the community might turn out to be a motivating factor. im gonna post a poll in general fs to see how many people would be willing to buy panel elements for a freespace cockpit simulator, should give us an idea for a market.
Hi Nuke,
I'm also looking at the Raspberry Pi as the motherboard of my simpit. For those of us who don't know this product: It is complete PC (motherboard, video out, SD card reader, usb port, CPU....) a really really small form factor (the size of a credit card) and it cost only 25 €... It seems that you can easily install linux on it.
On http://www.raspberrypi.org/ they are really impressive videos showing the Raspberry Pi running Open Transport Tycoon (another open source video game :D)
I will try to order one and test if it can be the core of my MFD... (by the way, I agree with ABetterWay, this thread is really far from it's first subject and it would be a good idea to open a new one, dedicated to simpit building...)
Daboule
-
i wouldnt call it a pc (its arm based, and im oldschool enough that 'pc' means 'x86', but not oldskool enough to call it ibm compatible :D), but i like it anyway. it could sidestep and simplify a lot of the hardware dev though. its already got video hardware, network interface, has enough gpio for any interfaces you might want to add, and you still have usb. you can use gles for fairly good graphics.
of course you need to find a smallish screen with an hdmi interface, and i see that as getting expensive (unless there is a cheap adapter). seems it has composite built in so i can keep using those 3.5" monitors.
i started a thread on general fs to discuss the marketability of open source cockpit gear. but yea im not really sure theres a board for hardware at all. i generally dont know where else to put it. but scripting is likely going to be the primary method to talk to hardware.
-
i generally dont know where else to put it. but scripting is likely going to be the primary method to talk to hardware.
Scripting will probably be used quite a bit, but I figure at some point we might want to bypass the scripting engine for speed. I'm just saying that off the top of my head based on past experience with scripting. I have never used lua so I can't really comment on its speed. I have always been a fan of native code vs scripting or interpretive languages. Especially when it comes to the speed we might need for something like this.
It would be really nice to have a board devoted to simpits, joysticks and other hardware. Probably to much to ask for though. Lets start a new thread in the same forum as your hardware poll. In General.
-
i generally dont know where else to put it. but scripting is likely going to be the primary method to talk to hardware.
Scripting will probably be used quite a bit, but I figure at some point we might want to bypass the scripting engine for speed. I'm just saying that off the top of my head based on past experience with scripting. I have never used lua so I can't really comment on its speed. I have always been a fan of native code vs scripting or interpretive languages. Especially when it comes to the speed we might need for something like this.
It would be really nice to have a board devoted to simpits, joysticks and other hardware. Probably to much to ask for though. Lets start a new thread in the same forum as your hardware poll. In General.
if you cant write the native code patches that dont interfere with what the rest of FSO does, dont reccomend "native code" blah blah, k?
-
if you cant write the native code patches that dont interfere with what the rest of FSO does, dont reccomend "native code" blah blah, k?
Ouch!
I believe I could write code that doesn't interfere. Why would you immediately assume I could not? I promise not to force you to use my changes.
Actually, why would it matter if I recommend a different way of doing things? I guess I am in the wrong forum. Is "native code" a bad word in the scripting section? :)
This is the reason I would like to move the thread out of this section.
-
put it this way. lua on a 3ghz machine will probibly run faster than asm on a 20mhz mcu. and barring transmission of actual video, most of the data will be low throughput anyway. also youre coind of constricted by communication speed. i really dont think it will be an issue.
-
if you cant write the native code patches that dont interfere with what the rest of FSO does, dont reccomend "native code" blah blah, k?
Ouch!
I believe I could write code that doesn't interfere. Why would you immediately assume I could not? I promise not to force you to use my changes.
Actually, why would it matter if I recommend a different way of doing things? I guess I am in the wrong forum. Is "native code" a bad word in the scripting section? :)
This is the reason I would like to move the thread out of this section.
lets just put it this way, a lot of people here love to do backseat coding, reccomending various ways how to do ****, without actually providing any proof of such, so, when someone reccomends native code, a lot of folks here have a spaz attack.
also, scripting is better in a way as it allows us not too experienced coders to faff around without a worry that we'll **** something up monumentally in regards to other mods and such.
-
lets just put it this way, a lot of people here love to do backseat coding, reccomending various ways how to do ****, without actually providing any proof of such, so, when someone reccomends native code, a lot of folks here have a spaz attack.
also, scripting is better in a way as it allows us not too experienced coders to faff around without a worry that we'll **** something up monumentally in regards to other mods and such.
I am new around here so I understand what you are saying to some degree, you just aren't very friendly. Just ignore the "backseat" coders if it ruffles your feathers so much. If I want to make changes and play with the source, I think you should be happy to let me. I wouldn't expect my changes to make it into the official build if they weren't up to snuff. I wouldn't want your scripts in there either if they didn't work well. I'm not saying you are a bad scripter, I don't know anything about you. I would appreciate the same respect. If I break your game, then you can act this way towards me all you want.
In the end we were just having a conversation about extracting HUD information. If we can extract the radar and communication visuals via a script and its fast enough, then we can go that direction. All I was saying was that accessing that data would probably be faster in C++ than lua. I was just speaking from 15+ years of development experience. Its a fact of life, interpreted code is not as fast as native code. There is no way script is going to run faster than the C++, but to Nukes comments above. I agree, its very possible it is fast enough. If so then that's fantastic. It will be a much easier task.
-
backseat coding doesnt bother me. if people want to discuss ideas about features, or better yet give me or other programmers ideas about features, or a method for solving a problem, then thats fine with me. someone may have a good understanding behind the theory of something but not be very good coders. now if people start demanding features and say **** like 'YOU MOST MAKE UPDATE!!', then you got to draw a line. so long as its productive and stirs up good discussion, im all for it.
should point out that this topic in particular is going to bring in hardware people and their perspectives as well. a lot of these people know how to program, but for mcus, not game engines. so there is going to be a little bit of misunderstanding in there.