Jump to content

stupor-mundi

Members
  • Content Count

    257
  • Joined

  • Last visited

Everything posted by stupor-mundi

  1. When these threads come up, and big discrepancies emerge between different posters as to what the situation (or ability of the engine) is, there's a recurring theme I think: The O.P. usually silently assumes the context is multiplayer. Then people respond, contradicting, and it turns out they do experiments offline. When this happened to me in the past, I had to concede that the engine can render planes up to 10km (or more, dont want to get into that fight). Many of us, in multiplayer, experience spotting issues, which I think aren't bottlenecked by what the engine will render, but rather, a client/server thing, often called a 'bubble', but which is distinct from the 10km rendering bubble, where you overfly an area and you're only presented with the contacts once you're far closer than 10km. Something similar, but slightly different, happened to me just now on the EFront server. I was driving around in tank, hatch open, looking at an AI stuka. It kept disappearing and reappearing. It's wasn't very small at all (distant), not: a single pixel or something. It was a bunch of pixels, not a compact blob, but vert stab distinguishable and so on. It wasn't flying away or approaching, but going perpendicular to my view axis. Then I realised I was playing around with the scroll wheel. When I zoomed out all the way, it disappeared. When I zoomed in a bit, it appeared again. When disappearing, it didn't decrease in size until disappearing, it disappeared, bang, going from multipel pixels across, to transparent. To confirm this, I played around with the zoom for a while, turning the plane on and off many times. This was an AI, so I tried to do the same thing with a player controlled plane nearby, where it didn't work. No idea if the distance wasn't right, or if this only happens with AI, or what determines the outcome. I'll continue to try and replicate that with player controlled planes. -- Edit: just went on EU official normal (with icons) to estimate how far away that stuka must have been. I'd say around 3.5 to 4.5 km.
  2. My laptop's fan wasn't sounding sketchy today, so I did some more testing. There were plenty of player-planes on the EFront tank server, good opportunity. The thing that pushes down my displayed fps more than anything, and causes microstutter to the level of slideshow, is, when in a tank, getting strafed by cannon, when looking at the plane (and, therefore, the shots, and explosions). Assuming multiplayer of course. That didn't occur though. I could establish though, that fps (and visuals) degrade rapidly, when (being in the cupola, with the hatch open), looking around in the sky rapidly (i.e. horizontal change), when there are (player controlled) planes (there were about 8, nearby) in various sectors of the sky. I was able to push down displayed fps below 20. There were no cpu spikes which correlated with the low fps, cpu remained around 60ish (on the most loaded core) max. The other cores lower. But checking the GPU in task manager (why hadn't I done that before??), the load was steadily close to 100%. I don't quite know how task manager gets the gpu load, over thunderbolt, but I have to assume it can, and the values are legit. So, this is just mind bending. It's pretty clear that cpu is not the bottleneck, but gpu is. My head hurts, trying to come up with some model of how this could work, that, in multiplayer, a 1070 can't do the job of rendering the scene properly (at 1080p), when offline it's clearly no issue, not even close. The only thing approaching an explanation would be that object position updates that come streaming in, cause IL-2 to throw away most of the rending work the gpu has already done. or something.
  3. In addition to using keys for forward/backward, it's possible to bind a joystick axis. When a joystick axis is bound, AND it's being used, IL-2/TC switches to a slightly different mode for the forward/backward keys. I used to prefer the default (without axis) behaviour, but I want to get used to the joystick-axis based behaviour, because it enables stealthier crawling. It's also possible possible to bind left/right to an axis, but I found that very annoying, so I haven't bound that. At times, axis behaviour has been entirely as expected, for entire missions. But, intermittently, there is a strange behaviour where, after driving fast, I move the axis back toward center, to slow down, or even halt completely, and then, after 2, 3 seconds or so, the engine howls to life and the tank starts accellerating again. A slight nudge on the axis reminds the sim that I wanted to go slow, but again after that interval, the engine revvs up. and so on. So the tank lurches forward in fits, until I turn the engine off. I first had this effect when using a midi device with a virtual joystick (vjoy), so I suspected that was to blame, but now I've tested it with the throttle axis on my real hardware joystick, and it's the same. Did anyone else get this effect? Since this is intermittent/erratic, it would be good to know what sets it off, and how to exit out of it without having to abort misson.
  4. I'll try it out. However, I'm more interested in understanding the logic behind what's happening, or rather, whether, based on the 1070 gpu I've got, I shouldn't really be able to expect not having to deal with such a trade-off. I think I forgot to mention anywhere above that my resolution is 1080p. Should be a picnic for a 1070 really. Since the stutter, which I believe is worse, and diffrerent from, the simultaneous fps drop to around 40, is multiplayer- and busy-area related, I find it weird to have to address such a thing with graphics settings. It makes no sense to me that rendering the scene which normally is no challenge to my gpu, should become a challenge when there are some planes present, in multiplayer, whereas the same thing, offline, would be no challenge at all. Yesterday my laptop has started acting up again, with noises indicating a faulty fan, after it had just been exchanged back in November. My main angle at the moment is to suspect that cpu might be the bottleneck, and so I'll just give up trying to debug this until the machine is fixed. I just checked the cpu core temps which are high-ish, under no load, so it may be that the cpu was throttling when I tested earlier today. -- To verify my point above, in spite of the questionable state of my cpu cooling, I did a quick mission with 2 flights of friendlies (of 2 friendlies each, including me), and 2 flights of enemies (of 4 enemies each), face to face. So I was in a tight space with 11 planes, and my fps counter was glued to 60, everything looked entirely smooth.
  5. Interesting how these settings can have inverse effects for different people. Are you using Vsync? I have a 60hz monitor and am using Vsync. For me, what helped to reduce microstutter (to my current level), was, to turn in-game Vsync off and turn Vsync on, in Nvidia control panel, and to turn fullscreen ON. Have just tried with fullscreen OFF, again. It apparently makes the Nvidia Vsync setting powerless, so I had vsync off apparently, framerate went, at times, above 70, but looked FAR worse. But, in a tank, in a busy area with planes, looking at the planes, framerate went down below 40, stutter was at least as bad as before. So, just for kicks, I turned in-game Vsyc on, now fps are again limited at 60, go down as before in a busy area, microstutter is certainly not better, but maybe worse. Interesting experiment, I'll go back to my normal settings now Regarding windowed, please see my other reply. Regarding 4k textures, I have them on, that's my normal setting. Regarding CPU, I will try to investigate that. I used to have trouble with multitasking, but since I run IL-2 as admin, this has improved. So maybe I'll be able to use task manager to see what the cpu load is like. I did some tests with task manager. My cpu is 4 core (8 logical), but task manager only seems to show an aggregated view. I drove around on a completely empty server, and then on a busy server (tanks+planes), where my fps dropped below 40. The shown cpu load tops out just under 40%, interesting, on the empty server the percentage wasn't much lower. First I thought that means cpu is fine, but considering that IL-2 *probably* is bad at using many cores, maybe this means cpu IS the problem. I will try to get some better diagnostics, showing all the cores. But yes, it looks likely that's the issue right there.
  6. @Hylo , it seems we are thinking along the same lines, as to the potential mechanisms of this microstutter. As for such speculations being somewhat pointless, I don't quite agree. I'm trying to establish whether my experience of microstutter is what the mainstream experiences, especially people who fly (and maybe tank) on the same servers, but who will have different hardware, and many will be in different locations. To exagerrate it a bit, potential outcomes could be: * it's purely to do with the netcode on the server, nothing the player can do, local hardware wise, to improve it. * the above, and has to do with how overloaded the server is. flying on less stressed servers will solve it. * it's purely to do with network latency, nothing I can do as long as I'm in the UK and the server is far away. * the above, but, as a player, getting faster broadband improves it a lot. * it's a cpu bottleneck, a low wattage laptop cpu can't do the job * it's caused by the extra delay between gpu and cpu, which happens when using an external gpu over thunderbolt. Need a desktop PC. * using a regular 60hz monitor is hopeless, you need a gaming monitor and more variations like that. So I'd be very keen to find out whether my experience is an outlier, or that amount of microstutter is just considered normal and you have to put up with it.
  7. tomtom. did you fly there?
  8. I used to fly on Warbirds, around 2000-ish. While the 'main arena' there, was with icons, there were others without icons. Even without icons, plane visibility (if memory serves) was much better then than it is in IL-2 BoX. I believe they must have resorted to, let's say, rendering tricks to achieve that. At the time I wasn't aware that that was the case, I only conclude it now, when comparing it. Since displays usually had a lower resolution, people didn't object to such subtle visual aids at all. The view back then would have been, that people recognized that the imperfect displays are worse than viewing IRL, therefore some rendering help to offset this disadvantage was called for. Whereas today, regarding naturalism, the general view seems to be, that the displays are so good that a plane should be rendered no larger or more contrasty than it would appear IRL. Personally, I would prefer it if there were options (let's say, 'servers' or 'maps'), where there'd be, some subtle visual reinforcement of planes, to make them easier to spot. Obviously this kind of thing couldn't be up to the player to choose for the 'expert' servers, for the sake of fairness. I currently mostly fly 'normal', with icons, because I constantly loose track of planes on expert servers, but I'd prefer a more subtle solution over icons.
  9. Further in the past, when I ran IL-2, there was quite strong microstutter. I played around with a number of graphics settings (there are a number of threads about this), which improved the situation. Microstutter, as I encounter it in IL-2, goes hand in hand with a framerate reduction, but is perceivable as different, more disruptive. I run Vsync 60 Hz. At microstutter, the fps displayed drops from 59/60 to for instance 45, but there is a visual disruption that is much worse than you would expect from proper 45 fps. Longer halts, multiple per second usually. After my graphics settings improvements, in multiplayer, in most situations, there is no microstutter. On populated servers with large maps, like WoL, I can tell, when looking for the combat area, when I overfly an area with action, by the microstutter (and displayed fps), that I have found it. On those servers, I think there is a 'visibility bubble' type multiplayer problem, which is often misunderstood as a visibility problem, where you seem to be flying around as a lonely plane (typically at high altitude), until the server finally (belatedly) recognizes that you are in a geographical box with some other planes, at which point you suddenly can see them, and at the same time the microstutter starts. I.e. you typically don't achieve what you would want, to have visibility of another plane (ideally just one) as soon as the 10km visibility boundary would allow. Rather, unpleasantly, you fly around in a desert, until you dumped into a phonebox with unpleasantly many planes. It seems, the more planes are in the 'bubble' with you, the worse the microstutter will be. When driving a tank, when there are only tanks, no planes, there is no microstutter. I find this interesting because you are in a small 'bubble' with more 'player vehicles' than otherwise. When there are (player controlled) planes, there is microstutter and it can get very extreme. So the speed of the 'player vehicles' seems to matter for the microstutter. I run on a quad core (but low wattage) laptop with an external GPU, 1070, of Thunderbolt. I find it interesting, but confusing, that initially, changing some graphics settings helped somewhat, but at the core, the microstutter seems to be a multiplayer, netcode related issue. So I wonder if others who use an eGPU have similar experience, and whether I could expect an improvement if I move to a desktop type machine with a graphics card right in the machine. Considering that the issue clearly has to do with multiplayer, the client and server locations might matter more than the client hardware. I am in the UK and most servers I have used are in Russia (and where the other clients, players, are, will matter).
  10. I think the problem with the exagerrated effect of HE is not 'russian bias' as is claimed here a lot. Yes, it gives the red side an advantage, T34 facing off to Tiger, front to front, relative to the real tanks, because T34 IRL wouldnt get through the front tiger armor. This is a modelling error, but I don't think it's selective. When I hit T34s from various distances with the Tiger 8.8 HE, they are on average mostly taken out with the first hit, sometimes 2, sometimes 3. This is still better than the effect of the T34s 7.6 HE against the Tiger, where a 1 hit kill can occur, but is rarer. The tank most disadvantaged by the exagerration of the HE effect is the Pz3, with its smaller caliber gun, I think. Funnily though, shooting at the Pz3 with the T34s HE is still relatively ineffective, maybe to do with the shape or how the armor thicknesses aren't varied as much? IDK...
  11. In a recent release this locking functionality has been improved. Before, the lock always disappeared and you had to re-set it at every mission. Now it remembers it which is a HUGE improvement. But yes, with the multiplayer as it currently is, where you're kicked out the commander seat and denigrated to driver, I can't imagine that anyone would ever want that to happen to them. As the driver you have zero situational awareness and are just looking at the grass right in front of the tank.
  12. That's certainly true IRL, I mentioned a thought experiment in a post in this thread (drones vs civilians). There seems to be widespread view in this community that because "it's a sim, not a game", whatever is the case IRL should be the case in the sim. But really this is a multiplayer online application (I'd say 'game', but whatever) that has to be attractive. Not every aspect of reality makes a fun thing you would want to spend time on, online. If this were the kind of online multiplayer application where you have a central game server, and only the 'missions' available on there, no alternatives, you could possibly force people into that, to some degree. But since this works based on game servers that people put up voluntarily, if there are some to choose from, and tankers have a choice whether to endure being bombed or not, they will simply choose not to. At the moment we have the situation that the tanker community is so small that such a mechanism doesn't apply yet. Blue tankers need red tankers, to have something to shoot at, and vice versa. They are dependent on each other. The same doesn't apply to attack planes. So TC would have to come up with some mechanism where the attack planes are needed, or at least, quite useful, from a tank point of view. That usefulness would have to be quite compelling to offset the massive annoyance of getting bombed.
  13. I've set those values to bracket the pixel sizes that actually occur, from Opentrack's point of view. I.e. trying to force the max value smaller than the max that really occurs doesn't help. In the end the occlusion that occurs has to do with the actual size of the LEDs in relation to the overall size of the clip (or rather the LED locations on it). Even lowering the threshhold doesn't help once it's low enough to prevent glare. Once the glare is gone, you have the actual size of the LED, as projected, and lowering the threshhold further just gives you something dimmer, not smaller. That's why I mentioned blurring as a possible solution (speculative, haven't tried it). ---------- Regarding the view pyramid: I might play around with that some more. I'm not a huge fan of the wide setting because on my PS Eye the optical quality of the wide setting is quite a bit worse than the narrow. Considering the wider pyramid, it will help a lot with the head position further from the screen, and only a bit when bending forward. And the question or camera orientation, and what xyz are, becomes even more important in that regard. My camera is center, top of the screen. To best have the clip visible in the head forward position, I would angle it strongly downward and a bit sideward. But there is no place in Opentrack where you enter those angle values, and I'm not sure the 'calibration' step informs it of those (it might). So I have the suspicion that xyz might be from the camera's point of view, no matter how it's angled (which would be bad). All those issues lead me to consider a gyro based solution, where you're not having to deal with such a view pyramid, or orientation issues...
  14. Apart from you, nobody really liked that "punish time" feature, at least from what I remember, how people were commenting in the chat. I don't like it, and I don't think the absence of that feature makes me a reckless tanker. However, if it was possible to have such a feature specifically to slow down switching from tanks to planes, rather than a generic 'death penalty', that might be a positive thing. Currently though, I don't observe people switching to attack planes when they can't win in tanks. The large number of attack planes seem to be people dedicated to that role. IIRC, there was a post about the reason for the 'death penalty', and it was nothing to with changing player behaviour. Rather, in the time of the server crashes, it was done to make them crash less often. Since the crashes already got fixed in Dserver months ago, I don't know why he didn't remove that setting. It clearly turns players away.
  15. We've been now through a batch of days where almost solidly there has been a strong numeric unbalance favouring red, mainly red planes. One factor will be that blue tankers' numbers are lacking because they are unhappy with the current DM (the unrealistic power of HE ammo). The other factor is the groups of attack planes that join red, no matter what the balance is at that point. Is this because they all prefer the IL-2? Not a great explanation I think considering the 110 is pretty attractive as an attack plane. I come up with this explanation: People who join a tank server as attack planes, with the intention of shooting at tanks, aren't super keen on air to air combat with other planes, especially fighters. So joining on one side in numbers increases their survival chances in that respect. The fact that the unbalanced mission becomes totally pointless for tankers doesn't bother them that much. If there are only very few opposing tanks, that's not ideal, but not that bad either because as soon as you blow them up they respawn. The effect this mechanism has is clear--the tankers on the disadvantaged side become annoyed and drop off. The tankers on the advantaged side get bored by the lack of opposition and drop off as well. If you join the server with the intention of joining as a tank after this has been going on for a while, you look at the map, you look at the numbers, you feel you should join the weak side but you're not keen on getting bombed, so you just leave instead. That's what happening currently in my opinion. Tanking is decreasing on the tank server. PS: I used to think an unbalance favouring red TANKs was appropriate, but with the current DM (and trees being shot obstacles) this is less so than it has been. an unbalance favouring red planes is not appropriate I think, but I'm no expert in the relative strength of the attack planes.
  16. Yes, that's correct. However, it doesn't matter as much now as I thought it did just yesterday. Since I discovered I had had the wrong idea about what Y and Z were (in opentrack), I've improved my mapping quite a lot, so, looking back works fairly alright now, even though purely by pitch I can only look up 90 deg., if I then twist my head a bit I can see back quite ok.
  17. I've dimmed them quite a lot, not sure I can get them much smaller. I'm about 1 1/3 feet from the screen, so I suppose that's in relation. But good idea. Maybe if I apply a blur filter, and then dim them more, I might get them smaller.
  18. From around 11px to around 13.5px They could be a fair bit bigger, if I hadn't toned them down quite a bit using the filters.
  19. I'm afraid I find the way Gramps writes it to be ambiguous. Before I go crazy looking for a mysterious factor of 0.5 in my local setup, I'll wait for someone to try it out and confirm they can actually look back all the way, by looking up. Other than that, I just discovered that Y and Z (in Opentrack) are reversed from what I had thought. So, whereever I had mentioned Z in my posts above, in Opentrack terms, I meant Y. Maximum confusion now
  20. Hi @sniperton , that would indeed make sense, after all, if my interpretation had been right, and yours wrong, the 90 degree setting in the GUI would amount to only 45 deg. up and 45 deg. down, which is just crazy, right? I just re-checked it. The 90 deg. setting gives me that, 45 deg up and down, and the 180 setting gives me 90 up and down. I'm running a version from last March, 2.3.49-plus-48-g.... Also just DL'd the latest beta, no change. If your Opentrack behaves differently, pls let me know. It would mean there is some wrong with my setup.
  21. Hi all. I currently use Opentrack with Delanclip and a PS3 Eye camera. I've now concluded that the difficulties I'm having have to do with the geometric limitations of this approach. I have my face closer to the monitor (27") than most setups. The camera, in the center, on top of the monitor, has to look down quite a bit. When I move my head closer to the screeen, in order to have the Y input, occlusion quickly occurs (2 LEDs get too close together, tracking stops). Apart from occlusion, when close to the screen, with some headmovements, some of the LEDs are outside of the camera's view pyramid. I used to have the camera off to one side on top of the screen so that it was centered on the clip, but realized I had to move it to the center in order to straighten out the Y head movement. Now the occlusion and clipping issues are worse. I could switch to Trackhat, but I think I'd still be fighting with occlusion and clipping, just at different head positions. Also I wouldn't want an actual hat which would interfere a bit with my headphones, so it would have to be something that has the hat geometry without being a hat, i.e. a horizontal clip onto the headphones. So I'm wondering what the situation is nowadays with gyro sensor based solutions. I don't want to use my phone (which is large), rather I'd like something that's permanently stuck to the headphones. Could be wired or wireless. I've just looked at the EDtracker site, those are currently sold out. Are there similar trackers that people have tried and found to be good? And would OpenTrack work with them or what software would be used instead? I'm not too keen on having to assemble/solder something, a product-type thing would be preferred. There is a wireless one "Nx Head Tracker", has anyone tried it?
  22. I'm a little surprised, in this, and various other multiplayer related threads, about the topic of server restarts. It appears to be a thing, something of a challenge. IIUC, this is about scripts to restart the IL-2 server application, i.e. detecting if it has exited or is hung, and then restarting it. I.e. not a crash of the entire OS, just this server process? I'm not familiar with windows server things, but on the surface this doesn't sound like a hard problem. Unless there is something about this particular server process that would make it challenging. So, if this not an area where the different groups which put IL-2 servers up, compete for excellence, maybe someone who already has a script working for achieving this, could just post it in one of the forums here, and the others could just DL it and use it? Or is that hopelessly naive?
  23. I'm quite happy with the opentrack behaviour resulting from the settings detailed above. There's one more, non-naturalistic, thing I'd like to achieve I think: The 'pitch' tab of the 'mapping properties' window has a 'max output' select which can be either 90 or 190 degrees. I.e. when you look up as far as possible, you hit a hard limit, in many planes before an obstacle such as a headrest would obstruct the view. I thought I was hitting an input limit to do with the geometry of my camera setup, but it was actually this output limit. I tried playing around with that in the config file, where under '[opentrack-mappings]' there is the 'pitch-max-output-value'. When the Select in the GUI is set to 180, this is, in the file, -180. I tried editing this, set it to -210. Once edited like this, and opentrack is restarted, it's not possible to edit the curves anymore. Putting it back to -180 restores that functionality. Somehow though I don't seem to see much effect from this, so maybe * there might be an internal limit at 180 * some interaction, maybe with the spline, prevents it from kicking in Or maybe I'm wrong and it really does work? Has anyone else tried playing around with this in the config file?
  24. At close range, you can aim at the cupola. Thus your chances, at very close range, of making the round go off right on top are pretty good.
×
×
  • Create New...