Deathstrike.

Hey wsxcgy, when you were re-texturing the M-12 Vest from SAF did you have access to their source .psd by any chance? Your re-textures are very cleanly done, yet the UV's for the vest are a bit messy for anyone else to edit. So I was wondering how you were able to get round all of that, thanks.

Considering the short time it's taken for you to put this together, you've done a fantastic job with Anizay as with your other terrains. Thanks for releasing this.

Love the terrain and the use of ditches with bushes in them, helps nicely to break up the terrain and offer good cover to infantry. Layout is very good for an 8x8km map with good sparseness to it which I guess replicates the Finnish countryside. Would make for good mixed Infantry and Mechanised missions with the open terrain. Overall the map looks lovely and has its own feel to it, much like VT5 in trying to capture Finland. Great work in achieving that on your first map Temppa. My one improve for this would be some more detailing to the small settlements that dot the landscape, they are fit for purpose at the moment. But lack a lived in feel, and offer only a few buildings in some cases. A minor expansion and some more props like tracks for some of the garages, gardens or other "obstacles" will help to make each settlement an interesting area to fight around as part of the mixed terrain on offer. Overall this is a great map for a first time job. I hope to make some missions on here soon.

I've noticed since TACOP's hit that AI are struggling to move as a group in vehicles offroad. Using the CSAT Wheeled APC in group of three placed off road in a clear field, resulted in the vehicles breaking formation and ignoring waypoints to reach the closest road. Then they decide to try and move in the direction of the waypoint at full speed regardless of waypoint speed setting. Occasionally going off road to meet the waypoint before returning to the road. Tracked vehicles don't move at all for me either, either directly placed or with AI moved into crew positions. Whilst the convoy improvements and road pathing improvements were great to receive, there are side effects to this. I'm not able to write a full report or repro at this time sadly, but will try to get one done in the future. I've seen others have had the tracked vehicle issue, but if others could verify the wheeled vehicle issue I'd appreciate that.

Mods Used: None. Version: 1.56 Stable. Issue: As per title, any items entered into a JIP players Init field will not be fired when the JIP enters the game. Creating issues with gear scripts and other items run on players. Reproduction: New 3D Editor Scenario Place two units down playable in the 3D, enter into the first unit a simple [ hint "Test One"; ] and into the second do [ hint "Test Two"; ]. Save unbinerised. Export to Multiplayer. Test in a dedicated server, have one player join. Load the mission and then load into game as the first player. They should see the hint for "Test One." Have a second player join and once in-game they should either see "Test One" or nothing if the hint has faded due to time. You should not see "Test Two". Notes: Issue is critical for missions that make use of the JIP initialisation for gearscripts and other modifiers in missions.

Unfortunately, releasing unbinerised versions of a model doesn't make you immune to criticism. In this case I was trying to point Pinaz towards the major issues with a suggested course of action that can normally be found by asking within the modding community either here or on Discord. I did not want to overload him with the smaller issues, nor make it out to seem that overall it is a bad release. But if he wishes to improve his abilities and the quality of the release, that was the suggested course of action. Also, I don't appreciate you trying to highlight my post count as anything to do with this. As it and my time spent here do not correctly reflect myself and my knowledge on these matters. I do have my own work to be doing at the moment too.

Good first release Pinaz for your version of the Typhoon. However, there are some pretty serious texture issues with the model that you're using from Pook. First of all is the stretching due to the simple UV Mapping creating stretching of any complex camouflage, this is best shown as you probably know with the AAF texture. You may be using a 4k map, but it's too simple and has a lot of wasted space. You could more easily section the model with the UV maps to get rid of that stretching, which would also benefit you trying to have the small decals for emergency releases or any sort of normal mapping. This is also affecting the shadow map which has jagged edges and unusual sharp edges. The aircraft's exhaust is also a little erh, simple and incorrect. If you want a good reference then follow the BI example for Jet exhaust. Don't worry about afterburners until the aircraft can perform without them, as in ArmA they tend to be a bit unnecessary. But the rotating triangle just looks completely out of place I'm afraid. Second point is the contrails, the double contrail for the canards and wing look silly and don't match how water vapour reacts with the actual aircraft. I would suggest removing the inner contrail and consider adding the water vapour from the vanilla aircraft to get closer to the real thing. Third and the final worst offender is the cockpit, which as the place where a pilot spends all their time is in a sorry state. And you've not mentioned fixing it at all which is what concerns me. The lack of the full instrument panel and how dark the HUD is makes it bland and unreadable in some darker lighting conditions. There are references to the additional panels which I can see were started on but really do need to be finished. Finally the flight model doesn't really befit the Typhoon, as the aircraft feels sluggish and whilst you've given it a greater top speed it doesn't have the thrust that the Typhoon is renowned for. The Typhoon is designed for knife fighting and is one of the smaller Gen 4.5's with a good thrust to weight ratio given by the EJ200 engines. Normally this would mean it is able to perform high Angle-of-Attack manoeuvrers and get out of them. I would suggest pushing for that rather than increasing the speed further.

Just to note Firewill, for the Hellfire firing sequence the Hellfires would alternate between the launchers. So you would fire one from one pod and then the next would fire from the opposite pod to balance out the weight lost through firing. Very nicely done though in turning the light version of the Comanche into the heavy.

It's due to a lack of vehicle config support from RHS, this is will be present for all vehicles that do not have ACRE support. This will also affect the crew comms feature and the ability to hear people from certain positions in vehicles.

I don't think you think it thinks like you think HG2012Trigger. Your first point sounds like you're using linkItem rather than addItem, something that is renown for breaking Radio's in ACRE, that's a problem on your mission maker who will have to ensure their gearscript is both correctly adding the baseRadio item and not any of the ID tagged Radio's. Not sure you mean when saying "Channels dissemble". But at UO we've not had any issues with Radio channels or custom frequencies so I'm going to put that down to being related to the first problem. Sounds like a server problem unless you provide further information rather than a brief description. The AN/PRC-148 is a long range Radio capable of communication ranges that can give the AN/PRC-117F a run for its money. If you think that all long range Radio's are backpack mounted then you're a bit behind the times. If you need communication past that, you would need a re-transmission option. Vehicle Radio's are due at a later date. If you have issues, please provide information on the problem you're having or you're unlikely to get any real help from the people who keep an eye on this thread. Also outright saying that the mod is horrible because you're having issues is a bit poor in judgement in my books, so please be more considerate to Nou/Jaynus and other contributors to ACRE.

Wouldn't be the issue Nuno, we've been able to have high player count sessions and not have any noticeable drop in sound as the player count grew. The only thing I've found is that people do need to make adjustments to their in-game or windows based output handling in order to get ACRE to a normalised state with the rest of the in-game sounds. Which I normally suggest is easiest done by reducing the effect volume down to a small sliver, then increasing the overall sound volume for your output device.

Very well done so far with what you've demo'd for the mod, my only feedback would be that the current choice of visible 'pain' does not really feedback to 'pain'. Might be some old ACE habits, but the pulsating blur effect seems more stamina related. A possible thing I'd suggest would be to try adding a hint of colour desaturation or a slight darkening of the view if possible, without needing to go into the whole bloody screen affair.

The grass fields in ArmA, particularly the southern and south-eastern ones are airfields for light aircraft. Meaning that they are or were maintained to a standard that allowed aircraft to operate from them, further that they were "smoothed" and the grass was kept at a level to not become FOD for the aircraft. (Though BIS could do with levelling them a bit more, I've flown in light aircraft from a nearby grass field and that wasn't quite as bumpy as the ones we have.) A feature for the bloc aircraft that the L-159's grandfather, the L-39 was apart of. Was that they had good rough field capabilities, all the better to be in places NATO may not expect them. And with its raised air intakes, there is nothing that I can see that inhibits the L-159 from operating on rough field as it can in ArmA. And Izaiak, have you any proof that such things are impossible at the moment? As far as I'm aware BI are able to build upon their own engine as much as any other developer, so if they needed to I'm sure they could expand to accommodate a more realistic flight model. But I don't believe that is what they are after as I stated with my last reply.

I'm aware of the L-159's capabilities, but none of the aircraft feature an afterburner. This is from a gameplay perspective that is in reference mostly to the airfield south of the main Altis airstrip. Whereby in a North to South departure the runway drops off into a small gulley, the other two do not have a problem with this. The L-159 however really struggles in comparision to the two newer aircraft and cannot clear it with an acceptable safety margin. (Safe take-off speed for the L-159 in-game is just above 140 kph with full flap, the L-159 needs the entire length of the runway to reach this.) Though the other two aircraft are twin-engined compared to the L-159's single, they are not straight upgrades in terms of the aircraft's overall thrust to weight ratio. The HUD issues seem to point to how the L-159 was forgotten about with the new config values and changes to aircraft handling. The A-164's nose droop was resolved in the latest dev branch update, and I don't believe BI needs or may not already have documentation on the two aircraft. It's just that ArmA's flight physics at the moment are not really aimed to replicate the full nature of what the actual aircraft are capable of, more that they want to have both visually and performance based differences between the three to separate each aircraft with its own strengths and weaknesses within BI's own scope. As they have done already with each factions core units. I wouldn't go so far as to state that OFP had better flight handling, far from. But I don't come to ArmA from Benchmark Sims expecting a realistic flight model, instead I see that they just want to be able to field usable but not arcade'y aircraft for their combined arms environment as with all past ArmA titles. From that perspective the aircraft at the moment are acceptable I guess, but issues such as the amount of side slip you can create with the aircraft seem to be odd and make certain situations a pain to correct, especially with the poor HUD symbology or lack of instrumentation. (To which the altitude readout has always been in AGL, only ACE in ArmA2 added an ASL readout. Not BI.)

The Buzzard is in need of some tender love and care even before the new BLUFOR/CSAT fixed wing aircraft were added. At the moment it cannot take-off from some airfields, has a hard to see HUD and when you can see it there are abnormalities for the roll indicator whilst the speed and altitude indicators roam free all around the HUD.

Re-read what Toadball posted yourself. The way you are trying to modify ACRE's core files is likely the cause behind your error, thus the only way around it is to create a config that works as Toadball has already done. It is also a bit rude to modify those files without the permission of the original developer, as much as it is to shrug off a person as you did who is trying to help.

The current flight model system for both the L-159 and the other series of Helicopters (Barring the KA-60's current flight model) is sufficient. And the recently added FM's for the Lynx's shows they are on the right path for this stuff. Minor gripes are still there though, but we have to remember that Arma's scale does not fit in with normal aircraft operations so overall it isn't the most needed area for corrections or adjustment. Personally my only gripe with the fixed wing handling is how the L-159 crabs with only a slight roll of a few degrees, making it seems like a low wing loading aircraft or similar to it being in a high cross wind. The extra effects of ToH weren't added as per the AI's handling of it iirc from a post Dwarden made on a separate forum by the name of Facepunch. Which makes sense, as the AI is still unable to handle aircraft and helicopters in their current state, so trying to factor in wind, torque and other additional factors sounds like a nightmare. (One of the to-do things that they never got round to due to their limits.) I was sad to hear this personally, as I'd rather have it for player controlled vehicles whilst the AI retain a simpler flight model or some common sense but again, this isn't the most high priority of areas compared to the mainstay of current infantry and vehicle related issues.

Curiously I've got to ask why this was considered? The laser designator at the moment provides a better laser guidance system considering the IR Grenades do not stick to vehicles or other objects unless thrown atop of them. It's also slightly unrealistic considering that IR that is visible under NV is operating on a different frequency to the type that is used in aircraft munition guidance, which also looks for laser designators on a specific frequency that a pilot must input. This is typically supplied during brief or when receiving a 9-line from a JTAC/FAC. (This also ignores how the munition or aircraft sensor must be able to "see" the point, as demo'd best by Nou's implementation of IR Guidance in Arma 2 ACE.) My only concern is that the IR Grenade is best served for visual marking due to the excellent draw distance it has over normal smoke or chemlight marking techniques. (This was tested by myself and others when the recent Dev branch came out, chemlights typically draw out to 600m whereas we found that IR Grenades draw out past 3k.) My only concern is that due to the tab-lock nature of Arma's guided weapons and the lack of ability to visually identify locked targets by extended means (by targeting pod), does mean that there is a chance for friendly fire if IR Grenades are used to mark targets, in the same space that a nearby friendly group may mark themselves or a possibly older position with an IR Grenade without a JTAC/FAC being aware when directing the aircraft in. I would ask that this feature be reverted, the IR Grenade can still provide an excellent tool for visual guidance with its excellent draw distance. The added "lock-on" just appears to be unnecessary and open to causing incidents due to the tab-lock nature of Arma and the lack of CCIP for aircraft munitions.