HWM ADDONS PACK RELEASE V4.0

[Gedis 0]

Excellent pack! Resurrected a couple missions I was making with the last version, really enjoying it. One thing I have noticed is the armour of the 1A4. I don't know how good a tank it is but it can only take 1 hit from a T72 and the crew bail. While it seems to take more than one hit from a 1A4 to knock out a T72. Surely the 1A4 is more than capable of going toe to toe with a T72? It would be better if it was able to take a hit or two without the crew bailing.

actually T-72 was invented to bounce 105mm(none DU) shells...

cmon people, you really think first leos could have a chance against "the satan's tank"(pro western propaganda from "top ten tanks" showed on discovery channel)?

[-Snafu- 78]

Excellent pack! Resurrected a couple missions I was making with the last version, really enjoying it. One thing I have noticed is the armour of the 1A4. I don't know how good a tank it is but it can only take 1 hit from a T72 and the crew bail. While it seems to take more than one hit from a 1A4 to knock out a T72. Surely the 1A4 is more than capable of going toe to toe with a T72? It would be better if it was able to take a hit or two without the crew bailing.

actually T-72 was invented to bounce 105mm(none DU) shells...

cmon people, you really think first leos could have a chance against "the satan's tank"(pro western propaganda from "top ten tanks" showed on discovery channel)?

I thought it was invented to fight.  

My question is game play oriented. Not something for armchair experts to chew over. Such stuff can be done in the OT section.

Anyway, back to my post above. I want to add that the T72s were advancing in front of cover of trees so I don't know of all of the shots hit. Mainly, I think it would be better if the Leo could take at least 1 shot before the crew bails.

[monty67t 0]

There is some serious problems when using the HWM mod in conjunction with ACE. I'm not sure how to fix it or what exactly the problem is. I'm pretty sure it has something to do with all the special key assingments. When running the HWM mod, sight adjustment, weapons rest, using non-HWM aircraft all give scripting errors and don't always work. Hopefully someone will work out a solution soon.

[dr_eyeball 16]

Display Event Handler incompatibility:

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.

@Q: Good suggestions. Will consider them all. I'll query some.

4) Back Num 0, is really no good choice from briefly playing with it. Shouldn't the keys stacked together either left or right? Like backspace or ~ (left of 1)? Or use num 1 - 9 as well.

4) Stacked? I don't understand this query. Are you talking about MFD menu control keys or optics keys? Keypad Num 0 (and 'V' key) are the default optics keys. Backspace (and 'Spacebar' ) is the default 'Previous Menu' key for MFD menus.

7) Flares are assigned to C no matter what. I have switch to manual fire here. Maybe you can think of something.

7) HWM flares are assigned to the 'Reload' key which is usually the 'R' key by default. That is configurable via your Arma options. It is not hard-coded, so not sure.

11) They grey lines in the white UI are quite hard to see in various conditions. Why not make it white-white?

11) That's a restriction of Arma's line drawing capabilities. All lines have a default transparency. I have a solution to fix 80% of those by using images instead, but any diagonal lines will have to remain the same. I hope Arma2 removes this restriction.

Thanks for responses. It emphasises which issues are more important.

[monty67t 0]

Thanks for the info Dr_Eyeball. Its good to know these issues are being addressed. Hopefully between HWM and ACE it will all get sorted so we can use these wonderful HWM addons with ACE.

EDIT: Here is a screenshot of one of the errors.

http://img.photobucket.com/albums/v238/monty67t/502/HELLFIRES04.jpg

[.kju 3244]

Thanks for the response Dr_Eyeball!

Quote[/b] ]

4) Back Num 0, is really no good choice from briefly playing with it. Shouldn't the keys stacked together either left or right? Like backspace or ~ (left of 1)? Or use num 1 - 9 as well.

4) Stacked? I don't understand this query. Are you talking about MFD menu control keys or optics keys? Keypad Num 0 (and 'V' key) are the default optics keys. Backspace (and 'Spacebar' ) is the default 'Previous Menu' key for MFD menus.

Sorry. Misconception on my side.

The issue is my configuration setup, as put some actions to other keys.

However you may want to use different keys for some actions

for the MFD anyway.

I am suggesting to use the "select all units" action key for

'Previous Menu' action. By default its at ~ (left to 1). I guess

only very very few people moved that one. And you are not

supposed to command AI at the same time being in the MFD I'd say.

Quote[/b] ]

7) Flares are assigned to C no matter what. I have switch to manual fire here. Maybe you can think of something.

7) HWM flares are assigned to the 'Reload' key which is usually the 'R' key by default. That is configurable via your Arma options. It is not hard-coded, so not sure.

Again sorry.

The issue is my configuration setup, as put some actions to other keys.

That said reload action is not needed for vehicles. So there is a

higher chance the people reuse that action already.

Maybe you can think of some other action.

What about B for binocular? Are you using that one already?

Quote[/b] ]

11) They grey lines in the white UI are quite hard to see in various conditions. Why not make it white-white?

11) That's a restriction of Arma's line drawing capabilities. All lines have a default transparency. I have a solution to fix 80% of those by using images instead, but any diagonal lines will have to remain the same. I hope Arma2 removes this restriction.

So the white UI is already completely white?

Making the lines more thick doesn't help?

Or combine the white UI with a different color for the thin lines

with problems.

Again outstanding work.

[UNN 0]

Quote[/b] ]The issue is my configuration setup, as put some actions to other keys. However you may want to use different keys for some actionsfor the MFD anyway.

To be fare, this is a problem with just about any addon that uses the KeyPress event handler outside of dialogs e.t.c I'm increasingly seeing my own Arma key configuration being compromised by user made Addons.

[madmedic 0]

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

[ig]http://hwm.armedassault.info/personal/developement/ah64/ingame.jpg[/img]

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.

[im]http://hwm.armedassault.info/personal/developement/ah64/raw.jpg[/img]

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.

Any plans to make the glass bullet proof?

Excellent addon...but can be shot down by anyone with a pistol.

[Snake Man 407]

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.

How many points / sections is the lowest resolution LOD?

[sparky 0]

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.

[.kju 3244]

Thanks for the excellent approach and overview XSparky

From some simple testing I see that having only 1-3 of them

in the screen is not a problem for my system along with other units.

That said, also in the long run, you want as many of these

beauties, along with other units on the battlefield.

Very much looking forward to the update!

[Synide 0]

...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...

As long as they have a "-", hyphen/minus or a ".", dot at the beginning of the name then just leave them in your working p3dm mlod. They don't end up in the odol.

However, if they (these temporary work related named selections) encompass actual polygons or points that physically do not need to be there then by all means remove the named selection and the geometry they relate too.

Btw, nice analytical approach. Shadows are a big slowdown eh...  

[sparky 0]

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

[.kju 3244]

Here are some questions about hwm_displayeventhandler.pbo - I guess mainly for Dr_Eyeball.

1)

It seems having both hwm_displayeventhandler.pbo and NWD Tank FCS loaded will

give this error on tab press:

More specifically the latest release of zGuba.

Error in expression <{
_codeStr = _list select _i;

_handled = call compile _codeStr;
if (_handled) e>
 Error position: <= call compile _codeStr;
if (_handled) e>
 Error Generic error in expression
File HWM_displayEventHandler\init.sqf, line 182

2)

There is no information about permission, copyright etc for hwm_displayeventhandler.pbo.

Did shole give his okay for a release and what conditions, or did he leave

the scene?

3)

What are the changes of 1.0b vs 1.0?

4)

Is it possible to turn this into a community project like XEH and get the source hosted

and developed by anyone interested on dev heaven?

Thanks for the response and have a good time. :bounce3:

Edited April 16, 2009 by kju

[dr_eyeball 16]

Here are some questions about hwm_displayeventhandler.pbo

1) That is the same issue already covered in my last post with a suggested solution to try (if using ACE, try using the ACE version alone).

Essentially you will only need one version in the end when one is fixed, or it will be changed to be dormant if another working version is already present.

2) That has been discussed in the XEH thread. This does not take over his project; it is just an interim version until the old beta version (Apr 2008) is fixed and released again by someone or use ACE's version when it's fixed.

3) The original released beta version 0.1 does not work correctly, so this includes about 5 fixes to correct that. Just compare them; it's very simple code.

4) See XEH thread. The next release of this project will include the required 2 line fix. Plus ACE has hopefully done the fixes to their version too (since the Issue #530 is closed now which I presume means fixed, although the history looks odd).

Edited April 16, 2009 by Dr_Eyeball

[.kju 3244]

Thanks for the quick response Dr_Eyeball!

1) Thanks for the link. I made a repost on the new ACE issue tracker.

Yet I do not have ACE loaded, shole DEH is deactivated as well.

Any idea of another addon possible to cause the conflict?

Or in general any addon using DEH vs shole DEH has the problem currently?

2) I am not able to find really much in the XEH thread. Are you referring to

KS's statement on Sep 2008?

Without making any promises either way, let's just say that I'm

currently doing some research related to a possible general display event

handler framework for XEH...

To me it seems no one is really working on a community standard version.

Also it should be an independent solution and not be consumed by ACE solely.

Why not use yours as a base to (re)start with?

3) Roger.

4) Fixed my edit..

Edit:

Having both hwm_displayeventhandler.pbo and S_displayEventHandler_KeyUp/Down.pbo loaded

does NOT seem to be the source.

Seems more like NWD Tank FCS. Will post more soon.

Thanks again for your comments. :bounce3:

Edit2: Indeed it is NWD Tank FCS - see zTanks Merge

Edited April 16, 2009 by kju

[Binkowski 26]

When I tested these addons I deleted the XEH that came with and ran them with the XEH that come with ACE and I didn't have any problems. However is was just a test.

[manzilla 1]

When I tested these addons I deleted the XEH that came with and ran them with the XEH that come with ACE and I didn't have any problems. However is was just a test.

\

Hmmmm.... I did the same thing but when I hit ctrl+v to bring up sight adjustment on applicable weapons I get the same error. I'll re-check the XEH .pbo's but I'm pretty diligent about em.

[Binkowski 26]

\

Hmmmm.... I did the same thing but when I hit ctrl+v to bring up sight adjustment on applicable weapons I get the same error. I'll re-check the XEH .pbo's but I'm pretty diligent about em.

Now that is one thing that I forgot to test, so it may be a problem.

[1in1class 0]

Plz put this bad boys in ArmA 2:bounce3: This is what ArmA 2 is missing love the AH-64s iv seen the F-16s enter ArmA 2 plz make the AH-64s enter ArmA 2 this would be vary nice to have.

[Raafatah64 0]

when will b the next update b released

[1in1class 0]

Next update would im hopeing to be is they put them in ArmA 2. Some how some way please make this happen love them AH-64s.

[manzilla 1]

I think they mentioned their plans a few pages back.

[sparky 0]

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... :)

[1in1class 0]

Thats vary good to here that the HWM team will be doing good in ArmA 2. As you say that it should not be an problem but the scripting, could we see an beta in the ArmA 2 with its vanilla scripting just to put in ArmA 2? Good luck on you tour hop ya can stay in tuch with your team.