Welcome, Please Register or Login

Downloads \ Street Legal Racing: Redline \ The Full Game \ Slrr Exhaustive

Author / Submitted by: Amilmand

Slrr Exhaustive

Very large collection with advanced fixes addressing stability.

Slrr Exhaustive

  • -200 chassis models
  • -272 tyres
  • -2042 rims
  • -150 custom tournaments on 20 maps against racers from the Valocity ladder during career mode (random racers otherwise)
  • -232 pre-built engines available from the catalogue (any engine any car)
  • -Packed into a working(video footage provided) Slrr(all java sources provided where available, I even found the source for system classes)
  • -Responsive catalogue
  • -Properly working Valocity and dealers (custom paintjobs on dummy race cars in Valocity during career mode and custom random generated opponents during night races and in tournaments)
  • -Every racer chassis customizable with nicely aligned paintjobs and with extra parts (10 different wide chassis compatible with all 200 chassis types)
  • -Bigfoot wheels (working semi-properly with collision on the wheels)
  • -Advanced bugfixes to the Slrr.exe: (Ida .idb and Olly .udd data included)
    • -Decal projection (crashed slrr when trying to paint a car with a model with more than 32767 vertices)
    • -Flying traffic cars
    • -Lag on collision
    • -Lag on look back, and generally looking around
    • -AI racer cars could not accelerate on sideways slopes
    • -Forced resource unloading addressing memory consumption
    • -Lag on spatial boundary crossing with a car that has large textures(this is what is happening at the end of the 4th gameplay video and why it does not happen in the 5th)
  • -Reshade customized for Slrr(Resahde source code provided under the BSD 3-clause license (https://github.com/crosire/reshade/blob/master/LICENSE.md))
    • -DOF effect that does not affect the UI
    • -Velocity dependent radial blur
    • -Dynamic reflection map
    • -AmbientLight
    • -Bloom
    • -MXAO(behind particle effects)
    • -and anything that reshade can compile
  • -Variables customizable (on the fly) from in-game reshade dialog(when in customization mode under the dubious ReflectionSettings.fx):
    • -Reflection Strength overwrite
    • -Other vehicle-material properties overwrite(specular power, color, refelction color...)
    • -Part deformation strength
    • -Car deformation strength (loss of driveability)
    • -Part detachment damage(how much you have to beat a part for it to fall off)
    • -Flop disabling(doors and hood will not open on collision)
    • -(with the variables above you can make an old-NFS style indestructible car)
    • -Engine wear
    • -Tyre wear
    • -AI power slide ignore factor(how much sliding the AI ignores when deciding whether to accelerate along a spline)
    • -AI over-breaking
    • -AI over-steering
    • -(these ones below can solve a lot of lagging)
    • -Maximum texture reserved memory
    • -Maximum vertex data memory
    • -Maximum sound memory
    • -Maximum script instances
    • -Resource loadrate
    • -and others...
  • -Controls for the game(not customizable):
    • -P put the car back if it has flipped
    • -1,2,3 simulation-time manipulation
    • -O (not a zero)toggle checkpoint markers during tournaments
    • -Esc return to tournament garage during tournaments (while watching a race or to give up)
    • -ctrl+shift+F10 for reshade menu
    • -ctrl+shift+F11 to toggle reshade effects
    • -"Tune" the chassis in the garage to move the wheels(Big foot mode) the engine or to overwrite the engine sound

In game pictures:

8hx99jb3qhtvfwfzg.jpg3czx7m3r8co1932zg.jpgxv7kkhjwqa9uj1czg.jpgtlvnbx1pc7mkv7wzg.jpgcvejtmnu0lin0hjzg.jpg

Gamefootage(near-potato pc):

Bigfoot:

All cars (and kind of a stress test):

Download Slrr Exhaustive from Google Drive

Technical part:

I worked a lot to decode the data files (scx,rpk..) and I developed some proof-of-concept
(they do not have, how should I put it, proper production code quality
(if I would have done this at work, well let's just say code review would have been quite a shaming))
little programs using the knowledge these can be found in the VS_Projects folder:

  • -Spl editor and map viewer (testing the concepts of RPK loading, and the spline .spl files define)
  • -Extra Part aligner (this includes putting together the car as Slrr would through slot attachments)
  • -UV editor (also, putting the car together properly so that the projected textures would line up)
  • -The map editor can load maps in POLY or PHYS editor mode which can be used to move around vertices in a map or its collision

These programs are not made for general public use but I did not want to withhold anything
they may come in handy for someone someday.
The general model for the datafiles is usable the sourcecode gets problematic in the tools.
This was done in (old)c# because well it was easier, also all the sources are provided
(under the "Dont Be a Dick" Public License (https://www.dbad-license.org/)). xdlc00b1pxkf245zg.jpg37hd66yqrk3lgbfzg.jpg

On this page I will provide the data file structures (as much as I found out) which was used to implement the tools (the c# source for datafile manipulation is understandable and serves as an example implementation (not all exceptions and common errors are listed here but the c# source is tested)).
c# source for datafile manipulation

  • Scx files:
    • There are two versions that Slrr uses for storing 3D model data:
    • Scx v3 file structure (fields in order of appearance (in a valid file)):
    • ScxV3
    • {
      • char[4] Signature = "INVO"
      • int Version = 3
      • ModelDefV3[] models //as many as can be also there may
        • be an int at the end of the file that is 0
    • }
    • ModelDefV3
    • {
      • MaterialV3
      • int vertexCount
      • VertexDataV3 vertexData[vertexCount]
      • int faceCount //triangle count
      • int IndicesV3[faceCount*3]
    • }
    • MaterialV3
    • {
      • int size
      • float DiffuseColorR
      • float DiffuseColorG
      • float DiffuseColorB
      • float Opacity
      • float SpecularColorR
      • float SpecularColorG
      • float SpecularColorB
      • float SpecularColorWeight
      • float GlossinessWeight
      • int Flags
      • {
        • int flagAlphaOpacity = 0x00000001;
        • int flagDiffuseBlend = 0x00000100;
        • int flagVertexColorBlend = 0x00000002;
        • int flagLayer2VertexColorBlend = 0x00001000;
        • int flagLayer2BlendByAlpha = 0x00000040;
      • }
      • short diffuseMapIndex //Which texture corresponds to which
        • mapindex is set in the RenderRef definition part as a
        • list of texture typeIDs in a RPK file referencing the given scx file
      • short bumpMapIndex
      • short specularMapIndex
      • short reflectionMapIndex
      • short diffuseLayer2MapIndex
      • short unkownMapIndex2
      • short illuminationIndex
      • short unkownMapIndex3
      • int oneVertexSize //in the next VertexDataV3
      • int unkownInt1
      • short unkownShort1
      • short diffuseMixFirstMapChannel //Channel is the index of UV that should be used
      • short diffuseMixSecondMapChannel
      • short bumpMapChannel
      • short specularMapChanel
      • short unkownShort2
      • int unkownInt2
      • int unkownInt3
      • int unkownInt4
      • float illuminationColorR
      • float illuminationColorG
      • float illuminationColorB
      • char materialName[32]
    • }
    • VertexDataV3// the size of this part is set in the MaterialV3
    • and can differ depending on the fields defined but the order
    • of them is fixed so if an UV channel 3 should be
    • defined all the field above must be as well
    • {
      • float vertexCoordX
      • float vertexCoordY
      • float vertexCoordZ
      • float vertexNormalX
      • float vertexNormalY
      • float vertexNormalZ
      • float uVChannel1X
      • float uVChannel1Y
      • float uVChannel2X
      • float uVChannel2Y
      • byte vertexColorB
      • byte vertexColorG
      • byte vertexColorR
      • byte vertexColorA
      • int unkown1
      • int unkown2
      • float uVChannel3X
      • float uVChannel3Y
      • int unkown3
    • }
    • Scx v4 file structure (fields in order of appearance (in a valid file)):
    • ScxV4
    • {
      • char[4] Signature = "INVO"
      • int Version = 4
      • int headerEntriesCount
      • HeaderEntry headerEntries[headerEntriesCount] // the order of these
        • definitions implicitly declares the logical connection between
        • entries (a mesh can only have one material definition...)
      • byte data[] //header entries point into this
    • }
    • HeaderEntry
    • {
      • int entryType
      • {
        • FaceIndices = 5, //FaceDef
        • MaterialDef = 0, //MaterialV4
        • HardSurfaceVertexDefinition = 1, //HardSurfaceDef
        • VertexData = 4, //VertexDataV4
        • SparseBoneIndexList = 2, //BoneList
        • BoneIndexList = 3 //BoneList
      • }
      • int entryOffsetInFile
    • }
    • MaterialV4
    • {
      • int unkownZero = 0
      • int size //of block
      • int flags
      • int unkownZero2 = 0
      • int EntriesCount
      • MaterialEntry entries[EntriesCount]
    • }
    • MaterialEntry
    • {
      • ushort unknownFlag
      • ushort Type
      • byte data[DataSize]
      • //DataSize is dependant on the Type:
      • //Type == 2048 => DataSize = 32 (char[32])
      • //Type == 0 => DataSize = 4 (byte RGBA)
      • //Type == 256 => DataSize = 4 (float intensity)
      • //Type == 1536 => DataSize = 28 (MapDefinitionEntry)
      • //Type == 1280 => DataSize = 4 (int)
      • //You can also deduce semantic meaning
        • (for this I used the TypeSwaped = (ushort)((Type >> 8) | (Type << 8)))
      • //if (unknownFlag == 0 && TypeSwapped == 0)
      • // return "Diffuse Color";
      • //if (unknownFlag == 2 && TypeSwapped == 0)
      • // return "Illumination Color";
      • //if (unknownFlag == 1 && TypeSwapped == 0)
      • // return "Specular Color";
      • //if (unknownFlag == 0 && TypeSwapped == 1)
      • // return "Glossiness";
      • //if (unknownFlag == 1 && TypeSwapped == 1)
      • // return "Reflection Percent";
      • //if (unknownFlag == 2 && TypeSwapped == 1)
      • // return "Bump Percent";
      • //if (unknownFlag == 0 && TypeSwapped == 6)
      • // return "Diffuse Map";
      • //if (unknownFlag == 1 && TypeSwapped == 6)
      • // return "Diffuse Mix Second";
      • //if (unknownFlag == 2 && TypeSwapped == 6)
      • // return "Bump Map";
      • //if (unknownFlag == 3 && TypeSwapped == 6)
      • // return "Reflection Map";
      • //if (unknownFlag == 4 && TypeSwapped == 6)
      • // return "Illumination Map";
      • //if (unknownFlag == 0 && TypeSwapped == 8)
      • // return "Material Name";
    • }
    • MapDefinitionEntry
    • {
      • int textureIndex //this index is taken from the texture
        • TypeID list defined in a RPK that references the scx file
        • containing this map definition record
      • int mapChannel //UV used
      • int TillingFlags//3=UTileVTile 0=UMirrorVMirror
      • float TillingU
      • float TillingV
      • float OffsetU
      • float OffsetV
      • //if the next entry is a float intensity MaterailEntry it is the
      • weight of this Map (like reflection strength)
    • }
    • FaceDef
    • {
      • int type
      • int size //of block
      • int numOfShorts
      • ushort indices[numOfShorts]//I must point out that these are ushorts
        • meaning if there are more than 0xffff (65535) vertices in a given
        • vertexDataV4 indices can overflow which in turn
        • can lead to crashes because of the extreme triangles
        • well actually slrr even used these as shorts when projecting
        • decals onto parts (on collision or by painting) so there could only
        • be 0xffff/2 vertices in a mesh (a model is made out of meshes)
        • technically:
        • 004F2DA1 (offset in Slrr.exe): two loops looping through all indices
        • and hence all vertices this can calculate bad pointers...
        • the loop checks a triangle (3 offsets are calculated but MOVSX is
        • used to load EDI which is "singextend" meaning it is cast to a short
        • from a ushort.... this is very bad EDI can move backwards
        • (even before the base pointer) in the buffer if the index is greater
        • than MAX_USHORT/2 which can happen ... that's not that many
        • vertices, all 6 (3 in each loop) MOVSX instructions
        • should be MOVZX (zero extend))
    • }
    • VertexDataV4
    • {
      • int type
      • int size //of block
      • int numberOfVertices//will be indexed with ushorts in FaceDef
        • so it should not be > 0xffff
      • int vertexType//flags declaring which fields are defined in the VertexData
      • //PossibleFeatures: (in order of possible appearance)
      • //Position = 0x1, float[3] XYZ floats
      • //BoneWeightNumIs0 = 0x2, 0 weight-float written
        • (one is implicit 1-Sum(WrittenWeights) = 1)
      • //BoneWeightNumIs1 = 0x4, 1 weight-float written
        • (one is implicit 1-Sum(WrittenWeights))
      • //BoneWeightNumIs2 = 0x8, 2 weight-floats written
        • (one is implicit 1-Sum(WrittenWeights))
      • //BoneWeightNumIs3 = 0x10, 3 weight-floats written
        • (one is implicit 1-Sum(WrittenWeights))
      • //BoneIndRef = 0x20, byte[4] (four indices to the BoneIndexList
        • (from the BoneList entry) defined before the current VertexDataV4)
      • //Normal = 0x40, float[3] XYZ floats
      • //VertexIllumination = 0x80, byte[4] RGBA
      • //VertexColor = 0x100, byte[4] RGBA
      • //UV1 = 0x200, float[2] UV
      • //UV2 = 0x400, float[2] UV
      • //UV3 = 0x800, float[2] UV
      • //BumpMapNormal = 0x40000, float[3] XYZ floats
      • byte vertexData[(size - 16)] //vertex data defined in accordance
        • with the vertexType
    • }
    • HardSurfaceDef //if this entry is present the current mesh is a
      • hard surface mesh meaning there won"t be any bone
      • references in the vertexDatas
    • {
      • int type
      • int size
      • int unkownInt = 0
    • }
    • BoneList
    • {
      • int type
      • int size
      • int unkownInt = 0
      • int BoneIndexList[((size - (3 * 4)) / 4)]
    • }
  • Rpk files:
  • These files are used to define the relations between other data files
  • (telling a Part script which cfg to use and which scx to use with which textures...)
  • Rpk
  • {
    • Header header
    • ExternalReference extRefs[header.externalReferencesCount]
    • EntriesHeader entriesHeader[]
    • ResEntry resEntries[entriesHeader.entriesCount]
    • byte rsdData[]
  • }
  • Header
  • {
    • char signature[4] = "RPAK"
    • int version512 = 512
    • int externalReferencesCount
    • int externalReferencesUnkownZero = 0
  • }
  • ExternalReference
  • {
    • short unkownIndexZero = 0
    • short indexOfReference
    • char referenceString[60] //padded with 0-s (at the end)
  • }
  • EntriesHeader
  • {
    • int entriesSize//resEntries size in bytes
    • int entriesCount
    • int entriesType1Count // number of entries with typeOfEntry == 1
    • int entriesNonType1Count
  • }
  • ResEntry
  • {
    • int superID
    • int typeID// it is called Type ID because it only needs to be unique
      • in combination with the value of┬átypeOfEntry
    • byte typeOfEntry
    • byte additionalType
    • float isParentCompatible
    • int fileOffsetOfRSD
    • int RSDLength
    • byte aliasLength
    • char alias[aliasLength] //despite the length defined this must
      • be zeroterminated (size includes the zero)
    • (//optional
    • float floatBounds[12]// it is present if additionalType & 1 != 0 this
      • is used in the spatial data structure used to define maps
    • )
  • }
  • RSDEntry
  • {
    • InnerRsdEntry innerEntries[]//as many as the corresponding RSDLength can hold
  • }
  • InnerRsdEntry can be one of; ICFGInnerEntry, XCFGInnerEntry,
  • RSDInnerEntry, StringInnerEntry, EXTPInnerEntry, NamedDataArray,
  • InnerPolyEntry, InnerPhysEntry
  • ICFGInnerEntry //Internal cfg entry: a cfg file defined directly in the rpk
  • {
    • char signature[4] = "ICFG"
    • int lengthOfData
    • char cfgData[lengthOfData]// \0 delimited list of strings (2 strings observed)
      • defining a common cfg with a key
  • }
  • XCFGInnerEntry //reference cfg
  • {
    • char signature[4] = "XCFG"
    • int lengthOfData
    • char cfgData[lengthOfData]// \0 delimited list of strings the first one
      • is usually empty the second one is a key, a whitespace and
      • than a file path relative to the slrr root directory to a cfg file
  • }
  • RSDInnerEntry
  • {
    • char signature[4] = "RSD\0"
    • int lengthOfData
    • char stringData[lengthOfData]// string data used mainly to
      • define map "entry points" //expect NamedDatas and the
      • spatial structure definition of a map (as in track not as in picture)
  • }
  • StringInnerEntry
  • {
    • char stringData[] //as much as the current RSD entry can
      • hold (ResEntry.RSDLength (or as much as is left of it))
  • }
  • EXTPInnerEntry
  • {
    • char signature[4] = "EXTP"
    • int lengthOfData = 4
    • int data//only 3 observed it is also the number of the root
      • NamedDataArrays defined but that can be coincidence
  • }
  • NamedDataArray
  • {
    • char signature[4] = "\0\0\0\0"
    • int numOfNamedDatas
    • NamedData namedDatas[numOfNamedDatas]//these represent the
      • spatial tree data structure (not a BSP, some axis aligned thing
      • not exactly an octree but definitely some bounding volume hierarchy)
  • }
  • NamedData
  • {
    • int TypeID
    • int SuperID
    • byte typeOfEntry
    • byte additionalType
    • float isParentCompatible
    • int offset//in file, references NamedDataArray, InnerPolyEntry
      • or InnerPhysEntry entries not always just one but uniquely;
      • only one NamedData references a given array or poly or phys
    • int sizeAtOffset
    • byte nameLength
    • char name[nameLength]//just as with the RES entries
    • float boundingBoxX//in range -50000 .. 50000 positioning the centre of the box
    • float boundingBoxY//in range -50000 .. 50000
    • float boundingBoxZ//in range -50000 .. 50000
    • float boundingBoxHalfWidthX//in range 0 .. 50000 generally small values
    • float boundingBoxHalfWidthY//in range 0 .. 50000 generally small values
    • float boundingBoxHalfWidthZ//in range 0 .. 50000 generally small values
    • float unkownData7// only 0 seen
    • float unkownData8// only 0 seen
    • float unkownData9// only 0 seen
    • float unkownData10// only 0 seen
    • float unkownData11// only 0 seen
    • float unkownData12// only 0 seen
  • }
  • InnerPolyEntry
  • {
    • char signature[4] = "POLY"
    • int size
    • int unkownCount1
    • int meshCount
    • Mesh meshes[meshCount]
  • }
  • Mesh
  • {
    • int textureIndex
    • int verticesCount
    • int triangleCount
    • VertexData vertexData[verticesCount]
    • int Indices[triangleCount*3]
  • }
  • VertexData
  • {
    • float coordX
    • float coordY
    • float coordZ
    • float normalX
    • float normalY
    • float normalZ
    • byte colorR
    • byte colorG
    • byte colorB
    • byte colorA
    • byte illuminationR
    • byte illuminationG
    • byte illuminationB
    • byte illuminationA
    • float uVChannel1U
    • float uVChannel1V
    • float uVChannel2U
    • float uVChannel2V
    • float uVChannel3U
    • float uVChannel3V
  • }
  • InnerPhysEntry
  • {
    • char signature[4] = "PHYS"
    • int size
    • int indexChunkCount
    • IndexChunk indexChunks[indexChunkCount]
    • int vertexChunkCount
    • VertexChunk vertexChunks[vertexChunkCount]
  • }
  • IndexChunk
  • {
    • int unkownInt1//probably the material...
    • int triIndices[3]
    • float normalX
    • float normalY
    • float normalZ
  • }
  • VertexChunk
  • {
    • float vertexX
    • float vertexY
    • float vertexZ
  • }
  • Class files:
  • The compiled script files of slrr this uses a custom java implementation it
  • was developed with Flex(,Bison) ... if someone wants a challenge
  • (to investigate the saved AST)
  • I only figured out the bare minimum that is needed to change the
  • rpk references, class and package names in the .class files without .java sources
  • Class
  • {
    • TUFA definedClasses[]//sequentially
  • }
  • TUFA
  • {
    • char signature[4] = "TUFA"
    • int unkownData1
    • int unkownData2
    • SignaturedSizedScriptEntry entries[]//as many as can be till the next TUFA
      • entry, can be SignaturedSizedScriptEntry or CONSEntry
  • }
  • SignaturedSizedScriptEntry
  • {
    • char signature[4]
    • int size;
    • byte data[size]
  • }
  • CONSEntry
  • {
    • char signature[4] = "CONS"
    • int size;
    • int entriesCount
    • ConstantEntry entries[entriesCount] //can be ConstantEntry, NameConstantEntry
      • or RpkRefConstant, the full class name(including the package) is the first
      • NameConstantEntry the full parent class name is the second
  • }
  • ConstantEntry
  • {
    • int ID
    • byte[] data// size is determined by the ID:
      • //ID == 0 => size = (the first int in data)+4
      • //ID == 4 => size = 4
      • //ID == 7 or 3 or 5 => size = 8
      • //data is generally an int[] referencing other ConstantEntries by their indices
      • in the given constant table if flatted out it will give a function reference or other string
  • }
  • NameConstantEntry
  • {
    • int ID = 0
    • int stringLength
    • char name[stringLength]
  • }
  • RpkRefConstant
  • {
    • int ID = 3
    • int RPKnameIndexInConstantTable//the index of a NameConstantEntry
      • in the current CONS that will be the rpk referenced (the file path)
    • int TypeIdInRPK
  • }

Other assorted info about Slrr:

  • -In the cfgs for vehicles and parts stockpart 0x00000001 line means that when creating a dummy model try and attach the part with typeID 0x00000001 (this is used when creating the cars roaming the city)
    • -creating a dummy car:
    • -dummycar = new GameRef();
    • -dummycar.create_native( map, new GameRef(dummyID), "0,-10000,0,0,0,0", "dummycar" );
    • -// here stockpart references will be attached
  • -In the cfgs for vehicles and parts the texture 0x00000001 line means that the texture 0x00000001 (which should be in the textureID list of the corresponding renderRef definition) will be replaced when painting is applied (or the setTexture method) this can be used to create parts with paintable reflection or illumination textures which is quite cool.
  • -Slrr manages RenderRefs competently but scripts are difficult for it this is the reason why in the demonstration "modded almost to hell" version of Slrr I created all the RenderRef lookup tables(to delay the loading of the corresponding classes); once a script is loaded (meaning an instance of one of the defined classes is created) it can not be unloaded and this is why slrr will always crash eventually; it is a 32bit application so it can only address <4Gb memory which will easily run out because every part has a unique class, of course as demonstrated in the videos this can be pushed out significantly (using the renderRef lookups), and this is why all the ExtraParts use the same script.
  • -The silent crashes (ones that do not produce a line in the error.log) are (if you can rule out the obvious missing resource thing and class redefinition (which can be easily checked using the file type model)) almost always caused by the GC freeing up a script instance from under another script-thread, multi threading is very dangerous in Slrr (Miran's added little camera icon to the navigator (which is updated from a thread created by the Track class) was a frequent cause of crashes).
  • -The game uses standard fixed function pipeline directx9
  • -The .spl file spline row format (%LF is float %d is int) is:
    • -(%lf %lf %lf) (%lf %lf %lf) %lf %lf %d %lf %lf %d:
    • -(pos XYZ), (normal XYZ), splineWidth, targetVelocity, I do not know the rest
    • -the two ints are used as bools the list of first two vectors define a closed cubic Hermite spline.
  • -Slrr can not load more than 256 RPKs and there are at least 5 reserved slots that get filled by the exe itself and not by loading a library this modded version loads 248 (I think), and that is pretty much the maximum possible.

All of the above and everything linked is provided as-is, feel free to extend but you know dont be a dick.

Tags: Career , Valocity , Tournaments , Stability , Graphics

Download: Slrr Exhaustive

Filesize, kB: 4488.546875KB

Downloaded: 128

report broken link

11. amilmand

2017-12-11 06:16

Outlaw_Racer I think something is amiss at your end noone else reported this and I know of an odd 10 people who use it maybe you have some missing assets (or you know you can try and give the game the CD you should own it to play it :/ ) nevertheless you can try applying the patch form of that download: LINK. Oh and for others reading this I do not get notified about messages here PM me instead if you expect help.


Avatar

10. Cobra289

2017-12-09 18:07

I tested your .exe file on my modded SLRR (based on SLRR Light Edition) and ooooohhhhh my lord it'awesome


9. Outlaw_Racer

2017-12-09 06:51

Insert SL2 Disk?


8. amilmand

2017-12-08 19:26

Only the exe patches with no reshade: (replaced default values with the "no shift time" ones (clutch:0 thorttle: 1))
GOOGLEDRIVE


7. amilmand

2017-12-08 18:59

This is the first patch that is not included in the main patch of 2017-12-07:
I got a request for some way to customise the "gear shift time" I found the values Slrr assigns to the clutch (how much it is pressed) and the throttle during the "dead-time" between shifts (auto-shifts) I also made it a parameter that is settable from the reshade menu (in the ReflectionSettings as every other like this (I should rename that)) and this can be used to make the transition seamless (no rev limiter hit and nothing else) (if the clutch is 0 and the throttle is 1 the default if 0.5, 0.5). For better understanding here is a video:
YOUTUBE
And the patch: (the exe alone can do the gear shift adjustment (default values 0.5, 0.5) resahde makes it customisable and the chassis.java adds some other functions (getting current RPM and turbo level among other things) that are still being tested)
GOOGLEDRIVE


6. amilmand

2017-12-07 13:53

I pulled the patches to the main file


5. amilmand

2017-12-07 01:33

There is another patch the tournament named "CrazyParkNight" had a bad prize car:
LINK


4. amilmand

2017-12-04 13:14

But if someone else also has problems playing the background video here is a patch: LINK


3. amilmand

2017-12-04 10:50

Ackowiak use proper codecs (cccp codec pack)


Avatar

2. Ackowiak

2017-12-04 10:39

Crashes just at the second loading where the activemovie window pops up, no error.log, freshly unpacked.


1. gorgoil

2017-12-04 06:51

Great work there


Only registered users can post new comments

Contact Info

Put your e-mail, skype, phone numbers or any other contact information here so that your visitors could easily get in touch with you.