Except LFS does not actually require you to log in every single time. If one wants to make reasonably sure the client is who they appear to be, the second login system makes sense
He hasn't yet incriminated himself, "S2" is part of the actual version string even in DEMO mode. Note how it explicitly says S2 all over the official site ...
Yeah... I mean I understand that there can be fatal errors even in robust implementations, but on cloning? Seriously? If we could at least overload / replace the critical language constructs and functions, but the way it is now, we cannot protect script authors from PHP's stricter-than-your-mother-in-law-hammer-of-fatality, unless we offer alternative functions and keep them from using the originals.
<?php
function safe_clone(&$object)
{
if(is_object($object) && is_callable(array($object, '__clone')))
{
return clone $object;
}
throw new InvalidArgumentException('Passed value is not an object or an uncloneable object.');
return NULL;
}
?>
He didn't say "level the playing field", he basically said "force some realism onto mouse (and keyboard) users". You can step on it all the way in real life, but you can't turn from lock to lock in under a sec
Sorry, I left out one important detail: $b is not an object in the example.
aha, that's fixed.
SCNR :lovies3d:
So we will.
Doubt it, but then it might not actually be a problem. The only context in which eval() is needed (that I can think of anyway) is an ingame command to execute user code. That's stupid and we might do good by disallowing eval() altogether, or if we want to retain a full php feature set, we implement a proxy eval() function that checks whether evaluating the string would cause a fatal.
To sum up what we've got so far, prior to inclusion:
- Make sure the file exists
- Make sure the syntax is valid using lint
- Scan file for function-, class- and interface declarations (and, if any, assignments to global vars that might not be entirely desireable)
- Replace any eval() call with a call to our proxy
- Do the same for any files the file-to-be-loaded includes or requires.
Edit: Question is, do we rename duplicate declarations (which would allow execution even if - in file at least - two functions/classes/interfaces share the same name) or do we simple throw an exception and tell the user the plugin contains a redeclaration?
Edit2: Okay, we can do very well, but I don't see a way to have it be 100% bulletproof. One particular case:
<?php
$a = clone $b;
?>
<?php
$b = unserialize(file_get_contents('myNeedlesslyObscureValueThatIsntAClass'));
?>
Well at least we're considering lots of improbable cases, which is good! Just a shame that there's so many of them that require ridiculous workarounds
Last edited by morpha, .
Perhaps something along the lines of: "Hey... my nickname starts with 'r'!"
They don't have to, since we can't make sure script authors sanitize their user input (or can we? perhaps we can... gotta think about it), any connected player could potentially start an attack of some sort. And yes, I realize this is an incredible long-shot.
Sadly no, there are recoverable/catchable fatals but very few of them are.
Or if we really wanna rub it in, PHP Revolutionary InSimMod 
Perhaps PHP Reincarnated InSimMod, seeing as it will be a joint effort by developers of prior PHP based InSim implementations?
PRISM is nice, we have to find something
Edit: Here's a good one; PHP Retitled [relabled|renamed] InSimMod
Edit2: Man I'm on fire tonight, James Brown, Red Bull, chinese food and everything! Anyway, regarding irrecoverable runtime fatals, the only one I cannot think of a solution for is eval()
Perhaps PHP Reincarnated InSimMod, seeing as it will be a joint effort by developers of prior PHP based InSim implementations?
PRISM is nice, we have to find something
Edit: Here's a good one; PHP Retitled [relabled|renamed] InSimMod
Edit2: Man I'm on fire tonight, James Brown, Red Bull, chinese food and everything! Anyway, regarding irrecoverable runtime fatals, the only one I cannot think of a solution for is eval()
Last edited by morpha, .
True, we should!
PHP [rugged, robust, reliable, rapid, ...?] InSimMod
Also Mark, keep escapeshellcmd(), better yet, replace it with escapeshellarg(). A potential attacker could simply create a file named '-i myfile.php', the file_exists would return true but the exec/system would return a whole lot of info about php and more importantly, always return 0!
Edit: Crap, neither escapeshellcmd nor -arg are helpful in that case, we'll have to
<?php
str_replace('-', '', $filePath);
?>
Edit3: Strike that, make it
<?php
ltrim($filePath, '-');
?>
Last edited by morpha, .
PISM has funny ring to it, but I approve
I expected no less
Few observations/suggestions though
- Attempting to include a non-existent file only throws a warning, so it's technically still safe to include.
- exec() instead of system() as the latter will output any output to STDOUT.
- Since the user input is quasi-sanitized by simply not exec()uting (or in your case, system()ing) if the specified file does not exist, escapeshellcmd() serves no purpose.
- I'd prefer it if the function provided more feedback, specifically exceptions for ... well, exceptions, like when something other than a string is passed to it (which can happen since it's public... actually why is it public?) or indeed if the file does not exist. Obviously we'll have to make sure all exceptions are caught at some point, I guess we'll log to file or STDOUT / STDERR.
- Lastly, the premature optimizer in me wants $filePath to be passed by reference since we're not manipulating it
Good catch! Handling this is entirely possible, but the solution I'm currently thinking of is probably not efficient enough.
You are probably right about the removal, at best it would be an inelegant construct like
<?php
unset($dispatcher[ISP_TINY][array($this, 'tiny')]);
?>
And yes, you're also right about the semantics... I tried to make myself like it, but objectively... Right, let's forget about ArrayAccessing the dispatcher, however, here's a proposal for dispatching packets:
<?php
$dispatcher($packet);
?>
Well I've finally registered with SF as "xigmorph". Not sure if I'll have the time for active development, but I sure am interested
My observations from over 600 days of use are that stability is not an issue, the implementation is bulletproof, it didn't crash a single time and handled well over 160 billion(!) packets. However, packet interpretation and object creation is also one of its major performance killers. I've found that performance could be increased by up to 66% (in my test environment, running 5.3.1 on Win2k3 x86) if a reference instance of every packet class is kept and cloned instead of always creating new instances. This will be particularly useful with incoming packets, since the constructor serves no purpose with those as they need to be unpacked.
As for memory usage, there might be room for improvement, but not much. The script I'm running on DriftWars (which is fairly complex) uses 8M with a total of ~24M allocated, the pyinsim running alongside uses approx. 6M but allocated 32M. I definitely prefer a slightly worse memory footprint over the performance impact of aggressive garbage collection.
Regarding the memory leak issues, I know of no solution that's entirely obscure to the script writer. We do need the object reference in the handler array and it will leak if the object is unset() because it will not be unset until the reference in the handler array is unset. The solution I have in mind is a plugin manager that takes care of all references, but for it to work, script authors must NEVER unset() loaded plugins themselves (instead use $plugin_manager->unload(...)) and must not create references to objects handled by the plugin manager (or if they do, unset them prior to an unload() call). I'm curious what kind of magic plugin system Mark is working on
And finally, I will be focusing on all the concepts I've neglected in the past, namely interfaces, abstract classes, magic methods and type hinting. A balance must be found between a semantically robust syntax and efficient code design. For example, this might be misleading at first, but to me it makes sense semantically:Don't be fooled by the syntax, the dispatcher class implements ArrayAccess, this is not an assignment to an element of an array. Well, it is, but $dispatcher is not the array, it's an object behaving like an array. What happens is the dispatcher's offsetSet() will add the received array to its list of handlers for the passed packet type:Thoughts?
Edit: Also, regarding the project title, will the "new" project be called PHPLFS?
Another edit: Since I'd like the plugin system to be as robust as possible, it should not allow for inclusion of plugins that cause fatal errors. Anyone got a better solution for checking than:
?
My observations from over 600 days of use are that stability is not an issue, the implementation is bulletproof, it didn't crash a single time and handled well over 160 billion(!) packets. However, packet interpretation and object creation is also one of its major performance killers. I've found that performance could be increased by up to 66% (in my test environment, running 5.3.1 on Win2k3 x86) if a reference instance of every packet class is kept and cloned instead of always creating new instances. This will be particularly useful with incoming packets, since the constructor serves no purpose with those as they need to be unpacked.
As for memory usage, there might be room for improvement, but not much. The script I'm running on DriftWars (which is fairly complex) uses 8M with a total of ~24M allocated, the pyinsim running alongside uses approx. 6M but allocated 32M. I definitely prefer a slightly worse memory footprint over the performance impact of aggressive garbage collection.
Regarding the memory leak issues, I know of no solution that's entirely obscure to the script writer. We do need the object reference in the handler array and it will leak if the object is unset() because it will not be unset until the reference in the handler array is unset. The solution I have in mind is a plugin manager that takes care of all references, but for it to work, script authors must NEVER unset() loaded plugins themselves (instead use $plugin_manager->unload(...)) and must not create references to objects handled by the plugin manager (or if they do, unset them prior to an unload() call). I'm curious what kind of magic plugin system Mark is working on
And finally, I will be focusing on all the concepts I've neglected in the past, namely interfaces, abstract classes, magic methods and type hinting. A balance must be found between a semantically robust syntax and efficient code design. For example, this might be misleading at first, but to me it makes sense semantically:
<?php
$dispatcher[ISP_TINY] = array($this, 'tiny');
?>
<?php
// Sadly we cannot use type hinting as it would
// differ from the ArrayAccess interface's signature
public function offsetSet($packet_type, $handler)
{
if(is_int($packet_type) && is_callable($handler))
{
$this->handlers[$packet_type][] = $handler;
}
// Instead of the else, the conditional above could return.
// We need to discuss coding standards :P
else
{
// Exceptions or error reporting? I'm for exceptions.
throw new InvalidArgumentException('...');
}
}
?>
Edit: Also, regarding the project title, will the "new" project be called PHPLFS?
Another edit: Since I'd like the plugin system to be as robust as possible, it should not allow for inclusion of plugins that cause fatal errors. Anyone got a better solution for checking than:
php -l plugin_file?
Last edited by morpha, .
Reason : Better wording, added question regarding project title.
Strictly speaking, yes, there will be a minimal delay due to the fact that the packet travels twice the distance and is subject to some processing along the way. We're talking microseconds here though, perhaps low single-digit milliseconds on a slow machine
If momoleds uses OutGauge, the reason for it not working anymore is that the OutGauge structure changed slightly. I've released [post=1329031]a tiny Python script[/post] to convert new to old OutGauge packets on the fly, try that and feel free to ask if you need help.
Facts? It would probably take a hypothetical space moped with comparable fuel consumption to a regular, earth-bound moped less than 1 litre of fuel to get to Uranus. It would reach its top speed of 45 kph and maintain its velocity from there on since there's nothing to resist it in space. Mind you, that trip would take approximately 6532 years, but what the hell.
A long term voting system like that doesn't really fit OsR in my opinion. You'll end up getting many votes from people who might not be on the server when their desired track is finally selected. Instead, I'd go with a fixed schedule or shuffle system.
Choosing track by day and configuration by vote would probably satisfy all parties.
Choosing track by day and configuration by vote would probably satisfy all parties.
I'm simply going to quote the Simple Machines licence without establishing a specific context. Draw your own conclusions as to what I'm getting at.
- Permission is hereby granted to use, copy, modify and/or distribute this Package, provided that:
- All copyright notices within source files and as generated by the Software as output are retained, unchanged.
Most arcades do feature something many LFS users wish for though, a nice cockpit with a fully adjustable seat, full sized wheel and pedals and an H-shifter, some even have a proper handbrake!
Edit: That actually might make such arcades more realistic than the average LFS experience...
Edit: That actually might make such arcades more realistic than the average LFS experience...
Never had any difficulty with it, works fine on Vista Business SP2 x86 (GPU = FireGL V5700) and Win7 Ultimate x64 (GPU = R4870X2) for me.
I completely agree, and again, it was never my intention to "steal" the project from you. When I showed it to Dygear, I did so in a collaborative editor (Gobby), it was simply a mixture of general confusion, blurry memory and messy file structure / documentation on my end.
On topic I have to say though, I think while PHPLFS+PHPInSim+PHP5 InSim Mod could prove powerful, the codebase lacks efficiency. Whether a complete rewrite is more efficient than a thorough revisit, I don't know, but it doesn't seem all that unlikely.
I meant ripnet's initial code, which was a functional InSim application for sure, just not fully functional.
Of course, I meant in the actual source file. PHPLFS doesn't really come with any documentation, hence comments in the code are really the only place for credit available. I'm not saying you did anything wrong or that I want you to change it
What do you mean? I don't want to start a fight, I just want to understand how we ended up in this situation, because I can't remember what went on 2 years ago to the extent that I could trust it'd be the truth. I don't generally claim code I did not write to be my own, nor do I think I would have done that 2 years ago.
Basically what I see is code that I'm fairly certain I wrote (by which I mean some code, not all of it of course) in a project I may either never have heard about or forgotten about (seeing as it apparently never really caught on, it's entirely possible that I simply forgot). Also note that I did not release the code as my own per se, I shared it with Mark who - correctly - stated to have received it from me.
As I said before, you deserve a lot of credit for the idea and proof-of-concept, and I should have added a copyright notice, but as I also said before, I never removed such notice or licence info. Should I have infringed your rights in some way, I apologize.
Edit: Well I suppose I did infringe your rights by not adding the copyright notice, regardless of it being intentional or not. My apologies.
Anyway, enjoy the party
Last edited by morpha, .
Only evidence of my involvement I could find so far
in D1GP-Admins.txt in the D1GP-1.2 sample script.
Anyway, if ripnet cares, remembers and is still around, he might be able to explain it further. All I can say is I'm not a thief. Look at pyinsim, it contains code, fixes and improvements I wrote (as Alex will undoubtedly confirm), yet there is no reference to me in any form or shape. I'm fine with that, I'm just saying don't judge by meta information (such as copyright and licence info) alone.
<?php
$this->admins = array('ripnet', 'morpha');
?>in D1GP-Admins.txt in the D1GP-1.2 sample script.
Anyway, if ripnet cares, remembers and is still around, he might be able to explain it further. All I can say is I'm not a thief. Look at pyinsim, it contains code, fixes and improvements I wrote (as Alex will undoubtedly confirm), yet there is no reference to me in any form or shape. I'm fine with that, I'm just saying don't judge by meta information (such as copyright and licence info) alone.
Last edited by morpha, .
FGED GREDG RDFGDR GSFDG