The online racing simulator
Quote from Dygear :
Quote from T3charmy :Dygear, You'd probably know where should I put the NCI in the state handler? should I put it where NCI is or should I just make a new function. Could you possibly take care of that? haha.

I think I would stick it in with the onClientPacket. It adds too that information about the client, so for me that seems like the most apporiate area for it.

Hmm alright, I'll work on that when I get home. almost done here in class.
Trying to cipher through this(for modules/prism_layoutobject.php), I assume some sort of changes need to be made to handle this:

if (Index >= AXO_CONCRETE_SLAB && Index <= AXO_CONCRETE_RAMP_WALL)
{
// Concrete objects - always floating regardless of 0x80 bit
// Flags byte contains various attributes depending on the object
// Each concrete object has three attributes

Attributes:

name bits values

Width : 0x03 >> 0 : 2, 4, 8, 16
Length : 0x0c >> 2 : 2, 4, 8, 16
Size X : 0x03 >> 0 : 0.25, 0.5, 0.75, 1
Size Y : 0x0c >> 2 : 0.25, 0.5, 0.75, 1
Height : 0xf0 >> 4 : 0.25 to 4 in steps of 0.25
Pitch : 0xf0 >> 4 : 0 to 90 in steps of 6 degrees
Colour : 0x03 >> 0 : grey / red / blue / yellow

Attributes used by each object:

AXO_CONCRETE_SLAB : Width / Length / Pitch
AXO_CONCRETE_RAMP : Width / Length / Height
AXO_CONCRETE_WALL : Colour / Length / Height
AXO_CONCRETE_PILLAR : Size X / Size Y / Height
AXO_CONCRETE_SLAB_WALL : Colour / Length / Pitch
AXO_CONCRETE_RAMP_WALL : Colour / Length / Height
}

Done a couple more pushes, look over them when you get a chance I guess:
  • Changes for 0.6H, still need to finish updating this (34257a4)[Missed a comma on this one... a7770b0)]
  • add NCI packet to state handler (328dc96)
Quote from T3charmy :

if (Index >= AXO_CONCRETE_SLAB && Index <= AXO_CONCRETE_RAMP_WALL)
{
// Concrete objects - always floating regardless of 0x80 bit
// Flags byte contains various attributes depending on the object
// Each concrete object has three attributes

Attributes:

name bits values

Width : 0x03 >> 0 : 2, 4, 8, 16
Length : 0x0c >> 2 : 2, 4, 8, 16
Size X : 0x03 >> 0 : 0.25, 0.5, 0.75, 1
Size Y : 0x0c >> 2 : 0.25, 0.5, 0.75, 1
Height : 0xf0 >> 4 : 0.25 to 4 in steps of 0.25
Pitch : 0xf0 >> 4 : 0 to 90 in steps of 6 degrees
Colour : 0x03 >> 0 : grey / red / blue / yellow

Attributes used by each object:

AXO_CONCRETE_SLAB : Width / Length / Pitch
AXO_CONCRETE_RAMP : Width / Length / Height
AXO_CONCRETE_WALL : Colour / Length / Height
AXO_CONCRETE_PILLAR : Size X / Size Y / Height
AXO_CONCRETE_SLAB_WALL : Colour / Length / Pitch
AXO_CONCRETE_RAMP_WALL : Colour / Length / Height
}


That's gonna be a bitch. Put simply, there are 6 different ways to read that struct now based off the Index . Meaning the the UNPACK and PACK functions have to change slightly for it.

Where is AXO_CONCRETE_SLAB, ect defined? I'm not seeing them in my InSim.txt file for 0.6G18.


<?php 
    
private function concrete_parse($index$bits)
    {
        switch(
$index)
        {
            case 
AXO_CONCRETE_SLAB:
                
$name 'Width/Length/Pitch';
                break;
            case 
AXO_CONCRETE_RAMP:
                
$name 'Width/Length/Height';
                break;
            case 
AXO_CONCRETE_WALL:
                
$name 'Color/Length/Height';
                break;
            case 
AXO_CONCRETE_PILLAR:
                
$name 'SizeX/SizeY/Pitch';
                break;
            case 
AXO_CONCRETE_SLAB_WALL:
                
$name 'Colour/Length/Pitch';
                break;
            case 
AXO_CONCRETE_RAMP_WALL:
                
$name 'Colour/Length/Height';
                break;
            default:
                
// No idea why we would get here.
                
break;
        }

        foreach (
explode('/'$name) as $name)
            
$packet[$name] = self::concret_bits($name$bits);
    }

    private function 
concrete_bits($name$bits)
    {
        switch (
$name)
        {    
// Some of these will not return the correct value yet.
            
case 'Width':
                return 
$bits 0x03 >> 0# 2, 4, 8, 16
            
case 'Length':
                return 
$bits 0x0c >> 2# 2, 4, 8, 16
            
case 'SizeX':
                return 
$bits 0x03 >> 0# 0.25, 0.5, 0.75, 1
            
case 'SizeY':
                return 
$bits 0x0c >> 2# 0.25, 0.5, 0.75, 1
            
case 'Height':
                return 
$bits 0xf0 >> 4# 0.25 to 4 in steps of 0.25
            
case 'Pitch':
                return 
$bits 0xf0 >> 4# 0 to 90 in steps of 6 degrees
            
case 'Colour':
                return 
$bits 0x03 >> 0# grey / red / blue / yellow
        
}
    }
?>

Base on the information I have, these helper functions should work for you. But I have no idea where these functions belong, because I don't know where the new defines are.
Quote from Dygear :
Quote from T3charmy :

if (Index >= AXO_CONCRETE_SLAB && Index <= AXO_CONCRETE_RAMP_WALL)
{
// Concrete objects - always floating regardless of 0x80 bit
// Flags byte contains various attributes depending on the object
// Each concrete object has three attributes

Attributes:

name bits values

Width : 0x03 >> 0 : 2, 4, 8, 16
Length : 0x0c >> 2 : 2, 4, 8, 16
Size X : 0x03 >> 0 : 0.25, 0.5, 0.75, 1
Size Y : 0x0c >> 2 : 0.25, 0.5, 0.75, 1
Height : 0xf0 >> 4 : 0.25 to 4 in steps of 0.25
Pitch : 0xf0 >> 4 : 0 to 90 in steps of 6 degrees
Colour : 0x03 >> 0 : grey / red / blue / yellow

Attributes used by each object:

AXO_CONCRETE_SLAB : Width / Length / Pitch
AXO_CONCRETE_RAMP : Width / Length / Height
AXO_CONCRETE_WALL : Colour / Length / Height
AXO_CONCRETE_PILLAR : Size X / Size Y / Height
AXO_CONCRETE_SLAB_WALL : Colour / Length / Pitch
AXO_CONCRETE_RAMP_WALL : Colour / Length / Height
}


That's gonna be a bitch. Put simply, there are 6 different ways to read that struct now based off the Index . Meaning the the UNPACK and PACK functions have to change slightly for it.

Where is AXO_CONCRETE_SLAB, ect defined? I'm not seeing them in my InSim.txt file for 0.6G18.


<?php 
    
private function concrete_parse($index$bits)
    {
        switch(
$index)
        {
            case 
AXO_CONCRETE_SLAB:
                
$name 'Width/Length/Pitch';
                break;
            case 
AXO_CONCRETE_RAMP:
                
$name 'Width/Length/Height';
                break;
            case 
AXO_CONCRETE_WALL:
                
$name 'Color/Length/Height';
                break;
            case 
AXO_CONCRETE_PILLAR:
                
$name 'SizeX/SizeY/Pitch';
                break;
            case 
AXO_CONCRETE_SLAB_WALL:
                
$name 'Colour/Length/Pitch';
                break;
            case 
AXO_CONCRETE_RAMP_WALL:
                
$name 'Colour/Length/Height';
                break;
            default:
                
// No idea why we would get here.
                
break;
        }

        foreach (
explode('/'$name) as $name)
            
$packet[$name] = self::concret_bits($name$bits);
    }

    private function 
concrete_bits($name$bits)
    {
        switch (
$name)
        {    
// Some of these will not return the correct value yet.
            
case 'Width':
                return 
$bits 0x03 >> 0# 2, 4, 8, 16
            
case 'Length':
                return 
$bits 0x0c >> 2# 2, 4, 8, 16
            
case 'SizeX':
                return 
$bits 0x03 >> 0# 0.25, 0.5, 0.75, 1
            
case 'SizeY':
                return 
$bits 0x0c >> 2# 0.25, 0.5, 0.75, 1
            
case 'Height':
                return 
$bits 0xf0 >> 4# 0.25 to 4 in steps of 0.25
            
case 'Pitch':
                return 
$bits 0xf0 >> 4# 0 to 90 in steps of 6 degrees
            
case 'Colour':
                return 
$bits 0x03 >> 0# grey / red / blue / yellow
        
}
    }
?>

Base on the information I have, these helper functions should work for you. But I have no idea where these functions belong, because I don't know where the new defines are.

I was given this: https://www.lfs.net/forum/post/1885434#post1885434
Eehhh.. How can NCI info be @NCN now? If there is a NCN (new connection) the NCN packet is send but there doesn't automatically follows a NCI packet, only when you request it with TINY_NCI so Statehandler contains empty info for every new NCN which is there after startup of the InSim?

Right? ... I was realizing that myself yesterday and went to bed but after every NCN now needs to follow a TINY_NCI.
Quote from cargame.nl :Eehhh.. How can NCI info be @NCN now? If there is a NCN (new connection) the NCN packet is send but there doesn't automatically follows a NCI packet, only when you request it with TINY_NCI so Statehandler contains empty info for every new NCN which is there after startup of the InSim?

Right? ... I was realizing that myself yesterday and went to bed but after every NCN now needs to follow a TINY_NCI.

https://github.com/Dygear/PRISM/blob/master/modules/prism_statehandler.php#L150
https://github.com/Dygear/PRISM/blob/master/modules/prism_statehandler.php#L373
https://github.com/Dygear/PRISM/blob/master/modules/prism_statehandler.php#L439
Quote from T3charmy :
https://github.com/Dygear/PRISM/blob/master/modules/prism_statehandler.php#L150

Yes.. But it only runs that sequence on startup of the InSim, not when there is a new connection? (NCN packet).

I have this at the end of my public function onClientConnect(IS_NCN $NCN);


<?php 
                
// do a request for extra connection info update (LFS_ID/Language/IP)
                
$TINY = new IS_TINY;
                
$TINY->ReqI(1)->SubT(TINY_NCI)->Send();
?>

NCI packet appears only when requested, as far as I know
Quote from cargame.nl :NCI packet appears only when requested, as far as I know

I did some testing on my own (non-PRISM) InSim program last night.
AFAICT, NCI behaves in exactly the same way as NCN:
  • When the InSim connects, you have to send a request for a batch of them by sending a TINY (I'm actually sending mine when I've received the first VER packet)
  • When a new player joins with the InSim already connected, an NCI (ReqI 0) is received for that player after the NCN
Maybe something in PRISM isn't picking them all up properly?

Edit: Just to make sure, I just disabled sending the TINY and I still got the NCI when a client connects (just not when the InSim connects of course)
Quote from Degats :
Quote from cargame.nl :NCI packet appears only when requested, as far as I know

I did some testing on my own (non-PRISM) InSim program last night.
AFAICT, NCI behaves in exactly the same way as NCN:
  • When the InSim connects, you have to send a request for a batch of them by sending a TINY (I'm actually sending mine when I've received the first VER packet)
  • When a new player joins with the InSim already connected, an NCI (ReqI 0) is received for that player after the NCN
Maybe something in PRISM isn't picking them all up properly?

Edit: Just to make sure, I just disabled sending the TINY and I still got the NCI when a client connects (just not when the InSim connects of course)

Hmm, thanks I'll have to look into it more when I get a chance.
Hmm I just downloaded a genuine 0.4.6.2 zip and run it on the server but I discovered statehandler is old in that zip. I also discovered welcome.php doesn't run at all;


PHP NOTICE:
Undefined variable: UName in /prism0462/plugins/welcome.php on line 31
1 :: onClientConnect in /prism0462/modules/prism_plugins.php:158
2 :: dispatchPacket in /prism0462/modules/prism_hosts.php:579
3 :: inspectPacket in /prism0462/modules/prism_hosts.php:487
4 :: handlePacket in /prism0462/modules/prism_hosts.php:340
5 :: checkTraffic in /prism0462/PHPInSimMod.php:225
PHP NOTICE:
Undefined index: in /prism0462/plugins/welcome.php on line 31
1 :: onClientConnect in /prism0462/modules/prism_plugins.php:158
2 :: dispatchPacket in /prism0462/modules/prism_hosts.php:579
3 :: inspectPacket in /prism0462/modules/prism_hosts.php:487
4 :: handlePacket in /prism0462/modules/prism_hosts.php:340
5 :: checkTraffic in /prism0462/PHPInSimMod.php:225

Fatal error: Call to a member function InitButton() on a non-object in /prism0462/plugins/welcome.php on line 31

I wait a little bit longer until T3charmy has more time Wink

(In my own version NCI is running but like I said, it's doing a request every time. And I already was surprised that Scawen was insufficient with that. Thought it had something to do with backwards compatibility that there was no NCI after NCN...)
Quote from cargame.nl :Hmm I just downloaded a genuine 0.4.6.2 zip and run it on the server but I discovered statehandler is old in that zip. I also discovered welcome.php doesn't run at all;


PHP NOTICE:
Undefined variable: UName in /prism0462/plugins/welcome.php on line 31
1 :: onClientConnect in /prism0462/modules/prism_plugins.php:158
2 :: dispatchPacket in /prism0462/modules/prism_hosts.php:579
3 :: inspectPacket in /prism0462/modules/prism_hosts.php:487
4 :: handlePacket in /prism0462/modules/prism_hosts.php:340
5 :: checkTraffic in /prism0462/PHPInSimMod.php:225
PHP NOTICE:
Undefined index: in /prism0462/plugins/welcome.php on line 31
1 :: onClientConnect in /prism0462/modules/prism_plugins.php:158
2 :: dispatchPacket in /prism0462/modules/prism_hosts.php:579
3 :: inspectPacket in /prism0462/modules/prism_hosts.php:487
4 :: handlePacket in /prism0462/modules/prism_hosts.php:340
5 :: checkTraffic in /prism0462/PHPInSimMod.php:225

Fatal error: Call to a member function InitButton() on a non-object in /prism0462/plugins/welcome.php on line 31

I wait a little bit longer until T3charmy has more time Wink

(In my own version NCI is running but like I said, it's doing a request every time. And I already was surprised that Scawen was insufficient with that. Thought it had something to do with backwards compatibility that there was no NCI after NCN...)

Fixed that error. Big grin I guess I'll need to make a new update soon.

My Thursdays are usually really busy, so I more then likely I'll be doing some some testing tomorrow as I am starting spring break here at work, and don't have classes on Fridays. I'm gonna be doing some thorough tests and make sure everything works right, if all goes well, I'll have a new update out by tomorrow night. Smile

Edit: I at least have PRISM starting, and running on my dedi. I have to wait till I get home to actually test if the NCI packet is working or not. Hopefully I'll be able to get NCI working with ease. I'll update this once I get home to test.

Edit 2: I just tested and NCI works fine, I did find a minor issue earlier with a missing comma in prism_statehandler.php, but it does work, haven't tested yet if it actually sets variables right or not. testing that next.

Edit 3: I also found a typo in betterButtonManager
PHPInSimMod (PRISM) Hotfix 0.4.6.3
  • Version changed to 0.4.6.3
  • Fixed incorrect variable in welcome plugin
  • Reformat code to use spaces not tabs
  • Fix bugs, that could potentially effect some users of PRISM
  • Fully Support the NCI packet, and properly format IPs
  • Fixed slight issue with RCM command in admin.php plugin
  • Fixed the wrong variable in if statement when adding a click event to a button using betterButtonManager
  • Added 2 new objects to prism_layoutobject
-
(Dygear) DELETED by T3charmy : *gasps* I was wrong. Although that was an issue, it didn't have the effect I thought it did.
-
(T3charmy) DELETED by T3charmy : *gasps* I was wrong. Although that was an issue, it didn't have the effect I thought it did.
Perhaps we should move the GUI folder under the data directory, or config? It just hanging out there by it's self is freaking me out a little bit on the inside.

We also need a lang directory that should probably data directory, or config. Thoughts?
Quote from Dygear :Perhaps we should move the GUI folder under the data directory, or config? It just hanging out there by it's self is freaking me out a little bit on the inside.

We also need a lang directory that should probably data directory, or config. Thoughts?

Hm, Either folder sounds good. maybe data might be good folders for those.

I think this file structure would be good:

PRISM/data/langs/plugin_name/(NCI->Language).ini
Dygear, I pushed 3 new code pushes to your repo(I really should start using mine to update code, not sure if it really matters...). I have gotten translations working pretty well. It could probably use some cleanup though. Not sure if there is a better way to do what I did or not.

Edit: Just did some testing(With insim half way across the world too), I'm able to send 2000 translated global messages to 3 clients(which are also half way across the world from the LFS server), in less then 5 seconds[no visual lag] only had minor CPU impact aswell, but what do you expect for sending 6000 packets.

Edit 2: Now we've hit a road block... Since the LanguageID is in the NCI packet, which comes after the NCN packet, you're unable to use any Translations in the NCN Packet(or until the NCI packet is recieved). This is really annoying -_-

Edit 3: I ended up temporarily working around the function by doing this:


<?php 
    
public function onClientConnect(IS_NCI $NCI)
    {
        
$Client $this->getClientByUCID($NCI->UCID);
        
#Continue on with rest of NCN packet using $Client instead of $NCN
        #You could probably just save yourself some time by just naming the $Client variable $NCN
?>

That way, I still have access to all the data from NCN packet in the NCI packet. While this isn't the best solution. it does work.

Edit 4: Testing an update now. I changed the order of NCI and NCN, so far it seems good, but I want to make sure it won't break anything.

Edit 5: Nope. That ran into issues. it worked great for people already on the server. but Can't get NCI to come before NCN for when a client connects after insim is started. Went back to solution in Edit 3 for now.
Pushed new code update which fixed issues with some packets(such as IS_REO). doing some testing, if everything still works properly, I will release a new update.

Edit: It looks like IS_REO might be the only one that uses said pack method. Gonna go ahead and get this ready for release.
PHPInSimMod (PRISM) 0.4.6.4
  • Version changed to 0.4.6.4
  • Fixed Issue with IS_REO so that it now works correctly(in some cases, the old method could crash PRISM).
  • Updated Reorder plugin
  • Added a TranslationEngine(Might need some fine tuning(See notes below)
  • PHP Standards[Sweep #1] by Zenware
  • You can now send a button an array of text on creation for alternating text.
  • Commands are no longer case sensitive(Let me know if you disagree with this change)
Download Link
Due to some LFS limitations, if you want to actually send any translations on connect(or in my case I had an account class that was spawned on Client Connect)

Notes:
  1. on your __construct of your plugin do this

    <?php 
            $this
    ->setTranslationSettings('plugin_name'); # if your default fallback language is english(en)
            
    $this->setTranslationSettings('plugin_name''fr'); # if you'd rather specify a different fallback
            # Translations will fail if this isn't ran.
    ?>

  2. Your fallback language is the language the translation engine will go to if the users language is missing.
  3. Due to some limitations of implementation in LFS, if you want to use translations, you'll need to do stuff you would normally do in NCN, in an NCI packet.

    <?php 
        
    public function onClientConnect(IS_NCI $NCI)
        {
            
    $NCN $this->getClientByUCID($NCI->UCID);
            
    #Continue on with rest of NCN packet the way you would in the IS_NCN packet
    ?>

  4. Example usage(These can not be used in NCN or any packets before the NCI connection):

    <?php 
        
    public function onPlayerJoin(IS_NPL $NPL)
        {
            
    $client $this->getClientByUCID($NPL->UCID);
            
    $this->translatePrivateMessage($NPL->UCID'User_Welcome', array($client->PName));
            
    $this->translateGlobalMessage('Global_Message'); # You can also specify an argument array here aswell
        
    }
    ?>

  5. File setup:

    ; PRISM/data/langs/plugin_name/en.ini
    Global_Message = "^7This is a global message!"
    User_Welcome = "^7Hello, %s^7!"

    ; PRISM/data/langs/plugin_name/fr.ini
    Global_Message = "^7Ce est un message global!"
    User_Welcome = "^7Bonjour, %s^7!"

Quote from T3charmy :
  • Commands are no longer case sensitive(Let me know if you disagree with this change)

I'd go so far as to say that you just fixed a bug on that one. Command case sensitivity does not really work in practice.
I didn't think they were supposed to be case sensitive, I might need to double check the other command functions and make sure those aren't case sensitive.

Edit: @Dygear, do you think this would actually be better as 0.4.7? or just another minor version of 0.4.6?

Edit 2: Thinking of some small changes to improve the translation engine. probably gonna change it so you don't have to specify the $lang_subdirectory every time, and also be able to specify the fallback instead of having to have an extra file.

Edit 3: Went ahead and did those updates, tested them and they work well. I've updated the zip.
All sounds great, certainly worth a 0.4.7 in my opinion =]

Excellent move forward, I cannot praise you enough about these important bug fixes and extension of functionality. Really motivating (y) Smile
Tend to agree, along with the old button manager starting to throw deprecation warnings to be remove in 0.5.0.
-
(cargame.nl) DELETED by cargame.nl : false report... wasted half an hour bcz different InSim was messing up :)
Quote from Dygear :Tend to agree, along with the old button manager starting to throw deprecation warnings to be remove in 0.5.0.

Gonna have to spend some time fixing that up since my button manager kind of uses the current one. Shouldn't be too much of an issue. I'll make that release 0.4.7.0
Hhmm I found a pretty serious bug.. No idea why nobody/me found it before but;


<?php 
class ClientHandler extends PropertyMaster
{
    public static 
$handles = array
    (
        
ISP_NCN => '__construct',    # 18
        
ISP_CNL => '__destruct',    # 19
        
ISP_CPR => 'onRename',        # 20
        
ISP_TOC => 'onTakeOverCar',    # 31
        
ISP_NCI => 'onClientInfo'    # 57
    
);
    
// ..[snip]..

    
public function __destruct()
    {
        unset(
$this);
    }
?>

doesn't do anything. Data of driver which leaves stays after a CNL


<?php 
class ClientHandler extends PropertyMaster
{
    public static 
$handles = array
    (
        
ISP_NCN => '__construct',    # 18
        
ISP_CNL => 'onClientLeave',    # 19
        
ISP_CPR => 'onRename',        # 20
        
ISP_TOC => 'onTakeOverCar',    # 31
        
ISP_NCI => 'onClientInfo'    # 57
    
);

// ..[snip]..

    
public function onClientLeave(IS_CNL $CNL)
    {
        unset(
$this->parent->clients[$CNL->UCID]);
    }
?>

This seems to work though.
Quote from cargame.nl :Hhmm I found a pretty serious bug.. No idea why nobody/me found it before but;

This seems to work though.

I wrote a todo in my lines of code somewhere that I needed to fix that. It's not too bad as not all plugins get the Connection Leave packet.

FGED GREDG RDFGDR GSFDG