It conflicts, also you cannot have LFS send OutGauge or OutSim information to multiple ports. I've written a [post=1331791]relay application[/post] for that purpose, see if that helps 
Of course not, that would make the LAN option incredibly stupid. Even online hosts can legally be run without the master by use of /usemaster=no.
You used the [img] tag for the link in the first post, which obviously won't work
Racing on tracks no-one has raced on before certainly will make it more interesting for "casual" racers who don't spend as much time practising on specific tracks. It's a nice idea, however, I agree that LFS is not the sim for this.
He is feeding them 19v to play with instead of the 24v they were designed for, how is that age related?
It's really incredibly simple, go to Options > Controls, make sure wheel / joystick is selected at the top, then click Axes / FF (it's the rightmost button of the small ones in the middle of the screen).
Now you'll see all available axes on the right side of the screen. At the top of that view, make sure the axes are unlocked, i.e. the "unlock" button's text is white. If you turn the wheel or operate the pedals, the bars on the right side will move. You may have to turn the wheel from lock to lock and fully depress all pedals to calibrate them.
From there on, your wheel and pedals are calibrated, meaning their full range of motion is recognized by LFS (and the wheel driver, which by itself can only calibrate the wheel, that's why it rotates from side to side on startup).
To get everything working, you simply select a function on the left side (actually more like the centre, but it's left of the axes list) by clicking it, for example Steer, and then the axis you want to assign to it, again by clicking it. If you don't know which axis does what, simply rotate the wheel or depress the pedal you're looking for and the bar next to it will move.
Now you'll see all available axes on the right side of the screen. At the top of that view, make sure the axes are unlocked, i.e. the "unlock" button's text is white. If you turn the wheel or operate the pedals, the bars on the right side will move. You may have to turn the wheel from lock to lock and fully depress all pedals to calibrate them.
From there on, your wheel and pedals are calibrated, meaning their full range of motion is recognized by LFS (and the wheel driver, which by itself can only calibrate the wheel, that's why it rotates from side to side on startup).
To get everything working, you simply select a function on the left side (actually more like the centre, but it's left of the axes list) by clicking it, for example Steer, and then the axis you want to assign to it, again by clicking it. If you don't know which axis does what, simply rotate the wheel or depress the pedal you're looking for and the bar next to it will move.
Well, to be frank, my big projects all use a template engine and end up having only a single echo echo'ing a large string anyway. It's a neat performance booster to keep in mind for CLI (PRISM :razz
or smaller, inline-markup'd projects though.You can and you should (if you care about the few nanoseconds) whenever it's possible instead of concatenation, although opcode caches (accelerators / optimizers, whatever you want to call them) nullify the advantage.
echo, being the odd language construct it is, does things a bit differently from regular functions and even its fellow language constructs.
<?php
echo $ServerName, ' is <font color=\"green\">Online</font><br />';
?>
I'm going to make a non-judgemental assumption here and assume you consume more than a single spliff when your inability to order pizza sets in
Just so we're clear on the terminology here; Core changes, modules/plugins/addons change the way PRISM operates, applications just use the features provided by PRISM (and possibly some modules/plugins/addons).
I agree that the former should be open-source enforced, because everyone involved in any way with PRISM, be it on the development side of things or the user side, will benefit from it.
On the application side, however, things look a bit different to me. While I have no problem with forcing local (single player) applications (of which I don't think there will be many using PRISM, to be honest) to be released, multiplayer InSim applications are what sets a server apart from the others. That's their de facto primary purpose when connected to a multiplayer host. InSim allows one to individualise the experience and create something unique. PRISM should extend on that and allow everyone (who's fluent in PHP) to express themselves. Improving the tool together is great and should be enforced, but taking away the individuality and/or uniqueness of an application by forcing the author to release his creation is not my desire.
Having run a reasonably successful server for the past 2 years, I dare say the InSim application running on a server makes between 50% and 90% of its popularity, depending on what type of server it is. If we permit use without the need to share the application, we may get some code back voluntarily, but if we force authors to release, they might choose not to use PRISM at all. I'm pretty sure I wouldn't release DriftWars's InSim and I don't think Krammeh would want to release LTC.
I've also read the PHP licence and thought about the PHP in the name, I came to the same conclusion Dustin arrived at. You're not allowed to use PHP in your project name or use it to promote you project, but that is only of concern to projects using PHP's source, not projects using the PHP interpreter to parse PHP code.
Forcing the core and modules/plugins to remain open source, in the original project (PHPInSimMod / PRISM) and in derivative works, is a good idea, I'm for that. Application authors (= end users, from our point of view), however, should not be forced to release their code as that would scare a great portion of them away.
What about commercial use?
Forcing the core and modules/plugins to remain open source, in the original project (PHPInSimMod / PRISM) and in derivative works, is a good idea, I'm for that. Application authors (= end users, from our point of view), however, should not be forced to release their code as that would scare a great portion of them away.
What about commercial use?
LFS will not download a skin if a file with that exact name already exists, that is, if the existing file is also newer than the one on LFSW. Always worked that way for me, with .jpg and .dds 
Just tried, both drive-through and stop-and-go are working as expected.
As those ran on leaded petrol, you couldn't run it straight from the pump... Granted, adding the lead additive is generally a lot easier than writing a device driver, but it is possible.
You know there are other options, PayPal, Moneybookers/NetPay, or a money order. superxp's tip will definitely pay off, regardless of which option you end up choosing:
It probably depends on a certain packet, not traffic in general. The server sends a ping and kicks the player if no pong arrives within a certain time, regardless of other packets that may have been exchanged in the meantime.
phpDocumentor's documenting blocks are simpler than doxygen's, but I prefer the output of doxygen. It provides more information in a clear structure, the autolinking is way better and it even provides a search (client-side, javascript!). And of course, there are the nice diagrams... Tough call, but I find myself prefering doxygen overall (although it's HTML output is somewhat terrible, markup-wise).
Yep, I definitely vote doxygen!
Yep, I definitely vote doxygen!
Last edited by morpha, .
More to the point, .eng files are not backwards compatible
Looks like it's fairly similar to doxygen in how it's used, will check it out
The project on SF needs some cleaning up, but we should probably keep the PHPLFS remains for now.
Well do it already
By the way, while we're kind of on the subject; will we be commenting for any particular documentation generator? I've somewhat adopted a doxygen compatible style, regardless of whether it's actually passed through doxygen or not.
You're right, working around the issues is not the way to go. We've got some key points figured out, I might just take the time and report them as bugs over at php.net, because frankly, most of the fatals should be recoverable - in CLI at least.
I might code a validation tool anyway, not for JIT validation like isSafeToInclude(), but for module writers to check their modules for robustness (checking for cloneability prior to cloning, illegal use of reserved names, potential memory leaks and whatnot).
FGED GREDG RDFGDR GSFDG