Jump to content


  • Content Count

  • Joined

  • Last visited

Everything posted by stupor-mundi

  1. 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?
  2. 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.
  3. 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.
  4. 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.
  5. 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...
  6. 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.
  7. 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.
  8. 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...
  9. 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.
  10. 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.
  11. 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.
  12. 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.
  13. 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.
  14. 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?
  15. 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.
  16. I won't leave, clearly I'm too addicted to tanking. But I will decide more opportunistically whether to join or not.
  17. 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.
  18. the dialogue is always right. it said it's my internet connection. wait, i'm on a forum reading messages. it's so confusing.
  19. same here. had to restart due to sound bug, and now this
  20. Wasn't familiar with the term x-touch editor, googled it... Found editor for windows from musictribe, which you can DL. is that what you're referring to? I've not used that at all. The x-touch, being a a MIDI device, initially gives you that. FreePIE, acting almost as a switchboard between the different protocols and drivers, with a suitable script, can give you vjoy output. I found that SOME of those things are getting bound to applications. For instance, I used MIDI OX initially for diagnosis, but while I had that on, it was basically hogging that midi output. So I had to turn it off when using FreePIE. To see whether the MIDI is incoming, FreePIE itself is suitable, it has a 'Watch' tab at the bottom. To see whether FreePIE is outputting the vjoy, "Monitor Vjoy" (which is part of the vjoy DL i think) is useful. IIRC , "Monitor Vjoy" doesn't get in the way, i.e. you can keep it running. (I could remember this wrong) Vjoy also needs to be set up appropriately, with "Configure Vjoy". In my current FreePIE script, I use vJoy[0], vJoy[1], vJoy[2], i.e. 3 vjoy devices, which means I had to set up (at least) 3. Equally, when you use the various axis' and buttons in the FreePIE script, you have to set up those vjoy devices with enough of those. Meaning, it has to fit. I think when I first ran vjoy, per default it probably had 1 device and only a few buttons. To debug these things, it's important to figure out, diagnostically, where the breakage is happening. i.e. are you not getting MIDI INTO FreePIE, or is that working, but somehow the output isn't getting to vjoy. An important thing to keep in mind, about the naming of those things, when there are multiples of something. Depending on the order in which a thing is loaded, those array indexes are being asigned. I vaguelly remember a situation where I had played around with devices and suddenly my script didn't fit that situation anymore. For example: you might have other MIDI devices connected, etc. I.e. FreePIE doesn't know which device is which, it just sees x of them, and calls them 0,1,2,...
  21. Simple: you're referring to a different mission. I was referring to a mission in a city with a bridge. The city itself is quite wooded. Also, the distances aren't very large. I agree with your other points.
  22. Sure, you could do that. It's more about what people realistically WILL do. Clicking back and forth before choosing a side is probably already beyond what most people do.
  23. I've just run into the first invisible obstacle ("invisible tree") on the Prokhorovka map. It was in a typical location, at the edge of a forest. I won't waste any breath explaining what those are, everyone who drives tank knows about them. I refuse to believe the devs don't know about them. One of more widely believed guesses of the cause of those invisible trees had been that they were artifacts of the low res, not-made-for-tanking maps we were using so far. This is out of the window now. It's time to recognize this as a bug and give it some attention.
  • Create New...