Quick update to the development plan: Several attempts at smoothing the problem areas in the mesh have failed spectacularly, so it's time to bite the bullet and start out with blender, I think. If I can't fix the door outline that way, I'll just draw the $%*%& thing into the skin 
That pushes the mesh-smoothing part of the project to the longer term as I don't have much free time, but it will be worth it in the end.
I've added a GT-compatible 100 to the line-up, with an NA inline 4 and more basic styling (smaller bonnet vents, rear bumper, and the much requested exhaust at the back ). It seems to sit between the two performance-wise, but is subject to tweaks with online testing. (test)
The 200 is staying as is, except mesh smoothing.
The 300 I'm still not happy with the tyres, there's just too much sidewall for that car. I will go back a step with that one soon, but much testing is needed as I want it to be the last physics change on that car.
To follow is the GTR-compatible 500. It'll be compatible in terms of performance but the lore is that it's a street car rather than a 'proper' race car. Reference images attached.
That pushes the mesh-smoothing part of the project to the longer term as I don't have much free time, but it will be worth it in the end.I've added a GT-compatible 100 to the line-up, with an NA inline 4 and more basic styling (smaller bonnet vents, rear bumper, and the much requested exhaust at the back
). It seems to sit between the two performance-wise, but is subject to tweaks with online testing. (test)The 200 is staying as is, except mesh smoothing.
The 300 I'm still not happy with the tyres, there's just too much sidewall for that car. I will go back a step with that one soon, but much testing is needed as I want it to be the last physics change on that car.
To follow is the GTR-compatible 500. It'll be compatible in terms of performance but the lore is that it's a street car rather than a 'proper' race car. Reference images attached.
No surprises to be found here
Stats at https://piranmoto.uk/events/146
Last edited by Racon, .
The default sets have very strong brakes, so it doesn't take much to get the ABS shaking - if you reduce them so that the ABS only just kicks in, that should help.
The 200 is now skinnable!
Attached are a default monochrome JPEG, and a layered PSD (zipped) with all the components used to make the default skins that come with the mod.
Attached are a default monochrome JPEG, and a layered PSD (zipped) with all the components used to make the default skins that come with the mod.
Stats at https://piranmoto.uk/events/145
Last edited by Racon, .
Awesome news 
I will definitely be there for that one. (Mondays are awkward for me, but I'm hoping to manage at least one other event before then too).
I have been working on the skin mapping recently, making good progress so far. LODs are all there. I won't make any changes to tyres/engine/suspension/etc before the race, so it will drive the same as it does now
I will definitely be there for that one. (Mondays are awkward for me, but I'm hoping to manage at least one other event before then too).I have been working on the skin mapping recently, making good progress so far. LODs are all there. I won't make any changes to tyres/engine/suspension/etc before the race, so it will drive the same as it does now
Last edited by Racon, .
Stats at https://piranmoto.uk/events/144
Last edited by Racon, .
In single player mode, in the mods screen. There's a button under the mods.
Sorry, I should have made clear: I don't use those automatic startup scripts - I'm not calling them, only LFS is (the automated calling). IE, whatever LFS does is triggering the warning.
I've just checked, and the script is still being run despite the warning.
I've just checked, and the script is still being run despite the warning.
I'm getting a notice about not being able to run the automated scripts that I don't think was there before:
I also got one for 'road', but not for 'ev'.
I also got one for 'road', but not for 'ev'.
Last edited by Racon, .
Stats at https://piranmoto.uk/events/143
Last edited by Racon, .
No problem, and good luck 
There's some discussion/help about direct access on LFS discord programming channel sometimes... it's worth joining if you're going to go on memory adventures
There's some discussion/help about direct access on LFS discord programming channel sometimes... it's worth joining if you're going to go on memory adventures
Some programs use InSim to manage the interface, but also do direct reading/writing of the memory of the running LFS exe as well. That kind of thing is beyond me I'm afraid
You can't use InSim to set a rev limit, if that's what you mean - the OutGauge part is read-only. You could warn people about high revs, but you can't force them to be cut.
Yes, if other players want to use your app, they will need to enable OutGauge also before the app will receive OutGauge packets.
Yes, if other players want to use your app, they will need to enable OutGauge also before the app will receive OutGauge packets.
You can only get that information from the OutGauge packet, so it's only available to local InSims. You need OutGauge configured in LFS's cfg.txt to get LFS to start sending it InSim, too.
Good job in the e-challenge... those blue-flaggers always gain that last chunk of time and burst into the mirrors out of nowhere, don't they? 
These changes to the text commands reminded me of something I thought about a while back - using /o and /i messages bound to a wheel button in order to communicate with an InSim. I would watch the packets for a command, then call my 'insim button has been clicked' function to simulate receiving a click.
Would it be possible to have a /click command that directly triggered an InSim click inside LFS? I imagine it would need to be /click [local|host] ClickId, or /clicklocal ClickId and /clickhost ClickId.
If it could be done that way we could use it with any existing InSim, not just ones that were written to catch hidden i/o messages. We could build InSim menus that could be navigated without taking your hands off the wheel.
edit: just thought, you'd have to check the button id was displayed to that user, else people could cause all sorts of mischief by spamming random click ids on servers where the security is done by showing a panel or not. I'm sure you would, but better to say than not
These changes to the text commands reminded me of something I thought about a while back - using /o and /i messages bound to a wheel button in order to communicate with an InSim. I would watch the packets for a command, then call my 'insim button has been clicked' function to simulate receiving a click.
Would it be possible to have a /click command that directly triggered an InSim click inside LFS? I imagine it would need to be /click [local|host] ClickId, or /clicklocal ClickId and /clickhost ClickId.
If it could be done that way we could use it with any existing InSim, not just ones that were written to catch hidden i/o messages. We could build InSim menus that could be navigated without taking your hands off the wheel.
edit: just thought, you'd have to check the button id was displayed to that user, else people could cause all sorts of mischief by spamming random click ids on servers where the security is done by showing a panel or not. I'm sure you would, but better to say than not
Last edited by Racon, .
Object Groups
A layout-building helper to hold multiple, nameable groups of objects which can be saved to file.
- Click the group's name to change it
- Click 'set' to assign the selected objects to that group
- Click 'set' with no selected objects to clear the group
- Click 'get' to load a saved group into the hand/cursor
- Click 'place' to place the objects in their original position
- Click the filename to change it
- Click 'save' to save the current groups and names to file
- Click 'load' to load from file
Here's a quick demo video by way of a guide:
Requirements:
PIE executable (https://www.lfs.net/forum/thread/98929)
InSim enabled in LFS (port 29999 default)
Usage:
- Click the group's name to change it
- Click 'set' to assign the selected objects to that group
- Click 'set' with no selected objects to clear the group
- Click 'get' to load a saved group into the hand/cursor
- Click 'place' to place the objects in their original position
- Click the filename to change it
- Click 'save' to save the current groups and names to file
- Click 'load' to load from file
Here's a quick demo video by way of a guide:
Requirements:
PIE executable (https://www.lfs.net/forum/thread/98929)
InSim enabled in LFS (port 29999 default)
Usage:
Fuel Monitor
A small display to help manange fuel/energy use in a race.
FuelMonitor shows the following four pieces of information, from left to right:
Updated live:
1) fuel / energy remaining
Updated at lap end:
2) fuel budget (fuel left per lap until race end)
3) fuel usage (fuel usage on previous lap)
4) range (predicted lap count when fuel runs out, if previous lap usage is maintained)
Requirements:
PIE executable (https://www.lfs.net/forum/thread/98929)
InSim enabled in LFS (port 29999 default)
OutGauge enabled in LFS (port 49999 default)
Usage:
FuelMonitor shows the following four pieces of information, from left to right:
Updated live:
1) fuel / energy remaining
Updated at lap end:
2) fuel budget (fuel left per lap until race end)
3) fuel usage (fuel usage on previous lap)
4) range (predicted lap count when fuel runs out, if previous lap usage is maintained)
Requirements:
PIE executable (https://www.lfs.net/forum/thread/98929)
InSim enabled in LFS (port 29999 default)
OutGauge enabled in LFS (port 49999 default)
Usage:
Last edited by Racon, .
Tutorial 7: Object info
// [Object Info] //////////////////////////////////////////////////////////////
Now we'll look at layout objects, button clicks and handling multiple
buttons.
We'll make a small panel that will give us information about a selected
object when we click on the header. We'll make a function called 'drawpanel'
that can be called at any time to initialise or update the entire panel.
We'll set some variables to control our panel, and then draw our panel.
We'll also make a variable to store our target object, so that our panel
doesn't need the object to be passed to it.
We'll need to hook the BTC object to detect button clicks. Here we only have
one to check, and if we find it we'll send a TTC packet that requests the
current layout editor selection.
We'll hook the AXM packet to watch for replies, and discard any that are not
of the correct type. We'll find the first object and store it before calling
for the panel to be redrawn.
Finally, we'll define our function to draw the panel. We'll make the first
button clickable, and then, if there is an object saved, we'll loop through
the fields and output them as a row. Note that we're increasing the id value
as we go - we'll use this next to delete any leftover buttons from a previous
draw using a BFN packet.
objectinfo.php:
command line:
Now we'll look at layout objects, button clicks and handling multiple
buttons.
We'll make a small panel that will give us information about a selected
object when we click on the header. We'll make a function called 'drawpanel'
that can be called at any time to initialise or update the entire panel.
We'll set some variables to control our panel, and then draw our panel.
We'll also make a variable to store our target object, so that our panel
doesn't need the object to be passed to it.
We'll need to hook the BTC object to detect button clicks. Here we only have
one to check, and if we find it we'll send a TTC packet that requests the
current layout editor selection.
We'll hook the AXM packet to watch for replies, and discard any that are not
of the correct type. We'll find the first object and store it before calling
for the panel to be redrawn.
Finally, we'll define our function to draw the panel. We'll make the first
button clickable, and then, if there is an object saved, we'll loop through
the fields and output them as a row. Note that we're increasing the id value
as we go - we'll use this next to delete any leftover buttons from a previous
draw using a BFN packet.
objectinfo.php:
<?php
function PIE_settings()
{
return array('flags' => ISF_LOCAL,
'insimname' => 'ObjectInfo');
}
function PIE_start()
{
$PIE = PIE::connect();
$PIE->set('panelbaseid', 20);
$PIE->set('paneltop', 7);
$PIE->set('panelleft', 154);
$PIE->set('panelwidth', 20);
$PIE->set('panelbheight', 5);
$PIE->set('object', array());
drawpanel();
}
function PIE_BTC($data)
{
$PIE = PIE::connect();
$bid = $PIE->get('panelbaseid');
if ($data['ClickID'] == $bid)
PIE_sendTTC(TTC_SEL);
}
function PIE_AXM($data)
{
if ($data['PMOAction'] != PMO_TTC_SEL)
return;
if ($data['NumO'] < 1)
$object = array();
else
$object = $data['Info'][0];
$PIE = PIE::connect();
$PIE->set('object', $object);
drawpanel();
}
function drawpanel()
{
$PIE = PIE::connect();
$bid = $PIE->get('panelbaseid');
$top = $PIE->get('paneltop');
$left = $PIE->get('panelleft');
$width = $PIE->get('panelwidth');
$bheight = $PIE->get('panelbheight');
$object = $PIE->get('object');
$id = $bid;
$packet = array('Type' => ISP_BTN,
'ClickID' => $id++,
'BStyle' => ISB_DARK | ISB_CLICK,
'T' => $top,
'L' => $left,
'W' => $width,
'H' => $bheight,
'Text' => '^7Get Object Info');
PIE_sendpacket($packet);
$row = 1;
foreach($object as $k=>$v)
{
$packet = array('Type' => ISP_BTN,
'ClickID' => $id++,
'BStyle' => ISB_DARK | ISB_RIGHT,
'T' => $top + ($row * $bheight),
'L' => $left,
'W' => 8,
'H' => $bheight,
'Text' => $k.':');
PIE_sendpacket($packet);
$packet = array('Type' => ISP_BTN,
'ClickID' => $id++,
'BStyle' => ISB_DARK | ISB_LEFT,
'T' => $top + ($row * $bheight),
'L' => $left+8,
'W' => 12,
'H' => $bheight,
'Text' => $v);
PIE_sendpacket($packet);
$row += 1;
}
$max = $bid + 12;
if ($id < $max)
PIE_sendpacket(array( 'Type' => ISP_BFN,
'SubType' => BFN_DEL_BTN,
'ClickID' => $id,
'ClickMax' => $max));
}
?>
> pie tutorials\objectinfo.php
FGED GREDG RDFGDR GSFDG