Bug11

if you have a firewall running, try turning it off and see if it helps.

having that large swapfile isn't really a solution it just allows you to live with whatever memory leak is chewing up available resources for longer. hopefully ED will locate it and squash it in another patch.

hey, have you apologized to Bard for saying he was lying about the 5 activation thing? Here's a statement for you to ponder. All the evidence points to Ruggbutt being a homosexual. You see the problem? I've made a statement claiming that there is evidence that you're gay when I don't have ANY though I would consider interior decorating a 'gayish' line of work. I do see hate in this community, and it's the kind that reminds me of spurned homosexual lovers. It's BITCHY. Is that what happened between you and Bard? he spurned your love? What's the word I am looking for. Obsessed.

Only useful if your system checksums the same with starforce. If it's asking to reactivate with each reboot it's likely that it isn't.

only if you're talking many miles of seperation between the two aircraft, aspect is much more important to RCS. perhaps the slammer is simply grabbing onto the closest target. great way of neutralizing in a fight against eagles - first guy is sacrificial lamb ;)

you'll have to purchase flaming cliffs in order to apply this patch to LOMAC.

especially when using things like global variables where local variables should be used and no 'data dictionary' is maintained to prevent such things happening.

until ECCM is modelled AMRAAM's will not behave like they do so no comparison to real life is relevant.

no starforce works perfectly without any issues so it must all be in your imagination. oh. you meant something else stopped working? that's just purely coincidence and has nothing to do with starforce at all. ;)

starforce. try reinstalling the app - or uninstalling starforce.

ParticleEffectPlayer: couldn't load material 'PFXExplFire', falling back to compatibility path .. looks to be self explanatory - these particle effects being called can't be loaded - what reasons for this could there be? 1 - the data doesn't exist 2 - it can't find the data 3 - the data can't be loaded because it's wrong/incompatible or something. are the particle effects stored as individual files somewhere?

see this thread: http://forum.lockon.ru/showthread.php?t=10547

performed some testing. to reduce stutters i set terrrain preload to 900km, and the same for around objects. using the stutter config from lomacfiles otherwise. launched the f-15 'flight' mission and this resulted in a 2 minute load time for the mission, BUT no stutter when panning 360 from the pit on immediate mission launch. memory usage for lockon.exe was 750meg. did the same with the su-25t column hunter track, and the memory usage was over a gig. the only stutter present was when the view switched. a tentative conclusion would be that 1 gig of memory is not enough to allow texture load free missions - therefore you will get stutters from either texture loading, or if you increase the preload you will get stutters from swapfile. i would consider 1.5 gig of memory to be the minimum to have to realistically expect to be able to preload data to reduce stutters, but would suggest 2 gig for extra playing room. when i get time i will try the same with an untweaked graphics config and see how it runs.

that seems to confirm it.

can a dev answer this please?

I am looking to try and get rid of stutters and have gone through all the various tweaks and tips, and it is obvious that a lot of stutter comes from loading data in game. I picked up an extra gig of RAM and would like to know if there is a way of forcing ALL game data to load into memory before the mission starts? How much memory this would take? How much 'working' memory for game processing is needed?

:D

yes - normally you would be right. for some reason the LOMAC process to offload the sound processing to the soundcard hardware takes up more processing power than you save by doing it.

Did some side by side tests with the same cpu and video card on two motherboards, but one of the systems had dual channel memory support - the sustained framerates on this box were significantly higher than on the other one.

how about removing some components of the graphics so that you can extend the draw distance so there are no popups whilst still retaining a playable framerate. in other words, cut down the object density to a level today and tomorrow's hardware can realistically handle.

create a mission in the northern areas where there is no water for 100 miles and check the framerate with all the different water settings. that will definitively prove it or not.

maybe after the next patch things will liven up a bit, at least for a couple of months.

0.1 - general feature requirements are compiled 0.2 - each requirement is analyzed and relationships between requirements are established 0.3 - data necessary for each feature are established 0.4 - data structure is rationalized 0.5 - features are designed 0.6 - features are tested at design stage 0.7 - revision of design is performed based upon results of tests 0.8 - repeat 0.6 and 0.7 until design passes test 0.9 - touch the keyboard.

There does need to be a new patch, not only to address 'bugs' but to also get rid of the awful way the game stutters when loading graphics.

Not without the old ball and chain finding out ;)