x3kj

not in my experience. If sprungMass is wrong, the vehicle gets pushed up more than usual (if its too high), but not float with wheels not touching the ground. Floating is either memorypoints not matching visuals or visual animations not matching physx movements

Can't argue with that logic

triggering mechanic is not related to the damage mechanic (apart from obviously triggering it...)

Valid points, however there is a problem - there is no "anti armor" weapon functionality in arma. It just causes more damage, which can be very problematic (e.g. a single hit or very few hits with one "anti-vehicle" mine could possibly bring down an entire building due to these limitations). Here's hoping for Tank DLC to fix that by introducing a shaped charge feature (possibly even via the submunition route of converting a flying explosive projectile on impact into a much faster one with penetration capability ).

Try with A-10, GBU-12 (hits normally) and then try with Mk82 (flies over). countermeasue bound to mouse button, so point of drop more noticeable. First bomb is gbu-12 - hits correct, others are mk82 - they all overshoot. It makes a much bigger difference when flying in faster jets or trying to hit stuff on reverse incline / mountain top.

Could you have a look at bomb reticles again too? Dropping unguided bombs will always result in beeing off target. Choose a flat target (i.e. a decal on a runway) and do some runs on it with the A-10 without extreme dive angles. You will notice that the bomb always overshoots by 20-30m, depending on speed altitude and angle. Idk if that deviation is because of some direct trajectory calculation issue, or if there is some delay after pusing the trigger, before the bomb starts flying. If this potential delay is not accounted for in the calculation then it will always overshoot.

The answer is below the "What is the currently planned scope of the Project?" headline ;)

except commanders irl do not have to deal with total morons or abysmally clunky UI to "controll" the moron and can rely on telling the gunner to engage at will and he will simply do it. Guess why 99% of the players will chose gunner position themself if they have only ai - the other way round is just utterly ineffective and frustrating.

If you sit in the tank yourself, AI gunners will not fire the main cannon (at least in vanilla), you have to order it via crtl+mousebutton... which is an unfortunate design decision that this is not tweakable via AI commands.

I’m looking for people who would like to help on the 40k realism total conversion. More information you can find in the mod discussion topic. There is a need for about anything one can think of: Terrain makers, Modellers, Texture Artists, Scripters, Config Coders, Audio Artists, VFX Artists, Animators, Mission Makers, Writers, etc. If you are interested contact me here, or come join the discord channel.

This is not a fix but a bad workaround. They use vehicle headlights. If vehicle has both (turret with light and headlight) you can only turn on both at the same time. And gunner cant turn on his light on his own. Only driver can controll headlights.

I think the talk about "uxo feature" seems a bit confusing. It's not a base feature, it's just something that was made possible by the actual feature: added possbility to spawn different projectile types randomly for submunition ammo, and extended submunition support for more projectile simulation types. The cluster spawns a random type of projectile (with different chance). So instead of spawning 100% of exploding projectiles, it spawns 3% as mine or similar. To have large uxo, you either have to convert all ordonance to cluster ammo (with spawn amount 1) - which just asks for trouble if you ask me, or replace the projectiles mid flight via a fired Eventhandler. Fired EH should be the better way for indirect fire and free-fall ordonance. The later method is possible since quite a while. If everything had uxo i would start to worry about performance for longer missions... _______ talking about cluster ammo, i've seen the new triggerSpeedCoef in the config. Is it possible to override the speed with an absolute value? A double functionality, just like initspeed for cfgmagazine, would be really usefull. That way even projectile forming high explosive projectiles could be created (HEAT and similar) - provided the triggerDistance at small values is reliable, OR if the triggerWhenDestroyed is compatible with submunition and keeps the orientation of the projectile intact. Another thing where submunition would be really usefull would be for mixed-belt Ammunition on aircraft and helicopter autocannons. If the triggerTime would work with submunition (didnt test), one could set it to 0 and mix AP and HE in one belt. Granted the distribution would be random, but thats still better than trying to butcher the projectile hit values to simulate both at once (which never works). If the spawnmode for submunition could be switched between random (standard) and deterministic that would be even better - meaning that with 80% A and 20% B, four shots will be A and the next always be B. But i guess thats pretty tricky because information between single submunition parent projectiles would have to be transferred.

You can, but i think it's hopeless atm... train has passed. I suggested it multiple times during when the system was beeing developed, no dice.

Impossible at present. There is no method to extract information from the hardcoded default HUD radar, means you cant process any of it's data and use it otherwise.

if its part of the backpack/vest i dont see why not. Not sure if the weapon can be softskinned itself. However, since there are no bones to guide the feed belt, it will stretch and deform an awefull lot. Just imagine all the use cases -> weapon shouldered, weapon lowered, weapon on the back. Impossible to make it look good without dedicated bones in the skeleton (which you cant just add to normal A3 man. You need a totally new character class with custom skeleton)

* only in "A3 Samples" Devbranch currently... I noticed that in the plane wreck LOD there are points named component. Do they really belong there? Pretty sure they dont.

In theory, i should be able to build Artillery Clusterammo that dispenses cluster-dispensers, correct? >insert "Yo dawg we pimped your weapons, so you can cluster while you cluster." meme<

Can you describe how the engine even considers the "weight" for triggering? In technical terms config/script side. I was under the impression that (for a regular mine) it just considers distance to infantry, with modifier based on your stance and possibly walking speed. Or do you have to stand directly on the thing to trigger it (because you saying "weight" would indicate that). edit: ok moricky's answer makes more sense. Please keep it that way. "BOOM" as technical description is of no use to anybody.

What does BOOM mean? When common already acts like a regular mine and reacts to infatry, does that mean Sensitive will all 100% explode on impact?

awesome :)

Hey Genesis, i've just seen your #17 video (im a bit behind the curve, admittedly). You mention a number of good and important topics which i would like to give some feedback on. AI Cheating: Yes it is certainly difficult to balance. Supply runs of course provide 'traffic' that can be attacked/protected. But since AI is unreliable this forces players to do the job (or the AI to cheat). It can be an easy money gainer, but i'd say the novelty wears off quickly (imagine a session of 3h - which is not unusual for a warfare mission i think). Personally i would not include the "pick up this and bring back to supply your team". What if players are busy fighting - which i would argue is the more fun part in arma. Should you force them to pick up supplies instead if they want to win? Realistically yes, but in terms of 'fun' i'd say no. There could be better ways to give players reasons to transport stuff from A to B - tying into the building system. Building system. You mentioned you are not sure how the gameplay/justification should be. Last time i posted (the task suggestion) i pulled it out of my "wish-gamemode" concept sheet. Let me pull out the section on building ^^ Building custom bases is finicky and time consuming. In Arma warfare you dont just have zombies and bandits running around like in 99% of survival rpg games. From cars to tanks, bombers and Artillery there is everything. Stuff that can flatten a base in seconds. That's why it would be a bad idea to encourage or try and support building the players "dream castle". In warfare your HQ is a field base mostly. Let's develop this idea further: Instead of having the player build buildings wherever he wants, it would make more sense to have it more coordinated. So a commander task could be to build an outpost. There can be certain types and they provide different functions. Positions could be chosen by the commander if necessary (but some player input might be good in some cases to not have an airfield surrounded by cliffs for example). Once position is chosen, players have to build specific (predetermined) buildings within a certain area around this position to have the outpost operational. There may be optional buildings that can extend functionality of the outpost or just help to defend it. So you basically have a check-list of single buildings/objects that are required to make the outpost functional. Should any be destroyed, the commander can then automatically issue repair orders, as he can determine what is missing. Players may add walls and other defensive stuff if they want, but the maximum object count should be restricted. Remember: Field outposts, not dream castles. Reason: Stuff will get destroyed, multiple times even. It is pointless building some base for hours if somebody can carpet bomb it. In fact, the outposts of the enemy provide logical non-town targets for your commander to attack (which he knows of thanks to your recon activity) Some outposts periodically need ammo/fuel to keep functioning. This is where the Supply-Trucking comes in. This can be more infrequently than the ressource supplies without affecting the base economy or gameflow too much. Forward operating Base [FOB] (unfortified or fortified) - the classic, an idea that i already pitched to Benny for his Becti version many moons ago ;) Small headquarter Bunker/Tent build ammo storage area build group rest area (bunker/ Tent) optional - build fighting positions and static weapons (infantry bunkers, mg nest, tripod AA/AT) Purpose: Forward respawn, infantry recruitment and handweapon-rearm point place closer to the front line. Reduces travel-time. Needs to be within certain (long) range of HQ to allow recruitment. Range can be extended via Communication relays (see below). May require periodic supply with ammo (the more people use it the more often). Communication Relay. build communication antenna. build generator. build walls/fences (optional). Purpose: connect various smaller outposts/bases to make them functional. A net can be build May require fuel over time Infantry support mortar position (2-3 mortars) build arty protection sandbag circle /dirt wall circle build mortars build small ammo storage 'building'/ crate build camo nets (optional) "Divisional" artillery firing position min 1, max 3 units of howitzer/MLRS/heavy mortar. Mobile or Static possible. build or park artillery unit(s) build arty protection around it (dirtwalls, large stonebags,...) build large ammo storage build camo nets (optional) These firing positions are manned automatically by AI gunners. Firing is ordered by commander only. Firemissions can be requested by players. Ammunition has to be supplied realistically for players (due to power of artillery) - that's where the ammo storage comes into play, since you have a defined and logical place where somebody with supplies should go to perform the resupply. Maybe have a "ammo wallet" for players. Everytime a player brings ammo, he can request a number (maybe 1-2) firemissions from artillery. Player has to pay for ammo. Alternatively it's a task. Bring certain amount of shells. Reward: either money or ensure 1 arty firemission. (it is quite powerfull after all) Build small custom airfield (VTOL aircraft/helos) build aircontroll building (bunker or tower) build 1-3 landing platform build hangar (concrete structure) for buying planes build ammo storage build fuel storage build power generator build quicklaunch ramps (optional) build AA defenses (optional, certain max amount.) build radar (optional, provides intel for friendly vehicles and AA defense weapons) (requires fuel and ammo periodically, depending on usage) In case an outpost is destroyed completey, it might make sense not to rebuild in the same place. Having artillery in the same place makes them more vulnerable. As for the building process itself, one truck load per n-amount of buildings could be used. You load truck at HQ, drive the truck to destination, place the buildings. Either you get an empty truck back, or the truck despawns (not so immersive and leaves player without vehicle, but may be better option for AI squads doing this task). It's a lot of stuff that it would require (i guess) which is why i didnt mention it the last time. Maybe it gives you some new ideas for Dissension. The last section of my sheet is dealing with experience and recruitment (though its more tailored to my total conversion), not sure if that would interest you.

This is it? You have nothing to contribute and cant read either? "hey guys i just came here to say that i'm first" ...

WIP-Eye-Candy Videos: myself talking about the current status (42min): Ingame Pictures: (Note: this is only a small selection) WIP Renders: (Note: this is only a small selection) FAQ Q: Will this be for everyone or will it be limited to only few select servers? As stated in the first few lines, this project is strictly non-profit. Therefore, it will be available for every server owner. I have a strong distaste for “server-exclusive” mods anyway. Servers using this mod will not be allowed for monetization. Q: When do you consider a first release? Intentionally vague answer: When two opposing factions have enough content completely finished and enough variety to enable smaller combined arms land based encounters. That means a bare minimum of copy pasta placeholders, no unoptimised models/scripts, etc. A small thematically fitting “demo” terrain is also a condition at this time. Q: Will it require DLC? A: No, at this point. But it may change depending on the development of our terrain/ terrain assets and BI’s policy for using for example textures and vegetation from a DLC in a mod. However, we will only use DLC content if there is a very good reason to do so. Q: Will there be Astartes? A: Using a regular human skeleton for them is definitely out of question. Creating fully functional characters with custom skeletons in arma is a big pile of work however. If we can find an animator and config coder able and willing to create and implement a gigaton of animations to enable custom characters with a custom skeleton worthy of an Astartes, then the answer would be yes. Everything else (model of character, armor, etc) are childsplay compared to that. Q: Will there be Titans? A: Unlikely, due to too large scale for gameplay and animation work involved (requires custom skeleton with all custom animations - less than for Astartes though). Not impossible but simply too low priority compared to most other things. Q: You know there is another 40k Project, right? A: Yes indeed. I've been in contact with them quite early on. They focus less on individual detail or super-realism (compared to my goal) and instead more on variety. I can totally respect that, since not everybody has the nerve to go into as much detail/feels the need to do it as i do. We both came to the mutual conclusion that it just would look completely wrong when having units from both projects side by side due to the stylistic differences. Still, there is room for collaboration (sound or effect department for example). So if you where wondering - no this is not a result of some silly rivalry or personal drama. Just different goals. Q: There was no update in a week. Is this dead? A: Asking this question (in this exact way or any similar conceivable complete or incomplete manner) is a crime against the Imperial Creed. Anyone guilty of it shall be flogged (no less than fifty lashes) followed by beating (no less than twenty blows with an object of no less than 2kg in weight under Terran standard gravitation), then shot. His corpse shall be burned, and his next of kin invoiced for expended Promethium. Bystanders who make themself guilty of not seizing, restraining and turning in any offender to the local commissariat will be punished similarly but are spared from the flogging.

Now, that Jet DLC is released with many improvements, can we get an updated Plane sample with all the latest bells and wistles (pylons, sensors, ...)?

if it is not optimized for ingame use, then yes it should be reduced before you go and weight it first, because it can be quite a bit of trial and error and labor intensive. I would also suggest finishing the UV and texture first