I was watching the replay from my yesterday night race and from the top view realized the shadow was very weird.

This is in FE3, weather 2 (I think), and the car was the XFG. I'm uploading a video to youtube right now. It certainly looks bad. Guess it has something to do with the latest graphics updates that now use 'subparts' or something like that.

Youtube link: http://www.youtube.com/watch?v=7FUvIxd9hj0

Last edited by MaKaKaZo, Mon 18 Aug 2008, 12:15.

Many people who play mostly in cruise servers have issues, but the one that don't tolerate cruisers/drifters are the ones that have real issues...

Stop thinking that the line of development is going to change because of a lot of cruisers/drifters asking for their needs to be fulfilled. The devs have very clear in their mind how they want the sim to be, and that's their main goal. After that they listen to what the community asks for, and if they like the idea they do it, otherwise they don't. But that's the order: first come the devs plans, then community requests.

If a bunch of cruisers ask for some changes to develop cruising the devs may like it, but you can be sure they'll be putting racing and hotlapping in the first place of their priority list.

So, don't worry about non-racers and just let them be, no hard feelings. In the end the sim will be what the devs want it to be, not what the majority of users want. It jut happens that the devs usually want the same things in the game as we do!

Quote from migf1 :

I seriously doubt that any average talented driver cannot reach the 103% of a wr in a given combo despite practicing tons of hours on that combo, as you say.

The point is that not every LFS player is an "average talented driver", there are people who are just very slow! And they train a lot, trust me!

Quote from St4Lk3R :

this sounds like some sort of homework. is it a piece of homework?

Totally!

Why is eveybody trying to figure out something that is so clear? Like giving metaphysical explanations and such about practice and stuff...

There are people that have been practising for tons of hours, know every car, every track, have watched other people's replays hundreds of times... and they're not even within the 103% benchmark. Why? Because they CAN'T do better. Those "anti-aliens" seem to be perfectly fine, no one asks "why are these people so slow if they practice so much and so hard?"

Well, aliens are the same. They're just people that are very good! No one can practice and get beyond their limit. Alien's limit is just further than most people. That's it.

All the fuss about aliens is generated but the word itself. When people start using the word "alien" the rest of the people start thinking about guys that are different to the rest. Well, I'm sorry to disappoint you but they as different from a guy who can do a 100.10% from their WR than you are compared to your teammate that always does 100.10% of your time (given you are an average racer).

Where's the line that tells who's an alien and who's a very fast driver? I'll tell you: there's no line.

Think of how many people there could be out there that may be faster than the aliens we know but they just don't play LFS. What would those be?

Quote from sun :

oh yer... my mistake sorry! i was supposed to say, how do you make a button that when it is clicked it brings up a dilog box where you can enter your information

Dude that's another thing

From the InSim documentation (people should try reading this before asking these kinds of questions):


And...

Last edited by MaKaKaZo, Fri 15 Aug 2008, 09:28.

Well, then please tell me how can I see my ctra image ingame. An consider asking becky rose about it, though I think she doesn't share her code. Inside a button you can only have 240 bytes that will be represented by LFS as text. If there's some way to trick LFS into loading a external image using that text (like a URL or something) I don't know how to do it.

Anyway, I'd like to see an ingame image first.

I have an image in my ctra account but I have never seen it ingame. Are you sure of what you mean?

Anyway, if that can be done, some tweaking must have been done somewhere because that's not an standard insim buttons feature.

Quote from filur :

:drink:

Indeed the best solution But that is based in nodes I think. I see no better way to know the race position anyway.

I don't understand what you're asking for. Right now you have the X,Y,Z coordinates for each car in every MCI packet. Is that what you want?

Anyway, what are you going to do with the physical coordinates of the car? Having the coordinates you can know where the cars are, but... how do you know which one is ahead? You can't know that!

That's why nodes are used. Nodes follow the outline of the track so you have info on how far into the lap each car is. Knowing the coordinates only gives you the position of the car, but you can't know which car is ahead relative to a certain lap.

Ok, here are some logs. I'll tell first the procedure I'm following:

• Start the dedicated server.
  
• Start the insim application (this starts the connection to insim).
  
• Connect a player to the server.
  
• Add the player to the grid and the race starts.
  
• MCI packets should start arriving by now.
  
• Vote race to end.
  
• After voting is complete type "!exit" to quit the insim application.
  
• Close the dedicated server.
  

I hace repeated this procedure using:


FULL TCP
(MCI packets requested every one second via TCP)

Application log:

Dedicated server log:

FULL UDP
(MCI packets requested every one second via UDP using the same port as the rest of the packets)

Application log:

Dedicated server log:

TCP+UDP
(Main connections uses TCP, but MCI packets are requested every one second via UDP using a specific port)

Application log:

Dedicated server log:

As you can see, when I'm using full TCP or full UDP the MCI packets are sent.

When using UDP I get a final last message "InSim : unknown packet (80 bytes) - X-Y-Z Pos" that I'm not sure what is causing it. The rest of "InSim - UDP : no slots available" arrive when I have already closed the application, they last for a while until LFS decides that it's been too long not receiving any UDP pakcet and closes the UDP connection due to a timeout.

When using TCP+UDP the main packets all arrive, but when MCI should start arriving the server says that "InSim - UDP : no slots available". This message stops when the vote to end race finishes and the player goes back to the main race config screen. In this screen no MCI packets are sent so there's no problem. With this method it looks like the server tries to send the MCI packets but for some reason it can't and delivers that message "no slots available".

I really don't know what is going on!

Quote from hyntty :

Yes I am asking for someone to do it for me. I thought that was the point of this forum section. Sorry if I was confusing.

About the other stuff, well I don't know because I have no clue whatsoever about insim programming (unless making some knightrider led-lights with assebly counts ) (sorry, unnecessary joke). Anyway, the thing to do would be to ask Sören Scharf (if that's the way to spell his name), which for me is difficult cause I wouldn't know what to ask.

Second of all, would it help/have anything to do with it, if I didn't run the program on my computer?

It's ok, I just found your first post confusing, didn't know if you wanted help or someone to do it.

It's possible to do what you want, but the best way would be to ask the author of TV Director to add the features you are asking for.

I don't have time to do someone else's projects anyway, but good luck with this

But are you asking for someone to do it for you or for someone to help you with "how you should do it"?

It can be done, but you need to know stuff like what button IDs does the LFS TV Director use and more stuff.

Quote from Bean0 :

I hope this is not possible.

It's not. You can only know his LFS username.

Quote from Dygear :

I think you have to send the ISI packet to the UDP port for LFS to accept it as an open connection. It's not as simple as simply setting it up in the TCP side, the LFS host also needs to know the UDP port is active.

Start LFS Server & allow InSim connections.
Start InSim program.
Set TCP listen & send port.
Set UDP listen & send port.
Send TCP ISI to establish connection with UDP Port information.
Send UDP ISI to establish connection with this port for MCI & NPL packets.


I already tried that when I was getting the "packet received before ISI" message, and what it did was generate double messages "packet received before ISI". I think my application opened a TCP+UDP connection and a pure UDP connection, so all the messages generated by UDP errors were generated twice.

Anyway, that was when I was using the same port for sending and receiving, so I'll try that again now that I use different ports and we'll see what happens

Thanks for the help


EDIT: Thinking about it, it doesn't make sense to do what you have suggested. Let's check the workings of all this!

• LFS servers use the same port for receiving and sending both TCP and UDP packets. Let's say we set in the server config "/insim 29999". That is the only port that will be used in the server side (along with the port for player connections, let's say 63395 for example).
  

• The client application can use TCP, UDP or TCP&UDP. For the TCP or UDP full connections we don't choose any port, it will be assigned randomly when we start the communication to the server by sending the IS_ISI packet (it doesn't matter if we are using TCP or UDP).
  

• When we use TCP&UDP (TCP for all but NLP and MCI, and UDP for just NLP and MCI), we don't have to choose a TCP port because we are the ones that start the communication, BUT we have to tell the server what UDP port it has to use when sending us NLP and MCI packets. Why? Because we are not going to start any UDP communication, we are just going to listen on that specific port for incoming UDP packets. So, we must make sure that UDP port is reachable from the server.
  

So, it doesn't make sense to try and open an UDP connection when you are specifying a listening port.

Anyway, I tried it again and as I expected got double the "InSim - UDP : no slots available" messages as before

Last edited by MaKaKaZo, Fri 8 Aug 2008, 09:22.

Quote from Dygear :

Main Loop -> UDP Loop & TCP Loop.

The main loop could be it's own process while the child threads of the UDP (Handles only MCI & NPL Packets.) and TCP (Handles all but MCI & NPL Packets.) could be child threads of the main process.

Well, right now I have the main function with the TCP loop, and right before this TCP loop I create and launch the child thread with the UDP loop.

What I'm guessing now is whether in ending the threads in a good way or not. The child (UDP) thread is canceled by the main function right after the TCP loop ends. Maybe I should add the same control variable to both loops and join them... Well, just thinking aloud

More data:

I had something wrong with the ports. I was using the same port for sending and receiving UDP packets. As the dedicated server is in the same machine than the client I'm testing this was causing conflicts.

Anyway, after selecting different ports I still don't get the UDP packets.

I'm connecting to:
localhost
29999

I use that port to create both TCP and UDP sockets, as the server uses the same port for receiving/sending all data.

Now, I've chosen port 60000 as "udpport" to which insim will be sending UDP packets. I define this in the IS_ISI packet.

After sending the IS_ISI packet the application connects to InSim. Message by server when connecting:
"InSim - TCP : X-Y-Z Pos (UDP port 60000)"

But when I enter the track and MCI packets are supposed to start being sent the dedi server console says "InSim - UDP : no slots available". This is different from the previous message "InSim : packet received before ISI packet", but still I get the same result. I got rid of the old "InSim : packet received before ISI packet" message when I picked different ports for UDP sending and receiving.

Aside from creating the UDP socket, connecting it (I use a connected datagram socket, but connecting this socket only stores adrress and port info, it performs no sending/receiving) and sending the IS_ISI packet I do nothing at all with UDP, just watch the dedi server console throwing errors.

Plesae I really need help on this

I've come to a wall that I don't understand

This morning I tried using full UDP InSim just changing the "stream socket" I was using to a "datagram socket". It worked (surprisingly).

Now I'm preparing my library to work with a main TCP connection and UDP connection for NLP & MCI packets.

This is the construction of the IS_ISI packet:

And this is a summary of the server log (only the interesting part):

The thing is... the IS_ISI packet HAS been sent and the application is connected to InSim: " InSim - TCP : X-Y-Z Pos (UDP port 29999)". I even have some buttons in screen.

When I get to the track I'm supposed to receive MCI packets every one second, but what I get instead is that " InSim : packet received before ISI packet" in the dedi server console (every one second). What does this mean? I'm not sending any packet, but I'm just trying to receive the MCI ones. Do anyone know what is happening?

Quote from T-RonX :

InSim V4 is made for TCP, since you don't have to send a confirm packet back to let the host know you received a packet. So you don't have to worry about it cus there is nothing you can do about it. For MCI/NLP this is acceptable because this is more like raw data, and there is no point for retreiving a lost packet. So I think its pretty essensial to use TCP for the main connection. If you use your program on a local network using TCP for MCI/NLP is fine because bandwidth/speed is not an issue then. Else you should use UDP for MCI/NLP for better performance.

Awesome. That's what I was going to do. I was confused because of what you said that InSim has no confirmation for received packets when using UDP.

So, pretty clear now: I'll use TCP always for the main connection and let the programmer decide whether to use TCP or UDP for NLP/MCI packets depending on the UDPPort field of the IS_ISI packet.

Thanks for your help

Hi! I'm updating my InSim C++ library to use the UDP connection method and I don't know what things I should do.

I grabbed an example I had done with MCI packets in which I used TCP, and just run it using an UDP socket. I hadn't tried UDP yet, but it worked just fine.

So, it looks like my library works with UDP, just using the corresponding argument in the initialization call (SOCK_DGRAM instead of SOCK_STREAM). But I wonder is that makes it... I mean, shouldn't I worry a bit abour lost packets or something like that?

This is my first time using UDP and I don't know what I should pay extra attention to.

Anyway, I think that maybe I'll just add UDP for NLP/MCI packets and do no checking at all. But in case I change my mind I'd like to know what to do

A small tip on calculating the distance to other cars:

You have 3 coordinates for each car: X, Y, Z. If you are good with geometry you can get the formula to calculate the distance between two points using 3 coordenates. But, in this context that is just a waste of processing time and power.

First of all, you can totally forget about the Z component. Surface is not totally plain, but comparing car's relative positions you would notice that the difference in heigth is irrelevant here, and most of all when you are looking for a car that should be close to you (therefore the heigth would be very close). Now you only have to compare positions using two coordenates, which simplifies the whole thing a lot (in terms of arithmetic operations needed).

With two coordenates you only need to apply the Pythagoras' theorem. But we can simplify it even more:

Car1 pos:
x1,y1

Car2 pos:
x2,y2

distance_in_meters = square_root ( (x1-x2)^2 + (y1-y2)^2 ) / 65536

This would give us the distance in meters (because of the "/65536")

But in our case we don't care about the actual distance in meters or any other measure unit. The only thing we want to know is "the closest car", not "how far is each car". So first of all we get rid of the "/65536". And then we change:

lfs_distance^2 = (x1-x2)^2 + (y1-y2)^2

We calculate "lfs_distance^2", and that's what we are going to compare. This way we don't need to calculate square roots or convert anything to meters.

The only thing you need to take care is not to cause an overflow here. For this you should choose the appropiate data types, and maybe divide the original x1,y1,x2,y2 by some factor like 2^17 to prevent getting too high. This would cause you to lose precission (precission this way would be 2 meters in each X and Y coordenate), but you won't be needing much precission.

This is awful Now I'll need to create an independent thread to handle all the UDP packets, because tge select() call would make it inappropiate within the main loop. Now I'll need two "main loops" working on different threads, one or TCP packets and one for UDP packets

Hi. I was about to do my first test on LFS coordinates in IS_MCI packets and I've come to the followign point.

I have been using InSim TCP connection all the time for my previous tests, but I saw in the documentation that there's the possibility to tell InSim to send only the IS_MCI/IS_NLP packets via UDP, while the rest of hte packets would use TCP.

If I want to receive MCI packets every one second this looks the best way to not get too much TCP traffic overhead.

Now this may be a stupid question, but as I'm not much into sockets... would I need t setup two sockets for this? One for the TCP connection and another for the UDP? I guess that's the way, but I just want someone to tell me to make sure.

I'll be doing tests for a couple of hours anyway

I use a freeware temp application called SpeedFan. It's very lightweight and it provides enough info. Check it here:
http://www.almico.com/sfdownload.php

I haven't had any problem with this, it won't install any addware or malicious stuff, and as I said, it's pretty lightweight

Check you temperature right before starting playing LFS and then check from time to time. If it reboots, then start speedfan inmediately to check the temp after the reboot.

If people like this shit, let them do whatever they want. They're not ruining the game by making cruising insims, they just add different kinds of games.

I don't like cruising much, but I'd love someone to host a cops vs robbers ONLY server. I mean, no cruising endlessly for money, no buying cars, no bank accounts... Just some robbers vs a bunch of cops, and see how long they last, then reset changing the roles, and that thing repeating all the time, but not in the carpark, but in some layout or standard track.