x3kj

does maldera have new trees? LODs are switching very late on trees (lowest resolution displayed even at short ranges), not sure if just my settings and PC. Can somebody confirm? Compare both screens, Right of the house, the pale green tree stand out badly.

i like it, looks good. Especially like the abundance of neat rock formations. Only the extreme steep parts near Vigny that are not covered by rocks look a bit poor due to heavy texture stretching Would appreciate smaller cellsize, but im pretty sure its a bit late for changing that? The Lighthouse type near La Rivierre has solid green texture as it's "light" (maybe someone forgot hiddenselection/settexture?) Green Lighthouse, green light. Solid logic, can't argue.

holy sheeeeeet!

popped up on devbranch (diag.exe)

i just tried the "carrier" turrets... apparently it takes 1 minute or two for their sensors to be operational. When starting the mission and having jets come at them, they dont recognize them on their radar (radar is permanently switched on), and can't be locked. After a while they work. However i had trouble with the 8 slot SAM launcher. When jets fly past you it's generally ok. When they come at you, sometimes they where on the sensor panel but i was not able to lock them whatsoever, no matter what i pressed. When they became lockable they where already inside minimum locking distance. I must say it was pretty confusing and i have no idea what is going on. I used the CSAT jet in the non-stealth version as targets, so there shouldnt be an issue recognizing the plane when it is in clear view and already quite large on the screen.

Big fan of your stuff Genesis. I dont know how i missed your work on dissension thus far. Congrats on the release. CTI is my favorite gamemode, its nice to see a new take on it. I always wished for a more sophisticated AI commanders. I have one thing that i would like to bring up for discussion and that is the style of the missions atm. The foundation of CTI (just my opinion, others may disagree) is about trying to take controll over territory and holding it against the enemy, thus naturally creating large combined arms battles.Most Warfare missions thus far never seemed to capture this ideal. The only things you where told to do in arma 2 vanilla is "capture this town". End of story. It didnt support different playstyles, it didnt support situations other than "attacking a town", it didnt promote defending in any way. Even BECTI (which i liked a lot) was quite limited in this. Some missions in Dissension atm feel to me as if they go even one step further and kind of detract from what is actually happening between the two sides, as they are not really connected in any way. The way they work feels very gamey and contrived. Having some hostage or bomb defusal "drama" near the frontlines seems kinda out of place, and the mission can quickly break if the frontlines reach this place (imagine CSAT gunship showing up when Blufor is trying to rescue hostages from guerilla). If such missions are instead spawned in the "hinterlands", far behind frontlines, they draw away players or AI from the real action. In addition, the assetts for the missions need to be spawned in specific places and ways to function properly, which can pose additional issues, and will always make it seem contrived. Why does it matter that a bomb is somewhere in a forest? From my point of view it would be much better to generate objectives/missions that relate to current situations on the battlefield. A good and integrated way (in my view anyway) would be to create a system that enables the commander to issue tasks to players and their group. And a system that allows players to request support task from commanders. With the request system AI commanders wouldnt have to be too "intelligent" to make usefull decisions, as playergroups can more or less shape the battle in their own way. So here's the idea: A commander can issue tasks based on their current plan and understanding of the battlefield situation. Tasks are accepted by players, which enables them and their group to contribute to the completion of it. For contribution towards a task, player/groups receive economical benfit to their actions (killing, damaging, capturing,etc). The commander also needs to receive some benefit for positive contribution by groups. Tasks could be global (acceptably for any player) or direct (only acceptable by the adressed group or type of group). Players could for example choose a role/ specialisation for the group they controll and certain tasks could be given to specific roles only. A player may suggest a task for himself to the commander. The commander accepts or declines. A player may also request a specific type of support. Commander can permit or denie. If permitted, a task of the requested type will be issued and forwarded to other groups automatically. Ideally, tasks should provide continual economic benefits to players (and commanders) while contributing to it. This means a group has to commit to a specific task for a while to maximize economical gains. It makes actions more persistent (e.g. fighting over a specific area for a while) and stabilizes the gameflow in the sense that people can get a picture of what is going on. One-off actions (capture this, then that) and frequent changes of tasks/locations lead to more chaos for everyone involved. Human and AI commanders can make better decisions if people follow the task system, as they know what each group is trying to achieve most of the time. This is also why the amount of active tasks at one time per group needs to be strictly limited to few tasks that are also not mutually exclusive (e.g. no defend position A and attack B at same time), in addition to limiting how often tasks can be switched. Due to the economic benefits that tasks provide, it should encourage players to make good use of the tasks and request system, which in turn automatically leads to more coordinated battles as well. Here are some task types i can think of from top of my head: Perimeter Tasks: Defense - unit stays in perimeter of position to receive some points. When killing enemies outside of the perimeter from within perimeter, reward per kill is increased. Reward per enemy killed that was inside perimeter is increased even more. Assault - unit needs to move into a designated perimeter. Unit receives extra points for killing enemies that are inside the perimeter. Unit receives extra points for capturing the position. Fortify - units that build field fortifications in designated area get points . Fire/Bombing Mission - kill units around certain perimeter (via heavy ordonance). Only active for limited time period Targeted tasks: Destruction - issued on target enemy unit that needs to be destroyed. Destruction of enemy unit by e.g. 50% would give bonus reward for killing/damaging, destruction by 100% gives even bigger bonus to contributing units Assassination "Bring it down"- destroy individual high value object with utmost priority (only on enemy vehicles and destructable fortifications/ weapon emplacements) Close Fire Support for friendly target group - ( Target group commander is reference position). Supporting group receives extra points for killing enemy units inside the target groups proximity. Direct Support for friendly target group - (Target group commander is reference position). Supporting group needs to stay in close proximity of target group. Supporting unit receives extra points for killing units Resupply/Repair for Target Group - Reward for repairing/resupplying. Reinforcement of Target Group - Load up infantry/ vehicles into a transport at a Base and transport them to friendly target group. When completed, the loaded units get transferred to the target group. Transport Target Group - Transport a target group to specific destination Handling of the tasks: AI commanders only really need to issue Defense, Assault, Fortify and Fire Mission tasks. The others could be "spawned" by players themself via requesting support. Human commanders generally could issue all tasks themself. However, requests and suggestions from groups are a key element and mechanics are required to make them important also to the commander. (e.g. impose cooldown on issuing tasks, but accepting requests/suggestions is free; Give more economical benefit for commander towards tasks that originated from requests/suggestions, etc) Depending on tasks, they may have an endstate, or not. They may be cancelled by the Commander after some timelimit, to account for no longer valid/usefull/desired actions. Some tasks may be available for multiple players, but once a player accepted, will become unavailable for others to prevent 3 groups trying to do the same thing which only requires 1 group. Once accepted, cancelling such "1-group-only tasks" without contributing to it's fullfillment could result in penalty (abuse prevention for repeated "stealing" of tasks from others and then cancelling). To make decisions more important on commander and player group side, issuing and requesting certain tasks should have cooldowns (also reduces frequent "hopping"), yet at the same time a unit should have at least one main task at any time available. Directed tasks (commander issues task to one specific group) could have a higher reward for both parties. This makes it attractive to execute specific tasks with priority for a group. Perimeter tasks that are global (acceptable by anyone) could have a greater perimeter radius compared to direct orders, but lower reward. Tasks could be "de-accepted" by players after accepting. No penalty, unless doing it repeatedly without contributing to any task. Not contributing to accepted tasks could have negative consequences (reduced "salary" income) -> encourage selecting a new task rather than leaving a wrong one active. Not contributing or accepting any Tasks for prolonged time could have negative consequences (reduced "salary" income) I know the implementation of such or similar thing would be quite a bit of work. I still hope this wall of text gave food for thought, inspires, or gives new ideas. Cheers.

The hours logged ingame are completely useless metric, because it can just be in the background. I have 3200 hours in arma tools just by having addonbuilder open in the background all the time. It would have been much more if i hadnt used a legacy non-steam version of it for the longest time. But people who like e-peen contests in general won't mind this "small" issue with the time of course.

Except this is propably the majority of people... reuploading someone elses work without permission or as part of some "pack" that they use on their server (not rarely monetized as well). And no the online community at large won't call it out, because they mostly dont know about any of this.

Its not subjective, it just depends a lot on the condition. In moonless, cloudcovered nights inside a european forest with medium undergrowth density and without lightpollution from cities it becomes so pitch black that even with 2nd gen+ NVG plus IR illumination you can see no further than 5m before the image becomes so noisy that you can't make out anything at all. Together with an ordinary handheld flashlight you could see 10m but that was it. Without light and NVG you could barely see your hand held in front of you, and that after adjusting for 30min. I already said so previously, but the problem ingame doesnt seem to be the light itself. It seems to be the disparity of reflectivity / specularity of different textures. Grassy ground textures and leafes are barely affected by light at night, they stay almost black. Whereas tree trunks and buildings catch light nicely. If you move in areas with almost no objects that catch light, you can lose orientation easily, even in nights with medium illumination. (unless you turn your monitor gamma up and darken your room completely. In reality gras and leaves can be pretty reflective. Like mentioned earlier, it's not the new lighting setting. It's the poor consistency between textures.

1.) Depends on the mission and playerbase of a server. I would argue that on public servers reconnaissance isnt needed (or maybe needed but people just blow things up and run around uncoordinated). On private communities/clans/groups things are different, but you have to find one. 2) I dont see why they shouldnt. The flightmodel is barebones basic, contrived and not really a good aproximation of physical behaviour, so dont expect wonders.

I'm most curious about more details on this

If the surface of your firegeometry sits below the visual LOD, you will not see the dots. Have the firegeo slightly above the visual LOD surface to see them.

thrustDelay config parameter should be close to 0. (0.1 is ok for example). Wrong rpm and gearbox settings can cause permanent application of "force". RHS has very simplified physx settings on their tracked vehicles (last time i checked anyway, which has been quite a while ago) - that could cause some other unique problems if you use their configs as base.

Many A3 planes seem to have 3° angle of incidence. They fly perfectly straight when oriented to -3° (csat vtol for example) You wonder whats wrong with the FM? Look at this. Plane is rolled to the side and has almost no airspeed -> falls sideways. Sidewaysacceleration shows 8.5-9 m/s². Sideways velocity barely increases. (and yes Gryphon can fly also backwards currently)

Not wrong. But not a complete representation of what should be happening. The long range missiles launch at large angles upwards and only steer towards the target when they reached some altitude. So small bumps are not really an issue, and the terrain intersect check should be conducted from a startingposition considerably above the vehicle. Regarding the -0.09 Z axis - The center of the vehicle could be the center of the models bounding box (which is automatically calculated), so if you have some memorypoints and stuff below the vehicle this could be the cause. If you want to use positions from the vehicle, i would recommend defining a custom memorypoint in the launchervehicle, then get the modelspace coordinate of this memorypoint selection and convert that into worldspace.

Regarding mine detector "radar" vs. "beep" detector - why not have both? Let the mission designer choose (and if he doesnt want to he can let the player choose).

there is no impact effect for Slammers 120mm APDSFS ammo for impacts on water (havent checked other vehicles) The new driver and gunner direction indicator has some texture blending/ phasing problems (not sure how else to describe it) - parts of it go darker as you rotate on my screen.

No it doesnt work like that. Damage is dealt in proportion to the amount of speed lost due to the contact with fire geometry. And bullet damage is also reduced in proportion to speed loss. Only explosive projectiles, or projectiles failing to penetrate armor deal full damage, but only once. These are the issues that are present with the current engine side damage system: https://feedback.bistudio.com/T120542 Vehicle configuration (location and settings of hitlocations and firegeometry) side is something else.

have you tried packing it with pboProject? It ensures that there are no typos or similar in the configs.

Thats not true. What matters is contrast over the background. If you increase the surface area 100 times but have the same total heat radiated you are much less successfull in beeing able to detect it. A IR flare does not produce the same amount of heat in total that a jet engine in full afterburn radiates. It burns hotter however (higher temperature over surface) -> higher temperature compared to jet engine. Which is what worked against early IR seekers. Nowadays there are algorithms to distinguish between such different objects.

Combustion temperatures are the same as for large vehicles. Small vehicles generally do not have any extra casing around their engine, cooler and exhaust. So they do emit more heat compared to large vehicles per cm² surface

The animations of the controll surfaces on the new jets seem really exaggerated compared to the effect they have on the planes maneuvering. It looks very floppy/wonky. There are a number of visual errors on Shikra that i noticed. Overall i must say that i would have expected slightly more in terms of visual quality inside the cockpits. There dont appear to be proper normalmaps so that the 90° edges dont look as jarring for example. The "digital" interfaces in the cockpits are barely readable and suffer from z-fighting issues. They have only primitive color as well, no texture to it. Esp. the wasp interior due to beeing almost entirely covered by interface looks poor as a result. I also got this popup when firing all missiles one after another (using diag.exe). Not sure of the significance. told you... there are no changes of flight physics under the hood, and there is no "Apex flight physics". They are just "soft" setting tweaks of the same flight equations, with the flight equations beeing responsible for unsatisfactory behvaiour. In DCS when flying Mig-29 and SU-27 they do not turn in any significant way when rolling to the side... take that however you will.

Considering that most vehicles and infantry do not have a mine detector at all, i'm okay with that. Maybe 10m would suffice, but having to walk directly by it would be too "much" for arma i think. Also remember that all mines in arma are visible if you look close enough. So having a mine detector with 3m for example would be a bit silly, as you are equally capable to see them with your eyes at that range. Only thing that should be checked is wether or not the thing detects them through walls and objects, which would be unfortunate.

doesnt happen in arma. Minigun bullets simply deal AoE damage like explosive weapons on impact

no.