messiahua

I've installed latest IF patch 1.03 and as far as I understand it is based on 1.62 for OA, but I still have the problem with textures and only one video memory setting - "low". BUT for arma 1.62 fixed this issue... why not for IF?

If there will be no 3D editor in A3 at all, I will be really disappointed :(

Common problem currently. Desynchronization causes this and I guess it's all related to: http://forums.bistudio.com/showthread.php?134831-Iron-Front-dedicated-server-statement That's probably related to http://forums.bistudio.com/showthread.php?134866-Video-memory, but you don't have flickering and performance degradation. Unfortunately, I guess the only solution is to wait for fixes/patches.

Unfortunately it is not as structured and organized as I would've wanted it to be, but I'm glad to provide any other additional info, if needed, and I hope this issue will be resolved, because it makes not only IF experience worse, but also Arma :(

Here is my iron front video: I've forced textures to "High" in config. The higher video memory/texture setting, the more severe is this problem. Pulverizer, do you have the same flickering? ---------- Post added at 14:38 ---------- Previous post was at 14:28 ---------- Tried maxVRAM with arma - doesn't help. Tried, the higher - the bigger the problem. No way :) See no sense... Atoc = 0, PPAA = 1

I have this problem also (with Arma2 too) since upgrading memory. I had 4Gb RAM and everything was perfectly fine, now I have 16Gb and textures/UI started to flicker in arma. I made extensive memory tests (memtest, s&m) and this is not memory related problem. I bought Iron Front and now have same problem. All other games and software works fine. I've tried everything possible to fix, but still no result, apparently it's engine bug. Currently experimenting with different mallocs in arma. Specs: win7 64, i5 750, radeon 4870

You need to start your own kickstarter resource to be able to collect money for specific features. :)

Nothing special in the mission itself, probably except its unusual size (~8mb). Every other mission we play is the same in terms of acre. Probably this is related to arma stability, but on previous stable version of acre I didn't get such error. Anyways I hope it won't repeat, because I see it's hard to figure out what's wrong.

Yesterday for no apparent reason I got this error and radios didn't work: Error in expression <(isNil "acre_sys_data_radioLockObject") && !(isNil "acre_sys_server_obelisk") ) > Error position: <&& !(isNil "acre_sys_server_obelisk") ) > Error Generic error in expression File idi\clients\acre\addons\sys_data\fnc_getRadioState.sqf, line 9 There where playing around 30 people and nobody, except I guess one more person, got this kind of error. All other missions where fine, this is the first time I see such kind of error after updating to latest version.

Where there fixed any bugs related to vehicle racks in this version?

I've just updated (build 2.9.5030) and now in standard ACE preset I see CBA_A2/CBA_OA and it offers me to install both, but I have CO and can't remove them from preset, it says: 13:48:14: Please confirm: Are you sure you want to remove @CBA_A2 from CUST - A2 OA - A.C.E. 13:48:16: Didn't find @CBA_A2. Perhaps it is a dependency for another mod or selected server What should I do?

I searched long for this one. ace_sys_eject_fnc_weaponCheckEnabled is holding code, which checks when to drop, so reassign it after ace_sys_eject addon load: ace_sys_eject_fnc_weaponCheckEnabled = { false };

The main problem I see right now in arma2 is simple shadow draw distance. Of course foliage drawing distance and total new lightning engine are also part of this, but simply drawing shadows for any object on any distance will drastically improve things. Don't know how much GPU intense it will be, but that's a massive drawback personally for me right now. You can very easily spot targets on long-range, because they are shining against the background. In close combat it's a lot more harder (even without grass). Also one should be able to force them on dedicated server, otherwise any person can disable them and gain tremendous advantage over other people. Screenshots for comparison:

Only stability? Nothing changed for vehicle radios? Just asking. Don't want to test them for nothing :)

I was playing random mission on dedicated server and first time ever for some reason this error appeared:

You can read mission makers notes here: http://ace.dev-heaven.net/wagn/Wind_Deflection

I need to execute some code in addon when player respawns in other unit inside group (if respawn = 4 in description.ext). I've tried using extended event handlers (cba xeh) and also script command add(MP)EventHandler (respawn/mprespawn), but it doesn't work (rpt only says "Group respawn processed locally"). The only script, that gets executed is onPlayerRespawnOtherUnit (http://community.bistudio.com/wiki/Event_Scripts), but I need to do this inside pbo, so that's a no go. I've searched all over the place + google, but found nothing. Is it possible to handle group respawn in addon somehow?

Implemented alternative solution: endless scripted loop which checks if player != player...

nevermind, I found function at last: ace_sys_eject_fnc_weaponCheckEnabled

Currently when you get in any crew position in vehicle, your weapons are being dropped or stored in vehicle cargo, but ace_sys_vehicle_limit_crew_weapons is false by default, so why is it working? How can one disable this feature?

Nevermind, I figured it out myself by storing handle number in uiNamespace.

I've just finished testing and came to conclusion that there are very serious problems with vehicle rack radios. I made 3 tests with one more player. 1st test (blackhawk): I have only 343, other player has 117F and 343 I enter blackhawk and press "Use Radio" on interaction menu: http://tacticalgaming.kiev.ua/tmp/acre3/1.jpg I try to use radio and it works on default frequency I switch to same frequency to contact another player and he hears me, but I can't hear him, even the debug hint is not showing If I try to switch to another radio (ctrl+shift+a/s), I can't switch back to 117, because it's completely missing on radio list: http://tacticalgaming.kiev.ua/tmp/acre3/2.jpg If I exit blackhawk, 117 appears on my radio list http://tacticalgaming.kiev.ua/tmp/acre3/3.jpg, I can use it and everything is working fine, also one more minor issue if I press "stop using" I still can use 117 until switch to any other radio (even far away from helicopter) If I then enter heli, I have fully working 117 and can switch forth and back, and we can contact and hear each other 2nd case (harrier): I have only 343, other player has 117F and 343 I get in harrier, press "Use Radio" on interaction menu and behavior is the same as with blackhawk, I can use 117, but it doesn't appear on active radio list and I can't hear other person: http://tacticalgaming.kiev.ua/tmp/acre3/4.jpg, but he can hear me. If I exit harrier, 117 still doesn't appear: http://tacticalgaming.kiev.ua/tmp/acre3/5.jpg and I can't hear other person (no debug hint), I can contact with him only using 343 If I enter harrier, 117 still missing: http://tacticalgaming.kiev.ua/tmp/acre3/6.jpg 3rd case (m1a1): exact same story as with harrier It's strange to me, that it's possible to override this bug with blackhawk, but not with other vehicles. I very much hope this issue will be fixed. If needed and it will be looked at I can create a ticket at bug tracker.

I'm playing around with arma2mysql and trying to get it working. Everything seems to be fine, except one critical problem. I start mission, pipe gets opened, then if I stop mission and restart it without closing pipe, it can't connect to the same pipe, i guess because it's blocked already. How can one handle this? ACRE is working somehow, but I guess it somehow handles this situation inside dll.

While surfing acre_sys_io\fnc_startServer.sqf i've noticed on lines 66 and 72 this function: acre_syc_core_fnc_resetAllPlayers and I guess it's misspelled, should be acre_sys?

Didn't know about that. BTW where I can see this 65dB loss? Not an expert at radio communication systems. Will make some more tests maybe tomorrow at different angles. I'm doing it because during our missions very often someone with 117F can't contact with pilots for some reason (clear LOS and very short distance), but another person can with just 148, so I want to find repro for this bug (if it is not fixed already :)). Yeah, indeed, didn't pay attention. And one more thing, I also did some test for this issue http://tracker.idi-systems.com/issues/194 and I guess it's fixed, but will do some more just to be sure. Also I noticed, that signal strength doesn't change with altitude difference. I guess, that if someone is higher, then his signal should be stronger or am I wrong?