Jump to content

MeanJim

Members
  • Posts

    24
  • Joined

  • Last visited

1 Follower

Recent Profile Visitors

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

  1. That sounds like exactly what happened to me last week on a MP server. I posted about it in this post in bug forums. I did turn off the HTS and it returned the TGP returned to normal. When I turned the HTS back on, it started looking off at some random spot. I did not even use the mark point page on the DED that flight. I did command the SEAD page using the TMS so I could cycle targets before it became unresponsive. I don't believe it's a scripting problem. When it happened to me, the SAMs I was trying to target were alive and shooting at me. I was going to try to test something out in SP, but I haven't been able to play DCS since then.
  2. I hear it. I assumed it's supposed to be the JFS shutting down. You can hear it in videos of real F-16's starting up, but it's faster, higher pitched "pew" sound, but what I'm hearing in DCS is a lower pitch and longer sound. In this video from in-cockpit, you can hear it right about 0:59: This one from outside, you hear (and see a black puff) around the 2:12: For comparison I just recorded a startup in DCS from inside the cockpit and outside. I've never started the jet from outside before, and (to me) it's much more noticeable from outside. Inside I hear it begin right at 0:33. While watching it back I also notice it happens right as the FLCS PMG and TO FLCS lights go out, and it's 2 seconds later when the JFS switch cuts off: Outsie I hear the sound begin between 0:38 and 0:39:
  3. I think this might have happened to me last night. I searched before making a post to ask what I might have done tonight to cause me to not be able to lock targets with the HTS. I was on a MP PVE server trying to thin out a SAM net. There were SA-5s surrounded by SA-2s and SA-6s. I didn't have anything under PGM5 on any radar. After dodging several SA-5 launches at me, eventually the SA-5 quit firing at me. I thought maybe it was out of missiles. I moved in closer to see if I could at least get the search radar or an SA-2 or SA-6 in the way. I had managed a PGM2 on an SA-6, but I could not lock it, or anything else. I've flown on this server quite a bit and had other F-16s initiate TDOA, so at one point in between dodging SAM, I noticed a couple of other F-16s in the area, so I did try to initiate TDOA. It showed TDOA in the HUD, but nothing happened. Eventually I got low on fuel, tried to AAR, but after a few disconnects I had burned more than I took in, and was dangerously low and had to divert to a neutral airport to refuel. After refueling, I took off, and was still unable to lock targets. I tried cycling power to the HTS and HARMs, but it didn't work. I gave up and decided to RTB. Then something weirder happened. After switching back to NAV mode, I pressed CZ on the HSD, turned to my home waypoint, then realized it was taking me nowhere near my waypoint. I looked at the HSD, and CZ was still there, I pressed it again, and it resets for a second then slews off to something. I switched through each sensor, FCR, TGP, etc. and pressed CZ, but it would do the same thing. It didn't stop doing that until I turned off the HTS. Since it was on a MP server, I do have a track, but it's large. I can play around with it in SP and see if I can reproduce it, but I won't be able to fly again until Friday or Saturday.
  4. It's been a while since I did AAR in the F-16. I personally found it easier to zoom out a bit and not even focus on the lights. I got to where I could do it consistently. When training in my own personal mission, I would top off on the tanker before landing. I got a bit rusty because I started learning the F/A-18. I find the 18 is easy to AAR. It seems more forgiving. My first attempt I hooked up and took a full load without a disconnect. I bounce back and forth between the two. When I come back to the F-16 it takes me a few times to get back to where I cad do it, but when going back to the F/A-18 I have no problem.
  5. I tried, but I can't replicate what happened yesterday. I left the nose fuse the default (M904E4), set the arm delay to 2s, left function delay at 0s. For the tail fuze well I selected plugged. I set the same options on SMS; single bomb, RP 6, and 200ft spacing. I even dropped them the same way, about a 20° dive at 2500ft AGL. The bombs are exploding now. Your dud GBU-10 wouldn't have been using the new TGP on a point track of a moving target? There is a known bug with the new TGP where LGBs miss moving targets in point track. That was what I was initially testing to see if it was fixed with the update (it isn't). I took two GBU-12s and 6 Mk-82s. The first GBU-12 didn't track, but I was able to use INR track and manually keep it on the moving target. I was going to use the Mk-82s to clean up, but they failed to explode.
  6. I usually only use one fuse if I'm using a plugged nose and a delayed tail fuse, and I've always left it on NSTL and it still worked. Tonight I was messing around and took some Mk82's with the default nose fuse, and plugged tail fuse. On the SMS page, I left it on NSTL, and the bombs were duds. I didn't have the time to test if a plugged nose and tail fuse worked. Before I go to the trouble of testing other single fuse options and reporting it as a bug, I want to make sure if this is correct behavior.
  7. That's the page I was talking about. It says that rejecting a target on the HAD doesn't clear the sight point. I've been pressing TMS aft before switching back to NAV mode and it has been resetting the cursor back to the steerpoint, and it shouldn't, so maybe it was a bug that they fixed. From now on I'll just remember that doesn't work on the HAD. The email that came a day after the patch says "a long list of HAD and CMDS improvements", but I only see two things listed in the change log related to the HAD.
  8. Hmm, that appears to be what it was. I don't know how I missed that, but it brings up more questions. Why did shutting down and restarting the jet not clear the cursor slew? That screen shot was taken before restarting, so I don't know if CZ was still even an option after that. That should be easy to test though. I had forgotten there was even a CZ button on the HSD because I've made it a habit to press TMS down a couple of times before I switch from A-G mode back to NAV mode to undesignate any SPI and reset the cursor. I was flying long range SEAD missions that night, and only had the HTS, two HARMs, two fuel tanks, and some AAMRAMs. Reading back over the HAD/HTS/HARM pages in the manual, it sounds like it's not supposed to reset the cursor, but I haven't had this happen in ages.
  9. This might need to be posted to bugs, but I don't want to jump the gun just yet, plus I don't have a track file because DCS crashed and it was corrupted. I do have the Tacview replay, but I doubt that would be of any help. I noticed the patch notes for the recent update says: "Fixed: INS drift is not GPS corrected and INS drift adds up to more than 1000 ft over time." I have been playing on the TTI Syria server lately, and have had no issues, until now. Unless I get shot down, I land, re-arm, and refuel, and go back up. I've never needed to do an INS re-alignment, and I've only noticed a small amount of drift over several hours (2-4) in a session. Last night though, after 1 hour my waypoints were 20nm off. I don't know if this is an INS issue or something else, because it was very odd. The location of the waypoints in the HUD, HMD, EHSI, and the cake symbol on the radar all showed the waypoints in the wrong place. The HSD page showed waypoints in the correct place, and the auto pilot navigated to the right place in steering hold. I didn't notice anything was wrong until I was RTB. I had a quite a way to go, so I flipped the auto pilot to altitude and steering hold while I cycled through other players to watch them while my jet cruised home. I popped back into my cockpit occasionally, and 50nm out I switched to attitude and steering hold and started a descent. When it showed ~25nm out I realized something didn't look right. The waypoint symbol was outside of the HUD to my right. I looked and the waypoint symbol in the HMD was in the middle of nowhere, not an airport. I looked around, and the city was to my left, so I knew I should be near the airport. I looked at the HSD and it showed I was passing over my home waypoint. I banked and I looked down and sure enough I was right over the airfield. I landed, and taxied to a parking area where players don't spawn to re-arm and refuel. After I re-armed, I performed a full INS re-alignment. I verified that the INS page showed the correct LAT/LNG and ALT before aligning. With 8 minutes to kill, I cycled through other players until the alignment was done, but it still showed my waypoint 20nm north of where I was, when it should have been right in front of me. I know I could have re-slotted and been on my way, but I was determined to fix this. I tried doing a complete shut down and restart of the jet, and another full INS alignment, but it still had my waypoint 20nm north of me. After that, I had no choice but to re-slot and start over with a fresh jet. My second mission was a little bit longer because while I was messing with all of the above, other players had cleared the area I was working on of SAM threats and were mopping up the remaining ground units. The second flight was about 1.5 hours, and upon returning home, my waypoint was off again. This time it was 10nm northwest, not as bad as before, but it shouldn't be off by that much in such a short time. When I disconnected, DCS crashed, which I don't think has ever happened either. I did submit the crash when the crash reporter popped up. The track file is probably corrupted because of the crash. I checked the tracks directory, and it has two files of the same name, but one has the .trk extension, which is only 11MB, and a .trk.writing that is 10MB, both are way to small for as long as I flew. I did try anyway though. The .trk fuke gives an error, and renaming the .trk.writing to just .trk causes DCS to sit at an infinite loading screen until I kill it. This screen shot shows the LAT/LNG on the INS DED page, which matches what I get from the F10 map. I ALT-clicked my aircraft on the F10 map to get the popup that stays when you go back to the cockpit, but I wasn't thinking and closed it when I took the screen shot. I took this screen shot to show that the position of the waypoint should be in front of me, I don't know why the map is in MGRS, but you can convert it to see that it matches what is shown above. You can also see that the waypoint is correct on the HSD. This screen shot is me looking over my right shoulder where it's saying the waypoint is.
  10. Awesome, but that still leaves some questions about the stores config caution light. I don't know if you found public sources for what some have said. It was mentioned that the stores config caution warning is basically and advisory and it's up to the pilot to know what is still loaded and put it in the correct position. For example the stores config caution will be triggered when dropping A-G ordnance from stations 2 and 7 when you have wing tanks loaded, but you still may be loaded in a way that requires a CAT-III config. This is how it is working in DCS now, but I didn't know that I was incorrect by placing the switch in CAT-1 to clear the warning. I'm also still curious as to why the AIM-120 is a CAT-III store. Is it the weight of the missile that can damage the aircraft, or can the missile be damaged? Although, unless you implement damage to the weapons or aircraft from flying in an incorrect stores config, people in PvP servers are just going to throw it in CAT-1 and not worry about it.
  11. I've been wondering about this but I keep forgetting to look into it, but today I finally looked into it. I noticed that when I have two wing tanks and an A-G load-out, when I drop the ordnance, I get the stores config caution, but with an A-A load-out and two wing tanks, it wants me in CAT-III, even later when they run dry. After reading through the topic, it's mentioned that the stores config does not limit the Gs the aircraft can pull. I remembered watching a video of an F-16 doing BFM a while back and the pilot mentioning having a G limit until below a certain weight. I assumed he was referring to the stores config. I managed to find the video, and at 6:40 the pilot mentions being limited to 7 Gs with two external tanks or risking over G-ing the jet, but he says it's something he has to watch out for. Later at 9:30 he says he has 400 lbs. to go until he can pull unrestricted Gs. It looks like damage from incorrect stores config and over-G isn't modeled in the DCS F-16 at all. I just tested it out with two external tanks, two Mk-84s and four AIM-120s. I put the stores switch to CAT-I and no matter how abused the flight controls, even managing to pull 11Gs, and nothing broke. I've always switched to CAT-I when I get the caution, so if I want to be realistic I should stay on CAT-III with TGP, HTS, AIM-120s, and asymmetric load outs. Who am I kidding, until ED implements damage to these systems or structural damage from improper stores config, I'll probably just keep doing what I've been doing. What makes the AIM-120 limited to CAT-III? Is there a source for that? If true, DCS has it wrong. Loading 6x AIM-120 has you in CAT-1 by default.
  12. I'm in the US. I just seems odd that two cards from two banks don't allow transactions to ED. The payment does show up as going to Switzerland on my account. In order to get the payment to go through, I have to call the bank, then make the order while on the phone with them so they can override the block as it goes through. The person said it's blocked because it's an international transfer, but I don't buy that. I also bought a new HOTAS back in March after getting the modules, which was also an international payment. It didn't get blocked, but it was held until I called and approved it. That was quick and automated, unlike when I try to make purchases here, it flat out blocks it and I have to spend ~30 minutes on the phone to get someone to override it. I'm also wondering why PayPal is setup different here. It only lets me chose my debit/credit cards and not my bank accounts to pay with like it does everywhere else.
  13. Back in February I bought my first modules. I prefer to use PayPal, Google, etc. because I don't like entering my debit and credit card numbers online. I first tried PayPal, then Google Pay with my debit card before trying with the credit card and those transactions were denied. I gave in and tried the Saferpay thing, they denied that too. These are two different cards from different banks, and they both blocked the transaction. The next day both cards were locked due to suspicious activity, and I had to call to get them re-activated. Normally when I pay with PayPal, I can choose any payment method on file, debit, credit or directly from my checking account, but when I pay through PayPal to here, it only lets me use my debit or credit cards. I was eventually able to pay by calling the bank and having them on the phone while I made the payment and they had to override it as it went through. I just tried to buy a couple of modules now and it happened again. I had to call again and get the transaction overridden. I bet my credit card is now locked. Like the last time it was locked, the notification didn't come through until the morning. This has never happened anywhere else except here. Do need to start buying modules from Steam? I don't like using Steam if I can buy directly from the source, but I don't want to have to spend 30+ minutes on the phone every time I want to buy a module.
  14. So they should be judged by the effort put into them? You can put a lot of effort to stage bad screenshot, meanwhile lots of good screenshots just happen all the time naturally, with no effort.
×
×
  • Create New...