homepage Forums Air Combat & Civil Aviation Jane's F-15 & F/A-18 JF-18 AI Traps

cool, will check it out, thanks a lot.

when it works with about 30-35 FPS locked, i can live with that framerate, as this is the range where your eyes do not see any stuttering. at least its sufficiant for a flight simulation. (think of FSX and its framerates...)

If a wrapper can be created that invokes the next TSH executable and has some run-time options by limiting/capping Framerate, this could be "solved."

Hm for me the FPS Limiter does not work. It seems to not limit the framerate.

If i use the default command line like 'FPS_limiter "path/f18.exe"' which should result
in using a limit of 30 fps using the D3D9 renderpath, the game starts correctly.
ACLS does not work, still the wave-off behaviour.

If i use the /F:xx switch on the command line to limit the frames to xx, it also seems to have no effect. To verify that i used a extreme setting like 10 FPS, which should clearly be noticable.

Also i tried the option /R to select the renderpath (D3D9 or 8, or OpenGL) which also made no difference.

I also have checked that VSync is turned of in the ATI Catalyst Control Center.

I use WINXP SP3, Specs are ATI 4870, Intel E8400 C2D, 4 GB Ram.

Maybe its an issue with dual core cpus.

I will try around with disabling a core during boot up.

Just a little upgrade :

If using FRAPS and recording a video with a framelock of 10 FPS, the ACLS landed correctly.
Anyway, the real issue for me remains the AI-cannot-land problem. For my landing i'd never used the ACLS. I like the challenge trapping manually.
So for the AI problem, if they would successfully land with lower framerates, in my opinion it is a very strange solution enabling FRAPS video recording for the time they approach.....

But sometimes AI are landing and you are still feet dry going about your mission...

Interesting that this is an issue linked to framerate, and not directly to CPU speed.

I also noted that my ACLS finals looked a bit different than the one posted from Tolwyn. I believe mine just catched the very last wire and Tolwyn's one or two before.

I first thought 'ok thats gonna be a bolter' but it was a trap then..

If your plane is NEAR the bubble of activity, then AI will likely not trap. It may be CPU for AI, Framerate for Human.

If you're outside the bubble, the prediction doesn't make much difference and AI should trap normally. To test, Call Inbound, but stay outside the bubble, and listen for bolters and wave-offs. You'll get less. To test agaain, do the same, put yourself in a FPAH and Roll hold and use the debub next aircraft command to watch aircraft landing. You'll be back "in" the bubble, and should, theorhetically, see more wave-offs and bolters.

It could be CPU only, as Fraps hits both.

FA18 is a Direct 3D app, using the Framerate limiter in opengl won't affect anything.
VSynch was my initial response before I read that you had it enabled.

Could be collision detecting BECAUSE OF a high framerate.

If the game's polling interval is 50Hz or something, and you're at 85Hz with 60fps... something could be dropping in the collision detection algorythm. Does that make sense?

Wrapper only works, by my guess, for AGP cards. PCI-E won't work.

Which wrapper ?

Tolwyn,

I'm curious, what bubble are you talking about? If you're thinking of a bubble like they have in Falcon (I'm assuming they still have it) I didn't do that. The only thing I remember that will factor where you, as a Player, (or units your computer is controlling) is the multiplayer update code which throttles periodic positional updates depending to how close you are. If you or units your computer is controlling aren't near an area then things being a bit out of date won't make a difference since all the important calculations are happening on another machine.

I can't think of what might make the guys behave similar to a wave off. At least with the bolters I could see some strangeness with the hook catch calculation. As you suggested I have wondered if there might be a problem if the framerate gets higher than the flight model update rate. For the Player this is 50 Hz. For the AI I believe it varies but I forget how much. From what I remember there are 3 levels. One for just flying along straight and level, the next level if they're in a turn and the highest level for things like dogfighting, refueling and I'm pretty sure landing, which should be the same 50 Hz. We had to set that up during JF-15 since running all the flight models at 50 Hz was really hurting the framerate.

Still, if it was something with the hook calculation I think there should still be a problem when the Player lands normally. The framerate might be a little lower in that case since that flight model uses more cycles but computers have gotten fast enough that it should have shown up by now.

Elf

No, not the bubble in Falcon4. Your first paragraph is what I'm talking about. Positioning updates.
But surely you're not sending AI updates at the same polling interval when the player is 100 miles away? This would explain why ai will trap fine when the player is NOT around.

I'd imagine the 50Hz updates is affecting AI when the player is AROUND the AI, if the player isn't the, obviously, no need to update AI every 50Hz to the player (positioning data).

FPS Java Limiter

As far as I'm aware, in single player, everything is exactly where it's supposed to be at all times. Even though we have to load terrain details I think the height information is available at all time which helps with things like radar detection LOS. Even if it wasn't the aircraft are landing relative to the carrier's position so that shouldn't be an issue.

As for multiplayer, which is where the position updates come into play, for each AI one computer is the definitive source of information about it (see "1" below for more info). Even if a landing aircraft is completely out of position on a client (no controlling) machine once it catches the wire on the server machine it will send a message so that all versions of the aircraft will know that they've trapped. I can't remember if I swap control of the carrier to the plane that's closest to landing but they don't require the same update frequency as fast movers and I don't think it should be enough to be a factor in a bolter more than occasionally. If this was a factor then once again it should show up when the Player is landing under direct control and not just for ACLS or an AIs.

1) All AI's except wingmen of Players are controlled by the "server" which is usually the machine that hosted the mission though I think if that machine drops another will take over. If the host drops and it ends for everyone then I'm confusing it with another game I worked on but that's easy enough to confirm. I believe I set it up though that wingmen will be controlled by the machine that their winglead is on. Since that Player is going to be the one seeing them the most the idea was that this would keep them from warping on that machine. I definitely remember writing code setting up a grid system so machines that had controlled units in the same grid(s) would get higher frequency updates then those not in the grid. I also did some buffer to avoid "just over the line" issues. The basic philosophy we had for multiplayer was whoever needed the most accurate information would be the one with the determining data. For example the guy firing a gun is going to have a lot better view of if he hit the aircraft he's shooting at then the plane trying to avoid being shot. Missiles might have been the same way but since you could padlock a missile I think we might have let that go to the defender.

Elf

I'm pretty sure that if a multiplayer JF-18 host drops then every else gets dropped as well.

DOH! Thanks for correcting me Joe. The projects start to run together after a while.

Elf

Well, then I still have no idea why I can get the AI (and myself) to trap with lower FPS and CPU load. And no trap with >40FPS and nominal/normal CPU load...

And that I've come back from long missions with 8 planes on the deck, but when I'm in the Marshall Stack, I get bolters.

But I'll keep workin' on it.

There are a couple of reasons why you could have planes on the deck but you still can't land. First off they probably landed while you were still feet dry. Out on the water there isn't a lot going on graphically so your framerates will be higher. This is why we were able to have more planes park up top before having to start sending them down. I believe I actually had more planes able to park on deck and there's a way to get that to happen with a registry setting or something but I forget the details. I think I posted it on comp.sys.ibm.pc.games.flight-sim or somewhere like (possibly here) years ago.

The other thing is that they may have run the pattern a few times and as mentioned earlier I put in an adjustment to move their landing point back, though eventually capping. Perhaps that code still does some good.

Elf