I know C++, but am definitely not a programmer. I've never made anything more than a very simple text mode program, and i've got no idea how insim/outsim work. So, before I even delve into how to begin such a project I thought I'd ask the gurus if what I'm after is possible.

My idea started with the fact that it can get very lonely in the car during longer races. With nobody on the radio it's easy to lose track of what lap it is, how soon you should pit for tires, how much fuel is left, etc. So, I had an idea for an insim app that would watch for a particular lap number then play an audio file telling me it's time to pit for tires. Then I thought the same thing could probably watch for <X% fuel and play a message that I need fuel. The more I thought about it the more it seemed like a "generic" app would be the best bet. So, here's what I'm after and I'm wondering if it's possible...

I'd like to be able to specify parameters to watch for, and when those parameters are true, either play an audio file or display a message to screen. Here are a few examples:

if lap == "25" play file pitfortires.wav (for, say, a 50 lap race. pitting halfway through)
if fuel < 3% play file fuellow.wav
if lap == "2" play file pitwindowopen.wav
if lap == "24" play file pitwindowclosing.wav

Does anyone have any idea if this sort of thing is possible?

Your idea is possible. But you want to compute insim/outsim data on your client at home during a race, so you must have a dedicated server connection by an own written client/server app to get insim/outsim data at the client side because insim/outsim is only available on a local root server machine. that means every server must run that "interface" and have to interact with the client.

i don´t know if it´s possible to get this data out of the client only to avoid a client/server solution. i don´t know anything about memory manipulation

Very possible. You've basically got 2 options, as far as I can see.
1. Implement your scripting language interpreter (as above)
2. Expose an API and load dll's as "plugins", which can hook into the main program.

The first option is probably more accessible, and better for your target market.
Option two has the problem that you'll end up just making your own, slightly convoluted InSim API.

Personally I'd go for option 1. It just depends how far you want to go with it

Edit: Jogdive, I think you've been reusing the bong water too much That doesnt make a lot of sense (although it could be because I'm tired). You can connect an InSim/OutSim app to a local client, not just servers, and get data about yourself - which is the goal. Or have I totally misread your post?

I've got a thingie in the works which i guess would almost fit your definition of a 'generic' app, it's basically a program which connects and handles all the insim stuff such as packet (de)construction, and feeds insim packets to whichever plugins are loaded, without any plugins it doesn't really do anything.

It's written in pure PHP, if you know C++, PHP should be very simple to pick up.

Quote from the_angry_angel :

Jogdive, I think you've been reusing the bong water too much That doesnt make a lot of sense (although it could be because I'm tired). You can connect an InSim/OutSim app to a local client, not just servers, and get data about yourself - which is the goal. Or have I totally misread your post?

drill me, my fault

Quote from JogDive :

drill me

I'm not sure what that means, but it sounds kinky... :o

I was about to hit the sack, but I've had an interesting thought. Rather than create your own "language" for this, potentially it would be somewhat more interesting to embed LUA, or Javascript (with the Mozilla Spidermonkey engine) as the language. This allows for a solid base and gives potential for adding your own functions fairly easily.

I've considered this path for a few test projects in the past, and if I recall, embedding SpiderMonkey was somewhat trivial. I never bothered with Lua.

Something to chew on.

How do you use two programming langues for one project. It's allways baffeld me. Back in the AMX days, the AMX dll was done in C, where all of the plugins where done in SmallC. How does one go about using 2 programming lanuges for one program?

Well, you're not using two languages in your example. You're using the output from two languages.

---simple answer---

DLLs have a common interface mechanism that can be accessed by any language that supports calls through that interface mechanism

---simple answer---