weisse8

Free Play Account
  • Content count

    35
  • Joined

  • Last visited

Community Reputation

0 Green Tag

About weisse8

  • Rank
    Member
  • Birthday
  1. What can i say? I don't believe it too, but it's gone somehow. From my point of view it could be related to 1.28 just as well (never tried that on the old sys, not active then). But no game-stopping stutters over cities anymore - i just don't know, why. The usual explanations (reinstall game/OS, new drivers,...) don't work, 'cause the old pc was as "fresh" as this one is, in it's time slot, of course. And all other games i used to play just ran smooth at 1600x1200. When the stutters occured i tried a lot of setting-combinations, NT4 and SSE and all of that stuff. None of it worked. But may be it will work for you. Good luck.
  2. Yes. Could be. I wish i could tell but the other comp is down. So i have no clue. I recall some "intel too" posts, but i may be wrong. And, to be honest, this would be the only app i've seen personally in the last two years which would have had that problem... and, strange, only in special circumstances ("over" cities).
  3. Thx all again for the useful tips. I've tried some (especially reconnecting). However, it turned out to be kind of a hardware problem. After a while i was not able to get it to normal behaviour whatsoever, neither the local vendor was. The new x52 (#3 for me now) does not have that problem at all. At least until now
  4. Had quite the same problems with 4600+, Asus Mb, 2 Gig, 7800 GT. 2 or 4 or 6 seconds with one frame per second. Personally i agree with barkas' pov: the game should run with his pc, as it did with mine pre 1.27. In my case i happened only over cities in the air at low altitude, not anywhere else. On the ground in the same city i've got 30+. In any other area in the air i had 50+ (1600x1200). When i've been over cities (and if i survived), it never got more than 25+, even while landing on an empty AF in an empty area. Until i despawned. Just some notes: 1) The "stutters-over-cities-low" all of sudden appeared with 1.27 and never stopped since. Before that there were only minor (and solveable) problems. I unsubbed at november. 2) I can't say if that would be still true now... the pc died january. I resubbed march i think (1.28.4) 3) Believe it or not, the new PC does never stutter at all: still XP Pro, still the same isp, still SB Live! 24, still 2 Gb, same periphals (joystick and stuff). "Changed": 8800 GT, E6850, mobo and some standard hdd (nothing special). Best regards.
  5. Agree with that. And that's what Saitek says about that, too, as i've tried to say in the "Yes, you can't" post. Only time will tell, if this is still true in a couple of years of heavy usage Good suggestion.Well, i did, at least kind of. Since the y-axis is "reduced in smoothness" (don't beat me, i am not a native speaker ) and range and direct reaction i've pulled even harder, cause i needed to in order to keep the plane in the air. Actually i must pull the stick back at max in order to do so, while the game reacts as if i've pulled it at 50% - with delay. And it's not only in the game: the properties window shows that behaviour, too; imagine the cross, which will whether touch the top/bottom border of the box nor move below/above about 50% of the available range (from 0,0 to 0,min/0,max) of the y-axis, and the movement is not linear, too. And the x-axis isn't affected at all; it has full range and normal behaviour. That's the most strange thing for me. I would expect a randomized behaviour depending of the given stick position. But it is only the y-axis. And the center is still the center, if you know, what i mean... it should move up or down, if there would be a problem with that. Oh, and very important: I don't blame the game for that; after the incidents it does, what the stick tells; but the stick tells rubbish. I only blame it for the stutters , of course! Never had those before 1.27. I've allready thought of turning it in and get a new one. That would be the third ... (Button #6 of the first didn't work, no complains from my side, can happen). Weird.
  6. Ok... didn't know that. How does it calibrate itself without reaching the maxima/minima ("moving the stick?"). As far as a know calibration was just a term for getting the actual mins/max of the two axis potentiometers*? But however, i don't believe it is a calibration problem. I still think, it "happens" after stutters. But i still can't proove it I just can say: It never happened, when there were no stutters. edit: Hum, yes, it could take it's own center every time. But that's all. *And all the other potis, sliders and throttles and wheels and... . Loads of them. Amazing. First day i wasn't able to find a button, which was in the properties window for the click test... but where could one find it on stick?
  7. Yes. You can't. It seems like saitek believes the top-down center-construction and the "contactless" position measurements won't ever need a calibration. We'll see that. However, it is possible with other joysticks. My XP offered that option for my M$ sw FFB2, e.g., without additional drivers. I am going to believe "Decalibrates" was a very bad choice to describe my problem edit: Oh, and it happened again... but now i am able to detect it very fast, and a swift reconnection still "solves" the problem - even in flight!
  8. Hi all, first of all thx very much for the answers and hints. Wasn't able to read here for a couple of time, so i didn't post before. Don't be upset. I've bought the stick and therefore loaded the drivers and the softwarepackage (5.5.0.82, 4.3.3.2059) just a week ago. I've no other device like a G15 or smth. like that... well, besides the mouse, a G5. I've checked the power comsumption, and following the letters it is enough - no single device exceeds the limit, the peek is 286mA, totalling to something about 590 mA over all devices. Now the description in my language says: 500mA per device. The term "decalibrates" is false... there seems to be no way to calibrate the X52 with the standard software, that is correct, sorry for that. I just wanted to describe the problem with one word - "decalibrates" - which is not, what was really happening. However, it is just strange... Only Y-Axis of main joystick is affected; it is reduced in range, and it doesn't "react as fast/smooth as before" and has a little delay; it is "reset" by reconnecting it while the game still runs and than all works as expected (again). And to be honest: I simply don't know, how long it was like that, before i recognized it the first time, if you know what i mean. One gets used to it, well, kind of. Aiming is difficult. So if you have problems with aiming in zoomed state 'cause the planes is jumping in the y-axis... go give it a try and check the properties of the X52. Since then i have the properties window open in background so i can do a quick ALT-TAB check. Now, this incident might be only hmm... sporadic? What is the word... it happens only from time to time? So far i can say: it didn't happen again. I just never heard of a problem like that before.
  9. Hi. Thx for answer. I allready have the actual drivers, shutdown that profiling crap (i didn't need it and now i am searching for the reason, so it had to leave ) , set up everything i need in the keymapper and all works fine - until all of sudden it is reduced. I *think* it depends on the stutters over cities... but i can't proove it. Weird, isn't it?
  10. Hello it might sound weird but i keep losing the y-axis of the joystick, which responds only at 50% and reacts with "stutters". On USB-reconnection everything works fine - for a while. Let's begin with the lift off: On start everything works fine. The properties window of XP gives full range on all axes. Flight is "normal". But after i "stuttered" over a town (Ciney that is today) the y-axis is reduced in respond; first, the range is set to about 50% to 60% in both directions from zero (up/down). Second, there is a slight slowdown of the joystick respond on that axis. This happened two times now. Any hints? Oh, more info: I've allready shutdown SaiMFD.exe and ProfilerU.exe (or whatever they were called), removed them from registry and restarted the comp.
  11. Oh, man. Nobody of us has seen the code, but everyone knows exactly, what that game needs and where the problem is. I'm not here to play games with other users in the forum, prooving how uber i am and what a brilliant hardware geek. And i definitely won't post Tom'sIAmAlwaysRight pages, even if i have to say: /cheers, ma, i appreciate your tries to explain things to wood-heads . (Sorry, no offense meant ). But that is not the problem. To repeat it: 4/5 of my (small) squad have PROBLEMS with THAT patch; these problems are NEW and UNKNOWN before - AND allready cause one of to take a break (as far as it seems). The problem consists of the following: 1) There are new (and very intense) stutters, introduced with 1.27 1b) New := not there before 1c) really! 1d) not to mention the various crashes (of course) and audio 2) These stutters are bound to certain circumstances, in most cases (aka flying over a town low) and ARE kind of PREDICTABLE. 3) Being on ground in the same city 30 secs after (death) does not cause any stutter 4) U start with 90+, and if u land, u land with 10+... always. WHY? 5) There's no real help. The "old" tricks don't work or are set allready. I've tried it all, and i am tired of it. 6) There's no off. hint, no workaround, not even a: "We know it" or did i miss something? I asked for a reference setting of QA only to try it. Nothing. 7) Well, however, i am not a "supporter" (like it is called a little pathetic on the new load screen) - i am just a gamer. If this won't work, i won't play - and pay. That's easy.
  12. Me. AMD X2 4600. Had the fps-problem! (all of sudden drop to 1 fps at ground for minutes!) Solution was to disable second core and disable Thread optimization in nVid-drivers. Always thought, both of them point in same direction: Thread sync. U simply can't recompile ur old code in a new compiler with "full support of everything" and expect all that suff to work fine . The stutters and fps were completely gone after the "reduce" to one core. One Core->no Thread sync problems u didn't have experienced allready while coding this. Two cores: part of the program can be "faster" as u expect them to be... and if u wait the wrong way, u may wait years for something that has allready been finished (on the second core) when u started to wait. Then things like artificial stutters may occure. But, hell, i never saw the code of this game. It might be something completely different Oh, and i have the fps-problem again. This time i can't get it to work. See FPS...boy thread.
  13. Sorry, my information may be somewhat outdated, but the solution to my earlier problems (1.25) was to set the affinity to only one core; otherwise i've experienced fps-problems on ground AND in air. So i thought, since that setting *is* changed right now, there's really a problem with two cores. Is that true or false?
  14. Hi @ all just my 5 cents Low fps hit me real hard that patch. AMD X2 4600+, 2 Gig, 7800 GT Air: Start with 90+, fly to target with 60-90, patrol over target with 40-60 (drops to 15 looking down), but following a diving ea to target below 2k results to one frame each 3 seconds(!). *If* i survive that, the frames will raise again, but not to more than 25... in some (most) cases it'll stay like that until i land on my "origin" AF (the spot, where i had 90+ at start), while the situation there (numbers etc.) is comparable. That's pretty strange and i don't believe it's a system dependend issue. 1) In earlier versions some workarounds existed, like tweaking nViddrivers or setting the _sse.exe to use one core only and stuff like that. But none of them help me now, e.g. the 1.27_sse.exe is allready SET by default to use one core only; i just swap from 0 to 1 right now. 2) My settings use ~1.55 GB at max, currently; since there are 2 Gb phys and additional 2 Gb virt, this does not cause any problems... except SmartHeap dies all off sudden, which it didn't since i started to run the mem-measurement in background last Tuesday. 3) I tried some of the new hints, like dis- or enabling the frame run ahead, trying some shadow settings, but believe it or not: it does not change much. Unfortunately. The "pattern" of the problem seems to stay the same: consumate something and stiff my graphic/memory with unfreed blocks until the exe dies and/or i leave the area. It would be nice if the QA teams just would publish their settings (complete!)... for testing purposes. I'm tired of switching on/off something, fly 10 minutes and die by lag-attack over a town - and i still wonder, what FOV/LOD changes, Dithering and things like that could do if they are used properly in the one "top-secret" combination of switches that might work. Nice trap, xen. But u rather should put some dollars in it and eat the cheese yourself. Word is that seems to work better
  15. Sorry, can't edit my post SB Live! 24bit hardware 64 infrequent alerts enabled music disabled