Ideas for plugin

M

MaXyM

Registered
I know, there is the subforum for posting ideas.
I have chosen to post here because I'm sure it's better place to keep programming-related things tracked.

So, let's start.


1. possibility to send chat messages from plugin (on public and private ones). Consider to allow it only on a server to avoid possibility of flooding
2. possibility to execute commands (control sessions, users, grids, weights, kick). Again, only for server.
3. Allow to control dedicated server from plugin (change sessions, track, set event params etc).
4. Provide more info:
- driver's current ping
- name of mod

Best regards
 
Yes, yes, yes, yes, yes! :p

For the local player, I hope this

Code: 
struct EnvironmentInfoV01
{
  // TEMPORARY buffers (you should copy them if needed for later use) containing various paths that may be needed.  Each of these
  // could be relative ("UserData\") or full ("C:\BlahBlah\rFactorProduct\UserData\").
  // mPath[ 0 ] points to the UserData directory.
  // mPath[ 1 ] points to the CustomPluginOptions.ini filename.
  // (in the future, we may add paths for the current garage setup, fully upgraded physics files, etc., any other requests?)
  char *mPath[ 16 ];
  unsigned char mExpansion[256];   // future use
};

is utilised further. I'm pretty sure I've seen an engine file sitting somewhere that is likely the last engine spec used, if this is expanded to include a current setup file, AIW file, maybe HDV and others, that would be very useful since we can't easily traverse the relevant folders with everything stuck inside MASes.

(actually setup and engine currently produce files from what I can see, and they're not that hard to find with code, but why not make it easier? :))

For ScoringInfo (so, for remote players, especially on a dedi) pretty much the same goal - in rF1 we can use the vehicle class and 'name' (actually the 'AI' driver name for that vehicle) to cross reference vehicle files and work out which mod is being used (by checking all the .rfm files for matching classes...), again this isn't possible in rF2 so being able to directly retrieve a bit more info about all vehicles would be very good (and as MaXym has suggested, the current mod name would be a good start). Since the list of present drivers will obviously be more dynamic than vehicle or setup parameters this is more suited to having relevant data available rather than a pointer to a temp file. Having most of the old .veh stuff would probably be enough for server purposes.
 
Another ideas/requests

Weather control
- access to weather data, even future one, would make possible to provide kind of forecast
- setting wather - for setting weathe based on some external sources
 
Team Name - make possible to output driver's team name.

Team name is assigned to specific car (veh file), so it might be starting point. I think would be fine to implement some possibility to set team name independently to what is set in mod. It might be set for each mod separately. But those are some ideas. Reporting Team Name to plugin is a key for live view systems.
 
How much it is possible to make inputs via plugin?

Now rFactor supports 9 gears and we have shifters that support 6 gears, would it be possible to create a plugin that would remap shifter for first six or last 3 gears via pressing a mappable button of controller?

Other gearbox related plugin would be one that plays with clutch to get behavior of old TH400R4 or similar automatic transmission. With rF1 this was however not possible, that is what author of Grinding Tranny mod told me, so maybe it would be possible in rF2?

It would widen range of vehicles that could be then possible to create virtually, of course if ISI would implement features directly to code would be really great, but maybe there is not much demand for such so their time might cost more than benefit the sim, hobbyist could perhaps then do a plugin that would do the job.
 
Team boss/pitwall plugin + remote control client that enables changes to car pit menu remotely from another computer.
Communication between remote control application and car need to be verified by two way key (password) exchange.

If possible it would also be nice to send a limited amount of logged car data to the client as well.

Someone started a project like this for rFactor but abandoned it.
 
I played around with it for a bit but struggled with changing the pit items because it works with left / right / up / down rather than absolute setting of the items. The plug in API needs extending a little to make a "race engineer" workable.
 
For recovering a server after a total system failure during an endurance race, the "/changelaps <laps> <name> as /admin /server and if possible maybe new as /plugin command to adjust the number of completed laps (-10 to +10)" in chunks is really a pain in the keister. Would be nice if an admin is able to just enter: "/changelaps +236 Player Name".

And as already stated, a "Team Name" for a vehicle provided by the UpdateScoring function is somehow a must have ;o)

Thanx
Frank
 
Something Like Source TV so we can have a moveable camera that can stream while the race is running so it would be possible to commentate and stream live race events

I have no idea if this is possible but if yo do not ask then you will defiantly not get
 
Dany Mitchel said:
Something Like Source TV so we can have a moveable camera that can stream while the race is running so it would be possible to commentate and stream live race events

I have no idea if this is possible but if yo do not ask then you will defiantly not get
Click to expand...

I 3rd this Idea would love to see top 5 or top10 random camera cycle going on... maybe detect contact as it happen and cut to that camera to see the action... 10-15sec delay would be cool... That's all I got
 
What's missing for me in the plugin info is the following:
- game name
- mod name
- boolean to check whether the server is passworded or not
- external IP and used port
- message of the day
- having the PhysicsOptionsV01 working for dedicated servers

And ideally getting these values at Startup() of the plugin instead of through the UpdateScoring() only, as UpdateScoring() isn't called when the option "Pause While Zero Players" is put to '1' in the multiplayer.ini.

Extracting these from the files is not really reliable nor convenient to do, especially if the same game installation and in-game profile is used for all dedicated servers running on the same machine.

Plus the rFactor executables seem to be using ASLR now, which is a good thing to help preventing memory cheats (although I don't think it works under Windows XP and you can quite easily switch it off using a Microsoft tool), but it also prevents reading values directly from the memory through the plugin. It would be annoying to force all users of the plugin to switch ASLR off, and having the plugin calculate the base address of ASLR to find the exact memory addresses is not ideal either.

So if this can be added to the plugin it would be great to avoid these workarounds :)
 
Last edited by a moderator:
Started on getting the info directly from the memory. It's quite easy actually, since the retrieval is done through the plugin you can find the ASLR base address using the GetModuleHandle function call and then add it to the memory offset of each value you want to retrieve.

So far I found:
Traction Control, AntiLock, Stability Control, Auto Shift, Steering, Braking, Auto Clutch, Invulnerability, Auto Pitstop, Opposite Lock, Spin Recovery, AI Toggle, Damage Multiplier, AI Strength, Flag Rules, Fuel Usage, Tire Usage, Mech Failures, Practice Time, Qualify Time, Qualify Laps, Warmup Time, Race Laps, Race Time, Race Length (criteria), Weather Type, Race Time Scale, Race Start Type, Max Drivers, Race Start Time, WAN Join Port, WAN Query Port.

Unfortunately I cannot retrieve the game name, mod name, event name, password nor message of the day from the memory. These all have dynamic addresses, so they change every time the server is launched. Instead I found them by matching the process ID of the dedicated window against the ID retrieved from the plugin (as there might multiple servers running) and then retrieving it from the GUI.

The problem with reading the memory is that every .exe update all these addresses are most likely to change, which means the plugin won't work anymore and you have to find all the correct addresses again. Although there won't be 10 patches once the game goes final (I hope), it's still a bit of a nuisance. Would be so much easier to have all this info directly through the plugin.

Alternatively to reading the memory to retrieve all the info above, they could be retrieved from the GUI as well (except for the used ports). This avoids the .exe patch issues, as well as potential issues with custom .exes (I saw some floating around for rFactor, not sure what they modified in them though). The only downside I can see is that you could have another plugin that directly manipulates the memory to set game options (#3 from MaXyM's first post) and the GUI won't reflect these changes till the next manual server relaunch, causing a desynchronisation between the GUI and the internal game values. You never know what other plugins are installed and what they are doing. Plus the plugin system might be updated to allow this manipulation for dedicated servers directly, such as using the SetPhysicsOptions function.

Note that all the retrieval of the values is done through the UpdateScoring method, so it will only work as long as the session is running.

Using the GUI is also a way to execute commands from the plugin (#2 from MaXyM's post), such as typing a server chat message, going to the next session or editing the grid. I'm sure this method is being used already by other plugins. We could write some functions and make them public on this forum, like NextSession(), GoToNextRace(), RestartWeekend(), SendChat() etc. so all can use them. Not sure what would happen if multiple plugins would do that at the same time though, you might get unpredictable behavior with session switches and weekend restarts without knowing which plugin does what :). If someone would want the part on how to fetch the data from the GUI or to push the GUI buttons I'd be happy to share to kickoff the idea above. Otherwise there are probably also plenty of examples to find on google, it's not really hard to do.

I prefer not sharing the code of the memory retrieval as it would make the creation of a cheat plugin ridiculously easy. (Then again, everyone who can program can make it as well and those who can't program probably wouldn't be able to adjust the code. Still, perhaps better to be safe than sorry :))

As for Frank Geyer's idea of "/changelaps +236 Player Name", this might be possible to do as well but it would be a bit complicated. If the plugin were to parse the chats of the game chat (retrieved through the GUI), then scan the memory to find the player name and use an offset to find the memory location of the number of laps, it could manipulate this value. Not sure how feasible this is, as you have to check both whether the chat is done by the server (or more difficult: done by the admin in-game), then scan through the memory to find the correct string and hopefully have a fixed offset for the number of laps address. Sounds like fun to try it out, but again it would be much easier if ISI provides this functionality directly instead of 'hacking' it in a plugin.

Sorry for the long post, just talking out loud to share ideas.
 
Some of data you may get from PLR file then dig into a bit deeper for rfm files etc. That's how I've done it in my SLS LiveView
 
That's how I used to do it, but a problem occurs when using the same profile for more than one dedicated server simultaneously: when launching the second server it overwrites the info from the first server in the PLR and multiplayer.ini files.

It's not reliable unless the host takes care about this issue and uses only one profile per server.
 
You must log in or register to reply here.
Back
Top