http://www.lfsforum.net/showthread.php?t=17866
Coincidence?

Quote from Quint999 :

suspect over zealous traffic shaping to be honest ..

I'm going to have to play devils advocate on this one;
Every man and his dog can figure out how to use torrents nowadays and this is having a hugely negative impact on ISPs the world over. Recent adoption of VOIP, Vidcasts and streaming media have not helped either.
Most ISPs tend to factor in a certain percentage of its user base as low users that will not use their alloted bandwidth in order to reduce costs (both internally in forms of wholesale pipes req'd and externally in the form of subscription fees).

When more and more of those 'low users' begin to use, or over use all of their alloted bandwidth the pipes are all of a sudden over subscribed.
This is what is happening with the majority of ISPs in the UK right now. They either face bankruptcy by just sucking it up, raise prices to compensate and get more pipes or implement traffic shaping in some form or another to stem the usage.

Quite a few have opted for the later option because it is the most cost effective and has less of an impact on end users than the other two options. Unfortunately, simple systems aren't enough because of throttling counter-measures such as bit torrent encryption. To combat this ISPs either need to be super heavy handed and just block traffic (which appears to be the case with virgin) or implement a more intelligent solution such as the ellacoya platform which still lets most traffic through, but prioritizes certain traffic based on current network usage. Ellacoya does however need constant tweaking to ensure that traffic is prioritized correctly.

/2p

Last edited by Anarchi-H, Wed, 10 Jan 2007 19:15. Reason : Speeling

What soundcards / chips are you guys using?

Quote from prodeg :

Dead zones and sensitivity make for extremely hard driving. Use the mouse or get a wheel is my advice.

XBCD drivers solve deadzone issues with the XBOX360 pad.

Quote from MonkOnHotTinRoof :

But I am already missing GUI library in phobos. As long as there is no portable GUI, I will have to stick with java, which unfortunately feels so slugish (which is weird, cause C# on the other hand seems more responsive, even if tests show, it's not any faster).
And as angry angel says, namespaces are a bit messy (slowly getting used to it however).

According to some research there is a wxWidgets interface being written and interfaces to tk / gtk already exist. I think "DUI" which is a GTK wrapper is the 'official' one.

Some useful links for this kind of stuff
http://www.dsource.org/projects/
http://www.digitalmars.com/d/dlinks.html
http://www.algonet.se/~afb/d/
http://www.prowiki.org/wiki4d/wiki.cgi?FrontPage

Last edited by Anarchi-H, Sat, 6 Jan 2007 22:59.

DigitalMars newsgroup reply to my query;
http://www.digitalmars.com/pne ... almars.D&artnum=46323

In summary; due to Ds RTTI implementation and the ability to dyamcially cast and such, executable sizes are way above what you might expect from C but the actual code executed should be a little bit more than the C version (because of RTTI and GC).

Hmm, good stuff. I think I'll keep digging

Hmm, I tried compiling their demo program and it came back with a 450k file for 100 odd lines. If binary size continues to grow at the same proportion, I would hate to see a binary compiled from D that was a million lines (large scale apps were one of the targetted audience).

I think I'm going to email someone at DMD about this before I get in to D anymore.

Quote from Stage D :

i am thinking about buying a PS2 controller converter so i can play LFS with a PS2 controller or steering wheel

BUT will it work?

S D

IMO you would be better off buying a corded XBOX 360 controller that will just work with your PC.
£20~ish and it has 6 analogue axes.

I got one as a stop gap for a G25 since my DFP broke and have it setup so that I have steering on the leftstick, look headin & pitch on the right stick, accelerator on the right trigger and brake on the left trigger.

This allows me to balance the car better than I could with just the sticks.

The only downside is that the sticks are not linear so it takes a bit of practice to drive the more tetchy cars.

Quote from MonkOnHotTinRoof :

which compiles to about 100K exe file
Code looks a lot like java

Hmmm, I just compiled the same program under linux (gdc) and got a 280k file!

O3 flag made no difference on size but for such a simple program there probably isn't much to be done.

The same program in C, compiled with gcc takes 7k!

I wonder what extra stuff D has to put in to support the new language features and how much of it is really necessary

Quote from Becky Rose :

Lots of people have servers who can handle this. The UKCT servers that I have my LFS servers on ticks over on idle.

Cool; Then I see no reason why not as long as (like Bob said) it's only available on sensible sized tracks.

A bit OT: @Becky; What sort of bandwidth usage do you typically see from your servers? If possible, could you PM me a bandwidth log or stats to that effect?
I'm quite interested in hosting my own server, mainly for testing mods on real racers but I'm not sure how expensive it would be.

Spotted this yesterday and downloaded the spec.
I'm been going through it this evening trying out some stuff and I must say it is very cool.

Bearing in mind I'm a PHP programmer with a little exposure to pretty much every language going, it seems to introduce some language features that were up until now (that I'm aware of) only thought of as dynamic language features to compiled languages.

Run time type info is available and it takes care of some implicit (albeit simple) casts automatically. Add to that dynamic arrays, garbage collection, anon functions, binary compatibility with existing C libs, integrated unit testing and much less reliance on pointers than C and you have a pretty spanky new language. (edit: there are an assload more features I forgot)

My only concerns are what extra complications might be introduced when using libs from other languages (mainly C I guess, which shouldn't be too bad) and what complications will arise for other language users (again, C mainly) when trying to interface with libs written in D?
I guess both will have been thought of already, but whether the outcome is a tasteful one is a different matter.

Last edited by Anarchi-H, Fri, 5 Jan 2007 08:12.

For a full grid of 40 cars, not only would you be backing the grid up around corners but T1 would degenerate into gridlock. By the time the last people get through T1 the people who were in front of the accident could well be around half the track!

In addition, it would take probably (based on really rough calculations) a 10Mbit upstream connection on the server end and a pretty large bandwidth bill to go with it.
The actual speed I calculated was 577KB/s (I did say roughly didn't I? :P) which works out at 4.6Mbit in PERFECT conditions and totally excludes protocol overheads. Given that this will be done over the internet, you can guaruntee you wont get that from a 5Mbit pipe.

I'm not sure how much on the client end but given the availability of high speed broadband these days that shouldn't be so much of an issue.

*edit*
Just to clarify, the purpose of this post is to point out that this would only be available from home users with a super fast connection or from paid for hosts in data centers that can afford the extra bandwidth.

Last edited by Anarchi-H, Thu, 4 Jan 2007 23:05.

Quote from duke_toaster :

Scavier would be aiding and abetting - and if both the plantiff, the server hosting company and the team were based in the UK ...

In about as much capacity as Ford or Subaru aide and abet drunk drivers

On the disabled law issue;
Scavier would not be liable as they are only providing the option.

If anyone would be liable it would be host providers, but then I still don't think you'd get anywhere in court, especially given the international boundaries.

Again, I state that this is such a pointless thread ...
carry on

This thread is so pointless.
Beyond duke_toasters original proposal, nothing is enforcable.

Get the right drivers and you have a virtual G25.
Connect outgauge to the right app and combined with the drivers you have yourself an automatic gearbox, WITH auto clutch emulated on an axis.

Whats that? You'll be able to tell if a driver is using emulation? Not if it's obfuscated with variable engage times and levels.

LFS will never be able to protect from this because if you put up a wall, some clever little sod WILL find a way around, over, under or just straight through.
If you build enough walls you'll start blocking out legitimate users while still not blocking out the ones you really want to stay out (DRM anyone?)

But hey, I've nothing against it. I reckon the more options the better but its ultimately pointless.

Have you tried another mic?
Cheap condenser mics tend to pick up everything and then some.

Also, where is your mic positioned?
Have you tried moving it around? (if you can)

If it is a table top one, consider moving it off the table since the plastics will carry the vibrations from the desk straight to the mic.

The only nice way to get around this is to cough up for premium stats.

However, here are some nasty hacks that will allow you to do this without premium but it means more work on your part.

The simplest of these is to make a request to LFSWorld and check to see if you got the tarpit error message. If you did then sleep(5) and make the request again.
This method sucks because it means slow loading images for some poor soul and if multiple team members post in the same thread with one of your images in your sig....

The next method requires your host to support cron jobs.
Simply write a script that fetches all data from lfsworld and puts it in the cache. Change your sig script to only fetch data from the cache and add the request scripts to your hosts crontab to run every X hours or however often you want it to update (min time is (teamMembers * 6) ... 6 incase the network is running a little slow).

Final method is a variation on the one above if your host doesn't support cron.
Do pretty much the same as above, only this time the request script must be accessible by URL.
The request scripts touches itself and this will act as a marker for the last lfsworld request time.
The sig generating script only fetches data out of cache again, but this time also checks the last modified time of the request script. If it was last modified over 'updateInterval' seconds ago then it makes a GET request to your request script, thus triggering it to update the cache.


Again, the best way to do this is through premium stats ... it's not like its expensive

Last edited by Anarchi-H, Mon, 1 Jan 2007 16:06.

Never used one myself, but this review seems like an open and honest one.

Based on that, I'd say it depends on what you are going to use it for and how much of a perfectionist you are.

Graceful degredation in the event of no JS support would be high on my priority list if I were to provide a usage sample for a JS implementation.
I browse with JS disabled by default and some sites just dont work without JS, sometimes for no good reason... which is annoying.

Take note Mr Dygear because SimFIA is one of them.

Last edited by Anarchi-H, Fri, 22 Dec 2006 20:39.

Quote from filur :

I don't mean it's a bad idea or that it would take very long, just that i wouldn't use it for the thing i had in mind (and not really fit the target group of users [my target group, if i was to .. etc etc]).

The JSON provider would surely be a neat thing all by itself.

Fair enough, I see your POV
From my POV a JSON provider would mean less focus on the implementation and more focus on the data and creative uses for it.

I think I'll check with Vic about redistribution first in case he has any issues with it. If not I'll front Scavier some cash for premium access and see if I can get something cooked up over christmas.

Quote from imthebestracerthereis :

uh, I think it would just be easier to link to my user cp and tell them to look at where i am :P I am only 14, I dont get all that conplex stuff real well

Lol, don't mind us, we just hijacked your thread

Quote from filur :

But very simple to use (and present), if the JSON backend already existed that't be great, but i wouldn't write one for this purpose.

I can't see many people using the more advanced stuff (insert fancy terms of choice, im very tired. ).

I could write the code the backend would require on a couple of sheets of toilet paper if I were to use LFSWorldSDK or PPF to parse the data.
Anyway, I think you've got your way and I've got mine. I doubt they are going to converge (do they ever? ) so I'd best just drop it...

Still might try it though

Quote from Dygear :

Or just binary ... It's a hell of a lot better for data to markup. (Yes there is SOME markup in binary, for example the fact the there is 24 chars and no matter what there is always going to be the 24 chars for that string.)

Thats not markup; the null bytes are just data!
In order for it to be markup, it has to have extraneous semantic, structural or presentation data in addition to the actual data (aka metadata).
Now if the length of that string was stored in a byte before the string or if there was a byte before the string that identified what was in the string (1=NAME, 2=USERNAME, 4=HOSTNAME, etc), then that could very loosely be called markup. (Albeit for a very specific data set)

Nit picking aside, text parsing is easier in JS than binary parsing is and you lose the whole 'JSON encoders & decoders already exist in about a million languages' advantage.

Quote from the_angry_angel :

Please! No document.write! It doesn't work with certain document / mime types... surely using the DOM tree object(s) would make more sense?

Yes it might but I couldn't be bothered to get my DOM for dummies book out to write the sample

Quote from filur :

I think i'd stick to extremely simple stuff for JS, code generator style, click button, copy, paste, stuff appears on website. XML for anything else.

You could easily do copy n paste stuff for JSON, only in this scenario, someone who knows a bit of JS could easily adapt you stuff to what they need. If you are just going to display it, you are making things harder to adapt.


Anyway, the reason for JSON over XML would be higher data to markup ratio. LFSWorld data is lots of little chunks of data which XML puts a huge overhead on (when someone suggested XML for the LFSWorld sources, I think I did a quick test and came up at 7 or 800% overhead for an average host list at the time).

I may mock up a quick demo script of this because it has a plethora of uses, and the more I think about it, the more it makes sense.

(filur: You aren't a Java programmer per chance are you? )

Quote from filur :

Well that's about a million times more complicated than what i meant/had in mind.

What i meant was ..

<script src="http://example.com/host.php?MyServername"></script>
<script src="http://example.com/online.php?users=username,username,username&template=vertical2"></script>

document.write('MyServername, Aston North (12/23)');
document.write('username is offline');

Service provider would probably be using a local cache of the hostlist.

That would be JS aggregation
The snippet of the script srcs would be the HTML page.
http://example.com/host.php & http://example.com/online.php being the scripts on ServerX that make the LFSWorld request and turn it in to something easy for JS to parse... or in your case display it directly.

I think it would be better to just give it back in a var though than display it, or like I said before use JSON. The advantage to the latter would be that you could use multiple remote scripting techniques to fetch it, therefore it is more flexible, and since more than one language has JSON encoders & decoders, you aren't just restricting clients of the backend script to JS.

The reason for the var or JSON over displaying it is fairly obvious I think; it lets the user do more with it, or use it more than once without making multiple requests.

Theoretically you could do it with a JS implementation of an LFSWorld parser, but it would be slow, error prone and likely very very nasty. In addition, caching would be difficult, if not impossible so if you got any concurrent requests to you page, someone is going to have to wait for the tarpit to expire.

JS aggregation or pretty much any remote scripting technique that requests remote data from a backend script / program would be better.
The HTML page would have JS that requests a page on ServerX.
ServerX would have a publically accessible page that takes the racer name and maybe some other options as parameters, queries LFSWorld and then displays data that is easily parsable by JS (JSON for example).
The JS on the requesting server would then decode the data, and you could use at will...

There are loads of web pages documenting remote scripiting that'll let you get around any browser sandbox issues, but it would still require a script / program somewhere to convert the LFSWorld request in to JS parsable data.

Of course, you'll need full source access for either approach, so posting your status on other sites that you do not have source access to would not be possible unless they allowed remote scripting (which none do intentionally becuase of the security risk).