169th_DedCat

Only if the other guy doesn't recognize what the hog is good at, and tries to win by out turning you in the horizontal plane. Once they recognize that mistake, the hog is a sitting duck. The hog can only be successful as an aggressor against pilots who don't know how to adapt their fighting style to suit the situation... as such, it is not a serious competitor.

Thanks guys. I will let you know if the disconnect problems persist after I've made these changes. S!

I seem to be having this problem fairly often with clients in my games. Clients are getting dropped as soon as they get into the game. Sometimes the log says they timed out, sometimes it says nothing besides "remove: client X". Yesterday this was happening to one of my squad members consistently who had been playing in the game for some time prior to it happening over and over. He would join a game with a fast ping (<80ms), click fly, and as soon as his game loaded and the server broadcast that he had entered the mission, he was dropped from the server play list... though the game kept running on his own end. He rebooted his computer, we both rebooted our routers, I switched to a different host computer, and still he was dropped as soon as he entered the mission. He had the quickest ping in the game. Other players were joining the mission without issue. I know some of my squad members are getting disconnected consistently every time they enter any server, but it only happens once and then they can re-join without issue. Yesterday the problem seemed to stick. Anyone know if perhaps lengthening the default 10s gameTimeout value might help?

Ya, Tweet's da man. :)

Good question.

Screenshots c/o 169th_Vulcan Ya, that neck is definately broke...

Sevastopol' Monument

Good summery GGTharos. Even in the case of a maddog ARH missile shot, I doubt the AMRAAM (or the Adder for that matter) would use a killbox for the full horizontal and vertical 180+ degrees that its gimbals may allow. Not only is search time an issue, but safety would be as well. The limits of the default killbox would probably be on par with the visual aiming circle on the HUD for the AMRAAM. If a pilot needs to make a maddog Fox 3, he wants the missile to go after the target he's pointing his nose towards. If the maddog fails to immediately find its intended target, the pilot doesn't want it to go for another, possible friendly, aircraft that may be much closer but 85 degrees above him. Missiles in LOMAC will. There must be safety restrictions to consider, even when a weapon is told to "go find your own target". It should be more of a "go find your own target, in this general area". Imagine a weapons production company designing a cruise missile that after initially failing to find its intended target, went after the first building it saw. I don't know anything about cruise missiles, but it seems to me that whatever the weapon, restrictions are usually considered for what it will and won't go after outside of the dangerous simplicity of anything as far and as wide as it can possibly see.

Turn your radar on while in VS and you can get get a lock on the nose for as far as the radar can see. All the F-15 Eagle's AACQ modes are still all locked in at 10 miles though. Some say the AN/APG-70 AACQ modes should work out to 15 miles, plus there is a 40 mile long-range boresight AACQ. That's not quite what is modeled in LOMAC though, our Eagle has some kind of unique radar hybrid between the 63/63v1/70. Suffice it to say that all the AACQ modes in LOMAC are modeled a little funny.

After going H2H against a couple of MiGs and the odd Flanker for a couple of hours. The missile effectiveness slider was set to full however. No magic ARH shots from 20 miles, just lots of hard work.

That's pretty normal. HOJ shouldn't be anywhere near as effective as a solid SARH or ARH shot. A true HOJ missile isn't going to have a lot of information to plot a serious intercept, it is a jammer it is tracking after all. HOJ shots are only really effective against non-aggressively manoeuvring targets. They seem to be pretty relentless against fleeing targets that don't know enough to switch their jammer off though.

Jamming doesn't make anyone immune to anything. If anything, the way most LOMAC pilots brainlessly fly around broadcasting ECM all over the place lights them up like a Christmas tree. People seem to think it makes them harder to find or track, it in fact makes it much much easier. Things only get tricky if there is a large group of jammers to sort. I prefer the way ECM is modeled now than to how it was in 1.02. There was no such thing as a HOJ shot in 1.02 since the burn-through range was well before any medium range missile shot.

These exaggerated gimbal limits on the ARH missiles radar have been noted before. Ice posted a thread here about it, complete with tracks demonstrating the issue, a while back for 1.02 under the topic heading of "maddogging". It is a problem for the AIM-120 and R-77 both. I believe I read somewhere in here that the modeling for these missiles is essentially the same, except for the differing rocket motor burn times.

I realize... my point was that when the scanning bug occurs in the Eagle, the radar not only stops scanning, it stops transmitting entirely.

I don't think the AIM-7's flood mode works when this bug occurs since the radar seems to not only stop scanning up/down and right/left, but it seems to stop transmitting entirely.

I have experienced it in at least three occasions so far, and switching from VS to RWS or anything else never fixes the problem. The only solution for me is and has always been to eject and get a new bird.

TWS works fine... bug a target, fire an AMRAAM, and they won't know it is coming until the missile goes active. The brightness contrast of the IFF icons in TWS could stand to be improved though. Eagle HOJ is messed however. A HOJ track in the Eagle will give the enemy a lock warning, however if you fire a HOJ Sparrow at them they won't receive a launch warning. ARH HOJ shots will give a launch warning I believe, but I think that's because they start pounding the jammer source with their radar as soon they come off the rail. I have no idea if that's what they do in real life. If there is a lot of music in the theatre (which there tends to be since everyone seems to flick their on SPJ and give away their location the moment they see a radar spike) I stay in RWS until I'm ready to engage.

I enjoy flying both the Eagle and the Flanker in LOMAC. You will never win this argument with DeathAngelBR because it is entirely based on a highly restrictive personal bias, and very little else. When DeathAngelBR or any other uni-plane fan says something as pointless and inane as they often do (see post directly above this one), it is usually best to just ignore them less another useful thread degrade into yet one more "Well, my dad can beat up your dad!" type childish, pointless, flame war.

Because they were WAY too scripted IMHO. ED is trying to model real world variables into their missile code, and I appreciate that a lot. To me the missiles in 1.02 were too infallible. They didn't feel like they behaved with any believable real-world limitations. It seemed like they were just following a given intercept point A for a designated target B, and unless target B caused the missile to run out of energy before reaching point A, the missile found its magic mark. Now missiles seem to actually work their intercept based on what information is available or masked in the theatre, rather than the ideal intercept flight path just being handed to them by the omnipotent game engine (with a small margin for error provided by counter measures). Yes, there are some obvious deficits with the current missile code. I set to the missile slider to 100% to compensate for those problems currently, and I quite enjoy the feel game at those settings. Everything I've read says that ED is re-working the missile code for the next version to get around the current limitations with their missile code anyway. I really hope they don't feel pressed to fall back to 1.02 missile logic. Personally, I would much much rather dynamic missiles that sometimes fall short of expectations, than scripted uber-missiles that seem to fly by the all seeing hand of god and always make the numbers. For the record, I've flown the Eagle extensively in 1.1 and have no major complaints about its performance (with the possible exception of no STT IFF and the HOJ lock warning it gives the enemy).

I think just about anyone who has driven the Eagle in LOMAC for any length of time has experienced this bug. I'm sure a lot of people just don't notice it when it is happening because they may not recognize when the radar antenna carets stop moving. To me it seems not only linked to switching the radar on and off, but some sort of combination of that and the AACQ modes, especially the Gun AACQ mode. Something about switching in and out of that mode, turning the radar on and off, and possibly even switching in and out of NAV mode in the improper way triggers the bug. I've never nailed down the key combination that causes it, but I try to avoid it as best I can by using the AACQ modes in as predictable a manner as possible.

I don't mind that feature at all Quirk. It allows you to easily set different parameters for the different missions you create instead of always having to remember to adjust them before the game. Should you want to change them while hosing you don't have to quit the server session. Before you launch them game (when clients are connecting and choosing teams), simply use the declassify password, go into options and set them as you wish. You do NOT need to re-classify it, save it, or disconnect clients. The mission will remain classified with the new options you set for your clients.

That's really a shame. I knew classifying the mission locked the client into the default payload, but I had thought that ED had set 1.1 up so that when a client joins an unclassified mission, their payload selection is still limited to the weapons available in the server's own weapon pylon configuration, so that they may create their own payload but are limited to the weapons available on that aircraft in the server's pylon config file. I guess it's all still locally configured. Looks like the only way to prevent LOPE cheaters is to lock the client into a single payload. :frown:

When you classify a multiplayer mission in 1.1 (In the top menu bar in the mission editor: Edit -> Classify -> Set a password) changes cannot be made by clients to their skin, aircraft #, or payload. They may only use the default one you specified in your mission.

This happened on one of our squad member's computer while he was hosting, see screenshot below. The mission was not classified, however even then I thought the client was supposed to be force fed the servers weapon pylon config LUA in 1.1 so they couldn't use completely bogus payloads like this on anything but their own PC. Am I wrong, or has someone already found a way around the server pushed pylon configs?

I do now. Where was this mentioned in the manual btw? I must've missed it. So the HSI in the Frogfoot is using INS? From what I've heard the INS is primarily only a backup system and is not normally tied into the HSI as a primary means of finding bearing. If your modeling is correct, than the Su-25T's HSI must be beyond old-school. Where does the HUD get its bearing information that it can't communicate it to and correct the HSI? Or why can't we have a knob to manually correct it ourselves? To quote Cobra...