Jump to content


Founders [premium]
  • Content Count

  • Joined

  • Last visited

Community Reputation

15 Good

About usr

  • Rank

Profile Information

  • Gender
    Not Telling
  1. Successfully operating CoD-style simulated antrhopomorphic controls would require a level of "cockpit chess" that simply does not exist on real controls. That translates to a clear vote for "no". Better leave that to text adventure flight sims: "You are sitting in the cockpit of a Hawker Hurricane" > push throttle "That is impossible" > move hand to throttle "I don't know which hand to move" > move left hand to throttle "Your left hand is grabbing the throttle lever" > push throttle "You are hit by an artillery shell" That being said, the original IL-2 has a very nice example of "moderately anthropomorphic" controls done right: the manual gear crank keys. Implementing a few particularly slow cockpit operations as "hold key until action is done" certainly won't do any harm, as long as there is sufficient on-screen feedback. Instead of artificially restricting the available "action bandwidth" of the desktop to the intended "action bandwidth" of the simulation (as CoD Anthro-Ctrl did) this would just require more real life activity for the same virtual activity, making the natural limitations of the desktop better match the intended level of activity in the simulation.
  2. usr


    Bei mir wird Freetrack erkannt (irgend eine ältere Beta), ein aktueller Build von Opentrack wird in IL2BoS allerdings nicht erkannt, in 46 hingegen schon (Opentrack bzw FTNoIR verwenden Komponenten von Freetrack, um sich als TrackIR. Generell scheinen Headtracker also schon unterstützt zu werden, aber alle denkbaren Kompatibilitätsaspekte sind wohl noch nicht geklärt.
  3. Hahaha, thank you so much, from now on, whenever i fly red, my battle cry shall be "FOR MACY!"
  4. This idea isn't as bad as people make it sound: if a custom skin is expected to go through some form of approvement process and get it into official distribution (making both 777 and all BoS customers pay for storage + bandwith, even if it's only a very, very small price in both cases) there might indeed be a certain handling fee. More skins are better than less skins only up to a certain point: nobody would really be happy to have to download terabyte upon terabyte of skins varying in a pixel or two, to give a radical example. Quality is as important as quantity. But: in order to even get to the point where too many skins might start becoming a problem you first need hobby skinmakers who produce a certain quantity of skins and nobody would be willing to pay for their first, second or even tenth attempt at making a skin they would not be ashamed of. Thus, charging for skin distribution without adequate ways to use custom skins for free would effectively kill off a whole feature of the sim that is important to many players. By adequate ways for free use i mean all three of: [1:] offline use, this is a no-brainer: local test runs are essential for the skinning process [2:] online use on servers with some form of mods=enable switch [3:] online use on servers where the server admin has personally approved the skin (e.g. squadron skin on the squadron's own server) What would remain hidden behind the paywall is this last one: [4:] inclusion in updates so that the skin will be available on any serverWould many people give money for #4? Surely not more than e.g. for a colored scarf in RoF. Realistically, it could probably not really be considered a revenue stream, if it maybe pays for half a day of development cost over the whole lifetime of the game. But on the other hand, every half-a-day paid without resorting to pay-to-win features is a good thing in my book. Still the main benefit would be the "spam filter" effect of a handling fee that would protect the update packages from getting bogged down in a torrent of circus skins or irrelevant repetitions of the same skin with only minor variations. If 777 were in a particularly generous mood they might even consider such a skin distribution fee entirely for the benefit of the "spam filter" effect and channel the money back to the community as price money for some form of skinmaker competition (which would be a good thing for the balance between quantity and quality in any scenario, with or without handling fee)
  5. Be nice and don't expect others to be. People who loudly complain about being denied some courtesy are just as annoying as those they complain about. (Now where does this leave me? I think i might have just done some compaining!)
  6. First a few things i would not like to see: Head shake: while that might be a perfeclty fine feedback/penalty mechanism in something like a simple arcade shooter, i think that in a sim like this, between headtrackers, all that importance of tiny visual structures like cockpit dials and single pixels in the sky and then quite possibly worst-case fps in those situations where you do your most radical flying, it would just result in some sublte negative synergy that might just make you not enjoy the software without being able to exactly point out what you don't like. Simple blackout/redout with no further consequences: if you panic and ground isn't too close, you just don't care for a few seconds of blindness. Perfectly reproducable mechanics: in real life, even the same person would have a good day or a not so good day. Some level of randomization should be included to limit predictability. Someone suggested a similar thing for the planes (a very good suggestion imho): if a slight variation of performance is true for machines of the same make, it must be doubly true for humans. In a simulated dogfight, you should never be able to predict the mechanics like in "he's done that for 8 seconds now, if he keeps it up for two more he'll be out for five, yay me!" Pilot activity limitation with insufficient feedback: just remember anthropomorphic controls in CoD. If you hit buttons and, without a trace of an explanation, nothing happens it just feels broken, simple as that. Silently ignoring user input is a great way to remind the player that he is just pressing a few buttons instead of flying an aircraft, in other words: immersion killer. But still, in my eyes, pilot limitation is still the way to go, sufficient feedback is the key. Example: penalty/limitation by limiting the speed of stick position change. I'm not suggesting that this is realistic (it might be or not, i honestly do not know), just saying that it might work well with good feedback. Without feedback, it would be terrible: you yank the stick halfway (no speed limit on the physical stick), "virtual stick" reacts with reduced speed, you instinctly try to compensate by yanking more and once the slowed down virtual stick has caught up you are totally oversteering and don't know why. Enter feedback (no, a rendered stick in the virtual cockpit that either moves as fast as the stick in front of the monitor or not is not what i'd consider sufficient feedback): as soon as the virtual stick starts lagging behind the screen goes 30% dark and the player knows something is wrong. By the third time this happens the player will have learnt that sudden darkening while doing hectic maneuvers means go easy on the stick and will soon train himself to avoid limitation-induced oversteer and move sharp on the edge of the virtual pilots current abilities, no matter how limited or unconstrained they are at any given moment. As a bonus, the amount of "wiggle space" available will be a a very subtle, "more belly than brains" way of telling the player what the current state of his pilot is. Yay immersion. Friends of headshake feedback might even like to see another variant of feedback added: excess movement of the real stick over the allowed maximum speed of the virtual stick could be converted to head movement, with the head returning to normal with the virtual stick catching up: feedback would be direct, the directional nature would add another level of intuitivity and the extra head movement would lack that randomness that makes conventional headshake so annoying. Would it be good? I don't know, things like this have to be experienced to get a qualified opinion. I honestly envy the people at 777 who can probably try out schemes like this with only a few lines of code changed. PS: all this still does not answer how fatigue level should be measured, but i think the exact mechanism of determining current load is a question completely orthogonal to the question of what to do with that number. In terms of gameplay, some kind of dynamic stress level would be the more interesting addition than an advanced system for modelling pilot injury: while a pilot might slowly recover from stress during plain old level flight, adding another small subtlety to the tactical dimension, injury would just be yet another damagable subsystem that can only move south after takeoff, like all the other damagable subsystems. Having n+1 instead of n damagable subsystems might be nice for sim bragging rights, but the gameplay impact is exactly zero. (yes, i openly admit: gameplay is important to me and no, it's not a zero-sum game where gameplay and sim are mutually exclusive and you always have either the one or the other: you can very well mess up simulation without adding gameplay and you can easily mess up gameplay without improving the simulation, so why should it not be possible to improve the one without sacrificing the other? I'm very confident that the combined maximum has not yet been reached!)
  7. Client-side validation can only go so far: if you can modify the data, then you can also modify a client-side validator. What you'd really want is a server-side check of the flight data (position, heading, speed) that is the result of the client-side simulation process: given the state at one point in time, can the simulation model with the unmodified, server-side copy of the parameter values support a valid "path" to the the state at a later point in time? Unfortunately, simulations like this tend to be somwhat sensitive to the precise timing of intermediate simulation steps etc, so a certain level of an error margin would have to be tolerated. Also, to be precise, a double-checking system like this would require a rather wide stream of internal values (controller movement and variable state parameters like engine temperature or fuel level) to be sent to the server which normally would not be needed for a multiplayer game. And while additional server CPU load could be limited by only occasionally checking random samples, the client would still have to constantly send all this additional data because just like in unannounced doping tests at the olympics, a potential cheater must not know when he is tested, otherwise an advanced client hack might be programmed to only cheat when nobody is watching. A reasonable compromise between cheat protection and client network bandswidth might be to have the clients not send the additional data immediately, but only store it locally for a few minutes to allow the server to retrospectively request parts of that data when it decides to double-check a past sample of this player's flight data. This should be good enough, because there is no need for instant detection and depending on the amount of performance manipulation and the length of the double-checked interval it would be very difficult or even impossible to come up with a faked retrospective controller/engine-state stream that could explain the logged movement. Implementing this would be quite complicated (and still not be enough to completely leave aside client side checking, because this could only target performance hacks, not visibility hacks), but since i know nothing about the state of the anticheat battle in RoF a small part of me can happily hope that the clever folks at 777 have already set up a similar system for RoF
  8. I guess it tells quite a lot that they are only demoing their tool with views from a safe distance below the clouds.
  • Create New...