I love the technical details. I like the insight to a world that I'm not interacting with yet. Exposing myself to the nitty-gritty is massively useful from an intellectual point of view as should you see it again, then you now have a frame of refrence to go back too.
Don't forget that quite a lot of us are programmers ourselves, so we have the technical experience to understand the scope of what you are dealing with. Don't be afraid of losing us.
I have some quiet optimism, emphasis on quiet.
[DEV Chat] PRISM Modules & Drivers
So, I'm doing some restructing of PRISM's modules. That goal of this restructuring is that we make LFS's modules act as a 'Driver' that allows for communications between LFS's InSim interface and PRISM. Then I'd like to make HTTP, WebSockets, Telnet and SSH a driver as well. This takes the colors of the rainbow, and focuses them into a single white beam (a packet stream) that all "userland developers" can use. I'm just trying to come up with a simple interface for that, and a folder structure that makes sense.
Currently, I'm thinking that each driver should be it's own subdirectory within the modules directory. Or should it be that there is a driver top level directory within PRISM's directory and we use that for all of the different drivers we intend on supporting. Then more general modules go into the modules directory, in this case admins would be a general module, as well as the INI handler. Then we can expand on that so that plugins that use LFS' driver can simply add use a trait to get access to their packet information.
Then we have to think about a common interface for PRISM into it's drivers. The most common way that Victor handled that was to use initialise(), getSelectableSockets() & checkTraffic(). We would make a module for the drivers, and make these required functions to implement.
I hope this will make for clearer code, while allowing the programming with this dev team, and programmers within the "userland" to be able to use PRISM in a more concise manner. As such, I'm shooting for PHP 5.6.0 to be a REQUIREMENT for PRISM 0.5.0. All devs should start testing PRISM with PHP 5.6.0-Alpha1 as soon as possible. There are many great things to be seen in 5.5.0, and now 5.6.0.
Currently, I'm thinking that each driver should be it's own subdirectory within the modules directory. Or should it be that there is a driver top level directory within PRISM's directory and we use that for all of the different drivers we intend on supporting. Then more general modules go into the modules directory, in this case admins would be a general module, as well as the INI handler. Then we can expand on that so that plugins that use LFS' driver can simply add use a trait to get access to their packet information.
Then we have to think about a common interface for PRISM into it's drivers. The most common way that Victor handled that was to use initialise(), getSelectableSockets() & checkTraffic(). We would make a module for the drivers, and make these required functions to implement.
I hope this will make for clearer code, while allowing the programming with this dev team, and programmers within the "userland" to be able to use PRISM in a more concise manner. As such, I'm shooting for PHP 5.6.0 to be a REQUIREMENT for PRISM 0.5.0. All devs should start testing PRISM with PHP 5.6.0-Alpha1 as soon as possible. There are many great things to be seen in 5.5.0, and now 5.6.0.
Can anyone report if they are still having issues with the client / player state information?
But that would be a lie. Do you really want to lose a race because the game engine took a guess. I guess you could make the argument that everything is a lie.
- Yes, you have total access to the InSim interface.
- Yes, you have total access to the InSim interface.
<?php
php
class pitInfo extends Plugins
{
const URL = 'https://www.lfsforum.net/viewthread.php?p=1843616';
const NAME = 'Pit Information';
const AUTHOR = 'Your Name Here';
const VERSION = '0.1.0';
const DESCRIPTION = 'Pit Info Example Plugin';
public $enumTyres = array(
TYRE_R1 => 'R1',
TYRE_R2 => 'R2',
TYRE_R3 => 'R3',
TYRE_R4 => 'R4',
TYRE_ROAD_SUPER => 'Road Super',
TYRE_ROAD_NORMAL => 'Road Normal',
TYRE_HYBRID => 'Hybrid',
TYRE_KNOBBLY => 'Knobbly'
);
public $playersTyres = array();
public function __construct()
{
$this->registerPacket('onNewPlayer', ISP_NPL);
$this->registerPacket('onPitEntry', ISP_PLA);
$this->registerPacket('onPit', ISP_PIT);
$this->registerPacket('onPitExit', ISP_PSF);
}
public function onNewPlayer(IS_NPL $NPL)
{
$this->playersTyres[$NPL->PLID] = $NPL->Tyres;
}
public function onPitEntry(IS_PLA $PLA)
{
print_r($PLA);
}
public function onPit(IS_PIT $PIT)
{
# Get Player Name
$PName = $this->getPlayerByPLID($PIT->PLID)->PName;
# Old Tyres
$oLF = $this->enumTyres[$this->playersTyres[$PIT->PLID][0]];
$oRF = $this->enumTyres[$this->playersTyres[$PIT->PLID][1]];
$oLR = $this->enumTyres[$this->playersTyres[$PIT->PLID][2]];
$oRR = $this->enumTyres[$this->playersTyres[$PIT->PLID][3]];
# New Tyres
$nLF = $this->enumTyres[$PIT->Tyres[0]];
$nRF = $this->enumTyres[$PIT->Tyres[1]];
$nLR = $this->enumTyres[$PIT->Tyres[2]];
$nRR = $this->enumTyres[$PIT->Tyres[3]];
# Print Output To Console
console("{$PName} Changed Tyres To: {$nLF}, {$nRF}, {$nLR}, & {$nRR}; From: {$oLF}, {$oRF}, {$oLR}, & {$oRR}.");
}
public function onPitExit(IS_PSF $PSF)
{
print_r($PSF);
}
}
?>
Lol, we live we learn. I kinda like that you put them all in this thread for their patch level. That's kinda nice.
I perfer to do 0.4.5.1 and then 0.4.5.2 as apposed to 0.4.5a, 0.4.5b. PRISM follows PHP's number scheme and the version number should be able to be parsed by version_compare.
Congrats on your first release T3!
Ok, once I get the pull request I should be ready to test it. In the next 24 hours right?
I'm going to give it 24 hours, then T3, if you'd like can you please setup for a PRISM 0.4.5 release. There are a number of enhancements that should be released to everyone.
Agreed!
Also the DLL does not just work by it's self, I'm pretty sure, you need the framework around it.
Does that mean that you're teaching it your driving style? What would happen if you put it on with the WR Replay?
Take out everything you don't want and make a plugin for LFSLapper / PRISM, etc..
Is the AI driver driving or is it just predicting where the car should go. As far as path's go, would it not make sense to include a cone of uncertainty. The cone of uncertainty being the same visual representation that is used for hurricane paths.
I have no idea what you mean by that.
Ya know, I don't think anyone else does that ... and come to think of it, it's not really needed because in theory we are all the same height in game because we all use the same model. Might become an issue when the occulus starts to know where you are in the Z axis in a 3D space, as the next version supports that, so it might be cool to add that now.
OutSim Packets are always local to the car, as it's meant for motion rig setups.
If someone makes an asm InSim application, I'll give them a billion geek points.
From my understanding, the idea of this project is to make a Driving AI that is agnostic to a single game. That's why there is a visual sensor, so he could then take the project and load up iRacing and it should just work because it can "See" the track the same way we do.
Fair point, about just using the auto gearbox mode. But it would depend also on the gear ratios ... I guess you could fuzz this information. Set 20 different values evenly spaced apart in 20 different setups then have the AI do a hot lap and find out where it shifts up and down. From there you'd only have to read the setup file and tween between the numbers if they are not on a value already set. That should get you 90% of the way there. When it comes to engine breaking and everything else, you'd also have to take in weight of the car, if it's on an incline or decline while breaking when you should be shifting ect.
You should be able to get the optimum shift time by RPM by looking at the RPM when the AI shifts into the next gear. I don't know for sure, but I think the AI (written by Scawen) knows the best time to shift.
If I remember correctly, that's because once you no longer are running the application in full screen mode, the driver will force V-Sync to save power. So when your just sitting at desktop, not doing anything, it's not rendering at 10,000 FPS, using needless power. I asked John Carmack on twitter, because I don't know the twitter handles of nVidia or AMD GPU reps, so I'm hoping for a reply to confirm.
[EDIT] Wow, Carmack is quick this was his reply:
So the answer is, it depends.
That would be pretty awesome. Having the setting "Tire Smoke Behind Fence (Costly)" [Yes / No] Would be a nice touch, let us decide if we want it, or you can just force it as everyone is getting free FPS from the DX9 patch anyway, so we might as well get some visual fixes to offset it anyway. I think we can burn a 15.98% FPS improvement to fix a visual bug.
0.6E (DX8)
Frames, Time (ms), Min, Max, Avg
13305, 108499, 72, 180, 122.6280.6E13 (DX9)
Frames, Time (ms), Min, Max, Avg
15747, 107891, 91, 194, 145.953- I had no idea that the wheelbase value was stored in the car_info.bin file.
- Most of the time, we get the information from OutGuage by revving the engine until the RPM flat lines, and then we save that value.
- Not that I know of.
- Again, nothing provided officially anyway.
FGED GREDG RDFGDR GSFDG