[Daboule]

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

[The E]

You are correct, these values are currently not accessible by the scripting engine.

[Daboule]

Hi The E,

Thanks for your answer.

Daboule.

[Nuke]

heres the breakdown of what i think can and cannot be done with scripting as far as the hud goes


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.

[JGZinv]

*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...

[Daboule]

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.

[Nuke]

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

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.

[Daboule]

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  (by the way if you need help on this side feel free to ask ). 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 

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 

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 

Daboule

[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

[m!m]

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 if you want to know how to add new functions to the engine.

[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 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

Thanks a lot.

Daboule

[pecenipicek]

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 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

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.

[Nuke]

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.

[Daboule]

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 ) 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

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

[Nuke]

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.

[Daboule]

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

Code: [Select]

#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 




Now, the next step are:

• directives
• monitor
• inspected ships
• wingmen status

More news later

See you.

Daboule

[m!m]

Great work! 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.

[Daboule]

 

Great work! 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 ) 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  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 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

Once again thanks to everybody. This forum rocks!!!

Daboule

[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.

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 they are plenty of really interesting links on various hardware interface boards.

Daboule

[Nuke]

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.