Now that Lewis has had his time deleted, does that mean he can choose the tires he wishes to start the race with? The rules say that the top ten drives must start with the tires that the fastest time was set with. Seeing as that was deleted, it would stand to reason that then Lewis could then use any set he wishes because he did not 'set a time'.
Ted Kravitz had repoerted that Lewis was out of the car for a while in the first part of the Q2 or Q3 due to a problem with the car that they fixed. So it might not of been an error, it was more likely due to a problem with the car.
Also on the subject of Perez, it seems that he had a puncture and that was why he was off line, and then when we went over the bump, his car bottomed out and he lost all control.
Good point! This is the same problem I'm having with the InSim Buttons myself right now. I don't know how to display a group of buttons that are meant to work as one, but when they display on top of another group. I though that I would use a push / pop kind of method, so that the last bunch of items to be put onto the screen are the first interfaced by the user. This way, the most 'current' information is placed up front for the user to deal with. Once they have handled that, they are then represented with the older button group so they can interact with that.
In essence the button bound key, would work just like a ClickID, but with a physical key to click. In the same way that if you use a ClickID twice, then the data is overwritten, the same could be true of this. It would be up to the InSim programmer to handle themselves. Of course this would become a problem with multiple InSim instances running at once, should they request the same key, but then I would think that the first in last out, push pop method could work there too.
Thanks for the reply. Sorry my example was confusing, I'll try to provide a more concise example using the LFS client with a plugin I'm making for PRISM as an example.
I'm not sure what you mean, it's normally better to just post the code and then to state the problem. It let's me know what your trying to do, and let's me see how your trying to do it.
The reason why I bring this up, is that right now, for people who use a mouse to steer have to use their mouse to also select these items. I would like to be able to race with my mouse and still interact with the InSim app without having to use my mouse. You can still click on these items if you wish, but having the option to use you keyboard I think makes it a more robust solution.
I would like to be able to bind InSim buttons to keys on the keyboard. For example, should I show a menu on the screen, and allow the player to use a button on their keyboard to activate (click) that button.
Something along the lines of this, but as you would suspect with LFS Track names, or player names as needed.
Ok, that's not going to work, but you could do a chain extension, where one class extends another, extends another until you have all the parts you need. It would look something like this:
povo.php
<?php php include 'povo_utils.php'; class povo extends povo_utils { const URL = '-'; const NAME = '-'; const AUTHOR = '-'; const VERSION = 'This can be anything by the way, and really you should set it to not be that of PHPInSimMod\'s Version'; const DESCRIPTION = '-';
public $data = array();
public function __construct() { $this->doFunction(); # function from povo_utils.php } } ?>
povo_utils.php
<?php php class povo_utils extends Plugins { public function doFunction(&$data = $this->data) { $data['Povo']['Place'] = 'Random Place!'; $MST = new IS_MST(); $MST->Msg('/msg Data Updated')->Send(); } } ?>
The MTC struct has changed in the newest versions of LFS, Scawen changed the Msg property to Text. So you'll have to use that from now on. Just replace Msg with Text and it should go away. Also make sure you're using the latest version of PRISM.
Yeah, I'm pretty sure I was going to use SQLiteV3 as well, seeing as it ships with PHP in all cases, and I'm pretty sure it's license is the same as PRISMs, but I'll have to check that.
Yes it is. Anything that can be done in PHP can be done in PRISM, I don't have the power to restrict the language at all.
I'm not quite sure what you mean here. There are many ways to handle this so if you could give me a full example, php code, of what you want to do I'll tell you if that's how I would set it up, or you could just run a pilot example and see if that works.
Depending on how you set it up, if you simply have game_utilities class extend the game class then it's really simple to use on function within the other. However, if you want to use two separate classes, then you would have to make $my_array public, in fact the syntax you have right now automatically makes it public.
You can send packets from anywhere within the PRISM instance, plugins, modules, or the core. (However, I'll pretty much be the only one sending packets from the core.) Any class that is made, as long as it uses the prism_packets.php instance module should be able to send the packet from PRISM. (Although, I've never really tried.)
As far as suggestions. I would recomend making the game plugin, into a module as I think that's more of what you want. It would act as a layer between the PRISM core and your plugin. But I still don't know what you have planned so if you could provide some more details and what exactly you want to do that would help me help you. Even better then that write me to pseudo code and I'll tell you from there what's the best way to handle it within PRISM.
We really do need to have full support for the UTF-8 standard as this could be used on websites as well as in email, or pretty much any transmission. I still don't know what I am going to do about this myself, and I do appreciate the suggestions so far.