String Values? (from iRacing)

Hi.

I'm the author of iSpeed (http://www.nessoft.com/ispeed), which currently uses the iRacing telemetry API to do a variety of things (splits, best lap, compare lap with other driver, visual track-map lap comparison, etc). I've had several requests to make this work via x-sim, which I think would be cool in case I ever go to the next step in my own cockpit (I've got a custom built cockpit that was originally designed with some motion, but I've never gotten around to going that far).

Anyway ...

iSpeed does some stuff with best lap comparisons, time and speed deltas, and a bunch of stuff where we need to know the car and track (and track length) we're driving on. iRacing sends this via the telemetry API, but I don't see any way to get to that information from x-sim. I don't even see how to send any kind of string (or char arrays) through the sender, or to access non-numeric data from the profiler or any consuming applications.

Am I missing something?

Maybe I just need to make my application a sender and forward on the interesting x-sim related information from iSpeed (my app) to x-sim for consumption by others with gauges/motion/etc. Is that the best way to do things if I need access to data that is published by the game (iRacing), but is not available through x-sim? It would be nice to be a consumer of x-sim data so that my app could possibly work with other games in the future (well, maybe that's dreaming)...

Any help on this topic would be welcome.

Thanks,
Pete

Hey Pete,

Eric P here.

Been having a couple PM with sirnoname(The Head Honcho), and this is what I can understand.

X-Sim has Unified Plugin Interface structure in order to permit many different games to connect to x-sim.

Unfortunately, it doesn't appear that most of what you pull in iSpeed can be available through this Unified method, at this time, or maybe ever without changes.


Here's my grunt work so far comparing what's compatible in both.
http://www.isimstation.net/files/x-sim_vs_iracing.html


So, I think the way to go is in what Chris(from CXCCSimulations) posted in the iRacing forum about creating a layer between iRacing and any plugin.

Chris ,I believe, quoted here: “So Sean, from all this discussion I guess my speculation was on target - it seems there’s really nothing stopping someone from creating a software layer to fan it out to multiple clients themselves.”

X-Sim could then just plugin to that software layer.


Pete, I mention this here, since instead of adding this to iSpeed directly. The software layer should be created to allow multiple other tools to connect to it. So iSpeed plugs to it also.

I was hoping X-Sim could fill that layer need, but I may be wrong on that.

Cheers,

Eric P

Yes, I think this is the way to go here. It seems hat everyone is headed in that general direction: http://www.eksimracing.com/forum/index.php?topic=550.0

I think you guys are confusing two different X-Sim initiatives. Project Plug Free (the one designed to get data from any game WITHOUT A PLUG-IN, should not interfere with any API including the iRacing one. However, it will provide limited output data.

X-Sim is always open to adding new data outputs to our plugins. It is also ALREADY an open platform for open sharing of this data. This can be done in a variety of ways such as:

1.) Write a new X-Sim plugin that provides all of the data that you want. If it is truly more thorough, it will be adopted as the X-Sim standard.

2.)Any hardware developer can already build an outout plugin to connect X-Sim to his hardware if he CHOOSES to do so.

3.) Read the data from the Force Sender youself and write your own profiler.

Clearly X-Sim provides the most robust software architecture for the open gathering of game data, mathematical manipulation of game data and finally output of this game data to ANY source either hardware or software! The data is made available and plugin source code is published in the Wiki which gives examples of how to accomplish this.

I am fairly certain that the wisest long term solution will be to improve the X-Sim plugin if it is missing something because it provides the greatest bang for the buck with regard to reaching the largest amount of hardware via a single software interface. My guess is those who don't get behind this concept (simulator and game manufacturers alike) will only fail to do so because they have competing agendas or relationships with competing agendas.

Is X-sim capable of publishing string data from the force sender to be consumed by a client? I was unable to find that anywhere. If it is, then an expanded the iRacing plugin should be able to provide all the information necessary. If string data is not part of the available data types (all I could find was 1 byte chars and 1-4 byte numerics), then it's a different kind of problem.

The string data doesn't change all that much - so maybe there's some kind of session information that can be published with this stuff in it?

I'm not really all that interested in re-architecting anything here. I don't have competing agendas or relationships. I just want to get to the end target (giving users the ability to use iSpeed *and* their motion/gauge hardware at the same time) and make things as easy and workable as possible. What's the best way to do that?

Thanks,
Pete

I'm glad to see your attempting X-Sim integration. I think your correct about the string passing, although I'm not sure if this effects your goal, because I'm not entirely sure what your goal is.

If I understand it correctly, your product is two-fold and has some overlap with X-Sim. It seems that you gather data, as does X-Sim, and you output the data to a secondary display, as does X-Sim. I think you may have some additional features with regard to outputting data to portable devices as well though, which while achieavable with X-Sim, it has not been done yet in the form of an output plugin.

Are you attempting to to make a hardware output plugin or are you simply trying to enhance the data that the X-Sim plugin calculates? You can provide the community the calculations that you use to arrive at this data and I'm sure that SirNoName will include it in a future release if that is your goal.

This brings me to my point of confusion about your goals:

If your goal is to write a propriatary plugin that interfaces through X-Sim to propriatary software, then it MAY be possible to encode the strings and decode them in your software. However, unless I'm missing something, the ability to pass strings is needed for only a VERY small amount of the functionality that you provide?

Perhaps we can get SirNoName to add string passing capabilities into the core product in any case.

A key piece of functionality is that iSpeed records your lap, and then lets you do things with that lap later:

* Drive against it - so you can see where you're faster / slower
* Load it up in the analyzer, and compare it to another lap.
* Publish it to the iSpeed datamart
* Download other people's laps from the iSpeed datamart

In order to be able to save laps, compare laps, load laps, etc, you need to be able to know which car and track are being driven. It doesn't do much good to compare a Road Atlanta lap with a Mosport lap, or the Formula Mazda against a Lotus 79 lap. So when iRacing provides the current track and car, this is used to tag a lap file with the track and car being used. Also, the track length is used along with the current track position (which is provided by iRacing as a %) makes it very nice to compare two laps.

This can be duplicated by having the user enter this information, but the information quality goes down considerably when people have to enter data - and it's harder to get reliable comparisons. Right now, with the data from iRacing, it just happens automatically - jump in a car on a track and laps are saved. You can download the right laps - all nice and easy.

My goal is to let people that rely on X-sim continue to use it. If someone is using a motion cockpit, they can't currently use iSpeed too. I'd like to solve that problem. If they have a gauge, other display (G13, etc) or other third party hardware device that relies on X-sim, then they can't also use iSpeed.

If all the information provided by the iRacing API was available via X-sim, then I could pull data from X-sim. It doesn't look like it is. All the numeric data can be provided by adding capabilities to the existing plugin, but without the ability to do string data, pulling from X-sim gets a lot less useful, because then I've got to write a bunch of prompting and verification logic, and it's just not as easy to use iSpeed via X-sim as it is via the Native iRacing API.

So maybe instead iSpeed should sit between iRacing and X-sim, and it can still pull all the data it needs but provide the numeric data to X-sim.

It's really people that already use X-sim that will benefit from this - so adding additional data out of iSpeed to X-sim would be useful (last lap, split times, delta time, delta speed, etc), but isn't really a primary goal. I'm mostly interested in allowing motion hardware and other controls to work.

Thanks for any guidance on the best solution for this.

- Pete

I will will take a closer look at the API in the next week or so.

One possible solution would be to build an API proxy that would simply expose the the API data in a memory mapped file. This is probably the fastest solution from a development time perspective, and one that nearly all programming languages can easily access. It also would help to ensure that the data is delivered as fast as possible to any app that consumes it.

X-Sim has the ability to easily access MMF's via the existing plugin architecture.

All of this begs the question: WHY? Why must me go the these lengths to get data out of iRacing. There must be some logical reason for the single API connection limitation, but it escapes me.

Whatever the case, I'm sure that we can devise an open method to circumvent it assuming that it is legal to do so, etc.. It would seem that you already have most of the code needed. Any chance you would want to define an MMF structure and create this proxy.

We can then create an plugin for X-SIm that reads from the MMF. I'm sure that SirNoName will have an opinion on this as well.

Uhmm. You mean the license model where I spend hundreds of hours on a project, give it away for free to anyone that wants to use it, host the datamart and data on my website for free, and then ask for donations?

Is the fact that I ask for donations in-application the part that you don't like, or that fact that I don't give away the source code?

You're certainly welcome to put whatever limitations you want on your project, but it seems pretty short-sited when someone who is giving away their product (but asking for donations) is being asked to not participate. Excluding *any kind* of commercial project may not be the best way to grow a strong product.

Your game, your rules. See you later.

This does bring up an interesting point though. It would be nice to be able to extract the current vehicle string via X-Sim and pass the string information. This would be useful for use in comparing to a chart of RPMs and RPMs by gear so that a shift light can be precisely calibrated.

I can also see some potential uses for other types of string information.