sparky

Let me give you a clue about what is happeing in GReece nowdays... "I went for a job interview for the position of web designer, after i get the 1st interview pass, i get to the 2nd one which i made a demo to present my skills to them, i also passed that interview and i arrange a meeting in order to talk about payment and workhours. Well in that meeting the company owner told me that he wants to take me but my monthly salary was going to be 700 euros for 8,5 hours per day 5 days per week." So tell me what would you do? btw unempolyment is around 17-20% All these are bullshit. 1.From one hand we have to pay our fucking assholes politicians and their corruption over the past 30 years (after the end of the dictation of 1974). 2.The loans which actually was the money in order to buy form our friends things link tanks, cars, airplanes, weapons etc... and which btw we have paid them.... EU isn't the thing you imagine, is a union in which Germany and other industrial countries can sell chepaer their shit to poor unindustrial countries....

I thin that vertex count and polycount are at the bottom of your O2 screen. About proxies. Be cautious, although proxies is a good technic to save some of the polies actually made on the vehicle, there are some things that you need to take care and walkaround them. i apologize to the admins about reposting a post of mine from an other thread but it's the best example to demonstrate the proxie use. The following is part of the HWM pack 4.0 release which included an ah64a. -------- ok, since we've promissed to reveal the polycount. here it is. The AH64 is quite BIG poly, BUT, we based the design, on proxies in order to minimize the parts render by the engine at a time, and make it off course loadable in game. Unfortunately since the model has a lot of details, we've created quite a few maps to get textured and in quite big size cause we wanted the best we could get. And that has as a result quite a few sections. Although we gave our best to eliminate ST point errors, no planar face errors, nd keep the section count the minimum, still we are quite high. Also keep in mind, that all the 3 weaponry versions are based on that one p3d. But anyway. Here the screens The 1st O2 screen represents the AH64 as is in game, proxy parts are visible by the triangles The next image represents the WHOLE ah64 combined, no proxies, higher version of cockpit that in the ingame version areavailbale only to pilot view and gunner view and even the missiles. You can read polycount/tri count and sections on the bottom, the last image hasn't very meaning since you can't have this polycount drawn at a time, basically cause of the cockpit, which are visible only in 1st person view, for 3rd person view it has been replaced with a simplified proxy of them. --------- comparing the previous images you can see that we have designed the wheels, the missile pylons, the whole interior cockpit,the tads and some other parts as proxies, also by noticing the bottom of each image you can see that we have already break the barrier of 30000polys (quads - no tris) since Arma1, using the proxy technic. BUT, here are the side effects. at least for ArmA1 since i haven't work with Arma2. 1)Engine doesn't handle proxies the same, which means that damage textures etc, aren't change for the proxie parts, you need to work with scripting technics in order to make an illusion. So, better use proxies for smaller parts which probably you will make them disappear when the vehicle will destruct. 2)since proxies are rendered seperately of the main object, as seperate you can have layered problems, which means that you can see some parts through the other, or you won't be able to see. alsop digging up, that post i found an other research of mine about what a high poly model could cause to your system (ArmA1), here it is. ------------------------------------------------------------------------ Well i think it doesn't matter very much the polycount at this point since the source for the BIG Fps drop is an other factor. So to sum up Issue -Stringtable problem with the non_English ArmA Versions (will be fixed in next version) -FOV although FOV isn't really an issue but a personal taste thing, since the majority wants a closer FOV, it's going to be fixed -Flight Model, Well at this point we can't invest very much in researching for the ultimate FM, but we will try some ideas to find a better one -Leopard Armor, well don't worry about that wait and see... -Tail Rotor, wrong spin direction, will be fixed in next version. -Glass grey effect, that issue needs some research before we can have a solution, we're going to try though. -Bullet Proof glass, Can easily fixed. The Chopy/Frame Drop Issue After the frame drop issue, we begun to invastigate in order to find the source. We do a varius tests in order to see different combinations and sum up with the safest results. Scores that will presented here, are from my PC which is at the low-med PC category to RUN ArmA. The configuration is Intel PIV Prescott 3.2Ghz, 2GB Ram 400Mhz, ATI X1950Pro Sapphire 512MB Ram AGP. ArmA configuration, all options to max, with terrain detail LOW, postprocess LOW and view distance 1630, Screen Resolution 1280X1024. With the following PC and ArmA configuration i Have 25-28FPS in an empty Rahmadi. The test was to have 9 empty AH64A's with players back at them and when the mission starts to turn and face them in a way that all of them can be on screen from close distance Results As you can see the number of materials and Texture sizes doesn't have great effect on the FPS Drop issue but the Major Factor for the FPS Drop is primarily the Huge Number of selections and secondly the shadow polycount and the model polycount. Indeed if you consider that there are around 78 selections only for hydra missile proxies, plus 78 for the flashes, plus 16 for hellfires the number is raising quite high. The better results for a low-end version could be a version that uses the 2nd LOD as 1st, and with no missile proxy disapearing or flashes (at list the way we do it now). Also the thing that must be revaluate for this version is dummy selections that have been left there from editing and probably have no use, but may raise the lag possibility, and a better more less poly shadow, or even an other lod (no matter if i think that won't have FPS effect since the problem is greater in closer distance. Also we need to consider the possibility for an other last LOD very low poly, and lowering the Resolution LOD numbers in order to achieve faster lod switching if that's possible. Hope that table can helps others to learn what thinks to avoid, in order not to face the same issue as we do. ------------------------------------------------------------------------------------- these are all i can remember now. The key when using proxies to lower your polucount but keeping the details high, is to use always smaller parts which aren't significant for the engine as proxies and not big and significant, like a turret or the maingun cause you will have problems. And off course try to make proper LODs

After a lot of thought we have decided to end HWM development. It was a good journey. Sure we have learnt a lot, and met excellent people in this community. Although we haven't achieved our goal, we are satisfied with the quality of the addons we managed to produce. There are a number of reasons that lead us to this decission some important some less important, the fact is that our decission is absolute. HWM website will be up for a few months for those who are interested in our addons for ArmA1 to have an access on them, but there will not be any release for ArmA2. As for now me (Sparky) has already join with the unsung mod, and Aplion probably will follow too, so there is great chance to see addons by us in the future. We like to thank all the people out there that help us at that difficult task. -Mainframe -AnzcsasSteve -DrEyeball -HAC (Hellenic Arma Community) From Behalf of HWM team (Sparky, Aplion, Liongreek) goodbye.... It was a good journey. :)

Well, 1st although i personally enjoying the "support" you're offering to our mod, I would suggest to stop popping new post around with questions about HWM AH64, the most likely is the moderators to lock them, better use the appropriate ArmA 1 thread. Now related to your question. HWM addons works up to a point by replacing the old XEH (extended events handler) with the new one that is included in the CBA, that can solve some issues. About the sidewinders, the HWM AH64A was designed in 4 Versions (4 Hydra 70, 4 Hellfire pods, 2 Hellfire pods + 2 Hydra and 2 Helfire + 2 sidewinder). BUT due to technical reasons the sidewinder version was deprectaed, although as a user you can unlock it, still it is problematic. If you have messed with the configs from the ArmA1 release and change the scope from private to public in that class then, that sidewinders you're seeing are a normal result. Just wait a bit, and you'll get the ArmA2 version no need to hurry...

good job. I have a question though, regardless of the missiles as proxies, there are cases that the pylons are different. Like in the Ah64, there is different pylon for hellfires and different pylon for the hydra pods. In situations like this does the new ArmA2 proxy handling permits change on the pylons? an example could be a version of an ah64a with 4 hydra-70 pylons and an other with 4 hellfire pods. Currently in ArmA1 we have srcipted our ah64a in order to work from a single p3d, but with an extensive use of animations and scripting which proven to be not a very good idea as from performance perspective since all the possible pylon combinations have to be modelled on the p3d.

For start thanks for the interest. Well indeed we have plans for ArmA 2, but forstart we need to have ArmA 2 in our hands or a demo at least since we're in 505 region.. Now as far as we've already read in these forums there is ArmA and ArmA2 addons compatibility so as far as the core things like model, textures etc, there won't be a problem. But as far as the scripting enhancements well we haven't much to say.... maybe Dr Eyeball knows better (I'm sure he does). Also we need to see the new capabilities of the game (like different types of loadouts that are embedded) in order to adopt every new feature, that process may require some time to do. And finally we're having a phase with reallife issues which are holding us a bit behind of our plans. To be sincre basically me (I have to be away for 6 months from August in order to do my Army service) and that may have effect on the mod development, but we can ensure that there are plenty of things to come from the HWM team for ArmA2... :)

Thanks for using our addons in your missions. For missions that are using HWM addons we're providing hosting. So here is a link HWM Website Download Section About the Requirements if the mission uses the HWM AH64A (Us or/and Racs Version), you need only the HWM Addon Pack 4.0 HWM Units Version 3.0 are for the Greek Version of the AH64 and HWM_Vehicles Version 3.0 are for those who want to have all the HWM addons.

Well that's a common error with the 'F' key functionality a far as i remember. HWM is using a set of "key" assigment for the key handlng. It seems that there is  conflict between ACE and HWM and it's related to this key assigment. More information abot the issue can provide Dr Eyeball. Copy Frm WM Release thread about the issue. <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">Display Event Handler incompatibility: Quote (Manzilla @ Mar. 10 2009,22:43) Every time I hit the "sight adjustment" button combo(shift+v) in ACE I get this appearing in the upper left of the screen: Those issues are definitely related to the display event handlers (DEH). One (or preferably both) of the following will have to occur for a proper final solution in future. - ACE DEH will need to be fixed to process the 'handled' return values of the functions (as required by BIS standards). - HWM DEH will need to be fixed to be more flexible to handle missing 'handled' return values (as BIS does) and default to false. I should have foreseen that. It was reported to ACE in this post but it has no priority number yet. Maybe because not many have reported it as a (reproducible) bug.  Add a vote to that post and maybe they will have it fixed sooner than we can. I was hoping ACE would have fixed it with ver 1.03 before this was released. I've just added a note there to further complete the suggested solution. Unofficial untested workaround (for personal testing only): When using ACE, try removing hwm_displayeventhandler.pbo. That would fix all of ACE's problems, but might introduce problems for the MFD. We would have to retest 50+ conditions to find out. I know there were less than 5 or so cases where this was required. The side effect could be either trivial/minor/major, not sure yet. If they are all minor, it may be an acceptable workaround until it is fixed.

HWM mirror updated Download Section Download Here I'll give a try ASAP.

well, i'm afraid that selections don't have the "-" in front of them, most of them made at a time and served a reason, but then changed or made uselless. So need to be removed. the funny thing is that the "no option shadow" in ArmA should give back the missing FPS, instead even by switching of the shadows you don't get back the missing FPS, i don't know how ArmA handles it, but it's strange to me. Also the "simplified" means for Geometry, Fire Geometry, View Geometry, most of the times, a very basic primitive of the helicopter around 50 faces or less. The simplified shadows was 900 faces (triangles). An other test that we made and isn't presented in the table, is removing all skeleton bones, from the Model.cfg by simplifying it to an empty. In that case even the FPS drop isn't fixed. It's strange since selections are serving for the skeletons animations. That proves that ArmA reserves memory for the selections even if they aren't used..... table updated in order to display the score for an empty model.cfg

Well i think it doesn't matter very much the polycount at this point since the source for the BIG Fps drop is an other factor. So to sum up Issue -Stringtable problem with the non_English ArmA Versions (will be fixed in next version) -FOV although FOV isn't really an issue but a personal taste thing, since the majority wants a closer FOV, it's going to be fixed -Flight Model, Well at this point we can't invest very much in researching for the ultimate FM, but we will try some ideas to find a better one -Leopard Armor, well don't worry about that wait and see... Â -Tail Rotor, wrong spin direction, will be fixed in next version. -Glass grey effect, that issue needs some research before we can have a solution, we're going to try though. -Bullet Proof glass, Can easily fixed. The Chopy/Frame Drop Issue After the frame drop issue, we begun to invastigate in order to find the source. We do a varius tests in order to see different combinations and sum up with the safest results. Scores that will presented here, are from my PC which is at the low-med PC category to RUN ArmA. The configuration is Intel PIV Prescott 3.2Ghz, 2GB Ram 400Mhz, ATI X1950Pro Sapphire 512MB Ram AGP. ArmA configuration, all options to max, with terrain detail LOW, postprocess LOW and view distance 1630, Screen Resolution 1280X1024. With the following PC and ArmA configuration i Have 25-28FPS in an empty Rahmadi. The test was to have 9 empty AH64A's with players back at them and when the mission starts to turn and face them in a way that all of them can be on screen from close distance Results As you can see the number of materials and Texture sizes doesn't have great effect on the FPS Drop issue but the Major Factor for the FPS Drop is primarily the Huge Number of selections and secondly the shadow polycount and the model polycount. Indeed if you consider that there are around 78 selections only for hydra missile proxies, plus 78 for the flashes, plus 16 for hellfires the number is raising quite high. The better results for a low-end version could be a version that uses the 2nd LOD as 1st, and with no missile proxy disapearing or flashes (at list the way we do it now). Also the thing that must be revaluate for this version is dummy selections that have been left there from editing and probably have no use, but may raise the lag possibility, and a better more less poly shadow, or even an other lod (no matter if i think that won't have FPS effect since the problem is greater in closer distance. Also we need to consider the possibility for an other last LOD very low poly, and lowering the Resolution LOD numbers in order to achieve faster lod switching if that's possible. Hope that table can helps others to learn what thinks to avoid, in order not to face the same issue as we do.

Thank you for your using our mod in creating a mission. I'll download and defenetely give a try. EDIT. We provide a mirror for the modifed version in HWM Webiste Download Section Download Here I couldn't play the mission, everything begun OK, i saw the intro video, i got my orders and boarded into chopper, but when mission started loading after the intro, i get an error that missind mercenaries_DB1.pbo. Is that Quenn's Gambit related or something? Cause i don't have Queen's Gambit.

ok, since we've promissed to reveal the polycount. here it is. The AH64 is quite BIG poly, BUT, we based the design, on proxies in order to minimize the parts render by the engine at a time, and make it off course loadable in game. Unfortunately since the model has a lot of details, we've created quite a few maps to get textured and in quite big size cause we wanted the best we could get. And that has as a result quite a few sections. Although we gave our best to eliminate ST point errors, no planar face errors, nd keep the section count the minimum, still we are quite high. Also keep in mind, that all the 3 weaponry versions are based on that one p3d. But anyway. Here the screens The 1st O2 screen represents the AH64 as is in game, proxy parts are visible by the triangles The next image represents the WHOLE ah64 combined, no proxies, higher version of cockpit that in the ingame version areavailbale only to pilot view and gunner view and even the missiles. You can read polycount/tri count and sections on the bottom, the last image hasn't very meaning since you can't have this polycount drawn at a time, basically cause of the cockpit, which are visible only in 1st person view, for 3rd person view it has been replaced with a simplified proxy of them.

@sk3pt. glass tranpsarency, was an issue, and since Faces with Alpha channel order, didn't work. We used a flag "Alpha no Z-Write" for the material. In order to diasable the Z-Buffer for the glasses. But probably, this is the cost we have to pay unfortunately since the grey parts, like pilots are proxies. So it's not your card. @Maddmat. Correct that could be a fix that can everyone do. Since the problem is located at HWM_Air, by unpboing it and deleting the header names for every language except english, could fix the "editor blank name s issue". I'm afraid though that the new pbo would have a not much signature.