Pit to car radio app available - work in progress

Not sure if I can do a lady voice... But I am gonna fill up the sound library as soon as I can.

 

Don't you have a lovely wife of daughter who can fill that gap?

 

Not sure they would see the fun in it like I do, my daughter is 9 and my wife already has a limit on how much she gets why I play racing (her words) let alone record over 200 files for me I can enjoy it a little more. She already gets in to a full body lycra cat suit in my racing color, stands in front of me for 5 mins before every race waving the union flag. That's immersion!

 

Your wife does that for me too, Mach. Generous, isn't she

 

I have no idea, just giving it a few shots in the dark..
But information of an accident in sector 3 when I just crossed the line to sector 1 isn't really useful for me.
Would it be possible to get notifications from the sector you're in and the one coming next, and then disregard the rest?

You are a lucky man machwebb!
The only immersion my wife contributes is if she times her appearance with an accident.
She'll pass as a driver from the other car standing over me, wondering what the hell I'm doing, then mumbling something about usefull stuff I could spend my time on when she's walking away to the pits..

 

My wife thinks it's a stupid and pointless hobby too. Pft, women eh? Still, my 6 year old son is turning into a proper racing car nut. Which could get expensive...

Anyway, I've added the project to GitHub here:

https://github.com/mrbelowski/r3e_crewchief

It's still in a pretty grotty state as I seem to be spending all my geek-time adding events, sound files, and bug fixes rather than refactoring and sorting out all the hard-coded crap and stuff.


Edit - i've started adding issues & enhancements to this GitHub project

 

Yea, women!..

Just made a 20 min MP WTCC race at Red Bull.
Was nice to hear about how much fuel I had left, and especially "P2, great job this was your fastest lap"

By the way, I actually think it sounds more realistic just because your not an actor! God job!

 

Being single i always imagine pitladies in Catsuits before the race
I can send your wife some Belgian chocolates (mmmmmm) to compensate if she would be willing to try

 

maybe not realistic but why not try, maybe S3S can use their Audi connections and ask the LeMans winning Race Engineer Leena Gade: when the time comes this is fully integrated into r3e

 

@Mikael Hermansson maybe not the full grid is needed, but let's say

int numPrevCars (<= MAX_SURROUNDING)
int numNextCars
prevCars [ MAX_SURROUNDING ] {pos, laptime..., class }
nextCars [ MAX_SURROUNDING ] {}

pos for "spotter" actions, laptime/laps to know if the car is active opponent or already lapped, or in case of multi-class not in same class... That also could allow warning the player if a fast mover is coming in from higher class.

 

@mr_belowski would you be okay about using Lua instead of c# in the future? Basically I would try to get the porting of your current state done this week-end. As I will refactor things, will account for different voice-directories and automatic loading of "events". Basically each event is its own lua file, that all get automatically registered by running thru the directory. The basic way things work is similar to yours. For events I will add something like priority, so that important messages ensure they get played prior others in queue, and maybe even allow for interrupting...

Don't want to hijack your project, hence asking if you are comfortable with such a language switch. As doing the work twice seems wasted. And not requiring people to install VisualStudio to "mod" it, is a huge plus imo.

Here is what I think of, for example for the "position event"

Code:

local eventtype = {
  priority = 0,
}

-- data used in this event
local lastPos

-- reset, called prior each race...
function eventtype:reset()
  lastPos  = 0
end

-- don't need to provide function if unused
-- event is the content that was returned in "check"
function eventtype:isInvalid(event, currentState)
end

function eventtype:check(common, lastState, currentState)
  if (not common.isNewLap or currentState.Position == 0) then return end

  local currentPos = currentState.Position
  if (lastPos ~= 0 and lastPos ~= currentPos and currentPos <= 10) then
    -- emit event(s)
    return {sounds = {string.format("position/p%d",currentPos)},
            delay = 0,
            eventtype = self,
            eventstate = nil}
  end
  lastPos = currentPos
end

return eventtype

 

Thank you mr_belowski.
I had some test drive with your app and enjoyed a lot.
And here is an idea for sound immersion.

• Applying walkie talkie effect on your voice would be very nice
This video might be useful. ( it’s simple. )

Also, check my attachment and guess who.
Hope that helps for your further work.
Cheers.

 

Like I've said before, I'm not precious about it and everyone's free to adapt, borrow, port, modify, and generally use it as they want.

However I'm not clear what porting to lua gives us. While C# isn't s language I'm familiar with, it does work and it provides all the functionality this app needs. The debug tools are quite good too. The only thing missing is the ability to play wav files concurrently and in not sure we even need it

For me, a Java port makes more sense because that's my preferred technology. I'm not sure what lua offers here other than it being your preferred technology. Like I said, you're welcome to port it, but wouldn't it make more sense for us to work on the current version? C# is like any other OO language.

I'd prefer Java but am not as keen to port it as I was. Now I'm a bit more comfy with C# it seems a decent technology choice. But I can be convinced otherwise. Does lua offer simple ui components?

Also bear in mind that fragmentation of this app into competing versions might be unhelpful.

Have a look at the github repo - it might help show what I want to do with the app. How would a lua port help with these enhancements?

Basically, I'm happy to be convinced but am not sure

 

The wife said she'll do it.... She's awesomeness.

 

The key difference is that Lua doesn't require any build setup or compiler of sorts. It is a tiny highly efficient run-time popular in games and real-time applications. So there is no dependency on VisualStudio to mod it, installing a proper Java runtime...
The language as such is also rather easy and doesn't require you to write/define datatypes as much as in Java or C#. So it's really just about allowing more people to mod it, and provide the mods back to the main branch.

(updated my previous post with some sample code)

If you check my championship tool, you will see that there is some UI possibilities via wxwidgets at the very end (arguably not as nice looking as what you could do via c#, but does the job, and has a log console...). The exe file in that project is basically just the runtime that calls the .lua file and executes it. Hence you can just make edits by any text editor. No build systems nothing...

As for your issue list, am using a sound module for Lua that allows multi-channel playback, so should be possible to add noise in parallel.
http://htmlpreview.github.io/?https...oteaAudio/blob/master/doc/proteaaudiolua.html

And I agree fragmentation would not be ideal, hence I would only move forward on this if it was the preferred solution.

 

I guess we need to look at a few issues here.

First, we all want to the app to be as useful as possible. This is distinct (but not entire unrelated) to how easy it is to work on. As I see it, more capable people working on it and adding to it is a very good thing. The technology stack can certainly help with this - barriers to entry and all that. So that's a plus for Lua. Installing VS 2013 and importing the project isn't much of an overhead for contributors with more of a development background but does require a Windows box and an acceptance of the MS stack (including some rather annoying packaging tools).

Second, we want any and all contributions to be good quality and work as intended. Here's where I need some convincing. Are the Lua debug tools good enough? Most of the app's logic is trivial and hard to get wrong but some of it was surprisingly fiddly and without the VS 2013 debugger it'd have been a right ball ache. I think VS 2013 might have the edge here.

Third, we want people to find using it easy and quick. No contest here - running a Lua app requires no .net installation.

Fourth, we need to be able to extend it with some potentially complex logic and state tracking. When the new bits and bobs get added to the shared data block there'll be a massive amount of new 'stuff' to be coded. We might need to alter the behaviour of delayed events in some weird and creative ways. I'm not familiar enough with Lua to properly judge this as my brain is full of objects and properties and lots of OO gubbins. Is Lua definitely powerful enough? Are the development tools up to the job?

Fifth, we all want the moon on a stick yesterday. Porting will take some time and set the project back a little, but would developing in Lua make it catch up? I guess this also depends on how many capable contributors are willing to work in which technologies. I know porting to Lua will mean a big re-learning on my part. Currently adding a new event (like the recently added 'race position' event) only takes half an hour (including the time to record the sound files). I wonder if Lua will speed up or slow down that process.


And a bunch of other stuff

If you're confident that Lua is up to the job, and the dev tools are good enough, we could just have a quick poll and see how many folks feel able and are willing to contribute for each of the possible technologies - Java, C#, or Lua. Then pick the one that looks like it might have the most dev weight behind it.

 

Just out of personal curiosity. How would you access the shared memory with Lua? Using LuaJIT's FFI or something?

 

Oh, and I'm sure the answer to this is "of course I bloody can", but you can access the shared memory block from Lua, can't you?

[edit] beaten to it

 

Just had a (very quick) look at the ZeroBrain IDE, which appears to have a proper debugger, so that's a plus for Lua

 

Good points @mr_belowski, yes porting will take a bit (I guess 1-2 days for the status quo), and I don't want to slow you down, so keep going. The weak points of Lua are: lack of native unicode (say someone would name filenames with unicode characters..), easy use of hardware threads (currently not required as the soundlib used creates an actual thread for handling those, and the logic of the app gets away single-threaded so far), debugging will not be as sophisticated as visual studio, although there is a popular LuaIDE with debugger... http://studio.zerobrane.com/

I would argue tuning the "logic" is easier with scripting languages, than with java/c#, but that is subjective of course. Lua allows you to code OO style, but doesn't enforce it, or requires all the strict class definitions, as its generic table container is very flexible. A quick primer about the language http://pixeljetstream.blogspot.de/2011/09/mini-lua-primer-tables-are-general.html

Yes @Mikael Hermansson the shared memory would be read via LuaJIT's FFI analog to the c sample making the appropriate native winapi calls.