royaltyinexile

In this thread we'll post updates in the form of short OPREPs, which provide details on specific topics of development. Goals: Share progress on important development Short (~500-1000 word) blogs related to a specific topic; likely to be more technical in nature Sometimes significant ongoing development can be difficult to notice; it's useful to highlight certain changes to gain valuable feedback Improve developer-community communications Provide a place to discover and browse information; avoid having to dig through threads for relevant developer posts Help support & develop the communication skills of our team members Keep an eye on the Dev Hub for all the details. OPREP: Soldier Protection Full Report

We'd like to try using this thread to track clear updates about changes to the AI. But first, some all important disclaimers! Not all the changes made to the AI can be logged as and when they happen Sometimes the changes made by the programmers require other departments to update or pack their data Sometimes that's not always possible right away (i.e. changes to AI Costmaps for terrain, tweaking of new/refined values in configs) Sometimes the changes must be put on hold while we make sure/prevent them from entirely annihilating the rest of the game Sometimes the changes must be reverted because they destroy more than they heal. Sometimes our programmers have to work, rather than talk about working. We hope it helps shine some light on the ongoing refinements/fixes being made to the AI, and can help to frame/promote some useful feedback/discussion/understanding about the current state/future direction and progress. You can discuss the changes across in the AI Dev Branch Discussion thread. Best, RiE First set of notes follows: It wasn't supposed to fix rotation speed of AI soldiers, but is letting them use "aiming deadzone" as specified in the unit config (minGunTurnAI, maxGunTurnAI) which is typically 60 degrees cone. Therefore currently AI should be able to follow targets better without moving whole body. RPG and NLAW are supposed to be unguided, but AI was still able to use them as guided weapons. This was corrected. Quite big change, now AI is able to calculate and predict accurate ballistic of bullet, therefore is able to aim and engage targets on all ranges, both static and moving. Also, this improves AI ability to hit moving targets by more precise time of leading calculation. Good way to check this change is try to fight AI sniper on 1km+ range. Of course it still depends on his skill. AI was considering animals as friendly, therefore denied to shot in theirs direction. Example: put yours character, enemy soldier and snake animal between you. After this fix AI won't bother with friendly fire against animals. N.b. Sometimes I'll quote one one of our Programmer's comments, but reserve the right to make splendid editorial adjustments! :cool:

I concede that they're similar, but - for the record - this is a new (for A3) set of actors (Dan Brown and 'Splendid cameos' aside). Nathan is voiced by Lane Davies, while the CTRG Commander from AP is Bob Boudreaux. :) Also, generally, thanks to all for their feedback - on this, and other threads - thus far; lots of good points, and plenty of ammunition for debates inside the dev team! (p.s. the lack of an orange emoticon on these forums must be a priority 1 fix! )

Full Report

Full Report

Full Report

Full Report

Full Report

Just to be sure, that's definitely the plan. It accidentally snuck into the RC, and has since continued to change internally. Once it hits Dev-Branch (which may possibly be right after 166), the designer responsible for the work plans to open up a thread and collect feedback on the state (for now it's considered a bit obsolete, as I get it). Apologies for any confusion so far!

Full Report

We talked a bit about the balance of enterable / destructable buildings in a previous REP: As mentioned in my above post, our artists have kicked off the process of investing time / effort into post-release updates by addressing the issue of un/openable doors. However, we're also preparing additional work, which includes planning for more ruin states, and perhaps even more besides. Although we're not yet in a position to make solid promises, we do recognise the long term benefit of making improvements to our terrains to stand the test of time. Finding a balance between this support and planning new work is something we're evaluating carefully for our 16-17 roadmap. Also, as mentioned, we hope to see a proper OPREP on the topic, once we can share our plans with a bit more confidence. Thanks to others for other bits of feedback (here and on twitter); there are some interesting points to share with the Art team!

Building upon some splendid community feedback, the Art Department in Mníšek pod Brdy (AKA Team Mike) has been experimenting with some improvements to certain Tanoa structures. To kick things off, they've been looking at ways to communicate the accessibility of buildings more effectively. Their first goal is to make enterable and non-enterable buildings more clearly recognisable (ie avoiding situations where players to run up to doors and discover that they can't be opened). Of course, the terrain is already released and many community scenarios are already built. With this in mind, the improvements focus on the addition of simple models, such as locks, barricades, etc., placed in the immediate proximity of doors. We hope these will be consistent and recognisable, without unduly affecting any existing community content; players should immediately know whether or not the building they're looking at can serve as a hide-out. Some WIP concepts here: https://twitter.com/jaycroweuk/status/770600973437956096 As the work has only recently started, we don't expect to release it with the forthcoming update (1.64); however, a few changes have started to appear on Dev-Branch recently, with more expected to appear over time. It's also worth mentioning that this is part of a longer-term, post-release effort to support (all of) our terrains. We hope to share an OPREP sharing our motivations / the possibilities in a bit more detail soon™.

Full Report

Full Report

I can see how there could be a bit of confusion. In Marksmen DLC, one of the platform features we added was 'Suppression'. We described the feature in the release blog like this: This laid the groundwork for more features. Now (on Dev-Branch / on Default Branch at some time on the #RoadToApex), it's possible for commanders to order their subordinates to lay down 'suppressive fire' on / around a certain area. Together, these features improve players' ability to plan / move more tactically. If you know / suspect an enemy position - but don't have a direct line of sight - it's possible to order units to target / shoot at 'empty' spaces (there are some limitations. If AI see friendly units or civilians, they won't shoot); previously, it was only possible to target a legitimate, known, target. Best, RiE

Full Report

Full Report

No, that would be the opposite; rather: the closer you get to a sound source, the more stereo is played. Are you experiencing this issue on Main Branch or Dev? Is it specific to the 'tails' (i.e. the part of the shot that changes based on your environment?) We will also make additional changes to weapon tails as part of some new configuration of audio for Eden Update; so it's possible something has gone awry in the short term. I'll check on Monday.

Definitely a good point. Group ownership and (multi-user) administration is something linked to the next steps for the Units service, related to the overall 'join' functionality. You're right that community leadership can change / grow from time to time, and it will be important for us to support that if we want to keep an up to date directory of units.

From the start, the primary keys are not tied to the unit name, so we should avoid the type of issues that could arise from that. However, I did make a mistake in saying Unit tags are not unique. At the moment they actually are, but I think such a constraint could be needlessly punishing in the long term. As for squad.xml, yes, there's the type of solution you've mentioned, and some simple form / wizard would be the simplest next step, but we're also considering how this may be integrated directly in game / in launcher to make it easier (particularly for those that may flick between units). However this may also be bound up with 'joining' units, which is a feature outside the scope of the foundation release. So some interim squad.xml creator hosted on our servers wouldn't be ruled out!

Full Report

So far, [TAG]s are not unique, but must be 2-5 chars long; but Unit names are identifiers and do need to be unique, and, yes, this could lead to some duplicity in the end. Like most services, we'll probably have to adopt a first-come policy, but - in clear examples of 'squatting' on names / cloning, etc - we have a reporting system in place to enable us to take a look at the accounts in question. Considering after-creation name changes vs the existing uses of identifiers etc, is certainly a valid question, and something we'll definitely have to tackle as we move past the foundation release to things like joining and events - great point! Best, RiE

Thanks for the rapid feedback! For those curious to know a bit more, we updated the announce thread with a few notes on the End Game additions. Best, RiE

It's been a wee while since our last official End Game update, but today's Dev-Branch update contained a few splendid developments! For us, End Game has been a great place to try out new ideas, validate improvements to existing systems, and, most crucially, demonstrate the superiority of the Mnisek team in our internal play-tests. Nexus Update, our next major deliverable, will include new 2 instances - Feres and Zaros - alongside a bunch of improvements and additions. Let's take a quick peek. End Game Instances Aside from some small tweaks to the logic of the mode (e.g., after each side's FOB is establish, additional vehicles are air-dropped), the 'instances' have been refined with improved compositions and new models, such as the upload terminal and schematics 'tablet'. The centrepiece of the development, however, is the two new instances. EG Feres This instance takes the existing (End Game Kavala) concept and opens up the AO. With a bigger area, more intel objectives to assault and secure, and an increased player count (16v16), our goal is to encourage planning and squad management. Successful sides will divide up into smaller units, and coordinate / prioritise their movements carefully. EG Zaros Focusing on smaller-scale tactics, Zaros is quite the opposite of Feres, more like an intense version of EG Kavala. The AO is more concentrated; the order in which to approach to objectives is less important than the ability to move quickly and effectively. Successful teams will be fast and lethal. Keeping team mates alive and maintaining a numerical advantage - particularly in the relatively exposed phase three upload sites - is the key to victory. End Game Spectator Our scenarios have new lobby slots available, where players can choose to watch the games. It's in a relatively early state, but the good news is that - like our other MP systems - our spectator camera is being designed to be pretty modular (and extensible). We've opened up a dedicated forum thread with a more in-depth introduction (and disclaimers!), where you can also offer up some feedback! Other MP Systems Work on Revive, Shared Objectives, and Dynamic Groups has continued (although, we must report, not as quickly as we'd originally hoped). Engine support for these scripted prototypes has been bumped back to later deliverables, as we switched around our development resources and priorities (such as recent changes to remote execution, which have brought welcome improvements to MP performance and security). Let's take a look at the progress in the mean time. Revive With Revive in particular, we want to take some time to get it right splendid. Simulating the incapacitated state and implementing robust (and consistent) interaction mechanics are the keys to further development, pencilled in for Apex. However, in the short term, we'll be implementing network traffic optimisations to the scripted prototype. Of course, we also have a backlog of additional features / customisation hooks, some of which derive from the splendid feedback discussed on these forums. Shared Objectives Translating the scripted prototype to engine is under way; however, the scope of the work has increased a bit. Now, we're aiming to overhaul the entire task framework, so the objectives you see in End Game will be used everywhere (with some appropriate adjustments). We now expect it to be part of the other usability improvements of Eden Update. Dynamic Groups Of all the scripted system first trialled in End Game's public beta, Dynamic Groups is the most stable. Although we recognise that we're still missing certain refinements and features, we've chosen to first invest programming resources in other areas, and plan to return to this system for Apex. In the continued development of End Game, our goal is to create a solid basis for future MP content, using the mode to refine shared systems, identify / solve performance and network traffic bottlenecks, and validate improvements in other areas. With your help, we hope to continue to improve and expand our platform together! Best, RiE

As our recent roadmap (ahem, vaguely) alluded to, Nexus Update will see the introduction of some new audio features. We didn't go into too many specifics in the roadmap; in part, this was to 'keep it simple' but, also, we weren't 100% certain about the timing of the audio updates. Since then, some features have slipped into the Eden Update; however, a few nice improvements are on the way, one of which has snuck onto Dev-Branch already. The goal of this update is to improve the richness / 'texture' of the soundscape, by playing stereo samples at close ranges. In simplistic terms, this technology enables us to define, based on distance, whether a sound source is 'mono', 'stereo', or a 'mix' of the two. In our previous implementation (ahem, for 15 years :)), stereo samples were used, but the engine down-mixed these samples (as mono). Now, in the new implementation, the closer you are to the source, the more 'stereo' the sound is (from 0 to 100%). Currently, a sound source will start to 'spread' to stereo at 3 meters (which will be adjusted in future) This value is currently global (it applies to all sound sources with stereo samples) In future, it will be possible to define it per sound source This relates to future changes to the way sound is configured, which we'll share soon Once this happens, we will re-balance the ranges and volumes (e.g., a helicopter will be configured differently than a rifle) It's more obvious with headphones and recently improved samples, such as explosions and shooting Our Audio lead, Dusa, will drop by the forums later to consider any feedback, answer some questions, and generally dig down into more of the technical details. By this time, we should also have some clearer sense of the other audio development we expect to make it into Nexus. That being said, we do expect the bulk of the larger improvements to be rolled out after Nexus, on the road to Eden (and Apex). Thanks for the note. We are aware of these issues (caused by the above-mentioned 'core update'), and should push out a fix to Dev-Branch asap. Best, RiE