Is it possible to return the name (not the type) of the car in lets say IS_NPL? So I mean the name for each different setting. Default name for XF GTI is "hard track".
InSim Feature Request: Car setting name
(23 posts, started )
InSim Feature Request: Car setting name
You mean the name of the setup that's being used? That's kind of irrelevant as you can rename a setup, or take a copy of it, which would make it a poor mans setup enforcement?
Agreed, this is useless. A hash based on the contents of the file wouldn't be, though.
You mean some kinda value thats not changable?
Not sure what you mean by "a value that's not changeable" Sean?
A hash can be defined as a number, or sequence of characters, generated by applying a mathematical formula to a document or sequence of text. The hash is significantly shorter that the original text and is unique to the original document. Typically this hash will be represented in hexidecimal.
A hash can be defined as a number, or sequence of characters, generated by applying a mathematical formula to a document or sequence of text. The hash is significantly shorter that the original text and is unique to the original document. Typically this hash will be represented in hexidecimal.
I was thinking of some value thats generated when a set is made (e.g setXy4511) or something but 'hash' makes more sence now i look at it
I just want to know via InSim (or some other way) what setup I use at the moment. If it is possible please let me know.
No it is not possible right now. There is a thread discussing the merits of this, at the moment, in the Improvement Suggestions subforum. Whether or not it'll be implemented soon, or in what form only Scawen would beable to confirm.
An MD5 hash of the setup or something could be sent. My knowledge of security is poor : can they be reverse engineered? Just an idea until LFS gets actual forced setups.
By definition a hash shouldn't be able to be reversed (that would be encryption), however any hash can be brute forced by enumerating over all possible values, given enough time.
However, because a setup wouldn't be a "normal" string of characters, but a string of bytes that would be very unlikely to equate to a normal string (such as a password). As such it's very unlikely that many hashes produced by LFS will have already been pre-computed and available in a rainbow table.
Don't forget that md5 isn't the only available hash out there. crc32 would be much quicker, and easier to compare since it outputs an int value.
At the end of the day, however, it would me much better to beable to force a setup from the server, since I could imagine a lot of trouble from a lot of people about how they'd go about calcing hashes from setups for their applications.
With such a small input, a rainbow table would be easy to make. It would not take long at all to each combination of the setup file, and then hash that, then check that agesnt the hash send in via InSim. Infact if this system is taken up, I would make it my goal in life to do this. (Just think, I could get all of the WR setups from the replay!)
There was an app posted a while ago that could do it anyways
Assuming that the setup file has changed whilst I've been asleep, the number of combinations would be about 255!/(134! * (255-134)). (damn my lack of scientific calculator here 
)
Whilst that's not exactly a small number, it's not massive and as NotAnIllusion says, there are easier ways to get setups from an spr
Or at least a very good approximation.
)Whilst that's not exactly a small number, it's not massive and as NotAnIllusion says, there are easier ways to get setups from an spr
Or at least a very good approximation.You forgot a !
Well and imo its very hard to make every possible combination of setup ingame, save the values and the hash for those... And because it's an online game the hash could contain the host name for example, or the ip.
(I assume the whole hash stuff is to check, that ppl use a forced setup online?)
Well and imo its very hard to make every possible combination of setup ingame, save the values and the hash for those... And because it's an online game the hash could contain the host name for example, or the ip.
(I assume the whole hash stuff is to check, that ppl use a forced setup online?)
If you did it in game. If you consider it to just be a series of bytes, which by definition can only have a value of 0-255, then it becomes much easier to produce. Whilst a vast number of those computed wouldnt be valid setups, they'd still produce a reasonable hash.
Oooh, salting the hash of the setup, with the hostname of the server.. That's evil. And brilliant.
You can see the setup name you`re currently using, by pressing F12 in-game.
I guess it's stored somewhere, if you really want to use via insim.
le: (maybe PSE_SETUP has something to do with it ?)
Or you could use the user name of the person who originally made the setup!
Then again, if the server side InSim app checks the hash and the driver is allowed to race, they would have got the setup from their site or something. Of course, if they are using something other than the forced setup, then they will have a hash, which sounds like it will be hard enough to deter all apart from the real idiots from deducing the stup.
Now that there is a positively horrendously brilliant idea. I love it.
And exactly how do you intend on storing that information for use in creating the hash?
Yes you are right about the latter. So I figured out that it is stored in "cfg.txt". So when you leave the garage, the name is written into that file. So that will be my solution to read it there.
Thanks al for the coöperation. :-)
Is everyone ok with requesting a setup hash from the client, with it being salted by the host name of the server?
The hash should be MD5 of the currently utilized car setup salted with the host name of the server. Ideally the InSim client should ask for a setup check when a player leaves the pits or joins the game (become a player not just a client).
The InSim client may request a setup by sending an ISP_SMALL packet with the UVal of the PLID of the car they wish to check the setup on. That will in turn prompt a ISP_RSH packet to be sent back in the following format:
This system as the downside (or upside) of requiring for each value having to be exact. You can not do range of values, you can't even set your own fuel level. All values much match, exactly. So this system is only good if you want a %100 match. The following system should, and if implemented would, superseded that system.
---------------------------------------------------------------------------------------
Ideally, any admin should be able to do this by telling the server what values they wish the client to be able to set. Either a range of values, or one value for each setup option. This would make it so that a client would be checked by the game's engine and not an InSim packet reducing overall network usages, and securing the system from potential rainbow table abuse.
This could be done via a button interface on the Admin's client, much the same way that the current setup screen works. But once the admin is done, they press submit and those values become the requirement for the server's participants. The data stored would have to be twice as large as the current set files to allow for a range, and if you want to require a exact value just define that min and the max as the same number. As the server side game engine needs to know setup details anyway, why not have it do the setup check intrinsically and we just have a packet that would tell the server what values to allow?
I need information on the format of the setup files, in order to make a packet, but each setup value should have a min value and a max value so we could allow for ranges and not just precise setups. What do you all think? The Insim packet could be called ISP_RSV or Required Setup Values, and it would be an instruction only.
207 (The total value of bytes seen below minus 1 times by 2 plus 1) Bytes would be the packet payload, with 210 being the total size when you include the packet header. Each value seen below would have two in it's place where applicable. The first one being the min value, the second being it's max. Anyone what to write this up while I find something to cool me down, because it feels like 100°F (37.7°C) in here.
InSim Packet Header:
InSim Packet Payload:
The hash should be MD5 of the currently utilized car setup salted with the host name of the server. Ideally the InSim client should ask for a setup check when a player leaves the pits or joins the game (become a player not just a client).
The InSim client may request a setup by sending an ISP_SMALL packet with the UVal of the PLID of the car they wish to check the setup on. That will in turn prompt a ISP_RSH packet to be sent back in the following format:
<?php
#define ISP_RSH 50; // 50 - info : Request Setup Hash
#define SMALL_RSH 8; // 8 - info request : send an IS_RSH - Requested Setup Hash
struct IS_RSH // Requested Setup Hash
{
word Size; // 26
word Type; // ISP_RSH
word ReqI; // TRUE if asked for by an SMALL packet, FALSE if not.
word PLID; // PLID of Car we wish to check the setup on.
char Hash[22]; // (MD5) Hash of setup values with host name as salt.
}
?>
---------------------------------------------------------------------------------------
Ideally, any admin should be able to do this by telling the server what values they wish the client to be able to set. Either a range of values, or one value for each setup option. This would make it so that a client would be checked by the game's engine and not an InSim packet reducing overall network usages, and securing the system from potential rainbow table abuse.
This could be done via a button interface on the Admin's client, much the same way that the current setup screen works. But once the admin is done, they press submit and those values become the requirement for the server's participants. The data stored would have to be twice as large as the current set files to allow for a range, and if you want to require a exact value just define that min and the max as the same number. As the server side game engine needs to know setup details anyway, why not have it do the setup check intrinsically and we just have a packet that would tell the server what values to allow?
I need information on the format of the setup files, in order to make a packet, but each setup value should have a min value and a max value so we could allow for ranges and not just precise setups. What do you all think? The Insim packet could be called ISP_RSV or Required Setup Values, and it would be an instruction only.
207 (The total value of bytes seen below minus 1 times by 2 plus 1) Bytes would be the packet payload, with 210 being the total size when you include the packet header. Each value seen below would have two in it's place where applicable. The first one being the min value, the second being it's max. Anyone what to write this up while I find something to cool me down, because it feels like 100°F (37.7°C) in here.
InSim Packet Header:
struct IS_RSV {
byte Size; // 210
byte Type; // ISP_RSV
byte Zero;
}
InSim Packet Payload:
Offset Type num Description
------ ---- --- -----------
0 byte 1 Bit 2 (ABS Allow=1, Disallow=0)
Bit 1 (Traction Control Allow=1, Disallow=0)
Bit 0 (Asymmetrical Allow=1, Disallow=0)
1 byte 1 Handicap Mass Position
2 byte 1 Tyre Brand (0=Cromo Plain, 1=Cromo, 2=Torro, 3=Michelin, 4=Evostar)
3 float 1 Brake Strength (Nm)
7 byte 1 Rear Wing Angle
8 byte 1 Front Wing Angle
9 byte 1 Voluntary Handicap Mass
10 byte 1 Voluntary Intake Restriction
11 byte 1 Max Steering Lock
12 byte 1 Parallel Steering
13 byte 1 Brake Balance
14 byte 1 Engine Brake Reduction
15 byte 1 Centre Diff Type (0=Open, 1=Viscous)
16 byte 1 Centre Diff Viscous Torque
17 byte 1 Centre Diff Torque Split
18 word 1 Gear Ratio 7 (0 to 65536 = 0.5 to 7.5)
20 word 1 Gear Ratio Final (0 to 65536 = 0.5 to 7.5)
22 word 1 Gear Ratio 1 (0 to 65536 = 0.5 to 7.5)
24 word 1 Gear Ratio 2 (0 to 65536 = 0.5 to 7.5)
26 word 1 Gear Ratio 3 (0 to 65536 = 0.5 to 7.5)
28 word 1 Gear Ratio 4 (0 to 65536 = 0.5 to 7.5)
30 word 1 Gear Ratio 5 (0 to 65536 = 0.5 to 7.5)
32 word 1 Gear Ratio 6 (0 to 65536 = 0.5 to 7.5)
34 byte 1 Passenger (4 2bit fields). Passengers are located in the byte
at the following locations
76|54|32|10
--+--+--+--
RR|RC|RL|FR
The individual passenger types are identified as follows.
00 = None
01 = Male
10 = Female
35 byte 1 Car Config (roof on LX4/6 and UF1)
36 byte 1 Traction Control Slip (divide by ten)
37 byte 1 Traction Control Engage Speed
38 float 1 Rear Ride Height (NOT spring motion range)
42 float 1 Rear Spring Stiffness (N/mm)
46 float 1 Rear Compression/Bump Damping (N/mm)
50 float 1 Rear Rebound Damping (N/mm)
54 float 1 Rear Anti Roll Bar Stiffness (N/mm)
58 byte 1 Rear Toe (0=-0.9deg, 9=0deg, 18=0.9deg)
59 byte 1 Rear Caster (i.e. always zero)
60 byte 1 Rear Tyre Type (0 through 7 is R1 through Knobbly, in order of grip)
61 byte 1 LR Camber Adjust ( 45=0.0deg, 0=-4.5deg, 90=4.5deg)
62 byte 1 RR Camber Adjust ( 45=0.0deg, 0=-4.5deg, 90=4.5deg)
63 byte 1 Rear Diff Clutch Pack Pre-load (multiply by ten)
64 byte 1 Rear Diff Type (0=Open, 1=Locked, 2=Viscous, 3=Clutch Pack)
65 byte 1 Rear Viscous Torque
66 byte 1 Rear Power Locking
67 byte 1 Rear Coast Locking
68 word 1 LR Tyre Pressure (kPa)
70 word 1 RR Tyre Pressure (kPa)
72 float 1 Front Ride Height (NOT spring motion range)
76 float 1 Front Spring Stiffness (N/mm)
80 float 1 Front Bump/Compression Damping (N/mm)
84 float 1 Front Rebound Damping (N/mm)
88 float 1 Front Anti Roll Bar Stiffness (N/mm)
92 byte 1 Front Toe In (0=-0.9deg, 9=0deg, 18=0.9deg)
93 byte 1 Front Caster (need to divide by ten)
94 byte 1 Front Tyre Type (0 through 7 is R1 through Knobbly, in order of grip)
95 byte 1 LF Camber Adjust ( 45=0.0deg, 0=-4.5deg, 90=4.5deg)
96 byte 1 RF Camber Adjust ( 45=0.0deg, 0=-4.5deg, 90=4.5deg)
97 byte 1 Front Diff Clutch Pack Pre-load (multiply by ten)
98 byte 1 Front Diff Type (0=Open, 1=Locked, 2=Viscous, 3=Clutch Pack)
99 byte 1 Front Viscous Torque
100 byte 1 Front Power Locking
101 byte 1 Front Coast Locking
102 word 1 LF TyrePressure (kPa)
104 word 1 RF TyrePressure (kPa)Is there any chance for RSH and/or RSV?
InSim Feature Request: Car setting name
(23 posts, started )
FGED GREDG RDFGDR GSFDG