The online racing simulator
InSim Devs & InSim Feature Triage.
(23 posts, started )
#1 - Dygear
InSim Devs & InSim Feature Triage.
I wonder who are the most prolific InSim developers right now? I think EQ Worry, Gai-Luron & DarkTimes are up there, but who else?

I feel that a thread is needed for InSim requests for Scawen to look over, so they are just in one place for him.

I also think the a group of core group of third party InSim devs should be considered, and known as The InSim Working Group, who's task it would be to triage InSim feature requests to ensure that most important items come to the fore front. I feel that The ISWG would be approate as it is often the InSim App devs that get feature requests that are out of our hands and thus need to be forwarded to Scawen, even better then that we can polish the end user request into a more technical, or focused form for Scawen. I've spoken with EQ Worry, who agrees this would be a good idea, I've not had the chance to speak with Gai-Luron or DarkTimes yet.

Lastly, does anyone have usage data on what InSim application is running at any given time, across all servers? I think I'll make a poll in the Unofficial Addons section and ask this question there if we have no official data.
#2 - sinanju
Quote :Lastly, does anyone have usage data on what InSim application is running at any given time, across all servers?

To look at who's runnning Gai-Luron's LFSLapper sim, go to

http://www.frh-team.net/reglapper/


EDIT:

What about T3PID? Pronounced "tepid"
(The 3rd Party Insim Developers)
#3 - Silverracer
Quote :Lastly, does anyone have usage data on what InSim application is running at any given time, across all servers?

To look at who's runnning EQ Worry's Airio, go to
http://www.airio.eu/AirioServers.aspx

On another note, Krammeh from [LTC] and the rest of the guys from [CLC] and [TC] constantly develop their InSim applications. Their input might be good.
#4 - Dygear
Quote from sinanju :To look at who's runnning Gai-Luron's LFSLapper sim, go to

http://www.frh-team.net/reglapper/

Thank you, that is pretty awesome! [edit]I wonder if AIRIO has the same kinda stats.

Quote from Silverracer :To look at who's runnning EQ Worry's Airio, go to
http://www.airio.eu/AirioServers.aspx

On another note, Krammeh from [LTC] and the rest of the guys from [CLC] and [TC] constantly develop their InSim applications. Their input might be good.

You two are awesome. Agreed about Krammeh and the CLC & TC devs.

[edit]I've added a poll in the Unofficial Addons Forum regarding who is using what. That thread can be found here; What InSim Addons Do You Have Installed?.
#5 - PoVo
Excellent idea, I have to say!
#6 - skywatcher122
its a nice idea for the developers who are good with it
#7 - Dygear
Seeing as the heavy hitters are reporting not only the servers they have using their tools, but also the clients on these servers I guess I'm going to have to do the same. Something like the Sourcemod Stats page, seeing as it would also include plugins.
#8 - the_angry_angel
#9 - Dygear
Quote from the_angry_angel :Sounds a bit like popularity-contest - awesome idea

I never really thought about it that way, but yeah!

[EDIT] ---

Things I've asked for;
  1. ISP_RSH (Requested Setup Hash) ... alues) Packet Suggestion.
  2. Language field to the NCN pack ... es their langue settings.
  3. An InSim Packet for Getting Max Clients from the Server.
Quote from Dygear :Lastly, does anyone have usage data on what InSim application is running at any given time, across all servers? I think I'll make a poll in the Unofficial Addons section and ask this question there if we have no official data.

I did make this thread, and it can be found here; What InSim Addons Do You Have Installed?.
#10 - Dygear
An additional request, redirecting connecting clients, or 'load balancing clients'.

It would be nice to have the ability to send a command to a client to force it to connect to another server.

// ([b]R[/b]e[b]d[/b]i[b]r[/b]ect)
struct IS_RDR
{
byte Size = 36;
byte Type = ISP_RDR;
byte Time; // Time until the connection is moved.
byte Flag; // Set 1 to force, 2 to ask, 3 would ask and force if they don't respond before the time expires.

char HName[32];
}

#11 - misiek08
IS_RDR could be good but 1 thing: maybe an UCID / PLID argument. The LFS have to know who should be moved.
#12 - Dygear
Quote from misiek08 :IS_RDR could be good but 1 thing: maybe an UCID / PLID argument. The LFS have to know who should be moved.

That's a very good point! I forgot about that small detail .

To keep the size the same as it is, combine the Time and Flag property into just Flag, and add UCID.

struct IS_RDR
{
byte Size = 36;
byte Type = ISP_RDR;
byte Flag; // Set 128 to force, setting a time will ask the client. The seven lower bits are used as the time given to the client. Giving a time value range of 0 - 127 seconds (2 minutes, 7 seconds.).
byte UCID; // Client to be moved.

char HName[32]; // Hostname to send the client too.
}

#13 - misiek08
And there is a next problem. For example if you have 32 on server with 32 slots so the LFS just shows "Too many clients". Maybe you wonna do it like CS slot reservation like forwarding when you have 31/32 players. So the packet with maxplayers will be needed.
#14 - Dygear
Quote from misiek08 :And there is a next problem. For example if you have 32 on server with 32 slots so the LFS just shows "Too many clients". Maybe you wonna do it like CS slot reservation like forwarding when you have 31/32 players. So the packet with maxplayers will be needed.

Exactly!
#15 - Dygear
I've been doing some research and this is what I've come up with.

The best of Krammeh.Ideas from other people;Dicussions from other people;In other news, I wonder how this poll would change with the intoduction of PRISM and a pretty intresting discussion about PHP frameworks.
#16 - Dygear
struct IS_VCN // Varable Change Notifiction - Called when a server varable changes, and reports the value it's changed too.
{
byte Size = 64; // Always 64
byte Type = ISP_VCN; // Always ISP_VCN
char Var[31]; // Variable that was changed.
char Val[31]; // Value of changed variable.
}

#17 - Dygear
Used for all sorts of nifty details about the track, mainly useful in the AutoX setting tho, as the standard track details would be static.

enum // the fourth byte of an IS_SMALL packet could be one of these
{
SMALL_VRX_PITSTOOL = 8, // 8 - instruction : Get coordinates on a / all pitstool(s).
SMALL_VRX_SECTOR, // 9 - instruction : Get coordinates on a / all sector(s).
SMALL_VRX_NODE, // 10 - instruction : Get coordinates on a node.
};

define('VRX_PITSTOOL', 64); # Tells you that your getting information on a pit stool position.
// To request this information send an IS_SMALL packet with the SubT SMALL_VRX_PITSTOOL.
// To request all pit stools, set the UVal to 255, InSim will then send as many VRX packets as there are pit stools.
// You will know what pit stool is described in the packet as the lower 6 bits is the pit boxes number.
// To request a single pit stool set the UVal from 0 to 32.
define('VRX_SECTOR', 128); # Tells you that the sector starts here.
// To request this information send an IS_SMALL packet with the SubT SMALL_VRX_SECTOR.
// Set the UVal to 0 for the Start / Finish line, 1 for Sector 1, ect ... 255 to request all.
// You will know what sector is described in the packet as the lower 6 bits is the sectors number (as described above).
define('VRX_NODE', 192); # Tells you that the node requeted lookup details is contained in this packet.
// To request this information send an IS_SMALL packet with the SubT SMALL_VRX_NODE.
// Set the UVal to what ever node you wish to get coordinates on.
// Because there are more nodes then 32, you should only request information on one node at a time,
// in the UDP setting, asorder and delivery are not guaranteed. TCP will return details in order of request.

struct IS_VRX // Anywhere from 16 to 256 bytes in length.
{
byte Size; // 4 + (Numb * 12);
byte Type = ISP_VRX; // Always ISP_VRX;
byte Numb; // Number of verticies in the packet (21 max)
byte SubT; // Type of verticies this packet describes.

Vec Vertex[Numb]; // 3 ints for the X, Y, Z of the coordinates of the vertex.
};

struct Vec // 12 Bytes in length, 3 ints (X, Y, Z) - 65536 means 1 metre.
{
int X; // X map (65536 = 1 metre)
int Y; // Y map (65536 = 1 metre)
int Z; // Z alt (65536 = 1 metre)
};

#18 - Dygear
Implementable Right Away:
  • IS_BTN Buttons interface improved to include animation states, indexable foreground and background colors, and selectable font.
  • IS_RCI Added this packet to allow for the InSim programmer to define colors they would also like used in the RGBa format. This should greatly improve the level of customization of text buttons allowing for custom color screams to be created.
Implementable with LFS Improvements:
  • IS_BNI This allows for the use of images within a button.
  • IS_DIW Display an image in the game world (on track).
For this to have the true desired effect, server must be able to upload information to the client. Or LFSWorld could be used as an intermediary that allows for images to be used on an LFS server, in game via these packets, this would both provide a fast HTTP download and no extra burden for the server. The current spec shows only the LFS server uploading to LFS client, but with small changes this could be made into a just a filename and a known (http) file path that could be used as the base to download these images.

struct IS_BTN // BuTtoN - button header - followed by 0 to 240 characters
{
byte Size; // 16 + SIZE (a multiple of 4)
byte Type; // ISP_BTN
byte ReqI; // non-zero (returned in IS_BTC and IS_BTT packets)
byte UCID; // connection to display the button (0 = local / 255 = all)

byte ClickID; // button ID (0 to 239)
byte Inst; // some extra flags - see below
byte TypeIn; // max chars to type in - see below
byte Annomate; // Button annomation state - see below

byte Style; // Button style flags - see below (BStyle without color)
byte BColor; // Background color index - see IS_RCI
byte FColor; // Foreground color index - see IS_RCI
byte Font; // Text font - see below

byte L; // left : 0 - 200
byte T; // top : 0 - 200
byte W; // width : 0 - 200
byte H; // height : 0 - 200

// char Text[SIZE]; // 0 to 240 characters of text
};

// Annomate: Things like fade in, fade out, pulse & inverse.

// Font: This depends on how Scawen what's to index his internal LFS fonts. You could also have a index font packet ...


struct IS_RCI // RegColorIndex - Registers a color index to be used.
{
byte Size; // Always 8
byte Type; // ISP_RCI
byte Index; // 20 - 255, First 20 are reserved by LFS.
byte Zero; //

byte R; // 0 - 255
byte G; // 0 - 255
byte B; // 0 - 255
byte A; // 0 - 255
};

// For the next two to happen, LFS has to have a way of getting data from the server to the client.

struct IS_BNI // ButtoN Image - Displays an button with an image on the screen.
{
byte Size; // 6 + SIZE + ((6 + SIZE) % 4)
byte Type; // ISP_DIS
byte ReqI; // non-zero (returned in IS_BTC and IS_BTT packets)
byte UCID; // connection to display the button (0 = local / 255 = all)

byte ClickID; // button ID (0 to 239)

byte L; // left : 0 - 200
byte T; // top : 0 - 200
byte W; // width : 0 - 200
byte H; // height : 0 - 200

// char Path[SIZE]; // 0 to 220 characters of text, must be null terminated, path is relative to LFS.exe
}

struct IS_DIW // Display an Image in the World.
{
byte Size; // (34 + SIZE + ((34 + SIZE) % 4)
byte Type; // ISP_DIS

float Scale; // 1.0 = Full Size
Angles Angles; // 3 floats: X, Y & Z
Pos Position; // 3 ints: X, Y & Z
float FPS; // In the case of an animated image, how many FPS should it run at? 0 = Do not animate.

// char Path[SIZE]; // 0 to 220 characters of text, must be null terminated, path is relative to LFS.exe
}

I might change IS_DIW so that you can attach an image to an object within the world to a PLID or AXOID (AutoX Object ID). The the things like Position would become relative to that object's position. Might be cool for adding like a flag above the car to let them know that they for example finished first ...
#19 - DarkTimes
LFS should reply with an error when you set the wrong admin password in the ISI packet. Even something as simple as adding a TINY_APR (Admin Password Refused) packet before closing the connection would work.
#20 - Dygear
Quote from DarkTimes :LFS should reply with an error when you set the wrong admin password in the ISI packet. Even something as simple as adding a TINY_APR (Admin Password Refused) packet before closing the connection would work.

Yes, there is no feedback from the InSim system on why the connection failed when you use a wrong password. This information would be nice!
#21 - misiek08
Why this topic died? It's very important and contains very interesting suggestions.

My next sugestion is to:
- let's InSim control car variables (power,weight)

This will make LFS more interesting, because we can use this options in legaues. Also we can make an upgrading-system on cruise server or NFS like servers.
#22 - PoVo
Quote from misiek08 :Why this topic died? It's very important and contains very interesting suggestions.

My next sugestion is to:
- let's InSim control car variables (power,weight)

This will make LFS more interesting, because we can use this options in legaues. Also we can make an upgrading-system on cruise server or NFS like servers.

IMO this would be very cool.

For drifters, we could even class the cars with "cloned" engines. E.G SR20DET
#23 - misiek08
Yeah, it could be used in every type of events. Race (we dont have to use air_intake or added_mass), drift (user can upgrade car for $, and win the $ in events), cruise (tuning/upgrade-system) and drag too.

InSim Devs & InSim Feature Triage.
(23 posts, started )
FGED GREDG RDFGDR GSFDG