Jump to content


  • Content Count

  • Joined

  • Last visited

Everything posted by stupor-mundi

  1. Formally speaking, this should probably be in the general multiplayer section, and not in tanks, however, on a practical level it's an issue I never encounter when flying. This is about the specific issue of ping degradation when under fire in a tank, with the result of "player kicked due to bad ping". I.e. not about players kicked who actually have bad ping, but a multitasking issue that is I believe graphics related. This used to happen to me, sometimes, when being strafed, and specifically looking at those many little explosions. It was often possible I believe to rescue this almost-kicked situation by looking away from the explosions, for instance by looking through the sight and being zoomed in. It pretty much never happened when being under fire by tank rounds. On my hardware (laptop with external gpu, 1070) CPU never managed to get near being bottlenecked, it was always the GPU that was limiting. I really have no idea how graphics overload can cause bad ping when there is plenty of CPU capacity left, but being strafed and getting kicked due to ping were clearly linked. I reduced the occurrence of this hugely by setting a dynamic resolution factor of 0.8. Now with the new version, everything else being equal (same tank server, same broadband, same hardware), there have been radically more kicks due to bad ping. Each time it was when I got shot, but now, a few times, when I got shot by a tank, which never happened before. I've set my d.r.f. now to 0.7, so far it hasn't helped. When this happens, when getting shot by a tank, my graphics-based explanation which had neatly worked when this only happened when getting strafed, doesn't make as much sense anymore. Does anyone have an idea of the mechanism at work here, and what to do about it?
  2. 1) Fix the invisible trees 2) Fix the invisible trees 3) Fix the invisible trees ... 10) Fix the frantic mouse in periscope sight in the T34
  3. In light of the revelations (to me anyway) on the nature of the commander of the T34, vs the loader, I won't insist that it would be appropriate to be able to instantly jump into the loader's open hatch position. I admit that would be silly. However, regarding the slow movement between the open hatch position of the gunner, and the on-sight position, I think that, even though the switch feels slow, opening or closing a heavy hatch will take that time, but it would be very helpful to have the option to more quickly jump inside, to the sight, without closing the hatch. Regarding the lethal mouse overreactiveness when in the periscope sight position, I've played around with that position in the KV a bit now, and it's much more manageble. It appears as if the new functionality was developed/optimized for the KV and some parameters just haven't been adapted/dialled in for the T34. It would be nice if that could get fixed. Since I've begun trying out the new T34 this mouse issue has been my #1 cause of death.
  4. Yup. If the overworkedness of the commander/loader has to be modeled by giving the T-34 a slow reload time, fair enough. But, the way I see it, when I pilot a tank as a single player, I'm all of the stations and should be able to jump between them instantly. Why does it have to be the gunner who opens the hatch? Sure, the new visor is nice, but I regard the crippling of the station jumping as unjustified. Now that I've played around more with jumping between the 2 sight-types... the exagerrated mouse sensitivity when using the periscope sight is really what turns the new tank into a death trap. No 'realism' argument works for this UI failure. The new gear limiter functionality is nice, and recovers some steerability, but involves being noisy. The old ability to steer at a medium speed, say in a forest, at low rpm, i.e. stealthily, is certainly gone. What I forgot to mention in my original post is how the engines are now even more prone to breaking, when bumping into invisible trees at low speed. Basically glass engines. Since ages I've been harping on about how they should fix the invisible trees, and instead we get even more easily broken engines. A feature I brought up months ago, having 'soft' collisions with objects such as trees, would also help making the interaction with organic objects like trees, more realistic, more, let's say, tank like. OTOH, a feature some new players have only very recently been asking for, in-mission repairs (no doubt originating from other tank games), has been implemented, and isn't remotely realistic. The in-sim time is meant to be real time, not accellerated time like in some strategy games. Thus, a 1 or 2 minute track repair, or 5 minute engine repair, is a joke. The irony is that we break our unrealistic glass engines when we bump into unrealistic invisible trees, and then we are thankful for an unrealistic 5 minute engine repair.
  5. [the context of everything that follows is multiplayer] I've critized in another thread, when the tiger came out, the design decisions regarding the 'new' UI, compared with the 'original' T34 and Pz3, which don't allow a single player to keep the turret pointing in a desired direction while jumping between gunner and commander (with the open hatch). Now that the new T34 has come out, it's evident that this is now the UI approach for all tanks. I understand (don't like, but understand) the crappyfication of the abilities of the T34 which are rooted in the real tank's actual abilities, or lack thereof. The steering is now crap, and I can only assume that this is based on research. IL-2 wants to be a simulation, so I can't argue with that. By making the turret turn towards 12:00 as soon as the player jumps into the commander position, the turreted tanks are effectively being turned into stugs. I can only guess that this might be done to favor players who get together to man a tank. As someone who has no intention of doing this, I resent that intent. There's a big problem for the mission designers (server admins) though: among the tankers are some which will play both sides (which I applaud), some which consider themselves blue, or red tankers. But among the blue tankers is a majority which consider themselves tiger tankers, and won't touch a Pz3 with a long stick. Thus, any missions which feature very limited or no tigers on some bases, remain devoid of blue tankers (almost), until bases with plenty of tigers come into play, and then the tiger heroes all pile in. I.e. the main instrument of mission designers to even out the situation doesn't really work in practice. The main reason why the red tankers were able to hold off the tiger hordes was the (maybe ahistorical) agility of the modeled T34. Now we have a weakly armored, weakly armed, un-agile tank. To add to all this, the gun control on the new T34 intermittently behaves in erratic ways, veering off in the wrong direction and so on. I thought I had identified a bug, until I read in another thread that this may be a 'simulation' to approximate the overworkedness of the commander, who is also loader. If this is really the case (not a bug but a feature), then I'm horrified. There are aspects of a vehicle you can and should simulate, and those which you can't reasonably do, and you shouldn't try. Who asked for this? It's widely known that for instance the driver's position in the T34 was very unergonomic, but I really don't want that simulated, or attempted. There was a thread some time ago, 'why the tiger', or similar. At the time I thought that the early introduction of the tiger on the roadmap was questionable, but not such a huge problem practically, because of the agility of the modeled T34. Now this situation has changed, and the tank selection is immensely skewed. If all this sounds a bit negative, it's because the update makes me doubt whether I should be spending any time on tanking at all. It's as if someone shoots you in the knee and says, here's your update.
  6. Thanks for pointing those things out, it's good to have an expectation of what will happen. So, if I understand correctly, the civilian buildings of a village are considered friendly, i.e. you should avoid collateral damage...
  7. I see some new missions coming up, on the Prokhorovka map. Some of the design decisions are quite different from what had come before, and I wonder what the rationale is behind those. A long time ago, you used to have bases that could be taken, i.e. if I came to a blue base in a red tank, and took the flag, the base would become red. Then, still long ago, you changed the lapino missions so that taking a flag would just make the the base inactive (grey). This made the game less volatile, but also slow. Now, on the new Prokh. missions, when, as a red tank, I take the flag of a blue base, the flag changes and a message appears, but the base stays blue, blue AIs and arty continue to spawn, blue players can still spawn. I struggle to understand how you have envisioned that those missions should be played. Or is the programming of the missions simply not finished yet? Another thing that happens is that when as a red tank I blow up buildings on the blue base, it counts as friendly fire. Is that intentional?
  8. I've changed the approach, to have the two OpenTrack instances write to UDP ports, and FreePIE read from there. The thread on the FreePIE forum is at https://www.mtbs3d.com/phpbb/viewtopic.php?f=139&t=23182&p=164525#p164525 but maybe it can only be viewed with a login, not sure. I have this working to the point where it writes to FreeTrack, using the FreeTrack DLL built into FreePIE. I've also attempted to write to TrackIR instead. IL-2 isn't enclined to act on this headtracking information (falling back to mouse look). Now I wonder whether IL-2 somehow identifies where the information comes from, and only accepts certain senders, such as OpenTrack... Hence my question: has anyone out there successfully sent FreeTrack or TrackIR from FreePIE to IL-2?
  9. I've run into a number of issues which my plan. The main one: Vjoy was the idea for "output", and it turned out that FreePIE can only write to those, not read. This leaves a number of headtracking protocols possible for output, but trying to use one of those with the intention that FreePIE would read it, but IL-2 would ignore it, would require some solid knowledge about how IL-2 choses a headtracking protocol in a situation where more than 1 is available. Then there is "UDP over network", which wouldn't create issues with IL-2, but involves more effort trying to read it into FreePIE. I've posted on the FreePIE forum (on mtbs3d). If no info is forthcoming I'll probably not pursue it. What gets in the way is that OpenTrack which is core to all this doesn't have its own forum, which would really be the right place for a thread like this.
  10. Preliminary result, regarding running 2 instances: I'm able to start two instances, and choose different config files, and run those configs. In this way I was able to run 1 config with pointtracker taking the delanclip camera input, and another config taking the EDTracker input. I then tried various outputs. Annoyingly, the output I want, VJoy, made my opentrack crash every time I try to run such a config. None of the other outputs seem to do that. This is not some side effect of running 2 instances. I tried it with just 1 instance... I had Vjoy Monitor on before trying this. Then I quit the monitor and tried again. No crash. Now that it's running I can start vJoy Monitor and it doesnt crash. Odd. There is no config possible when outputting to vJoy. It grabs vJoy Device #1.
  11. Interesting info about how this functionality (webcam based axis) was apparently integrated into the EDTracker Pro UI. I've just downloaded mine a few days ago from http://edtrackerpro.mybigcommerce.com/downloads/ where I bought the device. I've checked the version, it's pretty clear I've got the newest one. It's all a bit confusing since you can DL other, much older it seems, versions from http://www.edtracker.org.uk . It looks as if they removed this useful functionality from the EDTracker UI.
  12. I wonder if someone has tried this and what their experiences were. This is not so much about whether, on the OS, it's possible to do that (I'm sure it is, somehow), but more about: When OpenTrack is running, IL-2 just recognizes it. There's no UI to make some decision about it. Also, I can make some protocol decisions in OpenTrack, but, the ones I have tried, they just work. So, IL-2 internally must have some rules regarding, what if it finds this Freetrack protocol being active, and that other protocol being active, which one is it going to pick? Is it going to depend on timing? Is it random? And so on... Reason I'm asking about this: I have EDTracker now, with 3DOF, no X,Y,Z , but I still have a delanclip on my headphones and still have the camera set up. So, if I were to run 1 Opentrack for EDTracker, 1 Opentrack for the clip, and use FreePIE as a mixer... This would involve setting the output on the opentrack instances to something FreePIE accepts as input, and setting the FreePIE output to the protocol that's most preferred by IL-2. But I don't know if IL-2's preference goes by protocol, or if it would just latch onto one of the Opentrack instances, as the preferred application...
  13. Hi Baeumer, all I want from the devs is some statement that would clear up the situation. If they said, what are you talking about, we aren't aware of any invisible trees in our game, go look somewhere else for the cause, this would help greatly in moving issue forward. It's really important to narrow that down in order to tackle the problem. Or maybe it could turn out that the devs don't know about the issue because they rarely play it online (multiplayer), it could turn out to be a online-only issue. And so on. Or maybe it could turn out to be an issue in all modes of the game and the devs haven't encountered it because they always nicely drive on the roads, or in the open field, don't drive through people's back yards, don't drive through the forest, and so on. What strikes me as surreal is to imagine that they do encounter the issue, as much as we do, in online multiplayer, and somehow don't think it's a big deal. Maybe they drive their tanks much more slowly and don't get their drivetrains f*** up like I do all the time. At any rate, if they engaged in some communication about this, it could enormously help this along. After all, as pre-release users of TC we are effectively their beta testers, and they don't respond to bugs we find. I used to be an adherent of your hypothesis about the cause being the mission builder. But in the meantime, I've encountered invisible trees in locations which I felt were unlikely to have had objects on before, so now I am sceptical. I also never spend enough time single player to have a view on whether the invisible objects exist there. It could be valuable if someone who does this a lot could share their experience regarding that.
  14. There's really nothing new to be said here, about the invisible obstacles. But I'm slowly losing the plot about the total lack of feedback from the devs on this. I've written at least two prior regular threads on this topic, and in March a bug report (see below). No response whatsoever from anyone official. Hence this new thread. If those invisible trees drive you nuts, please respond here. I hope, the more is written on this, EVENTUALLY it might catch the eye of someone at 1C.
  15. Just received EDTracker Pro a few days ago, switching from LED/camera based tracking, and am very pleased so far. I've tried out a few variants of pseudo 6DOF, or 5DOF, involving OpenTrack. At the moment, I've fallen back to the 'normal' variant where you map head roll to X, i.e. virtual-you leans left and right when IRL-you rolls the head. It works, but my favourite variant would be something that I've got half working, the right half to be exact: Since I *always* want to lean to the right, when turning my head to the right (to look right, and in the extreme, to check six), and since I *always* want to elevate the head when doing this (Y in Opentrack), and since I *always* want my virtual head to move forward (Z in Opentrack) when doing this (checking six works better that way), I mapped X,Y,Z to input Yaw in Opentrack. And of course, I want the same things to happen when I turn my IRL head to the left. So I started playing with the mapping curves, and was able to make it do what I want, when turning my head in one direction (the right, but it could have been the other way round). But when turning my head left, my virtual head corkscrewed down, and back, in exactly the wrong way, making me look at the headrest when attempting to check six. So I enabled asymetric mapping, and made the asyn. mapping absolutely flat. That way, the virtual head behaves in the 'normal' way when I look left (not great), and behaves in the ideal way when I look right. I'm using an Opentrack version from last March. I had attempted to use a newer one but it had caused some issues, but if there are new features I might try a new version. Has anyone attempted to achieve the same thing and found a solution? Maybe OT has a feature for this and I haven't realized...
  16. Amazingly, it worked! But yes, as I kinda feared, it turned out to be a questionable idea. Since the data is coming straight from the EDTracker "joystick", there isn't a tweakable thing like opentrack in between. Meaning, while I can control the scaling for the head roll axis separately in Edtracker (I increased it to a factor 7), the upright head position corresponds to the camera being half zoomed in. I have to roll my head in one direction to intentionally zoom out, whereas being zoomed out would be good as a relaxed, straight head position. So yeah, probably not the way forward. interesting though.
  17. I'm switching from camera based headtracking to EdTracker. For the head Yaw and Pitch (and some X,Y,Z, "pseudy 6DOF" style), this goes through OpenTrack. OpenTrack also shows clearly that EdTracker exposes its data as a pseudo joystick. I had the idea to try to map head roll to pilot head zoom. This may turn out to be unpleasant, but I won't know until I've successfully set it up. Pilot head zoom is part of keyboard settings. I'm only aware of how to do the keyboard settings in-game. Is there a config file I could edit instead? When you try to associate a joystick setting to pilot head zoom in-game, at the point where you would wiggle a real joystick in a particular direction, for the game to recognize which joystick axis it is, the fake Edtracker joystick is ignored. This makes sense, since you're always moving your head a little, and therefore the Edtracker joystick motions would get in the way of doing any other proper joystick setup. However, if this could be done in a file, it would overcome that issue. If this isn't possible, I could still achieve the same thing by feeding the axis through FreePIE to a VJoy joystick, but it'll be more work.
  18. I didn't notice such a message when this happened to me, but it would make sense that it might be a network lag related issue. I'll keep an eye out whether the next time it happens to me such messages are shown.
  19. Just ordered EdTracker Pro. I hadn't realized for some time it's now possible to order them, because, strangely, they have a new site (shop), while the old site which lists the products as out-of-stock, with 'notify me' links, is still up. So, anyone who wants to order one, ignore your old bookmarks and do a fresh web search.
  20. Yes indeed, that situation. So maybe, the bug we're dealing with here, is not a lack of hit detection, but a flaw in the visual feedback on the shooter's side. In a situation like this one, at this range, *some* kind of visual effect would normally be guaranteed. I will now pay more attention to how normally a hit with APCR is rendered (if it doesnt penetrate), I couldn't really describe how, all I know is that it's clear and unambiguous at such a range. Even though this makes it a slightly less serious bug, I think it's still a serious problem, because if you aimed high or low you'd really want that visual feedback, for correction.
  21. When we encounter Tigers, we usually have APCR loaded. I try to get quite close, with the objective of hitting the side perpendicularly. If I'm detected and the tiger has turned towards me, the chances of getting through the frontal armor are minimal. Hence I shoot at the track, i.e. straight onto it, onto the wheel basically. It makes perfect sense to me that a round that can penetrate the side armor, at the same range, can separate two links of the track, or completely destroy one. How is this unrealistic?
  22. I wanted to post this as a bug report, but I've written bug reports before and got no feedback at all, so I'm thinking, better to post this here, and maybe get confirmation from more people. Maybe this will yield a higher visibility. It has happened to me a number of times in recent weeks that I shot at a tank and the round seemed to go right through, as if the tank wasnt there. That just happened to me again, but this time the circumstances were so unambiguous that I can't dismiss it. I fired at a tiger twice in a row with apcr, from the side, perpendicular, at about 300m. Of course you could say, what if the aim was slightly low, but with the tiger's kind of wheels it's pretty impossible for the round to find a gap, twice in a row. Had the round be so low to hit the ground in front of the tank (it wasnt), that would have been visible. A round ricocheting would have been visible. My impression is that this started, not very long ago. I used to have utter confidence in the hit detection. I'd like to get some feedback, if people can confirm this impression. Towards the dev team I'd like to point out, that I can see technical / networking / MMOG related tradeoffs, that one might, in a WW2 flight sim, say, if an optimization has the result, that not every round is checked, with MGs or machine cannon, one might consider that tradeoff acceptable. However for TC it's not. At all. When you shoot, you draw a great deal of attention. And in less well armored but more mobile tanks, fighting Pz6, we entirely rely on sneaking up on them and hitting them in the side, rely on, blowing them up with the first shot. And the game engine has to be reliable in this respect. Not, somewhat reliable. === P.S.: Just occurred to me, I hadn't mentioned explicitely, the context of this is of course, multiplayer. I keep forgetting some people play this offline.
  23. I won't leave, clearly I'm too addicted to tanking. But I will decide more opportunistically whether to join or not.
  24. I feel like quitting tanking on IL-2 in multiplayer, until the server admins address the issue or at least recognize the issue. I would describe the current situation as follows: Typically either red or blue have a numerical advantage regarding planes. There is a subset of missions (or maps) which are heavily forested where the tankers are not very affected by the planes. But on the majority of maps, the tankers in the team with the smaller number of planes usually get massively pissed of, until most of them quit. Then the ratio becomes even more uneven and the other side wins. Before the attack plane pilots "discovered" the tank servers, this wasn't the case. Most players will embrace the challenge of fighting against heavy odds, even against more powerful tanks. Why? because those are challenges which can be met, by trying to be a better tanker, or a trickier tanker, and so on. But trying to become good enough at shooting down those planes is just unrealistic, especially since the attack by the plane, the small explosions from the MGs, and so on , kill the tanker's fps and make it even harder to get an aimed shot off. Simply put, the tankers are just prey for the attack planes, there is no mutuality. Does fighter cover help? Ultimately no. One side prevails, and that side's attack planes are free to find the tanks, where they KNOW they will be, due to the well known spawn points, and well known routes the tanks must take, and the scale of all that simply being much smaller than it would be in reality. It has been proposed that (very sturdy) AA at the spawns might address the problem, but it will do so only for the defensively minded tankers, not for those keen to go on the offensive. So, right now, the situation is, that you have to hope for your team to have a numerical advantage (in planes), otherwise having a bad time is guaranteed. Those players who tank on both sides therefore have a strong incentive to join the already stronger side. The opposite of what would be desirable. Thus, I will do what I myself dislike, I will look at the numbers, and join when it's favourable for my side, and abstain from tanking when the plane numbers are unfavourable. Which of course leads to bad numeric ratios. But whatever.
  • Create New...