It can be done with video lan as the streaming server, you connect to video lan and send it the video, then the video lan server connects to the rest of the clients that want the information. 4,228,250,625 Users is the max ammout of users that can connect to that server in IPv4 even if the routers could have that large of a stack. I know my linksys gose into meltdown when ever I get near 1000 connections to my home computer. So there's not quite infinite bandwidth but if there is some one on here that has bandiwth to connect to over 4 billion computers then they are not going to ask us how to do it. It is possable, but you have to make the plan fit your situation. Idealy, you would want to have the end user watching LFS in the LFS exe, then you could make a HLTV style video service. That would decrees the bandwidth needed by 10 fold.

the only way i could see that happening is if demo users could spectate s1 and s2 races, but not participate

I would like to know why LFS : TV was not apart of the orignal LFS code. It would seem to be a logical step in the programming of LFS.

I would like to see the LFS exe be able to set a host TV server IP and Port. ex "/lfstvs 24.46.196.135 20022" That would send the LFS : TV packets to that IP and Port. Then that server would send on the packets to who ever logs on with the server in LFS with the simple command "/lfstv 24.46.196.135 20022" So, devs what do you guys think? The TV Server it self would log into the race server and act as a spectator. It would be like watching a replay, but in real time.

Quote from Dygear :

I would like to know why LFS : TV was not apart of the orignal LFS code. It would seem to be a logical step in the programming of LFS.

That boils down to what I've been trying to get at... Although to be honest why it isnt part of the original code we have, is that age old phrase "Keep It Simple Stupid".

Quote from the_angry_angel :

That boils down to what I've been trying to get at... Although to be honest why it isnt part of the original code we have, is that age old phrase "Keep It Simple Stupid".

KISS KISS.

:d

Quote from KeiichiRX7 :

heres an idea, one computer spectating and using a video out on it's video card, another with a capture card (recognized as a webcam by some programs) streaming teh video it captures

You don't need two PC's. I've streamed myself playing a game over MSN by taking a cable from a TV out, into a TV in, which can be used as a webcam. Then you set your recording source to WAV.

it appears that the problem here would be what camera should be used to show the race. LFS TV would need someone controlling which camera is active and what is being showed.
That is one of the reasons why this LFS TV should be integrated with the original LFS code, or at least another program with the ability to process all the information. Another important thing is that streaming requires much larger band than simply sending small packets to LFS.exe when you are connected as a spectator. On the other hand, although it uses less band, its not possible for a cheaper pc with no graphics card to exhibit the show of LFS running the original software, and it would require licensing for everyone.
Anyway, I think its important for this game to show up to the world of spectators some way.

Hi guys,

It was me over on RSC that I think you refer to. My idea was to somehow use the replay file encapsulated and broadcast to clients. The current method of spectating does take up a slot on the server. Using a one way lfs data stream would allow connected clients to set camera postions localy.

If it's possible, a seperate spectator client would be ideal, similar to the current viewer. All cars and tracks could be rendered regardless of license. The client would be passive in that synchronisation packets would not be required and the only control be for view. A cut down LFS if you will.

All of this could be run from a broadcast server that is connected to the original game server as a spectator. The "in race" packets retransmitted to spectator clients so as not to impact gameplay. I dubbed it "Live to Spectate", although life, and other projects have called a halt to it.

I talked about using the replay file, but this has it's problems. There is no timing information present, the positions of cars are generated asynchronously. This makes for smaller file sizes but isn't any good for live viewing. The header (footer) isn't generated until the file is closed either.

It would be really useful to have something like this. I want to have a full 360 degree display. Someone else has posted on these forums a method of connecting more than one machine, and setting the camera view to suit. This is a little wasteful of both bandwidth and server slots. As the data is already available for the connected playing client. A way of tapping into, and re using this data locally for different viewpoints would be excellent.

I'm sure there is a way of reverse engineering LFS to do this, but I have no desire to tread on sacred ground.

one small idea i have had is that if you want a cheap low bandwith solution to the problem is that for each "client" to use outsim data and then transfer each of these to another host, which then could stream too another server

and then use in sim (i think this is caperble) to get coordinates and have it overlayed on a map (like replay analyser)

dunno if this is possible but just an idea, kinda like the pit boards that F1 would have also another cool use s that for th eple with dual monitors to use a seperate monitor for all the rubish like map's, tyre temps, fuel etc and whack them on yur second screen leaving your main screen clutter free!

LFS Spectator is what I think you suggesting there doso. The F1 style overlay is being worked on too, now that outguage is available.

I have an F1 style GUI for LFS Spectator. It's to be used in the SimFIA events ( if team teams want it ) Here it is for you guys.

F1GUI-Spectator.zip - 3.76 KB (3,851 bytes)

I know this sounds really daft but its so simple! right the broadcaster needs two pcs, one pc to spectate in the race - actually connected to the server, then feeding the video and sound to a second pc via a capture card.

You could easily add effects, commentary or really anything else, this would work with Windows Media, RealServer or even (the most likely) WinampVideo... its so easy to setup a winamp server and you can easily adjust a hirable music server to stream the races, if anyone wants more details then give me a shout

Quote from f1r3b4ll :

I know this sounds really daft but its so simple! right the broadcaster needs two pcs, one pc to spectate in the race - actually connected to the server, then feeding the video and sound to a second pc via a capture card.

Oh dear god why didn't we think of this?!?!!!!111oneoneonetwoeleventwelve!! Even better this can be done on 1 PC, rather than 2.

(yes, I'm a little tetchy today).

Edit:
I know that it probably sounds harsh, and I apologise, but I think you've missed the discussion on this entire thread and / or probably not read it.

It's all a question of bandwidth. Yes it's possible to take the output from a race, digitise it, then broadcast this info. This would use so much bandwidth that the gameplay would suffer. LFS has a tight netcode that would be completely swamped by what you propose f1r3b4ll.

All of the information required to render a race is already there and being transmited to the connected clients. If this same information can be tapped and multicast (a one way communication) then we would have a TV like situation for people wishing to only watch a race. Presently the only way is to connect as a full client, which has the downside of taking up server slots, and two way comms. A passive replay like client that is connected to a multicast server could be the ideal. My programming skills don't allow me to explore this further, but imho it is very possible.

In the very first Live For Speed replay editor (Yea, that's not it's name, but you'll know what I'm talking about once I explain it), you had the Live For Speed application running inside the main application. It was easyer to see what was going on while you were editing. Live For Speed Movie Maker?

Anyway, you could use the same setup. The main application would call in Live For Speed, and the application would simply get the InSim packets and get the players position from there. Then you could send packets to Live For Speed by translating the InSim packets into normal race packets. Live For Speed would think that it is connected to a normal Live For Speed server like a normal client. You'd have to reverse engineer the LFS packets to send to correct information, but it can be done .

You could also get commentary over the same application.

Quote from Dygear :

Anyway, you could use the same setup. The main application would call in Live For Speed, and the application would simply get the InSim packets and get the players position from there. Then you could send packets to Live For Speed by translating the InSim packets into normal race packets. Live For Speed would think that it is connected to a normal Live For Speed server like a normal client. You'd have to reverse engineer the LFS packets to send to correct information, but it can be done .

Over complicated imho.

If you're going to reverse engineer the LFS server <-> client protocol you might as well just hack some packet rewriting in to trick the connecting clients into believing they're connecting directly to the server, and rejecting any requests to be "full" racers, instead of spectators. Plus this solution would require all "real racers" to have InSim clients to talk to a "master distributor" (which does all the magic).

It assumes I've understood you correctly...

Does anyone else get a sense that we're going round and round with this discussion? If anyone has started reverse engineering the server <-> client protocol, perhaps we should all pool our resources and actually make this possible (third party)?

Quote from the_angry_angel :

Over complicated imho.

If you're going to reverse engineer the LFS server <-> client protocol you might as well just hack some packet rewriting in to trick the connecting clients into believing they're connecting directly to the server, and rejecting any requests to be "full" racers, instead of spectators. Plus this solution would require all "real racers" to have InSim clients to talk to a "master distributor" (which does all the magic).

It assumes I've understood you correctly...

Does anyone else get a sense that we're going round and round with this discussion? If anyone has started reverse engineering the server <-> client protocol, perhaps we should all pool our resources and actually make this possible (third party)?

From my clumsy investigations the same data that is transmitted over the server <-> client channel is the same data within a replay. I have tried to pipe a current temp replay into another client. The replay showed up but cannot be played because the final finish posiitions are required. I've tried a little hacking to fool it into submission but no go so far.

If the temp replay data can be broadcast, and a replay file can be made to look complete to the client, this might achieve the end goal. The user just needs to start the top file in the list. The data is asynchronous, and only the positional information is sent on top of the username, setup etc. Hacking the complete data stream may be complicated or even not even required.

The question with the data stream is, how active a role does a "spectate" client have in the server communication. If it's simply listening, then you could set up a proxy that multi-plexes the spectate packets to any number of listeners, a la HLTV.

If the spectate client still has to do a lot of handshaking, but that handshaking is deterministic (i.e. it's the same each time), the proxy connects with its first client and it's all that the server really sees and voila you get your handshaking. All clients beyond that would connect to the proxy, and get the duplicate server data stream, but their responses would be thrown away, since they'd be the same as the responses from the initial client that's really talking to the server.

If the chatter is non-deterministic, then we're probably screwed and only dev involvement (by either creating the proxy or changing the spectate data stream) could help.

In the end, i think that LFS TV needs to be in-simulator, not a video feed, but I think that's generally agreed on anyhow.

Quote from Squelch :

Hacking the complete data stream may be complicated or even not even required.

Having not poked around much, I assumed that there maybe some fundamental difference between the replay and server <-> client communication, which is why I'd not really thought about this solution. Definately worth poking more at though...

Perhaps we could use this, and its just a case of replicating the initial handshaking, to get it to play nicely?

Quote from sdether :

The question with the data stream is, how active a role does a "spectate" client have in the server communication. If it's simply listening, then you could set up a proxy that multi-plexes the spectate packets to any number of listeners, a la HLTV.

If the spectate client still has to do a lot of handshaking, but that handshaking is deterministic (i.e. it's the same each time), the proxy connects with its first client and it's all that the server really sees and voila you get your handshaking. All clients beyond that would connect to the proxy, and get the duplicate server data stream, but their responses would be thrown away, since they'd be the same as the responses from the initial client that's really talking to the server.

I've got a few captured frames of tcp data, to start debugging this (or at least I did a few versions ago). Only with my client however. From my hazy memory I think that all the connections were "similar" by default.

Quote from sdether :

If the chatter is non-deterministic, then we're probably screwed and only dev involvement (by either creating the proxy or changing the spectate data stream) could help.

I think we'd have to fiddle with the stream at some stage tbh. The client at the other end needs to think that its directly connected, and have no knowledge of the proxy. This would only hold if the assumption that the per-server users limit is hard coded into the client. I imagine it barfing pretty badly, if a client joined and saw a pile more people (a la HLTV), than expected.

Is it more of a question as to which way to go, if this is attempted?

• We trick the normal client into thinking its on the server, as it normally would be (by rewriting packets)
  
• We go the HLTV route, as in you can see all the other spectators; and allowing inter-spectator chat? This would require a hell of a lot more work, and possibly not work if theres a hardcoded server limit, within the client.
  
• Use the replay data, and "fake" the initial and final handshakes?
  
• Any other ideas?

Technically both the first two ideas are the same, multiplexing, with a twist.

Quote from sdether :

In the end, i think that LFS TV needs to be in-simulator, not a video feed, but I think that's generally agreed on anyhow.

Hopefully... we've been banging on about it for long enough

The other question is, do we bother attempting it?

Quote from the_angry_angel :

Hopefully... we've been banging on about it for long enough

The other question is, do we bother attempting it?

It will:-

• Enable team events to be viewed without server load
  
• Enable multiview cockpits to work without bandwidth issues
  
• Allow more spectators than available slots
  
• Events based around LFS can be broadcast/viewed by real spectators
  
• Enable non regged users to view "Full" races (would require a light client)

I think it's worth doing.

Quote from Squelch :

It will:-

• Enable team events to be viewed without server load
  
• Enable multiview cockpits to work without bandwidth issues
  
• Allow more spectators than available slots
  
• Events based around LFS can be broadcast/viewed by real spectators
  
• Enable non regged users to view "Full" races (would require a light client)

I think it's worth doing.

I agree with everything you say, but doubt the last will come to pass. The issue being that until you reg, the content is encrypoted, or at least otherwise not accessible. That's why demo racers can't watch replays of races with cars and tracks they don't have (ok, i admit, i don't know for sure this is true.. is it?)

Quote from sdether :

I agree with everything you say, but doubt the last will come to pass. The issue being that until you reg, the content is encrypoted, or at least otherwise not accessible. That's why demo racers can't watch replays of races with cars and tracks they don't have (ok, i admit, i don't know for sure this is true.. is it?)

Yes it is the case.

I was thinking along the lines of the car viewer which allows all cars to be viewed regardless of reg status. If the rest of the track can be viewed in a similar way via a replay only setup, it would be nice. As there wouldn't be any connection to the master, nor would there be any requirement for the client to send data, registration shouldn't be needed. If it's possible, the full program could allow replay view.

Much further down the line that one.

LFSTV should be IMO like this:

cool yes it should be and they could watch us race and at the end but the lfs website on .