Jump to content

rogorogo

Members
  • Posts

    193
  • Joined

  • Last visited

1 Follower

About rogorogo

  • Birthday 06/21/1975

Personal Information

  • Flight Simulators
    DCS, IL-2
  • Location
    Austria
  • Interests
    Sailing
  • Occupation
    agile something something confusing

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. caveat: code can be deceiving. Just entering "correct" numbers does almot never result in "correct" representation in a game engine, especially in a flight sim, especially especially in a proprietary engine like the one of the DCS franchise (although labeling it "engine" is already a thin ice endeavour). Even if a product engine, any product, any engine is inteded to have 1:1 maintenance:representation coding, there will always inevitably have to be endless tuning. So to sourcetrack any issue we would have to know all factors and prerequisites of the causality chain, like (but not limited to): Eagle's code intent, solution approach and systemic cohesion concept (Eagle D <-> cohesive systemics.. lol.. good one ) DCS's engine behaviour and representation metrics vertical keylog subsidiarity behavioural function in- and outflow mapping Neither of which we have access to, for all we can know the correct numbers to enter for the intended representation (assuming that is the intent) could be "69", "666" and "wolperdingerfurz". What we DO know are soft factors, like the fact that especially HE fragmentation and explosive dispersion is modeled... hmmm.. what should we type... underwhelming? insufficient? odd? shorcoming?. Mostly as a result of the great tradition of zero attention for the longest time for anything unless ex-post of a matter-hits-fan realization (oh look ground asset models recently got a poly pass... but only here and there and mostly over there....gee.. I wonder why.. and why not before?). This can even reach module level, when anyone with one semester or even the faint idea to study BA or Marketing would understand all modules are to have the same scope and level and certain modules need special attention by necessity for a franchise scope and diversity and adversity balance. But here we are and here we will stay. Also this and every other discussion, while neat is completely academic. I can assure you that nothing gestated here registers at the end of the hallway of Офис 87 in 141983 Московская область and any information officially disseminated here is rather... freeform. And all the people with those yellow labels are mostly attention seekers in social media environments, herd animals going moooh for whoever and whatever (I refrain from typing 2 of the 5 actual media and gaming industry classification labels) neither doing any actual testing nor effluviating anything less safely dismissable than "official" anything (notable exception nonwithstanding, but exceptions are exactly that, statistical outliers non-representative of sample medians and centroids in a datapoint cloud). So would - despite the futilty - should we, as consumers admonish then? Well.. imho what we already have.. these rockets are not correctly represented. And this is the extent and limit of the admonishemt, supply correct sources, supply a problem outline.. and then rally and insist! to track the actual global source issue, not present a bandaid-fix. And in the process, it would be nice to also finally (after YEARS) adress (exemplaries from a very long list) things like: editor placeable beacons and NDBs not working role select screen server session table foliage fuse issue wipers and canopy rain shaders rain in general message and notification box cpu imprint multithread vulkan (beyond default) globalization of munitions behaviour globalization of radar systemics and behaviour globalized franchise standards in general But all of that, or any of that is as likely as world peace.
  2. If you use them this way.. all is fine.. but you should fly a repeatable pattern - you will notice more drift with the map than would happen if you did not readjust. If you ever change map scale after you have readjusted map scale (which in itself is kind of weird.. it would be an exchange of the paper map.. and a different readout of th dopper logic, which that system can do... but not in flight and that much "on the fly" - also there should be some sort of animation and longer "pause filler" to represent what would actially happen irl for fideltiy) this drift becomes way more noticeable.. to the point where finding your way home if you do not happen to know the terrain features very well by heart can become an issue. So again the issue is that if you have a repeatable scneario - the functional behaviour changes after an event (in this case, re-adjusting the map). Which defeats the purpose of this function.. you do not have this feature modelled in-game for the "moving map" to become less precise after needing more re-adjustmen. The "moving map" imprecision behaviour should not be affected by this. Again the source-issue is not necessarily in the keylog of the "map module" itself, it could be anything stacking or downflowing or something foundational. So the personal default behaviour to have the least manifestation of this not so noticeable bug is to just re-adjust when stationary (landed, not even hover) and never change "map scale". The manifestation is more imprecision - more drift (repeatable sortie/route, noticeable relevant difference). The triggers for manifestation are re-adjustment, re-adjustment underway, change of "map scale". P.S. offtopic - about the tracks... again.. it is what it is.. so ofc we keep supplying them, which usually results is its own communication minigame of "needs track" / "track too long, create track with only bug" (???) / "track shows nothing" with inevitable certainty, especially when it comes to actual bugs, so something that is not looks, not minor, something that is functional or at worst exposes a global issue (of which there are many) or a lack of standardization and practices (which would be needed for many many things). Which has no merit except inevitably reducing contributions and the likeliness of "new" contributors. But again, you cannot change mentalities and realities, it is what it is.
  3. well.. if you want the bug to manifest you have do do the following: MAP POWER ON: never exceed treetop level, preferably stay below treetop follow terrain ditches down to stay at low AGL and map level 0 (which is not 0 ASL but some random ASL value per map seemingly) will result in Map not moving, even with correct nose attitude and DISS-15, all other Doppler features working. If you have exceeded an undefined AGL value (I guess 40+ AGL but I was never able to systemically pinpoint and replicate, and tbh... I also did not have the time to "labtest" that) at any point, the map will work as intended (including stopping and drift if attitude too extreme, drift if airspeed-to-doppler turned on aso aso aso) even if you return below treetop. There is no reliable way to trigger a "snap"... but it has happened and can happen MAP POWER OFF: fly randomly around climb very high, really high, notice "SNAP" go down to "normal" envelope angels, notice map not moving (which is correct) change position and climb very high, notice "SNAP" which is the really weird manifestation. You also seem to have some speed and fly level at angels for some time (few minutes) for the "snap" to occur it seems. On an entirely unrelated note but topically fitting (so added as a general note of awareness for any glancers): That map corrections via the two adjustment wheels result in completely arbitrary drift that do not follow the rules of the "intended" behaviour of that functional keylog is also something that is sub-optimal P.S. But about any trackfiles.. they are currently at their most unreliable state for replicating anything on a any different system..
  4. Well.. again thank you for pointing that out.. this is extremely relevant, especially for the glancer-in-passing and fellow product user in dire straits. So addendum ->after noticing for some time, I just tried to finally report that.. and failed to be precise beyond ambiguity again... So brace, here comes the kicker... yes, the power switch has now a different (and "better", more realistic, more fidelic) default state. Which is a good thing. Which is also a thing that should have been a thing from the start. But so would have been any sort of actual documentation (no.. neither community contributions nor marketing skids count.. they are equally dismissable, regardless of their excellent quality and positive intent [for the former]). So do your checklist and don't forget to turn your map "on"! (those of us that do not press a magic diaper button ) BUT! That bug also manifests with the map power "on" if the aiframe never goes above a as-of-yet undefined "trigger angels" after takeof AND.. and that is the real weird thing... the "snap" manifests even when the map was NEVER turned on. Sou you can trigger an instant magic GPS like "snap" with a map that is OFF and was never ON. Now how utterly weird is that? Coming to think of it, I finally made that report on a Tuesday... how.. fitting :). I would provide a lot of trackfiles.. but as of now it should have become clear to everyone (translation: cannot be longer subject to "spinning") that they do not reliably reproduce bugs, or flights correctly by technical reality and even less so in the current especially unreliable state of the track-replay system (which has been a thing for.. 1, 2 years now?). And I do not run screengrab video... and there is no function to create proper debug-logs unfortunately. I have also not made that report on a whim... I started to notice that bug before the last patch.. but seemingly only under conditons I could not systemically identify - and more often to almost permanently after the last o-b patch. With the "trigger angels snap" manfesting almost permanently more often if I keep the map off (which again.. who does that.. and our fakeflight time is or should be limited after all). So there is something going on.. and as stated not necessarily with that functional keylog... it might be a more foundational issue just bleeding through.. again.
  5. With the recent patch DCS 2.7.14.23966 Open Beta (and maybe the one before) the Paper Map indicator for the DISS-15 has stopped working in Multiplayer while the DISS-15 itself is working reliably. The map indicator is not moving after takeoff, even with Airspeed2Doppler on (which causes drift), no movement. Any takeoff, fresh airframe, no damage, green OPER light, DISS-15 directional readout working, Doppler "Hover and Low Speed Control indicator" working correctly. If the airframe is moved above a certain "trigger" altitude at any point during a sortie, the map indicator will suddenly "snap" into the correct positon (which is technically impossible) at the time and move. If the "trigger angels" are a fixed AGL or ASL altitude is unclear at this point, especially as terrain masking seems to also influence bug manifestation. Which does not make sense in a systemic context but hints as a coincidental bug manifestation maybe related to DCS "radar" odditities overall. If the airframe is moved back into usual Crocodile angels (treetop, below treeop, terrain) at correct attitude for the DISS-15 to work, the indicator will stop moving again. The "snap" can be repeated then in a different position. This means that the module has currently lost its only means of navigation (since placeable beacons, radio truck NDBs are bugged for years by now on all available terrain modules) and the airframe has to operate in VFR, a correctly preset DISS-15 oneway Doppler and a maybe available ARK-15 beacon direction to find a FARP, a target, a destination.
  6. Well.. I am not coming up with these labels and their actual function and functional meaning vs a direct translation. see fe ... (which btw is still not cohesively labeled between cockpit labels and keybind labels but at least coherently labeled in each) But this is what the mousemap labels for the rockers are: up - MAIN center - AUTO down- BACKUP with the earliest "official" startup "guide" video (that may or may not have seen the usual ex-post treatment by now, which I will remain unaware of) stating the center position as the correct/intended/working one from the PoV of the product. Except that this never worked.. and many-a-times back then on SRS it was very helpfull for many to solve many issues by selecting the up position ("Main") for systems to work. With the down position ("Backup") to this day completely unknown if it has a function, if that functions works, if that functions works correctly. As currently every single impact anywhere by anything causes launch capabilty and or electrical damage, every actual impact causing minor pressure or rpm loss causing inevitable crashes, and one of the many sudden FM state changes still causing the unrecoverable RBS of doom from a stable peacefull and rather leisurely paced forward transition arrest, the DISS-15 working reliably but not for the rolling paper map which has a trigger issue suddenly to not work at all and then snap around like some sort of magic insta garmin - I'd rather not dig through documentation at this point. But more importantly I cannot tell if it works now.. because the reliable marker for it (the DISS-15 map) has currently stopped working altogether (unless you decide to become a commercial airliner.. which does not go so well for a Crocodile, especially on the Cold War Server.. the actual one, not the recent social media kindergarten clone. Also I am not getting paid for this, any of this - and those that are... well. Let us leave it at that. So to conclude.. back then.. center rocker positon was supposed to be correct, yet did not result in correctly (as in "function at the time") working systems.. up position did result in correctly working systems.
  7. first of all.. the read light going away means the gyros are "uncaged", aka working. The red light is not a "warning light", it just means that the gyros are spinning but caged. And if a button press does not uncage them... it usually means your birds systems have not enough voltage.. (usually when APU is off too early, before takeoff, throttle not at 100%, cold weather, rotor rpm too low, aso). This might also mean that the AP channels will not be able to be turned on, usually... until there is enough current in the system. For the longest time the source issue was solely that the 115V Transformer mode "auto" did not work.. and you had to switch the rockers to "main" on the left panel (breakes, not the rectifiers, the transfomers) - this seems to have been finally debugged... but I still switch them to main. null
  8. carefull @AeriaGloria, be precise with the labels to avoid confusion (since this also is now a help-thread especially relevant for the glancer-in-passing, so we must be precise beyond ambiguity). When you refer to "yaw autopilot" you are refering to the FCS-Yaw-Dampener/assist that is the AP-"heading"-CHANNEL. Many will easily confuse that with the actual autopilot mode "Route" - the "Autopilot Course (Route) Mode (SAU-V24)" The microswitch logic will click the assist CHANNEL on and off, not bo be confused with what the "autopilot mode" does. While very convenient and less straining, resulting in a much more "smoother" flight - especially for twist stick users (of which I am one) - it also prevents "drift flight" and "crabbing", and will confine you to lower threshold limits in your maneuverability (if that it your interest). And as Aeria typed, you simply have to find out what works for you or is needed for your personal situation based on your hardware and habits. But you must understand the difference between managing the input translation of your input peripherals, your physical hardware and the in-module application of the fidelic functions. You can reach any goal you have with either but not every combination will be as fidelic and as QoL as it could be.
  9. and thank the gods of russian proprietary product code for these (although why these are not a unfified franchise-wise global standard for all rotary modules.. or at least Eagle-modules... ) but in earnest.. despair not fellow fake digital pilot! In 85++ % of cases this setting will apply... the rest of combinations will be for A-segment peripherals, APIs, simpits.... the rest is already immersive.. aka in-module
  10. Difficult to tell.. The topic of "input translation", aka how to configure your peripherals to hand over inputs to the fidelic functions of the module you can only test out for yourself over time. Based on your description of your hardware peripherals a "no, rudder trim on special-tab level, peripheral level might not be needed" seems likely.. but you must find that out over time. If you have such hardware the microswitch logic of "presence/absence of pedal movement" might apply too. Once you have that figured out, cast it away as a given, do not think about it for now, considerit is "locked in". Then you can focus on the fidelic functions, aka what the modules offers in behaviour and how and how much of it to use in what way for your immersive perception of fidelic "flying the Shaitan-Arba". At this point talking about your stick takes on a different meaning and is actually talking about the cyclic, your pedals are the "anti torque pedals" (lol... soviet engineering terms.. oh my...) and the throttle is now the collective. And that you have to go through - iteratively, until everything works as "it should" on a cellular level, aka for your personal situation. And that is the problem, almost everyone does not make that differentiation, cannot discern between those topics, especially when it comes to bugs and seemingly including the product provider. That is not very feasible for debugging, especially when all layers have separate and stacking bugs. And that is before the simple reality of different engineering cultures and language barriers hit. While "we" see and define "fly by wire", "dampeners", "FCS" and "autopilots" as different systems that used not to be the case in soviet engineering culture (and still is not in Russian engineering). "Autopilot" has a vastly different meaning that encompasses a wide scope of subfunctions... even down to the motorized servos hydraulic actuators manipulating the cyclic for a very mechanical linkage "trim". examples:
  11. Because the "instant trim" is not exactly like the former "default", which was not the best solution for standard peripherals in the first place. And if you have a standard joystick and/or standard pedals (aka with springs that return the sticks and pedals to the centerpoint) you should have used "Central Position Trimmer Mode" in the first place (this is about the release point, or more precise, the point from which "new" inputs with the trims-state as "centerpoint zero" are stacked/accepted). Which - even if you had set it before- was changed to "instant" by this patch. Same as the rudder trim that was "enable rudder trim" before, it is about the details and combinations. in your case both options should be "central" - simply because it works more reliably with most peripherals. However for your PEDALS you now have a choice: You could use "disable by setting pedal axis to neutral" as the safest options to translate the fidelic function of the module to your peripheral hardware (aka input devices). OR you can use "presence/absence of pedal movement" if you fly with your pedals mostly off the center even with trimmed. The third option rarely applies statistically, but it still is a very relevant option to have for many. That is something you have to test (and weirdly enough, surely applies to some twist-stick users too). Unless you run a very complex throttle quadrant, you should also operate with everything set to one button, not different buttons for the trim... again something you have to test out for yourself (if you can retrim pedals without messing up your cyclic trim by your general input behaviour, if not, use different buttons). And check once twice thrice if you have "control helper" OFF.
  12. This might be a source issue when it stacks with other bugs - which can result often in there being no rudder/pedal/tail effect to the left very often and the dampeners and AP channels letting you barely hold attitude and nose orientation. I was never quite sure what might cause that... but I was never looking at the pedals because I am almost always below treetop - so what an important find!!! I hope this gets the prope attention.
  13. Also there is the battery heat switch on the right panel, which was the correct function to enable when I encountered the issue on a very cold mission map (Caucasus). At the time it felt very fidelic, and as the module is not documented (aka "early release") I was not able to judge what was actually working, what only pretended to be working and wheter it should or should not be like that (module-wise, fidelity is a different issue on top).
  14. Well.. which is why trackfiles are not really - especially in the current state - feasible to gather logging for debugging. (trackfile was a random example - also that track spanned a long sortie with various interactions and no crashes, especially not in any trees) Again another attempt to describe the bug in plain terms but beyond ambiguity: damaged Crocodile module landed on pad (services available) engines shut off, rpm at zero engine THROTTLE at ZERO fuel valves shut pump groups turned off rotor disc brake on disc arrested (blade no longer spin) electrics shut down batteries shut down systems shut down (on top of entire electrics and batteries off) ground crew will reply with "no can do - shut down your engines" - for minutes, for tens of minutes and more. Over time (observation span 1 quarter+) bug isolated to ENGINE THROTTLE. Engine throttle (with everything else shut down, arrested, off and time passed) is not registered at zero, despite being at zero and input peripherals at zero (with no input stutter or input value detected by windows OS or peripheral software). WORKAROUND: Repeated throttling up and down (in a turned off Crocodile with arrested disc, shut engines, shut valves, shut electrics) and "request repair" until at attempt "x" of "y" ground crew will reply with "copy" (and timer later starts). With throttle workaround successfull repair starts (as intended?) with engines off, fuel valves shut, first pump group off, rotor brake on and disc arrested but all electrics, systems and batteries running. BUG MANIFESTATION: bug manifestiation in conscious observation by me 2.7.6.13133-o-b to 2.7.11.22211-o.b More detailed report and additional details as per other posts in the report. Update: new variant, potentially latent but now manifesting in over 50% of repairs in multiplayer scenarios per 2.7.11.22211-o.b -> after repair low hydraulic oil pressure warning, vanishing after startup, after takeoff random system failures, power outages and with working turbines and disc gradual loss of rotor rpm until auto-giro landing. Conscious observation only with 2.7.11.22211-o.b - no separate bug report as not enough encounters for clear manifestation pattern. Exemplary trackfiles could be provided - but see above (also again long, so only log-stamo of repair and post-repair flight relevant).
  15. well.. and there is the reason actual bug-reports have to be extensive, and given how they are received and treated by the product provider, and under what conditions they have to be produced, less and less actual reports get gestated. That is all well meant advice - but given that I have monitored the issue since day1 of ea-release, any fidelity can be disregarded. That I never have the APU on in flight unless under very specific circumstances is a purely subjective me-issue (aka irrelevant) - but as for the actual bug, further clarification is needed. Bug was encountered and tested with - among other conditions - also: APU never running during sortie APU shut down after landing instrumentation full zero, soundboard full zero before shutdown of electrics fail-condition message present after 5-10 minutes on pad (fe while making a beverage and a sandwich) step-by-step shutdown of relevant systems, then random modules with decreasing relevance various maps and weather conditions, temperatures various damage states various pad types airfields as for any real life references, I was under the impression that my original bug-report had made clear that they are topically irrelevant as clearly none of them remotely applies. -> the reliable single reproduction is a INPUT (peripheral) engine throttle non.zero state or a failed condition despite INPUT (peripheral) engine throttle state (as monitored by 3rd party peripheral software and OS). Any fidelic considerations thus - again - can be disregarded as the bug would manifest nonetheless and also bugs have zero to do with design decisions, especially if that blatant in manifestation. So please - while constructive, productive, well intended - do not confuse the occasional glancer (the few that are left) with a topic that is - despite its suitability - unrelated to the technical actual bug.
×
×
  • Create New...