Since I have a G25 around at home and a pile of money that wants to turn into a big TV and a gaming console I'd like to ask a question:
Did anyone figure out yet how to make an Xbox think the connected wheel is Microsoft licensed? I've read a lot about it on the Logitech forums and apparently you could theoretically find out which USB-vendor and -product ID the Fanatec wheel uses and then make a little chip that connects between Xbox and G25 and acts as if the G25 were a Fanatec wheel. Add some force feedback algorithms and you should have your very own non-licensed Xbox to rest-of-the-world adapter.
I'd really like to support Forza 3. They appear to be on the right track, but Microsoft's hardware licensing policy is a rather big obstacle.
I wouldn't wait for such a list Arox.
I suspect the silence derives from the fact that you can't possibly see wether a new simulation model works well until you're finished. If there really is a new suspension model in the works, for the most part of it, it'll feel very bad right until you've finished 85% of the work, when suddenly everything falls into place and you can judge wether it's better than what you had before or not. If not, back to the drawing board and repeat the process. Thus there's no way to judge wether you'll include what you're working on in the public release or not.
On the topic itself I think the last posts of Scawen combined with what Victor said in germany indicate sufficiently that we'll see some good progress within the next half year. I really hope that the suspensions of all cars will be sufficiently unique to make a difference. If that's true it'll be a whole new game to discover.
By the way, I've moved to italy for a year without taking my sim-racing stuff and, the way things are looking, I won't be missing out on any new content at any point in time. Yay!
Actually, the way I see it, in WTCC, BTCC, V8, GP2 and every bike racing series I can think of people tend to fight over 10th place just as hard, or even harder, than the folks at the top. Really, I've never seen a driver give up without the actual need to do so unless it was a WTCC race where they wanted to repair the car before the second race.
I don't think though that arrogance is a trait only reserved to Hamilton. In F1 you just don't see people going for victory at all costs anymore. You don't get people risking to lose 8 points so they can get a shot at getting 10.
Neither do you see drivers actually getting agitated about racing. Back in the 80s, after a situation similar to Kubica's and Vettel's crash in Australia this season, the drivers would've shouted at each other trying to strangle the other guy. These days you hear them declare that actually the incident was no ones fault that that everybody should learn from the experience.
Vettel may be a great driver, but he's the worst of the faceless bunch.
At least on my singlecore laptop Opera 9.63 is vastly quicker than Firefox 3.5.
That's mostly to do with the way Opera responds to system events. It switches window focus or tabs immediately instead of having to think first like Firefox. It goes forwards and backwards also near-instantly while FF takes feeled ages to do the same task.
The addon-based SpeedDial for Firefox also completely kills the user experience. I don't want to wait for some 500ms to open a tab and see my preferred pages. Neither do I like it that Firefox takes a full tenth of a second to highlight the elements of the SpeedDial where Opera does the same task instantly.
Also, for some reason and contrary to what that study above claims, over here Opera appears to use less RAM than Firefox. Though that may be due to the setting I use in Opera whereas I used standard settings for Firefox.
On the bright side Firefox 3.5 doesn't feel quite as sluggish as older versions of Firefox did. So for people with the necessary system resources (e.g. dual core processor) it might be a good option due to the very good collection of addons.
I'm in no way an experienced programmer, but even in simple programs and even with a lot of discipline there *will* be difficult to identify bugs related to multi-threading.
A couple of months ago I started to develop a basic game engine that utilizes multi-threading. Even though I kept my game structure as simple as possible the darned thing will generate the most outrageous bugs.
So far I could only solve the issue by making the program switch between it's threads sequentially (physics thread finishes, GFX starts, GFX finishes, physics start, etc.) which completely defeats the purpose...
I can't imagin having to restructure a program that wasn't written with multi-threading in mind.
An example:
In a sequential program its a good idea to group e.g. the graphical properties of a car together with it's physical properties. That makes sense because a dented front bumper both has a visual effect and physical effects. Also an engine has both a physical effect and a sound effect. So why not stuff all these properties into a common data structure?
Enter multithreading. Up to now you thought you had a well structured program but now, since multiple threads can't work on the same data structure simultaneously, you have to treat a car's physical properties in one thread, the graphical properties in the other and have another thread to have sound effects. And you have to make sure that at no time one thread uses the other thread's data, so your sound thread isn't allowed to just ask the physical car data structure for the current revs. You have to either make the physics calculations stop for a bit, get the data, and make it continue or write some sort of moderator that distributes data between the threads. And in a complex program you have to be some sort of walking program data flow diagram to not at any point get your data mixed up. But if you get it wrong anywhere the program will behave oddly and cause crashes, freezes or unsynchronized data between clients (read: drop outs).
From what I've read from some developer diaries complex real time strategy games face a similar problem because they have to strictly differentiate between the shared network-state of the game and the presentation on screen. Most people propably noticed how long it takes the developers of such games to find random desync-bugs because somewhere an invisible object that is only created every 25th game uses a time-variable from the GFX-particle system to determin it's own life-time and thus causes a desync if the framerates of the involved clients are sufficiently far apart or something similarly absurd.
Bottom line: Switching to multi-threading is, in my mind, an extremely difficult job to handle.
I don't think that an InSim-system is a solution to the problem caused by InSim-systems.
I'd rather like some ability to filter out all servers that use an InSim-system or something like that. I didn't think a lot about it yet, but the basic thought is that you can't have carefree pickup racing if you have to study the manual of each server's InSim-system for 10 minutes first. I'd rather try connecting to an rFactor server because over there at least I get new cars or tracks.
Perhaps the basic functionality implemented in LFS also could to be improved so there is fewer demand for functions that, so far, only complicated InSim-systems can present.
Basically, for me, the problem is that every server is different, while actually I want to connect to a *random* server and just have some racing. I don't want servers to be different.
I only used CTRA because as a former STCC driver I had a free platinum license so I didn't have to bother with the points system at all. I didn't touch public servers since then because they are just too complicated.
So to conclude: Back then LFS started out with a very accessable online racing system but now all servers provide different functionality. LFS managed to get the same disadvantages as the modding scene of rFactor without actually providing the ability to add user-content.
Vain
P.S.: If you can't be bothered to read it all, just skim the marked terms to get the jist of my post.
Is it politically acceptable to own a Junkers watch in britain?
I have no idea how good their mechanical watches are, but I like the design of their corrugated sheet series and now use a Junker since my last watch broke.
...And I guess you will be able to find something that fits both your wrist and your pocket...
I wouldn't want to be informed that 4 of my friends are switching from some FOX server to an FBM server while I'm doing a quali-run in an LX6, so I'd rather see such notifications on demand.
On the topic, I still think LFS just needs more content. But I mean its content should at least double. And that's all I'm waiting for.
Though, since it's modern at the moment, we could alternatively start a break-away master server.
Naturally I'll be there for STCC2.
I still once in a while check the old stcc forum because I'm still looking for that last round of the STCC that never aired.
As a spectator I'd personally prefer a non-live version. It makes the broadcast a lot cooler because you (Becky) have some time to work on it and re-do all the mess-ups if they happen. "We're sorry for the problems with the overlays" doesn't really excuse for the fact that the live-overlay got all the driver's names or cars wrong. I'd rather see a non-live version where the overlays are properly fixed than a live version with issues.
For me watching STCC was about making space one day of the week, closing the windows, shutting off the mobile and watching a good show of action packed racing. A live-show can deliver that, but the recorded version will do it a lot better at a fraction of the work.
The trackvision stuff is really nice. From the sound of it I would've guessed you weren't brave enough to stay on the throttle at Gerrards and were struggling with understeer, but seeing the throttle inputs it seems that the injection system just dried out and you tried to keep the car straight to counter the issue. Is the fuel pressure perhaps not able to cope with the lateral acceleration or did you find another cause?
Oh, and are you struggling with oil temperature? The readout went from 60°C to 120°C, which is a rather significant jump...
@BBT: What you likely mean is that the geometry of the impeller is optimized for a specific ratio of gas velocity to impeller speed so the impeller blades are hit by the exhaust gasses head-on for maximum efficiency. Is that right?
That implies that if I wanted to I could equip a turbocharger with an impeller that works best at 4k rpm (the actual design factor would be the volume of exhaust gasses per second), but beyond 5.5k rpm the impeller would mostly stop converting energy from the exhaust gasses to the propeller but rather act as a block in the exhaust system because it's geometry doesn't at all fit the current situation (in this situation it'd only move due to it's friction against the exhaust gasses, not by expanding the hot gas).
On the other hand I could use an impeller that works at a high efficiency at 7k rpm, but I wouldn't be able to get the turbocharger to rotate very much before 5k rpm.
Thanks a lot for the answers. I still have a few questions though:
DragonCommando: Does the spark timing on your bike vary with engine speed?
I know that usually spark timing is given in crank shaft degrees past top dead point of the piston. If this was constant for the whole range of engine speeds then engine speed should have no major impact on the efficiency of the combustion because, at least I assume, that the time needed for the combustion is largely smaller than the sort of durations we talk about regarding the movement of the piston and thus the rate of change of the combustion chamber.
I think I remember that spark timing normally moves away from top dead point with higher engine speeds. So if executed properly this shouldn't cause a significant loss of power with high rpms.
I'm thinking of another factor though. The spark plugs also need to be charged in time for the next ignition, which gets progressivily more difficult with high engine speeds due to the large currents involved. A too low voltage in the ignition system will cause no or bad ignition and can thus be a reason for a very large loss of power within a rather small range of engine speed.
@Simpson:
I assume you attribute the loss of turbo pressure at large rpms to the upper limit of turbine speed due to friction? High engine speed means large a amount of air is sucked in, but at high turbine speeds the turbo generates a lot of friction which may disable it from providing the engine with enough fresh air to maintain maximum boost pressure. Am I understanding this correctly?
I believe Scawen mentioned that the current whole engine simulation is mostly a substitute for what is to come at a later stage ("stage" not to be taken literally ). If I'm not mistaken the engine simulation - at least on the user end of things - didn't change since the days of the first demo. Thus I'm very sure that Scawen is well aware of how things should work. I base this statement on the days when Scawen discussed the sound system and said that it can't be improved until the engine simulation is sophisticated enough to simulate everything that makes a sound.
But that's not the point I was trying to make with this post.
I'd like to know wether you have any more information on exactly how engines start to choke above their red line. I realize that the valve springs not being able to pull back the valves in time before the cylinder smashes into them in a rather painfull manner is one good reason for the engine to very aprubtly lose power, but I am under the impression that this is not the only factor that influences things.
I'm especially interested in what manner and for which reasons the engine torque at large rpms diminishes rapidly. I assume the fuel pump and injectors should be able to hold up on most cars and being a gasoline engine I'm sure the time needed to burn the fuel cleanly shouldn't be an issue either. What other factors influence the loss of power beyond optimum rpm?
I know for example that my own car choked itself to death just few rpms above the redline while I know from some semi-professional racers that a stock Porsche 964 engine will easily go a thousand rpm above what Porsche specified as healthy for it. It won't deliver a lot of power, but it saves you two shifts between corners. I'd like to get a better understanding on the effects involved in this.
Thanks for any replies.
I promised to look at race-media.tv and here's the first video I judge worthy of posting: This is an onboard video from the Tischner BMW in the 2nd race of 2009 of the VLN at the (at the time rather damp) Nordschleife. Some people may know the car, some people may see it when going to the 24h race this weekend. Most importantly the video features the opening lap with both forward and backwards pointing cameras so you can judge nicely just how busy the track is.
Vain
P.S.: And the Tischner car gets rather pwned by a Scirocco on the run up to Flugplatz.
I'm suprised anyone made a topic about that.
I read that, but it really isn't very significant. One example doesn't prove a theory. Positivism is not a method of science.
Actually showing that was the intention behind the wall of text in my last post. The method shown there still needs a security factor of 5 to 10 and is already complex rather complex.
Really, I think any proper analytical solution, at least based on the given problem, should be filed under "ad absurdum".
Actually I was very much expecting that sort of answer and give it full thumbs up.
From talking with people I always concluded that unhealthy weight is very often caused by people having a subconciously negative stance towards physical activities ("Exercising is a duty.") and a habitual attraction towards highly energetic food ("That's what I always eat.").
However I've never dared to voice that opinion because I never had to struggle with those issues myself.
I'm firmly convinced that the biggest obstacle any person can overcome is he himself.
Originally I wasn't going to participate in the discussion, but I'd like to ask you a question at this point.
I've recently started swimming almost daily (perhaps ... 25 days a month?) for at least an hour and it's been working out nicely, except for the fact that I'm actually running short on calories on my normal diet. I'm rather struggling to provide myself with the amount of energy I burn daily. I've always lacked motivation on that topic and tend to having to rely on nutritional supplements to stop myself from getting headaches/cramps/etc.
So out of interest I'd like to ask you how much you percieve yourself to be "holding back" on your eating habits despite the intensive training you're doing. I'm not looking for a too detailed/personal answer, rather just a general idea of wether you're actually applying discipline to your diet and to what degree - e.g. compared to your extensive work on exercise plans.
I think I said it a while ago already in this thread, but let me tell you again how much I admire your hard work. Especially running is something that takes a lot of willpower and I can only imagin how much additional work you put into other changes to your lifestyle. Willpower and determination are the characteristics I admire most in people and you've demonstrated very well how far those can get a person.
Did you know that you just posted the cars ordered by weight? Does that conclude that the fewer a car weights, the worse the driver is?
Obviously the reason is that a car that weights 0 kg is not going to achieve a laptime of 0 seconds (Fu&@ yeah, racing-zeppelins! :tilt.
Try calculating amount of fuel versus gap to Barrichello's Q2 laptime, that might just be a figure that says something.
Offtopic: The last lap by Jenson really was something special. I'm glad I watched the qualification.
Me too. It may be true that I wrote it, but if I had to read it again a couple of weeks later I'd also have to think hard to understand it. That's mostly though because it's in english and the formulae are formatted badly. Some LaTeX would help the formulae a lot.
Anyway, half an hour ago I was walking back home and had a thought about the issue. Maybe I can improve the estimation...
Let's start with a new assumed mechanism:
1. At the start of the discussion the journal is empty and contains no fluid.
2. The journal now starts to align with the oil delivery system.
3. Oil starts to flow into the journal.
4. The fail criteria is that the journal must be filled with oil up to the center of the bearing before it is shut off from the oil supply.
Let's calculate!
1. The backpressure (due to centrifugal forces) acting against the oil delivery is assumed to be constant as discussed in the last reply (0.36psi according to Tristan - actually that's the peak achieved once the journal is completely filled, but we'd like to overestimate the minimal oil pressure rather than underestimating it)
2. The two cross-sections move relative to each other at a speed of w*r. The time they intersect works out to be t = d/(w*r). At the beginning of this duration the intersecting area is infintely small, in the middle it's exactly pi*d² and at the end it's infinitely small again. Plotted over time the available area for oil transport looks like a sine-curve centred around 0.5*pi*d².
3. We neglect any time-based effects on the fluid resistance caused by the edges of the drillings and thus can handle the intersecting drillings as if they intersected with an area of 0.5*pi*d² for the whole duration of t. This is a very bad assumption. At the end of the calculation we should at least double the calculated minimum pressure due to the neglected effects here. Or just look further down and integrate the respective equotation over time - good luck .
4. During the duration t the minimum oil pressure needs to transport a volume of V = pi*d²*(D/2) (just enough to fill the journal to the middle) through a throttle of the area 0.5*pi*d².
Thus we receive a necessary flow rate of Q = pi*d²*(D/2)/t.
6. I treat the problem as an orifice plate with incompressible fluid (Wikipedia). It's bigger diameter is d, the smaller diameter d' calculates as follows:
pi*d'² = 0.5*pi*d²
d' = sqrt(0.5*d²) d' = d/sqrt(2)
Thus we can use the formula provided by wikipedia: Q = pi*d²*sqrt(1/(1-(d'/d)^4)*sqrt(dp/v)
(v is density, dp difference in pressure at the orifice)
(At this point you may want to use a more sophisticated formula. This one neglects compressibility. The wikipedia link provides many formulae.)
Rearrange: dp = Q²*v/(pi*d²*sqrt(1/(1-(d'/d)^4))²
And we finally receive the desired necessary theoretical oilpressure p as p = Q²*v/(pi*d²*sqrt(1/(1-(d'/d)^4))² + v*w²*0.5*D² + v*g*D
Modify as desired, e.g. multiply by two for security. But please repeat the whole calculation yourself. This post should only outline a possible method of estimation.