The online racing simulator
Proposed InSim Updates For 0.6F
(12 posts, started )
#1 - Dygear
Proposed InSim Updates For 0.6F
Before Scawen finishes up the E patch levels, does anyone want any changes to the InSim interface?

Being able to change the client's PName would be nice.

struct IS_RNP {
byte Type; // Value TBA
byte Size; // 20
byte SubT; //
byte PLID; // PlayerID to Rename

char[16] PName; // PName to set for this player.
}

As would forcing a control scheme onto a client.
// Force Control Scheme
struct IS_FCS {
byte Type; // Value TBA
byte Size; // 4
byte Flag; // Following Bools are in a single Byte here; 1 = Allow, 0 = Disallow
bool Automatic = 1;
bool BlipShiftDown = 1;
bool BlipShiftUp = 1;
bool Keyboard = 1;
bool Mouse = 1;
bool Wheel = 1;
bool Sp0 = 0;
bool Sp1 = 0;
byte UCID; // ClientID to Force Control Scheme Onto.
}

#2 - DANIEL-CRO
There wont be any insim changes in 0.6F.

1. You probably mean renaming by UCID, and playername is [24]. Would be nice in leagues and such, but thing that admins can rename players could often be abused.

2. +1
#3 - cargame.nl
Quote from Dygear :
Being able to change the client's PName would be nice.

And why? I think thats a bad idea. Controlling somebody else's name is not nice.
#4 - DarkKostas
Quote from cargame.nl :And why? I think thats a bad idea. Controlling somebody else's name is not nice.

Agree. Unless it only gives you the ability to add a "prefix" like a tag. But that will keep your original name.

What i'd like to see is a


struct IS_STC { //SeTCoordinates
byte Type; // Value TBA
byte Size; // 20
byte SubT; //
byte PLID; // PlayerID

int X; // X map (65536 = 1 metre)
int Y; // Y map (65536 = 1 metre)
int Z; // Z alt (65536 = 1 metre) word Heading; // direction of forward axis : 0 = world y direction, 32768 =
bool ResetCar; // Reset car. 1 = Fix it, 0 = Keep it same as it was.
}

And some more things which i had in another topic. One of them was to auto-spectate somebody if they drive an illegal car once you set per-player cars, same as it works for /cars command. And one more was to finally have LName @ AXI work for remote clients as well. So you can get their layout name.
#5 - Dygear
Quote from DANIEL-CRO :There wont be any insim changes in 0.6F.

1. You probably mean renaming by UCID, and playername is [24]. Would be nice in leagues and such, but thing that admins can rename players could often be abused.

2. +1

No, by PLID. You can't rename a client because their UName is set by their LFSW profile. But you can rename a Player that's spawed from a client.

Quote from cargame.nl :And why? I think thats a bad idea. Controlling somebody else's name is not nice.

Tag protection, instead of kicking the client, you could rename them. If they have an offensive name, you can rename them. Bring everyone in line to a common format according to league rules.

Quote from DarkKostas :What i'd like to see is a

struct IS_STC { //SeTCoordinates

That would be AWESOME!
#6 - DANIEL-CRO
Quote from Dygear :No, by PLID. You can't rename a client because their UName is set by their LFSW profile. But you can rename a Player that's spawed from a client.

Read post again, I'm talking about playername.

struct IS_NCN // New ConN
{
byte Size; // 56
byte Type; // ISP_NCN
byte ReqI; // 0 unless this is a reply to a TINY_NCN request
byte UCID; // new connection's unique id (0 = host)

char UName[24]; // username
[B]char PName[24]; // nickname[/B]

byte Admin; // 1 if admin
byte Total; // number of connections including host
byte Flags; // bit 2 : remote
byte Sp3;
};

#7 - Dygear
#8 - T3charmy
Quote from Dygear :Before Scawen finishes up the E patch levels, does anyone want any changes to the InSim interface?

Being able to change the client's PName would be nice.

Quote from DarkKostas :Agree. Unless it only gives you the ability to add a "prefix" like a tag. But that will keep your original name.

What i'd like to see is a


struct IS_STC { //SeTCoordinates
byte Type; // Value TBA
byte Size; // 20
byte SubT; //
byte PLID; // PlayerID

int X; // X map (65536 = 1 metre)
int Y; // Y map (65536 = 1 metre)
int Z; // Z alt (65536 = 1 metre) word Heading; // direction of forward axis : 0 = world y direction, 32768 =
bool ResetCar; // Reset car. 1 = Fix it, 0 = Keep it same as it was.
}


I'd like to see both of these... another thing I thought about was more buttons(and more button features)[including ability to use images]
#9 - Dygear
#10 - kdo
#11 - DANIEL-CRO
There already is thread specifically about images on insim buttons.
Images on InSim Buttons
I support the idea, but it should be carefully implemented. We certainly don't need really big pictures that will cause unnecessary problem to people with slow internet connection. And there should definitely be some kind of local caching thing.

On the other side, I'd like some additions to IS_STA locally, for example to detect if chatbox is in foreground, detect if LFS is in garage screen, options screen...
#12 - Dygear
Quote from Dygear :Here's an InSim packet that I'd like to see. IS_TRE (Tire)

struct ISP_TRE
{
byte Size; // 8
byte Type; // ISP_TRE
byte SubT; // Always 0
byte PLID; // Player ID of Client in Question

// Followings Byte's Value is From Contact Patch Defines;
byte DSF; // Driver Side Front
byte DSR; // Driver Side Rear
byte PSF; // Passenger Side Front
byte PSR; // Passenger Side Rear
}

#define TRE_TARMAC 0; // 0 - sent by the layout loading system only
#define TRE_OOB 1; // 1 - Tire is out of track bounds.
#define TRE_RUMBLE 2; // 2 - Tire on Rumble Strip.
#define TRE_GRASS 4; // 4 - Tire is on Grass.
#define TRE_SAND 8; // 8 - Tire is on Sand.

This packet would only be sent when there is a change of state. Could use useful for making a smarter lap invalidation system within an InSim application, outside of checking the client's cords being in the track's path. Mainly also useful on X and Y configs where there are no paths by default, we can then use this information as a backup.

Here is a copy of my proposal.

Quote from cargame.nl :
Quote from Dygear :
Here's an InSim packet that I'd like to see. IS_TRE (Tire)
Whats the difference with IS_HLV?


And to answer your question cargame, HLV invalidates laps, but does not give us information about the tires. Many times in this season of F1, they are talking about the number of tires going over and beyond the defined track limits (white lines). This packet will allow us to get that information and allow leagues to decide node by node (effectively better then corner by corner) what they wish to allow.

Proposed InSim Updates For 0.6F
(12 posts, started )
FGED GREDG RDFGDR GSFDG