The online racing simulator
Searching in All forums
(975 results)
morpha
S3 licensed
Quote from flymike91 :Cool camaro, was it a v6?

Nope, V8 auto SS, all stock mechanically.
morpha
S3 licensed
If I were to use brute force, I'd just kick them off
morpha
S3 licensed
Quote from Luke.S :wtf are those headlight washers meant to be? Tusks?

Mostly they're what you walk into when you attempt to navigate around the car in a pitch-black garage
Removing them is on my to-do list, but there's a fair bit of work involved in doing that and I don't have time for that at the moment.
morpha
S3 licensed
Went to visit my mum at work (ultimately to pick her up, not just for fun) thinking I'd draw attention, but when this arrived about an hour after me, it completely stole my thunder (phone pics, sorry):



The carbon vinyl the lower half is covered in looks decent actually, not nearly as rough a surface as it looks. Easy to clean too, apparently. I'm not a big fan of the 22s, but they don't completely ruin it either.
It sounds sweet, but I still like my i6 rumble better, especially on the overrun.
Owner is a nice guy, no sign of JDM-vs-USDM/Muscle rivalry, just genuine appreciation of special, and here in Austria, quite exotic cars. Best chat I had with another car person in a long time.

And just to comply with the topic title; as she sits outside right now, covered in insects and generally requiring a good cleaning (and a good service I'm ashamed to admit):
morpha
S3 licensed
I've now tested it on my laptop and the results are quite different to my home server's. My pure PHP solution (which I shall dub "PRISIM" [PRISM String Internationalisation Module] :razz is actually 16% faster than mb_convert_encoding(), but 30% slower than iconv().

Seeing as mbstring doesn't support CP1250, CP1253 and CP1257, and is apparently slower than PRISIM on modern machines, iconv should be used instead. It's the fastest and uses the system's underlying iconv-implementation, which nowadays usually means it'll support pretty much any registered character set you can throw at it.

iconv > PRISIM > mbstring

Alrighty, now knowing that it doesn't perform so poorly after all, I'm back on it
morpha
S3 licensed
Quote from Velociround :You didn't ask for the girl pic!

Could you please send me post this in high resolution?
http://img688.imageshack.us/img688/9620/dsc03211b.jpg

fixed
morpha
S3 licensed
Quote from Victor :If you ever see a wrong conversion, let me know I don't think I've ever seen one. But I'll happily be proven wrong.

I've encountered a few back in DriftWars's prime, ISOs instead of MSCPs messed up a few of the exotic names, but nothing major. I genuinely meant the "reasonably accurate", that wasn't sarcastic


CP932 and CP936 are now 100% complete and produce identical results to mb_convert_encoding() and iconv(). Unfortunately, being pure PHP, it's quite slow, about 50 times slower than iconv()/mb actually. As such, I don't think it's worth finishing, except maybe as a fall-back solution for systems where neither mbstring nor iconv are available. I've attached it though, if anyone wants to have a look.
morpha
S3 licensed
LMAO hosting on a PDA, had I eaten bricks I'd be shitting them right now, but unfortunately I had soup
morpha
S3 licensed
I actually saw that and chuckled, he started a host named "[WLC] WorldLife Cruise" (note the missing space) and asked for the "WLC Insim Track layout", whatever the hell that means.
morpha
S3 licensed
Quote from Dygear :That's great! I'm happy if you're willing to do the work. I wonder why Victor has not chimed in yet, seeing as he deals with this on the LFSWorld site, with hostnames, and usernames.

Probably because he's satisfied with his reasonably accurate solution

I must admit I haven't looked at a piece of actual PRISM code in really quite a while, so I'm not sure if this complies with its general coding standards and conventions, but this is the first take on the Encoding interface:

<?php 
interface Encoding
{
    public static function 
encode($utf8_encoded_string);
    public static function 
decode($codepage_encoded_string);
    public static function 
contains($character$needle_is_utf8=false);
}
?>

CP932 and CP936 are already implemented and passed a few test cases, I'll finish up the rest after a few hours of sleep
Obviously this needs at least one additional layer of abstraction to be of any actual use, something similar to pyinsim's strmanip. I also haven't done any performance related testing yet, but being pure PHP, it'll likely lose to mbstring and iconv. The upside is it works standalone and it's the exact mapping LFS uses.

Right then -> :sleep2:
morpha
S3 licensed
I don't think there is a way to reliably predict or analyse post-conversion string size that's less expensive than the actual conversion. For characters, it's known that they're at most 2 bytes each, but you won't know how many codepage-switches they'll necessitate without iterating over the Unicode-string and determining the language/cp of each character.

Anyway, I've now started working on strmanip and pretty much achieved what I set out to achieve, or so I thought. In theory, everything was 100% accurate, but when I tested it, LFS screwed me good.
The problem is that certain characters present in multiple codepages are rendered differently between them. For example, Simplified Chinese (S, CP936) contains 66 characters from the Cyrillic set, but their graphical representation in LFS is not identical to the actual Cyrillic (C, CP1251) one.
Here's a comparison screeny for the string 'ЁёАБВГДЕЖЗИЙКЛМНОПРСТУФХЦЧШЩЪЫЬЭЮЯабвгдежзийклмнопрстуфхцчшщъыьэюя' (all 66 characters present in both C and S):

The first two lines are the S-version (134 bytes including '^S', hence 2 lines), the last line the C-one (68 bytes including '^C').

Obviously that renders strmanip's sort of "lazy" conversion useless, because it not only produces visually incorrect but also significantly larger results than it should. The problem is, while detecting this is relatively easy for L, E, T, B, C and G, it's not at all easy for J, H, S and K because these are unified in the Unicode standard as CJK Unified Ideographs.
I'm now in the process of rewriting strmanip entirely, not only because of the issues above but also because there are some reliability issues with Python 2.7's (haven't checked 3/3.2) native conversion mappings.
Among other things, fromUnicode() will determine the Unicode Block of a character and select the appropriate codepage based on that. It'll also attempt to guess which codepage to use for CJK input based on whether the majority of the string is kana (making it most likely Japanese) or hangul (Korean), otherwise it'll default to Chinese.

This is some complex stuff and I realise I've taken this a bit far off-topic, if it bothers anyone just split the topic
If all goes according to plan, I'll also be able to provide conversion mappings for PRISM, though obviously not to and from Unicode but rather UTF-8 directly, since PHP doesn't have native Unicode support (yet).
Last edited by morpha, . Reason : typo²
morpha
S3 licensed
Quote from Nadeo4441 :Damn I'm glad that in my country I don't have to do this much shit to pass a driving licence test. Only 1 teoretical test (You have to get 50points from 55), and a 15 minute ride in the city with a cop sitting in your car.

Well that's the wrong way to look at it. If you don't have to do much to get a licence, then neither does anyone else. The driver's licence is supposed to certify your driving ability, so that everyone in possession of it can generally be trusted to behave correctly in traffic.
As long as it makes sense, the tests should be as complex and tough as they can be.
morpha
S3 licensed
This isn't an InSim.NET bug and not an issue InSim.NET can deal with by itself.
LFS will always send CompCars for all cars on the playerlist and occasionally an MCI is due and sent after the player is added to the list but before the NPL is sent.
morpha
S3 licensed
Over here there's no explicit hazard perception test as such, it's part of the regular theoretical test. For the B-class (passenger cars) there are 1514 questions out of which you get between 56-ish and 68-ish (not sure exactly) depending on their point value (1, 3 or 5) and whether or not you get the follow-up (worth 1 point for a 1 point main, 2 for a 3 main and 3 for a 5 main), which you only do if you answer the main question correctly.
You're always presented with 4 answers in random order, between 1 and 4 of them are correct.

You've got 45 minutes for the entire test, but if you take more than 10 you're almost certainly going to fail.
The record is 100% correct in 3m48s or something like that, definitely under 4 mins. I did it in 5m57s, also 100%
morpha
S3 licensed
I'd go for a lighter grey, similar to what they currently are. But between black and gunmental, gunmetal.
morpha
S3 licensed
Well it has to be said, the GLOF fits.
morpha
S3 licensed
It's also in the setup screen under "Steering", says "Car's steering wheel turns xxx° (lock to lock)" on the right side
morpha
S3 licensed
Quote from Scrabby :So when you accidently spin the wheels the bolts will fly off? Dayumm!!

http://www.youtube.com/watch?v=o6-8yCUbXiQ
morpha
S3 licensed
I doubt he's banging any chicks tbh. He's hanging with them, if you get my meaning.
morpha
S3 licensed
Quote from arco :What if one has both versions in the same folder, to be able to run each version? Unlock every time they are run?

Yes, each version requires a new unlock once the other one was unlocked. To work around this, copy the files f1.xyz, f2.xyz and f3.xyz in LFS/data/misc/ to a backup folder (name it after the the currently unlocked version, e.g. "unlock_z28") before switching version. Then, after switching and unlocking the other version, copy them again into yet another folder ("unlock_a1").
Now everytime you switch version, you'll have to copy the files back to LFS/data/misc/ and it'll be unlocked.
morpha
S3 licensed
Quote from DarkTimes :there are libraries available which have solved the problem.

"Libraries"? I don't even know of one
pyinsim's strmanip does the conversion stuff very well (not 100% accurate but close, I'll be improving it eventually) and so, I presume, does InSim.NET, but I don't know of any lib that does it literally "to the letter".

Splitting strings intelligently is the more pressing issue though, which, to my knowledge, none of the publicly available libraries are capable of. By "intelligently", I mean maintaining colour and codepages, not splitting escape sequences and double-byte characters, stripping redundant and trailing non-printable characters, etc.
morpha
S3 licensed
In a perfect world, we wouldn't need any security because people simply wouldn't enter areas they're not supposed to. We don't live in that dreamworld though, so I'll take a bragging "lulz"-group over some serious data thief, who actually makes money with the stolen information, or uses it for further mischief, any day.
morpha
S3 licensed
Back when LFS development started (2001? earlier?), UTF-8 wasn't as widely used and supported as it is today. It wasn't the obvious choice, the better one no doubt, but not yet the obvious one.
Most applications of the time didn't support multiple languages (at the same time) at all, so LFS set a good example in that respect.

You can blame Scawen for making us find solutions to problems we wouldn't be having if he'd made the "more innovative" choice, but LFS's system does its job. And if we're honest, we all enjoy a good programming challenge, don't we?

Perhaps when (if) right-to-left language support is added, he'll consider a complete re-write of the entire text handling system, but that's probably fairly low down on his to-do list.
morpha
S3 licensed
Bringing this one back up.

http://msdn.microsoft.com/en-us/goglobal/bb964654
Quote :DBCS (Double Byte Character Set) Codepages

[...]
  • 932 (Japanese Shift-JIS)
  • 936 (Simplified Chinese GBK)
  • 949 (Korean)
  • 950 (Traditional Chinese Big5)

So that confirms it, they are indeed 2-byte wide at most.

€: Just so everyone's up to speed, here's a "short" summary of what you should know when dealing with LFS strings:

Escape sequences:
  • All escape sequences start with a circumflex ('^')
  • All escape sequences are 2 bytes wide
Code pages:
  • The codepages J (CP932, Japanese), S (CP936, Simplified Chinese), K (CP949, Korean) and H (CP950, Traditional Chinese) are double-byte character sets. That doesn't mean all their characters occupy 2 bytes, but a large portion of them does.
  • All codepages contain all 128 ASCII characters, but CP932 (J, Japanese) is a bit of a special case, see next list item.
  • CP932 character 0x5C is mapped to UNICODE U+005C, REVERSE SOLIDUS (backslash), but many fonts display a Yen-sign (U+00A5) instead, as does LFS. This can lead to inconsistent results when converting from other character sets because the mapping differs from the displayed character. Dealing with this is difficult because the Yen-sign (U+00A5) is not mapped in any of LFS's CPs, only the full width Yen-sign (U+FFE5). Basically this means:
    • When converting LFS ^J strings to Unicode, convert 0x5C to U+00A5, not U+005C
    • When converting from Unicode to LFS, you cannot use ^J to output a backslash as both 0x5C and the escape sequence ^d will output a Yen-sign
    • When converting from Unicode to LFS, convert U+00A5 to ^J followed by 0x5C
Feel free to extend the list and add all the "gotchas" and "aha!"s you have
Last edited by morpha, .
morpha
S3 licensed
Quote from P5YcHoM4N :Of course, unfortunately a lot of garages don't like to torque up wheels because it takes time, so they just windy gun (or knuckle bar) them on.

I know, I added the "" because we've got the same problem here.

Quote from P5YcHoM4N :But there are a lot of factors which mean you need more force to take off a nut/bolt than you torqued them up to.

Well most Austrians change wheels/tyres twice a year, mandatory winter tyres, you know. Doesn't give them much time to corrode / rust / get stuck somehow.
FGED GREDG RDFGDR GSFDG