"rFactor 1 Developer's Corner" - a long-lost website from ISI

[MJQT]

This is a big find. Thank goodness the Web Archive preserved this.

rFactor 1 Developer’s Corner | rFactor

web.archive.org

Contains a lot of great information and material for download!

I have reposted a big ZIP file of all the modding tools from ISI that were available on this old web page on RaceDepartment here:

ISI rF1 modding tools - pack

Thank goodness the Internet Archive preserved this website from rFactor 1's heyday: "rFactor 1 Developer's Corner" https://web.archive.org/web/20171021035833/http://rfactor.net:80/web/rf1/devcorner/ It contains a lot of great information and...

www.racedepartment.com

Waypoint and camera editing tools

Download v1.255

rFactor mod development tool pack (Mas utility, scene viewer and more)

Download version 2
Download version 1

rFactor internals plugin

Instruction PDF
Download version 3
Download version 2
Download version 1

gMotor 2.0 MAS Utility

Download version 2.0

rFactor Max Plugins (32 Bit)

rFactor Max 8
rFactor Max 9
rFactor Max 2009
rFactor Max 2010

rFactor MD5/SHA1

Download v1.255g Files

Documents and Notes

Basic track editing
Replay Format Information

Developer Q&As

06.22.05 – Pete Knepley
09.18.04 – Joe Campana
08.27.04 – Brad Shuber
08.13.04 – Terence Groening
08.10.04 – Gjon Camaj

All information, documentation, or software (“Information”) is being provided “AS IS”. Image Space Incorporated does not and cannot warrant this Information (including any fixes and updates) or the performance or results obtained by using it. Image Space Incorporated makes no warranties of any kind, either expressed or implied, including but not limited to, non-infringement of third party rights, merchantability, or fitness for a particular purpose. To the extent you use or implement this Information, you do so at your own risk. In no event will ISI be liable to you or others for any damages arising from your use or your inability to use any of the information, documentation, or software. Commercial exploitation is prohibited. Image Space Incorporated may terminate, change, or suspend any aspect of this Site and the contents provided at any time. Please visit http://rfactor.net/web/termsofuse/ for additional or updated information.

 

[MJQT]

Basic track editing information - Notes from the field

– Never, never have the same xobject two times in your scn file. I had many problems with the xobjects, you can move them around, rotate them but don’t edit their vertices.
– I didn’t find the right key setups (rotation) for editing static cameras. I found easier to delete the misaligned one and create a new one. You can also edit the values in the cam file (txt file).
– All base materials have to be Multi/Sub-Object

– All sub materials have to be gMotorMaterial (gMat)
– All textures have to be in gTex (they are gTex by default – do not change them)
– Increasing the specular power of a material reduce the hot spot in the sim
– A little trick : Don’t know why but if you have a Multi/Sub-Object with many mats you can’t expand the list enough to copy a mat down the list. I copy the needed mat to an adjacent slot then copy it back down the list from the copied slot. (you can use the get materials button to browse the editor as well)
– You can adjust the Emissive color in the material but that will hurt nighttime lighting. I suggest adjusting the main ambient values in the *.gdb file
– S button is disabled

– Be careful when naming materials:

– They are linked by their names to the terrain.ini files (physical characteristics)
– Don’t use the same name for two different materials or textures (also make sure that you don’t name your material the same as one existing in the common.mas or *.map files. Be sure to delete any texture with the same name in the *map.mas file if you are working with textures in your main folder.(ed. cant overstate the importance of this – multiply-defined mats will cause lots of hard-to-debug grief)

– The following objects can’t be renamed (they won’t work):

– xfinish, xsector1, xsector2, xpitin, xpitout
– startlight, startglow, pitlightin, pitlightout, pitglowout, pitglowin

– The Light=FDirect01 object isn’t enabled in the sim but the code line should be left there as it is a code holder
– The **glow objects linked to a NightLight are made with two sided polygons. To have them lit up properly the std face (not the reverse one) should be facing the NightLight position. (ed. Since the glowing mat should be full emissive…this is not unnecessary. It should probably be tagged w/ no lighting as well)
– When you loft a track that has various width I suggest to modify both sides to keep the spline in the center of the track. Doing that will later help texturing as a the white dotted line will follow the centered spline. I didn’t do that for TR and I had to manually adjust the center UVW unwrap vertices.
– Be careful with the mirroring tool in Max. You could end up with reversed faces in the sim but with “normal” normals in Max.
– When modeling an object that will cast shadows make it a full box (don’t remove the bottom faces)
– When texturing a track, I use the unwrap UVW modifier, the Max viewports won’t show the real results you have to render it or see it in the viewer or sim
– Be sure to set the tiling properties to 1 if you need to unwrap UVW some faces because the if the tiling is set to anything else the texture adjustment made in unwrap UVW won’t be applied in the sim.(ed. you can have multiple UVW Unwrap modifiers – one for each map channel you’re using)
– Don’t forget to break the vertices in the Edit UVW windows if you don’t want adjacent faces to be influenced.
– To texture the walls (which are at 90 deg relative to the track, I break the vertices in the Unwrap UVW window, select all the vertices and rotate them 90 deg, then adjust them on the grid)
– Use a low level (sunrise or sunset) to “see” to adjust the bumpmapping of the track surface
– I also did run into a bug when selecting faces with material ID in the Unwrap modifier that didn’t correspond with the material ID in the material editor. I use the wireframe view in the viewport to see which faces I’m selecting and texturing.
– A cylinder with 6 sides (5 isn’t enough) is correctly smoothed by the converter (for use as posts, etc.)
– On my oval test track I tried a topographical object which extended to 7000m outside of the track. To view it (without clipping) in the onboard cameras (TVcockpit, cockpit, etc.) you have to readjust the clip planes to a similar value in the default.cfg file: ClipPlanes=(0.90, 7000.0), in the scn file (View=mainview ClipPlanes=(0.50, 7000.0)) and in the cam file. (ed. it would be better to tag the materials for this object as No ZBuffer, and set No Clip in the instance panel. These clip plane values are going to cause huge z fighting issues)
– When you generate a solid static shadow on an object don’t forget to set the surface receiving the shadow to “receiver”
– Lowering the bitmap scale in the shadow “caster” parameter makes the shadow less precise which can be interesting for trees or objects far away from the track (you can go down to 16 or even 8)
– The specular texture of a fence is a highly contrasted copy of the basic texture.
– To get a transparent effect on fences, etc. use an alpha channel you then have to set the material setting as : Source Blend : Src Alpha, Dest Blend : Inv Src Alpha
– I had many problems with alpha channel transparent objects Z buffer and I had to sometimes revert to transparent chroma color to lessen that problem.
– If you use a chroma color be sure to make the alpha channel of the tga texture completely white (full opaque). The chroma color won’t be transparent if the alpha channel isn’t opaque. (ed. It is a myth that the alpha channel is required for chroma blend. If using chroma blend, use a 24-bit tga or bmp.)
– Unwrap UVW help on walls and fences : Because the track isn’t the same width all-around your walls and fences uvw coordinates aren’t lined up. To lessen the workload I manually input the needed values in the input boxes (lower left) after selecting the vertex in the uvw unwrap editor.
– If you modify a material be sure to reassign the new material to all faces using it in the scene. Having two objects sharing the same original material but not the edited one confuse the sim and will result in strange behavior.
– I’m unable to see in the viewports or in a rendering (though better correlated) the final result of a tiling adjustment for a material so I use UVW unwrap with tiling and offset set to 0.
– If you plan to use DX7 I suggest you don’t assign specular maps as they turn out very bright in the sim if specular color is set grey (128, 128,128) and/or specular power is set to more than 1,0.
– I found that a few objects made in previous version of ISI sims are aligned in Max but show up with strange rotations in rFactor. I followed the following procedure to get them right :

– Affect pivot only/Center to object/Align to object/return to object/set rotation to 0,0,0/scale the object to his original values/rotate to final position
– If you have the measure tools visible you will see the overall dimensions when modifying the object with the scaling tools

– Transforming your transparent textures with magenta (255,0,255) to alpha channels one for rFactor is quite easy in PSP6 (just make sure you don’t have black (0,0,0) pixels that you want to keep):

– With the color replacer tool change all magenta pixels to black
– Select all the texture
– In the Selection menu use the Modify/Transparent color function
– Choose foreground color and save the selection to the alpha channel

– Use the Slice modifier to cleanly cut through objects. First select the faces you want cut.
– Very strange ! When doing the low tension wires, I was unable to “see” them in the sim even after making sure the pivot point was centered and aligned to the object. I had to rotate them 180 deg. and then they were ok.
– When you want to “reset” an object “box” in Max you can use the reset X form modifier in the Utilities
– To generate the fences posts for TR :

– Generate a spline at the bottom of the chain fence polygon. You can do this easily by setting the snap settings to vertex and enabling snap3 toggle this will insure that your spline vertices match the fences vertices.
– Generate a post template (make sure the pivot is “align on object”)
– Use the spacing tool with the follow option on
– Tests until rotation/position of the template post generate the objects at the right place and without inverted faces (I had to flip the normals of the template posts to make it work!)

– I use a fully closed night object (with faces facing the inside) to “fill” all white cracks that may happen between soil/track surfaces at night
– In Max you can select objects from the same material in Material editor utilities menu
– After a few hours of work I finally made the gMotor 2.0 Viewer work for TR :

– Win32Viewer, coreshaders.mas and binkw32.dll in the C:\Program Files\rFactor\GameData\Locations folder
– Select Scene file : 2004_TROISRIV.SCN, 800*600 32 bit windowed, FSAA set to Level 1 Multisample, Special Fx on AUTO
– Root path unused (ed. You’ll need a root path if you’re viewing the same scene file as used in the game unless your viewer is in the rFactor root directory)
– Paths in the 2004_TROISRIV.SCN file :
SearchPath=.
SearchPath=troisriv
SearchPath=troisriv\2004_troisriv
SearchPath=2004_troisriv
//——————————————————-
MASFile=troisriv.MAS
MASFile=troisrivmap.MAS
MASFile=COMMONMAPS.MAS
– Setup2.ini : (ed. Some of this information is irrelevant because it is dependent on your video card.)

VideoDriver=(0)
VideoMode=(79)
VideoRefresh=(60)
WindowMode=(1)
ShaderLevel=(2)
LowDetail=(0)
FSAA=(65536)
VisGroups=(0)
Shadow=(983040)
ApplyAnim=(0)
Ownship=(3)
Mode=(0)
MoveSlow=(8)
MoveFast=(80)
MoveDelay=(2000)
SceneFile=2004_TROISRIV.SCN
SceneDir=C:\PROGRAM FILES\RFACTOR\GAMEDATA\LOCATIONS\TROISRIV\2004_TROISRIV
UseRootDir=(0)
RootDir=
ShaderDir=C:\PROGRAM FILES\RFACTOR\GAMEDATA\LOCATIONS
AnimFile=
AnimDir=
AmbientDawn=(3355468)
DirectDawn=(11717861)
AmbientDay=(5000268)
DirectDay=(16777215)
AmbientDusk=(3355468)
DirectDusk=(8368818)
AmbientNight=(1644825)
DirectNight=(3355443)
AmbientSunny=(3355443)
DirectSunny=(16777215)
AmbientCloudy=(13421772)
DirectCloudy=(1644825)

– Viewer hot keys: (H for Help, which gives you this same list)

– F for Fog on/off
– N for Normals on/off
– B for Objects Bounding boxes on/off
– U for Shadows
– S for Framerate
– L for Omni lights on/off
– R select one object and displays its nb. of vertices ?
– A and Z for Up/Down
– Arrows for movement
– F1 to F6 for lighting transitions

Gilles Benoit
November 2005

 

[MJQT]

Replay format information

ENUMS

enum EventClass
ECLASS_LOC = 0,
ECLASS_VFX,
ECLASS_SFX,
ECLASS_SYS,
ECLASS_COMM,
ECLASS_OTHER,
ECLASS_MAXIMUM

enum EventType
ETYPE_NOTYPE = 63, // doesn’t need to be anything in particular, but this is
the number least likely to be used for a real event type

// ECLASS_LOC events
ETYPE_CONE = 0, // cone state
ETYPE_POST = 1, // post state
ETYPE_SIGN = 2, // sign state
ETYPE_WHEEL = 3, // wheel state
ETYPE_WING = 4, // wing state
ETYPE_PART = 5, // part state
// note: do not change order of the ETYPE_*LOC events!
ETYPE_ZIPUPDATE = 6, // tells server that last zip can be safely extrapolated
ETYPE_ZIPLOC_R = 7, // compressed vehicle loc (more detailed than SIMPLELOC)
ETYPE_ZIPLOC_N = 8, // compressed vehicle loc
ETYPE_ZIPLOC_1 = 9, // compressed vehicle loc
ETYPE_ZIPLOC_2 = 10, // compressed vehicle loc
ETYPE_ZIPLOC_3 = 11, // compressed vehicle loc
ETYPE_ZIPLOC_4 = 12, // compressed vehicle loc
ETYPE_ZIPLOC_5 = 13, // compressed vehicle loc
ETYPE_ZIPLOC_6 = 14, // compressed vehicle loc
ETYPE_ZIPLOC_7 = 15, // compressed vehicle loc
ETYPE_SIMPLELOC_00 = 16, // simplified location event (smaller than ZIPLOC)
ETYPE_SIMPLELOC_01 = 17, // simplified location event
ETYPE_SIMPLELOC_02 = 18, // simplified location event
ETYPE_SIMPLELOC_03 = 19, // simplified location event
ETYPE_SIMPLELOC_04 = 20, // simplified location event
ETYPE_SIMPLELOC_05 = 21, // simplified location event
ETYPE_SIMPLELOC_06 = 22, // simplified location event
ETYPE_SIMPLELOC_07 = 23, // simplified location event
ETYPE_SIMPLELOC_08 = 24, // simplified location event
ETYPE_SIMPLELOC_09 = 25, // simplified location event
ETYPE_SIMPLELOC_10 = 26, // simplified location event
ETYPE_SIMPLELOC_11 = 27, // simplified location event
ETYPE_SIMPLELOC_12 = 28, // simplified location event
ETYPE_SIMPLELOC_13 = 29, // simplified location event
ETYPE_SIMPLELOC_14 = 30, // simplified location event
ETYPE_SIMPLELOC_15 = 31, // simplified location event
ETYPE_SIMPLELOC_16 = 32, // simplified location event
ETYPE_SIMPLELOC_17 = 33, // simplified location event
ETYPE_SIMPLELOC_18 = 34, // simplified location event
ETYPE_SIMPLELOC_19 = 35, // simplified location event
ETYPE_SIMPLELOC_20 = 36, // simplified location event
ETYPE_SIMPLELOC_21 = 37, // simplified location event
ETYPE_SIMPLELOC_22 = 38, // simplified location event
ETYPE_SIMPLELOC_23 = 39, // simplified location event
ETYPE_SIMPLELOC_24 = 40, // simplified location event
ETYPE_SIMPLELOC_25 = 41, // simplified location event
ETYPE_SIMPLELOC_26 = 42, // simplified location event
ETYPE_SIMPLELOC_27 = 43, // simplified location event
ETYPE_SIMPLELOC_28 = 44, // simplified location event
ETYPE_SIMPLELOC_29 = 45, // simplified location event
ETYPE_SIMPLELOC_30 = 46, // simplified location event
ETYPE_SIMPLELOC_31 = 47, // simplified location event
ETYPE_SIMPLELOC_32 = 48, // simplified location event

// ECLASS_VFX events
ETYPE_BACKFIRE = 0, // veh backfire animation
ETYPE_LIGHT = 1, // veh rain light switch
ETYPE_TERRAIN = 2, // terrain conditions event
ETYPE_COPTER = 3, // sends the helicopter on its way
ETYPE_WEATHER = 4, // weather updates from the server
ETYPE_CLOUDMAP = 5, // cloud texture map names
ETYPE_LIGHTNING = 6, // lightning
ETYPE_DENT_BODY = 7, // dent bodywork
ETYPE_RESET_BODY = 8, // reset bodywork (vehicle reset to pits or something)
ETYPE_WALLSKID = 9, // generate skid on wall
ETYPE_RACELIGHTS = 10, // start lights, pit entrance & exit lights, maybe caution lights around track?

// ECLASS_SFX events
ETYPE_VEHSFX_START = 0, // starts a vehicle sound effect
ETYPE_THUNDER = 1, // thunder
ETYPE_PIT_HORN = 2, // pit horn plays when someone enters pits

ECLASS_SYS events

ETYPE_SYNC_NOTIFY = 0, // server sends this to client if client should send a sync request (state change, etc)
ETYPE_PLAYER_READY = 1, // message from client to server requesting verification
ETYPE_PLAYER_VERIFY = 2, // server to client, data verify along with any changes
ETYPE_TRACKTOLOAD = 3, // server to client, new track is being loaded
ETYPE_CHATMSG = 4, // chat message, bi-directional
ETYPE_SCOREBOARD = 5, // score update
ETYPE_CHECKPOINT = 6,
ETYPE_SPEEDCOMP = 7,
ETYPE_NEWSTATIONS = 8, // complete new list of all active flag stations
ETYPE_UPDATESTATIONS = 9, // update flag stations

ETYPE_COUNTDOWN = 10, // start countdown
ETYPE_NEXTPHASE = 11, // move to next phase
ETYPE_SKIPFORMATION = 12, // skip formation lap

ETYPE_YELLOW_FLAG = 13,
ETYPE_STOP_GO = 14, // received stop/go
ETYPE_SERVE_STOP_GO = 15, // served stop/go

ETYPE_DNF = 16, // DNF player
ETYPE_UNDO_DNF = 17, // Undo DNF
ETYPE_DISQUALIFY = 18,
ETYPE_CLIENTKICK = 19, // used to kick client

ETYPE_PIT_BLUE_ON = 20, // pit exit flashing blue
ETYPE_PIT_BLUE_OFF = 21, // pit exit not flashing blue

ETYPE_TRACK_ORDER = 24, // order of vehicles on track (while under yellow
flag)
ETYPE_SAFETY_CAR_ON = 25, // safety car is active
ETYPE_SAFETY_CAR_OFF = 26, // safety car is not active
ETYPE_SAFETY_CAR_LAPS = 27, // set the number of safety car formation laps

ETYPE_NEW_ENGINE = 28, // slot needed new engine during warmup (so send
to back of grid)
ETYPE_QUAL_ORDER = 29, // listing of new qualifying order (used when player

ETYPE_TORDER_ADD = 30, // client -> server msg, if client is added from track order
ETYPE_TORDER_REMOVE = 31, // client -> server msg, if client is removed from
track order
ETYPE_TORDER_TOBACK = 32, // client -> server msg, if client is removed from
track order
ETYPE_TRACK_CLOSED = 33, // server -> client msg, track has been closed for
business
ETYPE_TRACK_OPENED = 34, // server -> client msg, track has been opened for
business
ETYPE_ENTRY_DATA = 35, // client -> server, client is sending entry data
ETYPE_ENTRY_DATA_OK = 36, // server -> client, entry data is ok
ETYPE_ENTRY_DATA_NO = 37, // server -> client, entry data not allowed

ETYPE_DRIVER_CHANGE = 38, // sent from previous driver to new driver
(through server if necessary)
ETYPE_DRIVER_CHANGE_NOTIFY = 39, // sent from previous driver to new
driver (through server if necessary)
ETYPE_PASSENGER_CHANGE = 40, // notifies drivers that a passenger has
joined/left their vehicle
ETYPE_FILE_REQUEST = 41,
ETYPE_FILE_HEADER = 42,
ETYPE_NET_AI_INFO = 43, // server info about one multiplayer AI
ETYPE_NET_AI_REQUEST = 44, // request server info about one or more AIs
ETYPE_NET_RESTART = 45, // restart event or race in multiplayer
ETYPE_CLIENT_VIEW = 46, // what client is looking at (slot or actual position)
for server throttling purposes

ETYPE_VOICE_CHAT_MIXED = 47, // voice chat data thats been mixed by the
server and ready for client consumption
ETYPE_VOICE_CHAT_CLIENT = 48, // voice chat data that the clients are
submitting to the server

// ECLASS_OTHER events
ETYPE_FIX = 0, // fix damage
ETYPE_PITSTATE = 1, // change in pitstate
ETYPE_BASICSCORE = 2, // basic score
ETYPE_BASICSCORECLIENT = 3, // basic score client
ETYPE_SIMULATEINTERNET = 4, // simulate some attributes of the Internet
for network testing purposes
ETYPE_CALLVOTE_NEXTSESSION = 5, // “/callvote nextsession”
ETYPE_CALLVOTE_NEXTEVENT = 6, // “/callvote nextrace”
ETYPE_CALLVOTE_ADDAI = 7, // “/callvote addai”
ETYPE_CALLVOTE_ADD5AI = 8, // “/callvote add5ai”
ETYPE_CALLVOTE_REMOTESERVER = 9, // “/callvote kingme”
ETYPE_CALLVOTE_RESTARTEVENT = 10, // “/callvote restartweekend”
ETYPE_CALLVOTE_RESTARTRACE = 11, // “/callvote restartrace”
ETYPE_VOTE_YES = 12, // “/vote yes”
ETYPE_VOTE_NO = 13, // “/vote no”
ETYPE_VOTEIGNORED_PARTICIPANT = 14, // “Vote ignored: Only active
participants may vote”
ETYPE_VOTEIGNORED_NOVOTE = 15, // “Vote ignored: There is no vote in
progress”
ETYPE_VOTEIGNORED_ONEVOTE = 16, // “Vote ignored: You can only vote
once per issue”
ETYPE_NODE_VOTED_YES = 17, // “%s voted YES to %s:” plus either “%d
more to pass” or “vote PASSED”
ETYPE_NODE_VOTED_NO = 18, // “%s voted NO to %s”
ETYPE_CANNOTCALL_DISABLED = 19, // “Cannot call vote: voting for %s is
disabled”
ETYPE_CANNOTCALL_INPROGRESS = 20, // “Cannot call vote: there is a vote in
progress”
ETYPE_CANNOTCALL_JUSTENDED = 21, // “Cannot call vote: voted just ended
(wait %d seconds)”
ETYPE_CANNOTCALL_PARTICIPANT = 22, // “Cannot call vote: must be server or active participant”
ETYPE_CANNOTCALL_BEFORERACE = 23, // “Cannot call vote: cannot restart race before race starts”
ETYPE_CANNOTCALL_PASTRACE = 24, // “Cannot call vote: cannot advance session past race”
ETYPE_CANNOTCALL_MINVOTERS = 25, // “Cannot call vote: %d voters required”
ETYPE_CANNOTCALL_RACERESTARTS = 26, // “Cannot call vote: no more race restarts allowed”
ETYPE_CANNOTCALL_MOREAI = 27, // “Cannot call vote: no more AIs can be added”
ETYPE_VOTE_PROPOSED = 28, // “\”%s\” proposed by %s:” plus either “%d vote(s) needed to pass” or “vote PASSED”
ETYPE_WITHHOLDING_GREEN = 29, // WITHHOLDING_GREEN_MSG defined in steward.hpp
ETYPE_CANNOTCALL_PLRNOTFOUND = 31, // “Cannot call vote: player specified not found”
ETYPE_ADMIN_MSG = 32, // Some admin message
ETYPE_CANNOTCALL_SPECEVENT = 33, // “Cannot call vote: circuit not found or request disallowed”

enum EventFlag // Event flag

EFLAG_NONE = 0, // no special flags (default)
EFLAG_NO_NETWORK, // do not send across network (i.e. replay only)
EFLAG_HIGH_PRIO, // make sure it’s in the high priority list (but not guaranteed)
EFLAG_GUARANTEE, // guaranteed network event
EFLAG_MAXIMUM

enum FileRequestType

FREQ_PARTIAL=0, //request has full partial path
FREQ_FULLPATH, //request has full path
FREQ_SYMBOLIC //request is a symbol so the server needs to do a table lookup

// Invalid owner definition
#define EOWNER_INVALID (0x0ff)

Event data packets (used for network and playback)


struct ZipLoc, data for compressed body and tire locations

// Used Bits in mInfo1:
// xxxxxxxx xxxxxx00 00000000 00000000 – current RPS (14 bits)
// 00000000 000000×0 00000000 00000000 – in pit lane flag (1 bit)
// 00000000 0000000x xxxx0000 00000000 – throttle (5 bits)
// 00000000 00000000 0000×000 00000000 – brake light flag (1 bit)
// 00000000 00000000 00000×00 00000000 – horn (1 bit)
// 00000000 00000000 000000xx 00000000 – traction control level (2 bits)
// 00000000 00000000 00000000 x0000000 – speed limiter (1 bit)
// 00000000 00000000 00000000 0xxxxxxx – steer yaw (7 bits)

// Used Bits in mInfo2:
// xxxxxxxx 00000000 00000000 00000000 – acceleration (see below)
// 00000000 x0000000 00000000 00000000 –

// 00000000 0x000000 00000000 00000000 – warning light flag
// 00000000 00×00000 00000000 00000000 – driver visible flag
// 00000000 000×0000 00000000 00000000 – head light flag
// 00000000 0000xx00 00000000 00000000 – current driver (2 bits)
// 00000000 000000×0 00000000 00000000 – detachable Part Damage State (DPART_DEBRIS11)
// 00000000 0000000x 00000000 00000000 – detachable Part Damage State (DPART_DEBRIS10)
// 00000000 00000000 x0000000 00000000 – detachable Part Damage State (DPART_DEBRIS9)
// 00000000 00000000 0x000000 00000000 – detachable Part Damage State (DPART_DEBRIS8)
// 00000000 00000000 00×00000 00000000 – detachable Part Damage State (DPART_DEBRIS7)
// 00000000 00000000 000×0000 00000000 – detachable Part Damage State (DPART_DEBRIS6)
// 00000000 00000000 0000×000 00000000 – detachable Part Damage State (DPART_DEBRIS5)
// 00000000 00000000 00000×00 00000000 – detachable Part Damage State (DPART_DEBRIS4)
// 00000000 00000000 000000×0 00000000 – detachable Part Damage State (DPART_DEBRIS3)
// 00000000 00000000 0000000x 00000000 – detachable Part Damage State (DPART_DEBRIS2)
// 00000000 00000000 00000000 x0000000 – detachable Part Damage State (DPART_DEBRIS1)
// 00000000 00000000 00000000 0x000000 – detachable Part Damage State (DPART_DEBRIS0)
// 00000000 00000000 00000000 00×00000 – detachable Part Damage State (DPART_RWING)
// 00000000 00000000 00000000 000×0000 – detachable Part Damage State (DPART_FWING)
// 00000000 00000000 00000000 0000×000 – detachable Part Damage State (DPART_RR)
// 00000000 00000000 00000000 00000×00 – detachable Part Damage State (DPART_RL)
// 00000000 00000000 00000000 000000×0 – detachable Part Damage State (DPART_FR)
// 00000000 00000000 00000000 0000000x – detachable Part Damage State (DPART_FL)

Event Class

ZipLoc zip; // normal positional event
SimpleLoc loc; // extremely simplified positional event
LooseObjectEvent looseobject;
TerrainEvent terr;
DentEvent dent;
WallSkidEvent wallskid;
VFXEvent vfx;
VFXEventX xvfx;
TinyEvent tiny;
ParticleEvent particle;
SFXEvent sfx;
SysEvent sys;
SyncNotify syncNotify;
SyncEvent sync;
ChatMessage chat;
WeatherEvent weather;
TrackEvent track;
CountdownEvent countdown;
NextPhaseEvent nextphase;
ScoreEvent score;
TrackOrderEvent trackOrder;
StationEvent station;
SpdCmpEvent spdcmp;
CPointEvent cpoint;
SignPostEvent signpost;
PingEvent ping;
BeginEvent begin;
AddPlayerEvent addPlayer;
KickUserEvent kick;
PlayerVerifyData verify;
ClientEntryData entryData;
YellowFlagEvent yellow;
DriverChangeEvent newDriver;
DriverChangeNotify nextDriver;
PassengerChangeEvent passengerChange;
BasicScore basicScore;
BasicScoreClient basicScoreClient;
FileRequest fileRequest;
FileHeader fileHeader;
MultiplayerAI mAI;
MultiplayerAIRequest mAIRequest;
ClientView mClientView;
RaceLightEvent mRaceLight;
SimulateInternet mInternet; // just a debugging tool
VoiceEvent mVoice;

Fast inline functions to retrieve header information
EventClass GetClass() const { return (EventClass) ( mPack >> 29 ); }
EventFlag GetFlag() const { return (EventFlag) ((mPack >> 27) & 0x03 ); }
GameSession GetSession() const { return (GameSession)((mPack >> 24) & 0x07 ); }
EventType GetType() const { return (EventType) ((mPack >> 18) & 0x03f ); }
long GetSize() const { return ((mPack >> 8 ) & 0x03ff); }
long GetOwner() const { return ( mPack & 0x0ff ); }
float GetTime() const { return ( mTime ); }
Struct ReplayParticipant , used to track participants throughout the course of a race.

basic participant information
unsigned char mSlot; // participant slot
char mName1[32]; // name of primary driver
char mName2[32]; // name of co-driver if any
char mVehFile[32]; // name of the participants vehicle file
char mSkinFile[32]; // name of the participants vehicle skin
unsigned char mUpgradePack[8]; // packed upgrade list
float mEntryTime; // game ET of participants first appearance
float mExitTime; // when participant leaves this slot

 

[MJQT]

Q&A with Pete Knepley
From 06.22.05
By John Bayley – Product Development…

Unlike single player games, games with robust multiplayer capabilities often last and grow well beyond their shelf life. With that in mind I had some questions for Pete Knepley about the multiplayer aspect of rFactor.

I’m told you trashed the way Matchmaking was done in the past and decided to start over. Can you give some reasons why and what the experience was like?

Previously we used a commercial internet matchmaking service. However to get control over the process and be in a position to support it long term, we decided to build one.

rFactor is built to last. People still play SCGT and F1C, they will still be playing rFactor for years, I want them to be able to have internet matchmaking forever. The matchmaker used by rFactor can be easily changed in the configuration files. This allows for the opportunity to move, enhance or possibly duplicate the match matching service. ISI will be running a matchmaker when the game is released just like we did for the MP test.

My solution to matchmaking was to write a lightweight application that could be easily deployed. It runs the server listings and friends listings with minimal processor, memory and bandwidth usage. It also uses minimal platform dependant code so that it can be simply ported to future machines. The development of this was not easy for me. In my previous game programming experiences, I did a little bit of socket programming, but this project was a bit different. This was a hardcore multithreaded server app that is the cornerstone to internet play for possibly thousands of players at once. It took several prototypes and a couple full rewrites to get it production quality.

You have had a chance to see progress of the multiplayer code. What is your assessment of it?

The multiplayer code is very good in my opinion. It is the vanilla client and server model that has been around for years, but I think it is the best way to run racing games and allows for server-side processing protections. rFactor does a lot of verifications to ensure that the racing is fair that would not be as trustable with a different model.

The new throttling code provides good scalability. You receive the most information about the cars that are close to you so door rubbing is possible, while you can still have 40+ cars on the track.

The code also now allows for banning users. The ban list is an xml file that can be shared among server admins to keep the chronic wreckers from bothering their users.

My favorite feature is the join lag elimination. Since rFactor lets you join a game while people are driving, there is a potential for a new car loading to slow down your computer. In rFactor, temporary assets are loaded from a cache when players join and you are out racing, but when you go back to the pits, the full versions are loaded. Your turns will not be disturbed at all and you barely notice anyone joining and leaving.

You added IRC and a buddy list. How does this work?

I added support for using Internet Relay Chat (IRC) into the game lobby. IRC has been around basically since the internet as we know it existed. It has been refined and expanded since then and provides a feature-rich place to meet and discuss in realtime. The IRC client inside rFactor right now defaults to join #rFactor on EFnet, but can be set to join any network and any channel the player wants. The client supports most of the features of the popular mIRC client for windows, although it is constrained to one channel at a time. I think players will find that IRC is a good tool to communicate with other sim racers while having a somewhat controlled environment. IRC allows for instant channel kicks and bans for those who chose to try to ruin others good times.

The buddy list is another cool thing I implemented. When turned on, a player can tell the matchmaker which server they are currently racing on. Then their friends can query the matchmaker with a list of players to check which ones are online and which servers they are racing on. Its completely voluntary, but I think it will greatly reduce the amount of time you waste searching the server browser and get you on a server with your racing friends much faster.

Voice over IP. How important is this?

The voice chat in rFactor should be very useful. It will keep you from having to pull over just to type a quick message to a friend. Since you don’t have to read any text, it will also keep your eyes on the road at all times. Voice chat is a relatively new and complicated feature so it still has a few quirks, but the system should be stable enough for inclusion with the first release.

There is code in place for transferring files around from within the game. How does this work and where is it at right now?

There is code that allows for in-game missing asset downloading. I’ve been able to download missing tracks, car skins, cars and helmets while I’m playing LAN games.

It will probably not be in the first release since all the details have not been worked out with regards to mods and updates. It also enlarges the attack surface for downloading of unwanted files or the transfer of files that you did not wish to transfer.

The file transfer code that will be included in rFactor is HTTP download code. This code allows us to interface with websites and download updates from them. The server browser can now be notified of updates to rFactor by means of rFactor.net. It will also let us make dynamic user interface components with content from the internet.

What was the purpose of the Multiplayer demo that was released earlier this year?

The MP demo was released so that we could stress test our new multiplayer layer and the new matchmaker.

The stress test immediately showed oversights in the design of the matchmaker. I was able to create a quick fix just to the matchmaker dll for rFactor and upload it to retest it. The matchmaker itself also had a bug or two that I was able to remedy. So after a couple small fixes, the matchmaker proved itself a worthy replacement.

We were also able to analyze a lot of traffic from the new network layer. This helped us optimize it and reduce the amount of bandwidth needed to play the game.

 

[MJQT]

Q&A with Joe Campana
From 09.18.04
By John Bayley – Product Development…

So much of rFactor seems to be built around a number of new technologies. One important new technology is most certainly its graphics engine, gMotor2. Not only was I curious about its capabilities and features, but also what this could mean to modders. The driving force behind gMotor2 is Joe Campana.

What can you tell us about the gMotor2 graphics engine used in rFactor?

gMotor2 is our DX9 engine, all new and making its debut in rFactor. It took me almost a year of non-stop typing. There is support for a wide range of video hardware, from fixed function DX7 to shader-based Dx8/Dx9 GPUs. Some of the gM2 features you’ll see in rFactor are lots of dynamic shadows, active lighting for accurate time-of-day, and night driving with dynamic track lights and real headlights.

Tell us more about the time-of-day feature.

The time-of-day feature means that you can setup your race session to start at any time of day or night, and time marches forward from that point, in real-time or at an accelerated rate if you want to speed through the day-night and night-day transitions. As time progresses, you’ll see accurate changes in lighting, shadows, and skies. Circuit builders will even be able to include latitude/longitude and date information into the track description for complete real-world accuracy.

Night driving?

As the day gets later, the sun will set, shadows grow longer, and at some point the track lights will come on. The driver can turn on headlights when it gets too dark, the AI drivers will do this too. If you drive through the night, things will start to brighten up as the sun rises, shadows shorten up, and eventually the track lights turn off. Again, this can all happen at an accelerated rate so you don’t have to drive for 12 hours to see the effects (unless you want to).

This sounds pretty CPU intensive. Does this limit the number of polygons used in cars and tracks?

Not really. Modders should of course use as few triangles as possible for tracks and cars, but the real limits are video memory. A mod which requires 200 MB of video RAM will run fine on a card with that much memory, but won’t run on cards with less RAM. Creation of complete LOD chains, particularly for car models, is critical for mods meant to run across a wide range of hardware.

I’ve worked on some mods myself in the past for your previous products. Can I convert or reuse them?

rFactor supports gMotor2-format assets only. We really encourage modders to work from original source assets, and use our tools (or tools created from the Export SDK) to create gMotor2 assets. Previously created assets will probably produce less then optimal results.

How do you think this engine compares to your previous efforts, and to others that are currently available?

It’s been a long time since I’ve been able to make this kind of foundation change, so I’ve been able to incorporate lots of new concepts and technology into the engine. The raw engine itself is amazingly fast, but making a real game engine is also about providing tools to asset builders, and exposing technology to game designers while keeping things accessible to mod makers. So compromises are necessary to make their world better, but even so, this engine is our best yet, and only getting better.

Well, from what I’ve seen so far, it’s more than doing the job, and quite impressively…

 

[MJQT]

Q&A with Brad Shuber
From 08.27.04
By John Bayley – Product Development…

It would seem the majority of our email lately indicates that there are a lot of people out there excited about, and wondering how we arrived at (or returned to) ‘mixed class racing’, the rF modeling process, and how all this will apply to those wanting to create MOD’s for rF. If we’re going to talk vehicles, tracks, or any form of modeling, Brad is definitely the go-to guy.

Why choose mixed class road racing as the first product for rF?

Mixed class road racing was not a difficult decision for us. We have all been in love with that form of racing ever since we worked on Sports Car GT released back in 1999. It was inevitable that we would some day get back to this form of racing sim and we could not be happier then to be returning to it with rFactor.

One of the most exciting aspects to the mixed class racing appears in Multiplayer. Not only can you enter the race with whatever vehicle you choose, but you can also set up which vehicles the AI will drive. So you can set up a race with the diversity of all the vehicles you have installed or just a very specific subset thru our filtering system. This has been really fun for us here at ISI as we can easily add competitive AI or just a few back markers with slower vehicles.

What is the development process for making vehicles and tracks in rF?

Creating the assets of rFactor is somewhat different than previous products . Since we are designing all the vehicles and tracks from scratch we spend less time researching the specific details in every centimeter of the tracks or vehicles and more time testing them to make sure they feel realistic and are both fun and challenging.

Most of the early work that goes into the tracks is making sure it feels right. We test the tracks exhaustively to ensure the vehicle handles well over the bumps, thru the turns, gets up to just the right speeds, and performs in the way you would expect from what you see if front of you. We have spent allot of time adding in bumps, banking, elevation, and even some hazards to the track surface. Once we are happy with the road surface we move on to the outside geometry. We feel this is sometimes just as important. Allot of drama can be added to a turn or suspense in the straights by what is surrounding the track. In most cases the turns are not as difficult as they first look or feel. Most of this visual deception is due to the placement of walls, trees, and other objects. It is really important to us to use all parts of the track to give the racer the most intense experience we can.

As for the vehicles, we start out by designing it so that it fits the type of vehicle we need next. In the beginning, we create spline models of the vehicle. These are later use for shading. We tweak them for size and shape, and then divide them up for parts and upgrades.

What would you say to those people out there interested in modeling circuits for your sim?

Dive in! The technology in rFactor is the best that we have ever had a chance to work with. It opens up new possibilities and allows us to flex our creativity. Although with the power comes added complexity. The new pixel shaders and lighting means all new options to wrestle with, but the results you can achieve are well worth it. I think that modeling in rFactor is a large leap forward for the mod community and we are very excited about this aspect.

 

[MJQT]

Q&A with Terence Groening
From 08.13.04
By John Bayley – Product Development…

Being a little hungry lately for more specific info on some of rF’s new technology, I figured it was time to hunt down someone who had good knowledge about not only rF’s technology, but technology used by ISI in the past. I knew just the right brain to pick for this one, so I managed to corner Terence long enough to pop a few questions…

What new technology appears in rFactor?

Well, I’m going to let our resident eye-popper, Mr. Joseph Campana, cover the graphics technology in another thread. But I can tell you a bit about the rest of the application.

We’ve put in alot of work revamping the modding system. This includes new ways to define whole games and seasons, a variety of rules to emulate different race series, plus an ability to download mods from a server.

There is a completely new replay system that allows easier editing, special video and audio effects, plus the creation of AVIs from within the game. We are very excited about this feature which I think our fans have been patiently waiting for.

Another key technology has been the development of our multiplayer system which includes a dedicated server. Not only have we improved the more important aspects such as prediction, but we’ve also managed to eliminate some of the most common complaints about our previous games. There are some other interesting features which will reveal themselves in due time.

Of course we are always working on AI and physics. The AI in rFactor are more life-like than ever, and I’ve been personally surprised by some of the dicing required to get by these clever suckers.

Is the physics engine all new for rFactor?

There are some new components to the physics engine, but our main focus has been to realize the full potential of the driving experience. We wanted to improve the sense of speed, and have the user feel the bumps in the road and the air rushing by. We accomplished this by developing several areas, from audio to camera work to the physics themselves. I think that people will find that we’ve polished this technology and taken care of some of the oddities experienced in previous products.

Where do you get the data you need to accurately represent the wide range of vehicles modeled in Image Space products?

From SCGT through our Formula One and NASCAR products, we have had contact with many insiders who shared varying amounts of data with us. Some of these contacts were established by contract with our publisher, while others volunteered information after playing our other simulations. While it was often difficult to obtain certain proprietary data, we would fill in the gaps through research and experimentation. Feedback from certain knowledgeable users was also very beneficial, so we really owe a thank you to the racing sim community for helping us along the way.

What makes rF fun to drive?

Well, first off I don’t think you should take my word for it … please give it a spin! But in my opinion, this game is very fun to drive.

Each car requires its own technique to push its envelope. Some cars are easy to over-drive, which may look cool but wastes time and punishes tires. I hope that our fans will enjoy some of the same wheel-to-wheel racing that we’ve seen in testing.

 

[MJQT]

Q&A with Gjon Camaj
From 08.10.04
By John Bayley – Product Development…

Having been knee deep in designing tools and mods for a number of ISI racing sims since 1999, when the chance to work on ISI’s latest leap in racing sim technology came along, well, who wouldn’t jump in. Enter, rFactor. If you think you’ve seen it all when it comes to racing sims, then you’re in for a pleasant surprise.

One of the first things that struck me about rFactor was the SCGT (Sports Car GT) type concept. A game with solid physics, mod-ability, and that immersion factor which makes it hard to pull yourself away from the game. However, with the new technology in rFactor, the comparison pretty much ends there. I’m not talking about technology you just read about in some tech doc (which is all fine and dandy), this is technology that kicks the human senses into high gear the moment you get behind the wheel and head out of the pits.

Over the next few weeks I’ll try and cover all aspects of rF through a series of interviews with the dev team, and no better place to start than with Gjon Camaj….

What is rFactor all about?

rF is the game we want to play. It is being designed in such a way so that we and the community can continuously develop and refine it. rF is a serious simulation that is both challenging and fun to play. The initial installment will feature mixed class road racing, something we have always enjoyed. Future installments will include not only additional vehicles, circuits, new features, and refinements, but also new types of racing.

Why rFactor instead of continuing some of ISI’s other product lines?

rF provides us the freedom to do what we enjoy most and be the best at it. This new start was a much needed opportunity to clean out some closets and lay new foundation stones.

rF will also allow us to work even more closely with the racing sim community, something we’ve always enjoyed doing in the past. It will be the most mod-able game to date that has come out of ISI.

I have always considered our products to be very well architected. With rF we’ve pushed this even further. We’ve incorporated our many years of commercial and military simulation experience along with the lessons we learned putting out AAA entertainment titles year after year. I’m extremely proud of what is brewing in the lab.

What makes the community around your products so important?

Over the past ten years, I’ve had the opportunity to meet allot of people interested in racing simulations. Some were complementary of our products, others were very critical, and a few have become very good friends. But one thing they all had in common that really impressed me was a passion, intelligence and commitment to making the field of computer generated racing simulations better than it was before.

Unfortunately over the past few years, I noticed a push to cater to everyone but this person. We hope to reverse this trend.

How do you plan to compete with blockbuster games out there?

We don’t. Our goal has never been to be the exclusive maker of racing games. I’m pretty sure that would be a bad thing in the long run.

What does the future have in store for rFactor?

We are currently in discussion with organizations, manufactures and teams about bringing their type of racing to rF. Ultimately, I expect to see every car, of every paint scheme, from every year driving on every circuit both current and historical, which has ever held an event where an internal combustion engine was used to decide the winner of a race.

What is it like working on such an ambitious project?

Our nose is pretty close to canvas right now so to be honest, it’s a huge mess. It’s also a work of art. Many of the concepts that I once was only able to toy with are now becoming a reality and it’s a beautiful thing.

We understand we are not able to fully realize all of our goals with the initial release. But we have laid the foundation that will allow us to meet these goals. We also feel we created a development environment from which the community can use as a springboard to create things we haven’t even dreamed of.

 

[Finno Zidjian]

MJQT, Man, thank you, thank you very much(!!), for these amazing posts with the testimonials of these geniuses!!! I've recently been familiar with RF, but since the language is identical to F1C, which I'm widely familiar with, I'm adapting easily to the game and I'm still unraveling things that are typical of RF. One of the most amazing things I understood, finally, was the question of the dates and positions of each track, latitude and NorthDirection, next to the GDB... I thought the data was there only as a reference, without a practical application and after reading the post, I could understand that it is real!! I even experimented using Google Earth as a proof reference and, in fact, the sky, the light, the time of sunset, the shadows, all according to the season of the place!!! Really amazing!! I'm studying all the information a lot like a bible!!! Hahaha... Anyway, I could not go through here and not thank you for the excellent content, once again, thank you very much!

Greetings

 

[Finno Zidjian]

Oh yes, enjoying the passage... Of course, I still have some (many) doubts about some behaviors of the game and one of them is in the matter of the shadows of the cars that disappear from several cars at sunset (fig. Shadow X noshadow)... would it be because I don't have a good video card? My system holds up well and the game develops without any problem, without lag and etc. I use all the settings to the maximum and even in the cameras (cockpit I use 3.5) and in the main view of the SCN I get to put 10000 and even above said and I have no problem ... but could it be the exaggeration of the data I use that would generate this problem? Anyway, if you have any tips I appreciate it.
Thank you again!

 

[MJQT]

one of them is in the matter of the shadows of the cars that disappear from several cars at sunset (fig. Shadow X noshadow)... would it be because I don't have a good video card? My system holds up well and the game develops without any problem, without lag and etc. I use all the settings to the maximum and even in the cameras (cockpit I use 3.5) and in the main view of the SCN I get to put 10000 and even above said and I have no problem ... but could it be the exaggeration of the data I use that would generate this problem? Anyway, if you have any tips I appreciate it.

I suspect it's simply an issue with the particular car mod you're using... but I'm not really sure. It would be better to start a separate dedicated thread for this in the forum, instead of tacking it on to this thread. More likely to get answers from people and easier to find for others searching for help in the future.