Quote from PMD9409 :

At the end of the day, it's a choice, with no difference than a simple opinion. Last time I checked people are entitled to their opinions, so Dustin and whoever can text in one hand and wank with the other, just keep the **** away from me in the process.

It's against the law, which people are free to have their opinions about, but must still abide by.

€: It is here, not sure about Canada.

Quote from dawesdust_12 :

In town, sure it's a bad idea because conditions do change very rapidly (pedestrians, cars stop, construction, emergency vehicles).. but on a highway, where lanes are gaping and margin of error is measured in months. I could probably write an essay before I crash.

Unless something unexpected happens, not like the list of things that could go wrong is short. Doesn't necessarily have to be something crazy, like people throwing stuff from bridges, or jumping onto the highway to commit suicide (but both these things happen), someone could lose their cargo, or experience some sort of sudden defect. Hell, someone could simply have a heart attack and become completely unpredictable as a result.

Granted, most of things that can go wrong on the highway produce a lot of noise before contact with your vehicle occurs, but even then you lose at least a second reacting and are less likely to react correctly.

Psycho beat me to it but I had this written already so ima post it anyway :P

OBH looks pretty good, although it might produce a lot of traffic in certain situations, such as a cone killing spree.
Would X and Y be the position the object was placed at? Or the position at the time the OBH is sent? Should be the former.
Some way to determine whether the object was moving (i.e. struck by another car, then propelled toward the current OBH-trigger) at the time of impact would also be nice.

I'd also like to raise something from EQ's InSim Bug Report / Update Request thread:

• Notification when objects are added, moved (by an admin, not a collision) or deleted; should contain an ObjectID, X/Y/Z coords, Rotation and the UCID of the user responsible for the change of state.
• Ability to add objects by specifying ObjectType, X/Y/Z and Rotation. If ReqI != 0, a response is sent containing the added object's ObjectID.
• Ability to move or remove objects using the ObjectID, providing new coordinates and rotation when moving.
• Ability to instantly reset an object that's been moved by a collision.

Instead of the unique ObjectID, the ObjectType with the X/Y could also work, i.e. to delete, you specify the ObjectType and coords and LFS will remove the object of the specified type closest to the specified coords.

I disagree, select() should be left blocking indefinitely whenever possible. The whole point of select() is to have the application sleep when there's nothing to do, making select() perfect for passive/reactive applications, which most InSim applications are. That's probably especially true for those made with PRISM due to its limited support for interactivity (as in, GUI or console input).

The current approach is good, but sorting the timer list on every iteration isn't terribly efficient, should be done when timers enter the queue.

Quote from DarkTimes :

pyinsim 2.0 doesn't use threads at all, it uses the Python asyncore module, which is basically just a wrapper around select. Yes, if you just want to create a timer you can use the threading.Timer class, but all of the send/receive stuff in pyinsim is done with non-blocking sockets.

Should probably check that out sometime, I'm still running 1.5.3

Quote from DarkTimes :

Yeah, I realise this, but still changing the select timeout would still improves things a lot. A better solution would of course be to use a threaded timer for the timer events, but I don't remember enough about PHP to advise on how easy/hard that would be to implement. Frankly I was just impressed I managed to figure out that there might be a timeout issue within 30 seconds of downloading the codebase.

With just PHP and its most common extensions alone, it's impossible. Threading is obviously a very low priority item for what is still primarily a hypertext preprocessor.

Quote from DarkTimes :

I'm looking through the code and there's something I'm slightly unsure of. It seems you're executing the timers between select returns, which is fair enough. But it looks to me that your select timeout is almost always 1 second. Now I might be wrong on this (it's very likely, as I don't know the codebase or PHP), but wouldn't that mean your timers can only be fired at minimum once a second? From looking at T3's output it seems that the timer is always elapsing after one second, which would bare my theory out.

Obviously incoming packets will also resume execution, which could potentially double (almost) the delay.

• Timer is set to 1 second
• select() suspends execution with a timeout of 1 second
• a packet arrives after 900ms and is handled within 50ms, the timer has not yet expired and thus does not trigger
• select() suspends again with 1s timeout
• a second goes by without any packets
• timeout triggers the timer, which is now 950ms late

Even with a very low timeout the timer resolution will be limited and vary greatly depending on the complexity of the script, as it's all running in a single thread of execution. Still, dynamically calculating the timeout will greatly improve the timer reliability, i.e.

Quote from DarkTimes :

If I'm not wrong then you could try putting the select timeout to a very low value, such as a 0.01 seconds or something, basically just enough to prevent it from flooding the CPU. pyinsim uses select as well and in that I use a timeout of 0.05 seconds, but this is a pretty arbitrary value that I came to after a discussion on StackOverflow. I could of course be completely wrong about all of this, in which case just slap me with a big fish.

I don't see any reason for pyinsim to use a timeout at all, since it can use (virtual) threads for timers and keep the socket blocked until there actually is something to do, including handling socket exceptions (disconnects mostly). More to the point, it would just use actual threading.Timers or something similar, I'm fairly certain those provide sufficient resolution.

Quote from Whiskey :

the welcome message that you edited in the cfg is showed while connecting. To show a message after you connect you need an insim program running in the background, as could be AIRIO or LFS Lapper

Or use the InSim Relay service (see "Special options").

Quote from BlakjeKaas :

Probably because you have a MASSIVE world and there is just a maximum amount of mobs for the server.

200 hostiles max IIRC, but they despawn if there's no player within 4 chunks. If you're all alone on the server, your trap/tower should yield the same as it does in singleplayer. A possible explanation could be caves underneath the tower or around it, so instead of spawning in your tower, they spawn in those caves.

Quote from Matrixi :

I bloody hate VW for making a car called R32.

Every time I try to google something for my car, the first thing that always comes up is about some kübelwagen R32. Argh.

Here's a tip: http://tinyurl.com/3jlx2j2

Quote from S14 DRIFT :

They are diesel [engines] thus have an inherent reliability that a petrol may not have plus it's good old fashioned steel, not poncy aluminium so can take extra stresses without causing increased wear.

Everything true in above statement is marked green.

"Inherent reliability" based on the type of fuel combusted? Really now?
Cast iron is not steel, guess what your block is made from?
Aluminium is not steel either, guess what your head and oil sump are made from?
Extra stresses without increased wear? Again: really?

Quote from dawesdust_12 :

I personally don't see any issue with me sending a simple text while driving on a highway. Particularly in clear conditions, there's no reason why there's a problem with it. Everyone is moving at a consistent speed, in a relatively straight line, with large margins (due to the speeds being higher (110 kmh~)). I don't think it matters that much on a highway.

Problem is, as predictable as that situation might seem, there are still lots of unknowns. In Germany, people (predominantely teenagers) throwing stuff from bridges is a big problem, here in Lower Austria we had a "run across for a dare" recently where a driver was killed because he rolled it attempting to evade. There could be an accident ahead that doesn't necessarily affect the flow / fluidity of traffic all that much until right up to it. You cannot be certain that highway traffic is constantly fluid, even if it should be.

A lot can change in a few seconds and a few seconds can change a lot.

Quote from MadCatX :

On the other hand, red color makes your pupils constrict the least so you don't loose the ability to see in the dark when you glance at the dashboard.

That's a matter of brightness (i.e. the amount of light), not colour.
As quoted a few posts back, the human eye is more sensitive to green light than red, meaning if you displayed the same thing in green and red light, you'd need less green light than red to make the eye perceive it with the same intensity.

Quote from G!NhO :

Red is the best for night driving.

Teal / turquoise if you need colours, white if you don't. There's a reason most dashes are (were, before designers became more important than scientists) lit green (cheaper than teal, better than blue), including racing displays (Motec and the likes).

Quote :

The sensitivity of the dark-adapted human eye is greatest at about 507 nm, a bluish-green color, while the light-adapted eye is most sensitive about 555 nm, a yellowish-green color.

Also:

Quote :

Green is restful to the eye. Studies show that a green environment can reduce fatigue.

clicky

MyHome and Lightvote work fine, everything else throws "An internal error occured while attempting to perform this command", including /spawn, /playerlist, etc.

There you go.

Why are there replies to this? Don't feed the troll!

When will people learn

Urge people not to connect via in-game hostlist and instead either type the name in directly ("Join specific host") or join via lfs://join= links from trusted sources (your signature on LFSF or your website, for example).

Quote from Dygear :

I am trying to get licensing information on that font, I hope to enable it via an @font-face CSS rule.

From what I've found, all of Neale Davidson's fonts are freeware

Quote :

The only rules are that a) credit isn’t stolen for their use ... and that you do not charge for their distribution.

I'm fairly certain the Optimus font Flame used is in fact Neale Davidson's, so there shouldn't be any legal issues.

I downloaded the 1.4 .exe and .jar yesterday, both work just fine and show 1.4. Are you absolutely sure you're running the right file?

Quote from E.Reiljans :

Um, how about ^1 to ^7? Or you mean that admin can't see what colors people have?

Remote escapes all LFS special chars.

Quote from Timo1992 :

An admin doesnt know my gamepassword...

An admin doesn't need it, they can fabricate whatever message they want on their server.

It's either what Hahmo suggested or an admin having fun

Quote from Hyperactive :

Did the server just crash?

Says "Lost Connection: End of stream" when trying to reconnect.

Same

It's a bug introduced with one of the recent updates, has it's advantages though. You can use the 4 crafting slots in your inventory for additional storage, just make sure to take the stuff out before you log out or it'll be gone. It's most useful for tools you intend to consume on your trip.

If you're talking about the tree house, nycska accidentally burned it down (again). Apparently a fully contained fire can still spread, I've observed it myself placing a wooden note block on top of a dirt block with a still lava block underneath.