Hmm alright, I'll work on that when I get home. almost done here in class.
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:
Done a couple more pushes, look over them when you get a chance I guess:
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:
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
}
}
?>
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.
Right? ... I was realizing that myself yesterday and went to bed but after every NCN now needs to follow a TINY_NCI.
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();
?>
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
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;
I wait a little bit longer until T3charmy has more time
(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...)
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
(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.
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.
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?
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:
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.
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
?>
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.
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)
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:
Notes:
- 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.
?>
- Your fallback language is the language the translation engine will go to if the users language is missing.
- 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
?>
- 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
}
?>
- 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!"
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.
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)
Excellent move forward, I cannot praise you enough about these important bug fixes and extension of functionality. Really motivating (y)
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 :)
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;
doesn't do anything. Data of driver which leaves stays after a CNL
This seems to work though.
<?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);
}
?>
<?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]);
}
?>
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.
PHPInSimMod - PRISM 0.4.6 Discussion
(51 posts, started )
FGED GREDG RDFGDR GSFDG