Jump to content

Bankler

Members
  • Posts

    308
  • Joined

  • Last visited

Everything posted by Bankler

  1. This just happened to me. Three cold starts in a row the trim didn't affect the aircraft. Found no config/bindings problems. I tried spawning in an airborne slot, and the trim worked fine. Tried cold starting again, this time being meticulously careful that everything (generators and such) were started in the correct order. Suddenly it worked. I'm not sure if it was the airspawn that made it work, or if I just made some weird startup error, three times in a row. But since it has never happened to me before, I'm leaning on the theory that it's a rare bug, and that airspawning one time fixes it. Not sure though.
  2. 3 month bump. What do you SMEs say? I have yet to see anything indicating that the laser needs to be armed for you to be able to change laser code. It makes no logical sense, there is no documentation presented that it works this way, and several Hornet drivers have confirmed the laser does not need to be armed to change the code.
  3. Small clarification, I believe (sorry for splitting hairs, @BIGNEWY ) TR - 5N62 "Square Pair": 129 SR - ST-68U "Tin Shield": 130
  4. Any update on this? Last evening we did some IFR practice. I realized that in order to enable the ILS on Kutaisi RWY 07, I had to set the headwind to at least 6 knots. First, I assumed it was related to which rwy is the active one. But even with the 2 kts wind we usually use, the AI aircraft used the correct active RWY (07), but only with 6 kts+ the ILS was enabled. So it's not really related to which runway is active. Changing the wind like that caused problems and extra work, having to change carrier routes and stuff. It makes little or no sense that ILS should be dependent on wind. Please, just keep it simple. Let it be on at all times. (As a side-note, I would LOVE a feature where you can enforce which runway is the active one, so that the AI uses a certain one under calm wind conditions)
  5. Thanks for the reply! Curious to see what you end up with and what you base the conclusion on. What does this mean? What is this other view, and what is pointing towards it? (Assuming it wasn't just a typo) You used available information and logic, you say. However, you also state that you didn't have any information. So just "logic" then, whatever that means. Developer's best guess, I assume? (again, that's NOT a bad thing in itself, you can't double check everything, or you would get nowhere. As long as you don't get defensive about it when you're corrected, everything's great!) "It's already done" could perhaps be a valid argument to keep it the way it was initially implemented (for now) IF a lot of work went into, it worked great already (albeit wrong), and changing it would require another big chunk of work (some radar features come to mind). That WOULD be reasonable. I don't think that's the case here though. This one shouldn't be a time-consuming or risky fix. So just like Harker says, witness testimony by an expert (or three) is the best thing you got, and I do firmly believe it outweighs the developer's best guess. I suggest you embrace these people's willingness to help you out, or at least let us know why you think they all are wrong. I'm not saying they can't be, just that it doesn't seem likely. Please let me know what that one thing is. I want to make sure these guys testimonies didn't get ruined by my stellar(!) MS Paint work or me asking the "wrong questions". Because then I can try to do better. I appreciate the reply by the way, and apologize if I sound harsh. Be sure my input is only meant to help you make the best product possible. I see no self-value in proving someone wrong. I just want to help you make an accurate computery-pew-pew-navy-plane, nothing else.
  6. Bumping this. Any word from your SMEs? Unless you're willing to take Mo410 and GBs words for it that is. I realize there are other more pressing issues. Still, it's quite annoying, and it doesn't seem like a huge thing to fix code-wise, so it would be great if could get taken care of.
  7. Thanks for asking. It's completely fine though. You can just post it here.
  8. Was trying to learn how offset aimpoint works. I realized I can input offset data for waypoints, but when I try to do it for markpoints, nothing happens (all the offset info is there and I can input stuff, but everything stays at 0). Am I doing something wrong, is it not supported, or is it bugged?
  9. Thanks for confirming that you saw it, @IronMike ! Looking forward to deploy tons of Tomcats on the deck soon.
  10. It's only vaguely related. But I'm sure you guys will iron this stuff out one way or another. Thanks!
  11. Regarding the current implementation: I only read what it says in the DCS F/A-18C manual, and correlated that to what the current behavior is (or at least "kind of", except it's somewhat different in different ACM modes). It currently works like a stack: If you're in TWS, go to BST, and lock something, as long as you turn away from the target (getting him off your boresight), pressing undesignate will take you back from STT -> BST -> TWS. And if you were in in RWS, it will brings you back from STT -> BST -> RWS. My assumption (and what a credible source tells me) is that it should instead take you immediately back to RWS/TWS (and if you really want to go back to BST instead, you simply press SCS Fwd again). If it wouldn't work like this, then it brings up the question "how do you then undesignate something that's in front of you if you locked him up in BST?".
  12. Sorry in advance that this post is rather long and brings up a mix of questions/bugs/weirdness/speculations. Let me know if you want me to break it up and report it in another way. I'd be happy to. I start with this though, as it might explain the big picture of what's happening. I have been confused what the undesignate button does in the different ACM mode. My expectation is that it should break lock AND return to RWS (or whatever mode you were in before you entered ACM). But after reading in the DCS manual on what RTS means I understand that the indication under RTS indicates what you'll go back to if you press undesignate at that point. So in DC, if you don't have a lock, it will go back to RWS. If you have a lock, it will instead go back to the ACM mode you were in before you acquired the lock. Fair enough, I personally don't think it's correct, but makes somewhat sense. However, I believe some things are rather strange: 1) If I have an aircraft right in front of me (let's say a friendly tanker), that I have locked up with BST, I find no way to break that lock using HOTAS. If I press undesignate, it will go back to BST, and immediately re-acquire it. I guess it's possible that it works this way, and have no proof of the opposite. However, since pressing SCS FWD in this scenario does the exact same thing (break lock and re-enter BST), it would be far more useful for the undesignate button to bring you back to RWS, or at least wait 1 second before re-acquiring the target, so that you can go to RWS by pressing undesignate twice in rapid succession. 2) To break the lock after having locked something with BST, I have to maneuver to get the target away from my nose. Undesignate does nothing if he's still in front of me, so I can't break lock with HOTAS. Even if I go heads down, pressing the RTS BST does nothing (which I guess can be expected, and trying to "unbox" ACM does nothing. Neither does RESET. It just keeps the lock. 3) While BST and VACQ both works in this (strange?) way, WACQ does not. It says RST WACQ when you lock something in WACQ, but if you press undesignate in this scenario, it will bring you back to RWS regardless. (This is actually useful, see below, and is likely how every ACM mode should work) 4) If you have the JHMCS enabled, there is yet another behavior. In HACQ, if the target is off to you side, it works just like in BST/VACQ, in the sense that it returns the HACQ when you break the lock (and if you look at him while pressing, it will immediately reacquire). However, if you press undesignate when the target is inside your hud, the lock will break. You will still be in HACQ, but the radar will no longer lock the target up, until you exit HACQ and re-enter it, or maneuver so you get the target on your side, and look at it through the JHMCS only (not the HUD). Remark: To break a BST lock when the contact is still right in front of you, as a workaround, currently you can: 1) Press SCS Left to enter WACQ. 2) Press undesignate to break lock and return to RWS. OR 1) Turn on the JHMCS (if you have one). 2) Press undesignate twice. Hornet_AACQ_2.trk Hornet_AACQ.trk
  13. Thanks! Much appreciated. I hope they manage to find out what's happening. Cheers!
  14. @IronMike @BIGNEWY Hi guys! It would be great to know if this is an F-14 issue or a Supercarrier issue so we know who owns the bug.
  15. Overview: If you are not the host, and a SAM-site (have tried with SA-2, but I suspect it's the same for all SAM-sites) is set to "Late Activation" and is activated during the mission, its search radar (P-19 for instance) is undetectable by the HARM. That means it can be seen in the RWR, but it doesn't show up on the TOO page (Hornet) or HAS page (Viper). Repro: 1) Join a mission as client (not hosting yourself). 2) Activate the SAM by some kind of trigger (in the attached mission, you activate it with the comms/other menu). 3) Note that you will get painted by the search radar (S in your RWR), but you can't fire a HARM in TOO/HAS mode at it. Reproducibility: 100% Remarks: * If you host the mission yourself, everything works as expected. It's only bugged if you're a remote client. * Same result for dedicated server and server run on another player's machine. * If the SAM site is activate from start, everything works as expected. It's only bugged when set to "Late Activation". * Tested with both F-16 and F/A-18. The provided test mission has slots for both types. * Thoroughly tested with SA-2 only. Probably the same for all S-radars though (I believe I have experienced this in MP server with SA-6 and other SAM types, but I'm not 100% sure about that). * Tested in the Caucasus and Syria theatres. Hornet_HARM_Bug_LateActivation_CA.miz Hornet_HARM_Bug_LateActivation_SY_Small.trk Hornet_HARM_Bug_LateActivation_CA_Large.trk
  16. Hi! No, I won't do versions for other maps. You can try an open the miz with a zip program and edit the mission-file in a text editor. Replace: ["theatre"] = "Caucasus", with: ["theatre"] = "MarianaIslands", ...and see what happens. In theory it should work. But depending on the two maps' respective coordinate systems, the units might be put in weird places, and you might have to get your hands dirty to fix that.
  17. It has been like this long before that actually. But yeah, I assume it's connected to the wing sweep functionality in one way or another.
  18. Hi Heatblur! I posted this bug in the Supercarrier bug section. However, I'm not sure if this should be on your table or EDs? As long as not both parties say "talk to the other party", I'm happy! Cheers!
  19. (Posting a link to this threas in the Heatblur F-14 section as well, because I don't know who's responsibility this is) Overview: In multiplayer, when spawning on the supercarrier, the client F-14s take up more space than they should. The first player always spawns on point 5 (I have no idea why the sixpack spawn points 1-4 is ignored in MP). But instead of spawning on point 6, the next Tomcat spawns on 7, then point 9, and so on. Hornets spawn 5, 6, 7, 8, 9, 10 etc as expected. One might think the Tomcat is too large to fit two next to each other. However, that's not the case, since all AI Tomcats will spawn as expected, and they can clearly fit in there. A possibility is that the game tests availability by checking if the aircraft collision box would fit in the spawn position. Maybe the game is using the collision box for Tomcats with un-swept wings instead of swept, which is wrong, since Tomcats always have swept wings when spawning. Still strange that it works for AI but not for clients though. Repro 1: 1. Launch a server in MP 2. Spawn one client Tomcat (will spawn at 5) 3. Spawn another client Tomcat (will spawn at 7, which is wrong) Repro 2: 1. Lauch a server in MP 2. Spawn one AI Tomcat (will spawn at 5) 3. Spawn another AI Tomcat (will spawn at 6, as intended) Remarks: 1) The bug is severe for multiplayer, since a mixed package of Hornets and Tomcats will only be able to spawn a few aircraft before the deck is full. We have been forced to spawn Tomcats hot on the catapult instead, which isn't what we want. 2) If you spawn a Hornet and then a Tomcat (or a Tomcat, then a Hornet), the same bug occurs. So two Tomcats are not strictly necessary for the repro. If one (1) or more Tomcats are involved, it breaks. Tracks and miz: Tracks attached. Note that the Human track plays a little weird. It spawns the first player (me) at the sixpack (like it would in SP), instead of at point 5 (which is where I actually spawned when we recorded the track). Still, then next client spawns at point 7, so it still shows the bug. The F-14_SpawningBug_AI_Delayed.miz file spawns the AI with 5 second intervals instead of being spawned at mission start, to make it as similar to client spawning as possible. Also attached the .miz files for easy testing. F-14_SpawningBug_MP_AI_WorksAsIntended.trk F-14_SpawningBug_MP_Humans_Bugged.trk F-14_SpawnBug_AI_Delayed.miz F-14_SpawnBug_Human.miz F-14_SpawnBug_AI.miz
  20. Bankler

    LA Lights

    +1 I would like to see a ME option for "lights always on". In addition to the use-case above, it would be very useful for multiplayer scenarios. In my community, we use human marshal, LSO and such. So we have no need for the AI comms. Still, during CASE 3, our pilots (or at least the one landing last) have to contact the AI tower with the comms menu and request "approach". Apart from breaking immersion, which is a problem in itself, this is many times forgotten, and the first aircraft comes down to a pitch black deck. So at least make it an option, so that we can skip this unnecessary step. I know that controlling the lights manually is in the roadmap. But considering the development pace for the Supercarrier, I think you need to take a couple of easy fix "shortcuts" like these to put out the worst fires, for now.
  21. My training mission only covers CASE 1. You can tweak the weather yourself in the Mission Editor. As long as the ceiling is no lower than 3,000 feet, and the visibility is no less than 5 nautical miles, it's still CASE 1. Regarding landing only/full cycle, there are two modes. Break mode (which is the default), starts ~3 nm behind the boat and will evaluate your flying from the point where you pass the boat just before the break. This is not how they do CQ IRL, but imho I think it's a very good way to practice, since this is how you would land when coming back from a mission. You can use the comms menu to switch to "pattern mode", which will be more like real life CQ. You take off and turn left straight into downwind, and the evaluation will start when you're abeam. I have no scoring support if you want to practice the full cyclic ops recovery thing, with overhead port hold and such. However, there is nothing stopping you from doing that procedure, commence, and then go into the last part. The script will start on initial, and everything should work as usual. We often do it this way if we're a lot of people in our CQ events (not realistic to be 20 guys during CQ, but lots of fun!).
  22. Hi there @Habu_69! Not a fix by any means (meaning this is slightly off topic), but potentially something that can be helpful for you and your buddies:
  23. TL;DR: Use the provided .miz to be able to reactivate TACAN and ICLS on the carrier through the comms menu they stop working. For as long as I can remember, there has been a bug causing the TACAN and the ICLS to randomly stop transmitting. This can obviously be a disaster if it happens during a large multiplayer event, especially night time. Unfortunately ED has not been able to solve it, and it's rare and random enough making really hard to help out by providing any data. There have been suggestions on workarounds resetting the TACAN when the carrier group reaches certain waypoints, or putting a reactivation timer in there or so. I haven't really liked any of these solutions, because you'll still have to wait until the next reset point. And if you're on your way down during a CASE 3 recovery, you can't really wait, you need that TACAN now. My workaround uses the comms menu, adding an entry under "Other" which reactivates the TACAN and the ICLS. We have been using this for months in my community, and it has saved it dozens of times. It works in both SP and MP, any player on the server can trigger it, and it reactivates the carrier TACAN and the ICLS immediately. It can be used multiple times during a mission if needed as well. I'm providing a .miz which you can use as a template. If you want to re-create it on your own, here's how you do it: 1. Place a carrier (legacy or SC) and give it a route 2. Under "Triggered Actions" on the carrier, add the same TCN and ICLS tasks that you normally set under WP 1 Adv Waypoint Actions. 3. In the mission triggers section, create two triggers. 4. The first one should be set to "Mission Start", no condition, and as action add a radio item that sets a flag to 1. I used "72" to make it easy since I use TCN 72 and CVN 72, but you can use anything. 5. The second trigger should be set to "Switched Condition", have the condition Flag equals 1 (or Flag true), and as actions A) AI TASK PUSH (the TACAN action), B) AI TASK PUSH (the ICLS action), SET FLAG VALUE back to 0 (so it can be used several times), and (optionally) spit out a MESSAGE TO ALL saying that the deed has been done, just to confirm to the players on the server. If you want to test it, you can remove the automatically created TACAN WP 0 action from the carrier, and run the mission. Note that you can't see the TCN, but when you activate it through the comms menu, it will be there. Just don't forget to re-add the WP 0 actions again (not only TCN btw, you should probably set the ICLS in there as well), so you don't have to enable the stuff manually first time you start the mission. If you don't understand the above, just download the .miz and carefully copy what's in there, or even use the .miz as a base for your mission. TacanReactivation.miz
  24. @BIGNEWY I would warmly suggest ED to set the RCS to 0 on all air-to-air missiles and SAMs in the release builds until you have figured all this stuff out internally. Even if a missile has a (tiny) RCS in real life and scenarios like the above ones could be plausible in extreme cases (maybe?), I think we can live without it for now. It wouldn't impact the experience notably (if at all) to just remove it, at least not in comparison to the funky false positives in there now. You obviously have other more important things to solve than how radars realistically should react to a/a missiles, so I think disabling it completely is the best and most pragmatic approach at this point. That's my $0.02 at least. @Krippz "This really needs to get looked at. " I agree. I don't really know how the closed beta works. But as a ED Closed Beta Tester, didn't you get the opportunity to look at this before it was released? Not intended to sound acidic btw, I genuinely don't know.
×
×
  • Create New...