oukej
-
Content Count
1063 -
Joined
-
Last visited
-
Medals
-
Medals
-
Everything posted by oukej
-
Strange, the addon should be public :/ You can try looking for "Wipeout Test" addon or look into my workshop entries ( http://steamcommunity.com/id/okdante/myworkshopfiles/ ) As for the Targeting Pod - it has already been possible for a while via an engine functionality. You can check it on the recent implementation of down-looking cameras on helicopters (a slingloading aid). You can enter the full screen camera feed via Ctrl+RMB. The max. ranges and angles of the camera movement can be defined in the config.
-
If you want you can try a different Wipeout configuration here - http://steamcommunity.com/sharedfile.../?id=334622056 and tell us what you think about it. Disclaimer: It's not an official addon and it doesn't work properly with AI. Just a test to see can be achieved as for now - with some generally acceptable degree of abstraction. In this addon the Wipeout should behave a little bit closer to the A10 (scaled for A3) with some sort of FBW (we don't precisely simulate stalling). I've chosen Wipeout because from the planes we currently have it has this closest direct counterpart it can be compared to and people have experience with.
-
Not currently, but it is a widely requested feature. (Possibility to map any combination or map different modifier keys) Can't promise anything as for now.
-
Wrong ;) I know it's damn unintuitive, but you have to map BOTH X Axis + and X Axis - to "Thrust (Analogue)" to have the full extent of one axis. Like: (Similarly you can map both halves of one axis to "Brake (Analogue)" to have airbrakes' input stretch over the full axis. The consequence of mapping + and - also defines if the axis is going to be inverted.). You can also check http://feedback.arma3.com/view.php?id=6888 Recently a new programmer started looking into some of the long-lasting controller issues. (you may have noticed that e.g. the painful 16-button limit has already been fixed in the dev branch)
-
There are researches going on. Concerned is a soft word. I wouldn't say so, things need to be kept simple, easy and fast to reach. "Hold Fire" & "Return Fire" ROE modes do however make sense. I can imagine situations when you don't want the AI to return fire at all (retreating in the dark and giving up positions by the muzzleflashes ...)
-
Humanlike, aren't they? I was expecting you to shoot them in the end. Our programmers do that usually. :) Btw, you have any details, circumstances? Quickly tried damaging a non-local AI controlled helicopter and the AIs happily disembarked with no intention to get back in whatsoever..
-
Lol, true Actually I have a 16:9 and I tried to see it in full screen...didn't think of checking in window, downloading or anything. I shouldn't sit here for that long, not healthy :D thx anyway
-
Could you please give me the rev. number? I can't see it thru the YT bar. But anyway - went into May revisions and the behavior was the same even back then :/ This is for a longer run.
-
Won't happen for Helicopter DLC. Please try to stick to the topic ;)
-
I think this would already be a super nice-to-have if not completely technically impossible without the AI crashing all the time ;) The aerial pathfinding, given they have to be able to control different helicopter sizes and configuration, must be as simple as possible and as safe as possible. The way they behave in the air is strongly affected by the heli's configuration. In this regard there's no point in comparing AI pilots to players ;)
-
Development Branch Captain's AI Log
oukej replied to royaltyinexile's topic in ARMA 3 - DEVELOPMENT BRANCH
Plus some pathfinding and also http://feedback.arma3.com/view.php?id=13493 -
This is more about the flight model. They have to flare or bleed the speed as much as the player + some more to be sure and safe.
-
Will check what went wrong. Otherwise we had been aware, that sometimes the AI units would have gone stuck under moveTo (http://forums.bistudio.com/showthread.php?177393-List-of-regressions-between-1-62-and-1-63-betas&p=2718181&viewfull=1#post2718181 )
-
I wouldn't say so. Depends on the airplane's longitudinal stability, but generally I wouldn't like to sit in a plane, that doesn't tend to dive after loosing speed. We don't have trimming (or autotrim.) for airplanes, so you have to constantly adjust and maintain your input depending on the speed (and configured envelope). On a standard airplane the lower airspeed the more input on elevators is needed to keep the plane leveled (up to stalling). The balance - as already noted by John Spartan - is dependable on the model. (you can also check http://www.armaholic.com/page.php?id=3157 ) You may say so and it wasn't an easy decision for the project. We won't try to hide the fact that airplanes have become a poorer neighbor of the helicopters (those damn rotoflipperz even have a lift force simulated on each individual surface now ;) :P). We were given the chance to utilize the Take On legacy and experience and we thought something relatively immediate for all of us to enjoy is better than any uncertainties in a far future. Even though we had been aware that it would have highlighted the shortcomings elsewhere. The other thing is how it revolves around the combined arms combat - to be sorely honest, there will always be more cannonfodder on the ground or close to it than the elite hawks high in the sky. The love a feature has - as democratic as it gets. (And I am saying that as a total sim-freak). We are still gonna try to do our best to improve the system and fix the obvious issues. Noone ever doubted ;) Thanks a lot for the solid elaboration! I'll go thru it in detail as soon as I can. Just by looking at it - I wouldn't go into the extreme numbers (30 or 0.0x) when configuring the forces and torques. Ideally start just with 1.0 and build up. Conversely you may want to try higher TorqueCoefs. All these X-ZCoefs are applied in the relation to the model world. Everything goes together or against each other with envelope and control surfaces' coefs and relatively to the maxSpeed. Also I've noted the use of VTOL - it hasn't been revisited in A3. It should work, but no assurance. --- I support that. As for the moar info - we may try to put some more into the modding samples.
-
Do you have any more details about this? When it usually happens? (Even if it's only present in large MP scenarios and will be hard to catch.) Could you, please, create ticket on feedback tracker (if there isn't any for it already) and ev. let me know via PM?
-
Development Branch Captain's AI Log
oukej replied to royaltyinexile's topic in ARMA 3 - DEVELOPMENT BRANCH
The algorithm for rotation speed of the AI within a free-aim/upper body deadzone has been improved. (This applies almost exclusively to situations when the AI is using a weapon in a vehicle's cargo or when firing from a cover.) Together with the change there's been a mass re-adjustment of dexterity property in weapons' configs. Referential values are 0.8 - Titan, 1.2 - Zafir, 1.5 - MX and 1.9 - P07 http://feedback.arma3.com/view.php?id=10143 -
Development Branch Captain's AI Log
oukej replied to royaltyinexile's topic in ARMA 3 - DEVELOPMENT BRANCH
A fine example of Murphy's law - if you get excited about something too much... Once fixed a bigger package of pathfinding improvements may land on the Dev Branch at once. The last two Dev Branch updates have brought some AI improvements - better management of AI sling-loading, more careful AI pilots* and a fix of http://feedback.arma3.com/view.php?id=18937. Not exactly AI but tightly AI-related are the Headless Client improvement. *The AI pilots should better avoid collisions with objects and also pick their LZ more carefully. AI crashing with a helicopter should become a rare sight (unless one as a leader or scenario designer really forces the helicopter into e.g. dropping cargo under the powerlines). It may come in some situations at a cost of less tight maneuvers and longer time to transition into a hover. -
This has already been discussed back in the thread. And it's still a valid point, no doubt. And also made possible by it ;) Anything that is not actually present in the code should not be taken as if it should have been there.
-
You see, AI doing everything on their own or being scripted for a specific scenario situation. It's one of the major design problems and you are always going to end up with compromises. Let's have an example - autonomously rearming AI. Players do that. If you see a better weapon or an AT, you grab it. But what if you want to have a military-proper scenario? AI looting stuff around - not very immersive. Not talking about situations where you need the AI to run away from a suppressed location. But it sees a nice launcher, goes for it, eats mortar. For every added functionality, you have to prioritize the behavior and put relations and exceptions to functions that are already in place. You can easily end up with a unmaintainable system. There's always great amount of situations, where some behavior is not desired. And it's nearly impossible to account for all those situations. So you can either have a modular system which in return places higher workload on the scenario designer and still requires a crazy amount of maintenance. Or you can just put in a set of features you think are the most beneficial to the gameplay and fit most of the situations. But once you have that and want or need to change it, you're entering a game of Jenga Tower :) And I think this is also somewhat related to the issues mentioned beforehand and why it may seem that some of the development is taking too long. Bottom line - AI universality and backwards compatibility From the AI point of view there are "direct" fixes continuously being done. DLCs mainly add some sexy functionality. And then we can steal some more maneuverability (overhaulin') space within the bigger package of an expansion.
-
fixed wing model i assume? can we get any more info on this (before/after)? Currently nothing you'd be able to see in the game, but rudderCoef now allows for more freedom in rudder configuration.
-
Ref. http://feedback.arma3.com/view.php?id=14899 In Arma 2 it was achieved by the "auto-rudder" that would "assist" the turn as you rolled the airplane. This wasn't a correct approach, so Dr.Hladik removed it. If you take a look at the A-164 Wipeout, you'll notice, that unlike the other two airplanes there is a slight tendency to turn under a roll angle. (It's not exactly how an A10 wing and fuselage shape would behave, but there's a glimpse of the correct behavior ;)). We welcome you to tweak the parameters in airplane's configuration (mentioned here). Let us please know what were you able to achieve or if you bumped into a limitation somewhere. Thanks a lot!
-
Please, try to stick in this thread only to the flight model configuration / actual behavior of the helicopters in Advanced Flight Model.
-
I think he meant the camera shake. What you're describing is a bug when the JIP player in a turret (active vehicle pos.) is not synced correctly. It was fixed (at least we hope so) by a major change in the order JIP messages are created 23-07-2014, rev. 126089. But afaict it can also be caused by data inconsistency. If you encounter the issue again or have any further info about how to reproduce it, please create a ticket on the Feedback Tracker and you can also let me know in a PM. Thanks a lot!
-
Development Branch Captain's AI Log
oukej replied to royaltyinexile's topic in ARMA 3 - DEVELOPMENT BRANCH
Change log notes, v. 127272 Find more about this little new feature Klamacz decided to implement after accidentally finding about some request on the feedback tracker... ;) Ok. Srsly now. Check OPREP: Firing from vehicles - written on behalf of the FFV Task Forks and the whole A3 team - to find out more about what's so exciting about the latest Dev branch update. And direct please all your feedback to Another AI remedy from Dr. Hladik - AI should generally fly more carefully with a cargo sling-loaded. AI should no longer smash its cargo into obstacles or even crash the helicopter itself because the turn was sharp and the load was to heavy.) -
.