Asheara

Hello there! I know it's been way too long since my last appearance :) Today, with the release, we shall bring you... answers! 1) Yes, it is 2) Yes, not defining HitFuel class will disable it 3) 0.9 4) Eh, that's a bit complicated... speed of fuel leak can be calculated as: 0.2 * 0.1 * (fuelcapacity ^ 0.8) * (fuelHit) fuelHit return 0 or 1, depending whether HitFuel is smaller or bigger than 0.9 fuelCapacity has 0.8 exponent to make it a logaritmic function, so 100 units (Hunter) of fuel will be leaked in ~2min and 1882 units (MBT_01) will be leaked in ~4min Don't ask me what these constants are :D I'll get back to you soon to sift through the other questions which might be here!

The duplicate light hitpoints should be fixed by now :) Also, the turret hitpoints have been tweaked, it shouldn't give the total damage anymore. However, the values to make them last longer are still WIP

@Strike_NOR I know about the issue with HEAT, TandemHEAT and such, however right at this moment I cannot do anything about it - those weapons are still being worked on by someone else and thus unfinished (teaser: possible submunition!). I've been told to hold on with these and focus on AP balance for now. But thanks for the suggestion! Once we get the green light, it will be very useful :)

Well :D That's quite complicated question. To crush your hopes and dreams from the start: no, we won't do that. However, it's more complicated. You see - most of the times we have 'wreck' p3d for this purpose. It is usually without the turret. Sure, it can be pasted from normal p3d and such, and hiding some parts on some condition is not really a problem. Problem is randomizing it. Although there is randomization in Virtual Garage and Eden, I believe that except the scripting, we have no proper way to randomize this kind of things. It would probably require either programming support, or script it. Scripting we are generally trying to avoid - when it comes to the vehicle functionality, we have configs for that and... we can't just hack everything with scripts, we need to maintain some standards ;) Stability, performance and this kind of things. So all in all - it would require some work from art department to remodel the wrecks. It would require work from programming to give us proper way to randomize things upon destruction. And work of encoding to put it together. That's quite a bit of work for a small visual fluff, don't you think? :) Especially when receiving reports around here how broken the configs of the damage model are :P With the short time given to us, we need to focus on the important things :) @Yoshi_E Damn, the overall protection is weak? And here I thought the tanks are kinda tanking it (well everything except APFSDS). Will try to look into it, but... Turrets first! Started working on it, and yes, we plan to tweak that total damage which gets done. Divide it into the categories of unmanned remote vs. manned turret, and the unmanned ones won't give any total damage (except Angara, because that's one huge ass turret), while the others will be getting some total damage. However, I'll try to tweak it in a way so... hitting a gun barrel doesn't do this kind of stuff :D

Now now, which one? :D There's plenty of tools in there. Either way, all of this is kind of outside of my power and for sure we can't release everything, but some of these you can find in diag exe :) That should have at least limited functionality of this with several diagnostics :)

Tell me about it. *runs around in panic with a fire extinguisher*

It's done! Devbranching inbound :) Aaaand for anyone who asked about those weird reflections, deflections and other movements of the projectiles within the tank - also aware, it has been shown to programming, hopefully it will get somehow fixed or tweaked, but mo promises :) There's still new feature which could use some fixing ;)

1. I believe touching the surface is enough, it still has hit the component. But I can maybe get more detailed answer from programmers 2. Further damage modifiers - whole black magic which worked before works now as well. The sphere hitpoints are still calculated for explosive damage, works the same as before. Damage is affected by size of explosion, size of sphere, how close they are, whether or how much they overlap... Damage via components works exactly the same in terms of config parameters for projectiles. CfgArmorSimulations "hit" parameter only modifies those which have been previously defined. 3. (B) is right! Projectile does calculate penetration normally by .rvmat in firegeo but does ALSO modifiy exit speed by the speed parameter in armorsimulation 4. Hitpointcomponents don't behave in any way for indirect damage - for that, there are still those "memorylod" hitpoints in hitpoints lod. They are still necessary to have there precisely for this reason - indirect hit. 5. I have no idea, would need to ask programming, but I'm not aware of any specific differences. however, i believe it will respect some differencies between those classes as they are there for a reason. But honestly, I don't know, I'd need to ask :) Thanks, I'll definitely take a look. Or well, arrange it. Turrets, their hitpoint and balance are going to be tweaked / fixed in near future, quite possibly this week or start of the next one. @scavenjer Thanks for noticing! It is actually one of the global and more pressing issues we are trying to fix about now. It is on our to do list for programming, but your input is definitely helpful! Better repro and all. But yes, we are aware of this one. The technology of the new feature still doesn't 100% work as intended. I'm not certain who asked about this one, but yes, damage values are still a placeholder, and still not tweaked. We're terribly sorry about that, but now with upcoming devbranch release we've been having our hands full with clearing out as many bugs as possible. It's two encoders against the world! I know it's not ideal and I would rather have it done by now as the release is pretty close, so time for tweaks and feedbacks, but... not there yet. Apologies for taking long time to reply! At least it wasn't fully spammed when I returned :) Following the forums and such can be quite time consuming and the devbranch release robbed us of this time ;)

While personally I would really, really love this, it's unlikely to happen :( I can write it down for nice to have things and try to forward it somewhere, but... I'll be happy if we'll somewhat managed to balance it properly on time. Bugs from devbranch piling up, we have several broken animations reported and way too few people to add in anything new :( Still, loving the suggestion! If we get any room to breathe (unlikely), would be definitely something.

Wow, what the hell! That is something... which shouldn't have happened. I'm not sure whether we can do something about it, I believe significantly changing the penetration at this point would be too risky and expensive, but I'll forward it to programming to investigate. We'll be definitely looking into those ricocheting projectiles, so while we're at it... might ask about this as well, but no promises. If you could send me this repro mission to try it for us, I'd be grateful. Thanks a lot for the feedback! It's exactly what we need! 1) sure, it's a valid suggestion, but this is only naming of selection in hitpoint LOD, not the hitpoint itself, therefore it doesn't have the priority. Sure, I'm with you on this page, the naming is better and makes sense, but we'll be having our hands full with other fixes. I'm afraid we won't get to it, but I'll see if it can be done while working on fixes written below. 2) Thanks for bringing it to my attention! I really need to sift through all hitpoints. This is caused by one of the things I've written in documentation under the "quality of life" updates. In other words, visual = "" vs. visual = "-". And didn't update it everywhere yet. 3) Same as above. We'll get working on it. 4) I believe HitGun never actually blocked the firing from the cannon. I know, it's logical, but this wasn't intended. We don't have the engine soolution for this and it wasn't planned either. HitTurret and HitGun hitpoints are intended to affect the turret rotations and elevations. So yes, even with destroyed hitpoints, you'll be able to fire - but not control well where to fire. If you still can move the turret freely in all directions with destroyed hitpoint, THEN it's a bug :) 5) Well, as far as I can see, you sure are unable to start up and move in any direction. But I see that it's still able to turn on the place, which is logical that it shouldn't. But I'm not certain if this is intended or not. I can ask around, but fixing this might get bit more extensive as... we would have to think thoroughly about the consequences it might cause :) More people and decisions would be involved, whether we would actually want to fix it and how will it affect sandbox. At this point, it's unlikely to happen, as it's certainly not trivial. 6) I see it as, with damaged gun it should lower down as it was. I'm surprised it happened as late as in the point of changing seats, but I didn't see any further elevation. Yes, it moved a little here or there, but in general it appeared that the gun didn't elevate, so i might fail to see the problem. 7) Won't fix, I'm afraid. Many more pressing problems, even visual, to be taken care of earlier. This would require a thorough investigation of the magical particle config and so on. 8) Not a bug, they better, they know what's about to happen! :D Would you want to stay in the vehicle about to explode?

Oh my, what a dedication! Lot to read and reply to on Monday, sorry for the delay and apologies is advance if I overlook anything :) I'm happy you all are so interested! 1) Yes, they can create as many components types and ammo types and define their interaction 2) Yes, they can be stacked and placed freely as in image above. Just adding some more hitpoints, as armorComponent is a hitzone parameter. You can even expand on the existing hitzone we provide. Define specific component type for say... engine and add it. 3) The FireGeometry and materials are still working as they were previously. However, the damage which would be dealt upon penetrating this component will be 'multiplied' by the number in hit parameter, should work the same way with speed :) 4) HitHull can sort of simulate the ammo rack, however the instant destruction might be bit overrated. It's more complicated - if the HitHull is > 0.9, the explosion will occur, in case parameter hullDamageCauseExplosion is set to true. The time, in which the explosion will occur, however, is randomized, so it doesn't lead to instant destruction. It seems the explosion will be delayed by time between 2 and 20 seconds. Nothing I know of. I don't think anything like that will happen. Thank you very much! There was a typo in the named selection. Fixed now. Great work on the damage system! What are those custom parameters, something read by a script? I'll gladly answer your questions if I can, though... do I understand it well those are the two under the video, or I overlooked something? Could you reformulate the first question, not sure I understand it. And as for expensive submunition - I'd love to give you an answer, but I don't know it myself. However, I'll try to get the answer for you, hopefully programmers might point me somewhere. If there are any specific questions, shoot! If I overlooked someone, please tag me again, will sift through the posts once more, but I can tell I've made a mistake by not looking for two whole days :P

Thank you for your service to the community, good sir! Will do, it's a valid suggestion, shame on me this wasn't done already ;)

That is actually sort of in progress. HitHull has the chance of randomly exploding vehicle, therefore this hitzone should be now smaller, harder to reach and basically serve this purpose. @Strike_NOR The damage modules you've proposed are nice and make sense! However, despite the fact that we've been considering these (both optics and ammo rack) and even had some prototype, we've decided to focus on the component system and the armor simulations, as this entire damage enhancement is a gargantuan piece of work. We'll already have our hands full to balance all this on time - as few of you already noted, some of those values are merely a placeholder. We don't have enough people nor enough time till release to actually make it happen. I'm sorry.

Hello again, I've tried to shed the light on how the new upgrades work with this documentation. Enjoy yourself, and if anything is unclear, please let me know!

Thanks for pointing it out! I made a mental note about this before, but we're yet to fix it. I'll definitely put it on my list of thing to be dealt ASAP. Ooops, will need to look into it. Damaging the opposite side is not desirable, thanks for feedback! Uhm, yes, in my tests HE and HEAT were blowing up completely all around the vehicle too Didn't manage to figure it out yet and fix it on time, but it's in progress. About HEAT doing no damage to the side on Slammer UP - also on my to-do list, though honestly not sure yet WHY is this happening. But I'll figure it out! And as for the netting on Kuma - as far as I'm aware, that's not even supposed to happen. The netting gets destroyed mostly due to explosion of ERA and Kuma doesn't have any. Netting is not a separate hitpoint to be destroyed, simply a fluff which goes with destroying other hitpoints. Yes you can! I'll try to write it today, apologies for the delay, I know it would be more ideal to have it ready with the devbranch release :)