Asheara
-
Content Count
27 -
Joined
-
Last visited
-
Medals
Posts posted by Asheara
-
-
On 3/1/2018 at 6:38 PM, Yoshi_E said:@Asheara Please take a look at the hitpoints "hitcomturret" and "hitcomgun" for the vehicles: AMV-7 Marshall, CRV-6e Bobcat, IFV-6c Panther and IF-6a Cheetah.
A simple burst with a normal gun on the commander optics sets the hull and the main turret into the "badly damaged" state.
Also a lot of lights have duplicate names (can be found on almost all armored vehicles):
"#light_l",
"#light_l", <----
"#light_l2",
"#light_r",
"#light_r", <----
"#light_r2"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
-
4
-
1
-
-
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 :)
-
7
-
1
-
-
On 3/11/2018 at 1:10 AM, Damian90 said:Question, is it a possible thing that you guys can make vehicles turrets not disappear during their destruction or at least make this a random behavior, for example 20% of chance that turret will disappear, kinda emulating a turret being thrown away from the hull by random ammo cook off?
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
-
5
-
1
-
-
9 hours ago, pr9inichek said:@Asheara Can you give us this tool for find more errors?
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 :)
-
5
-
-
37 minutes ago, teabagginpeople said:Oooooohhhhhhh sheeet this dlc is coming in hot.
Tell me about it. *runs around in panic with a fire extinguisher*
-
5
-
4
-
-
On 2/23/2018 at 9:08 AM, mondkalb said:Heya @Asheara please consider scalability of the system for community warhead types by adding baseclasses to
class Armor_CAGE class Armor_ERA_Heavy class Armor_ERA_Light
A class Default for these to inherit from.
This way community creators can simply add their own Warhead types to class Default and rest assured that all other Official and Community-Made Armor-Simulations (that inherit correctly from class Default) will have the new Warheads, too.
An easy way to establish compatibility across various mods without requiring explicit compatibility class patching.
A baseclass will make this a lot easier to config-patch, too.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 ;)-
9
-
-
On 2/26/2018 at 9:31 PM, x3kj said:My questions regarding how the new firegeo/hitpointcomponent based hitpoints work are these:
- What is the condition for a projectile to cause damage to a hitpointcomponent? Does it just need to touch the surface, or does it need to penetrate?
- Are there any further damage modifiers than the one in the armorsimulationconfig class? For comparison, "memorylod hitpoints" damage depends on amount of speed lost during penetration, plus projectile parameters (hit, explosive, actual speed vs. typical speed parameter). Does damage via hitpointcomponents behave exactly the same, or do they only take the config based parameters into account (projectile properties as mentioned, plus hit modifier in armorsimulation cfg)?
- The armorsimulation config has speed modifiers. This leads me to believe it affects bullet travelspeed. What exactly does the speed parameter in there do, what effect does it have on the projectile ballistic simulation/ flight path. Which of the three is true: [A] Projectile ignored the .rvmat and .bisurf of the firegeo from this component and only uses the speed modifier Projectile does calculate penetration normally by .rvmat in firegeo but does ALSO modifiy exit speed by the speed parameter in armorsimulation [C] Projectile travelspeed and vector is not affected by the parameter, it just uses .rvmat in firegeo - like for any other part in firegeo ? If C, then what's the purpose behind the speed modifier?
- Do hitpointcomponents behave different for indirect damage than memorylod based hitpoints (i assume not?)
- Do the projectile simulation classes (shotBullet, shotShell, shotMissile, shotRocket) lead to different behaviour on hitpointcomponents or are they treated all the same?
Yes my damage script/config-system uses custom config properties and hitpoint names that are processed within the damage script - which makes it fairly flexible and handy to configure.
Regarding the random time until explosion on hithull>0 damage: I dont see it as big issue having some random delay until explosion. Real tank explosions/cookoffs can also be quite random with delay at times. The biggest issue is AI however. They immediately know when conditions for explosion are met and jump out immediately (within 1 frame). This is unrealistic, because it takes considerable time to recognize a critical failure like this (while beeing dazed from impact), react and and climb out of a tank. In arma its like some spring puppet toy with button on it. Push button and *BRRR* instant puppet ejection.
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 :)On 3/1/2018 at 6:38 PM, Yoshi_E said:@Asheara Please take a look at the hitpoints "hitcomturret" and "hitcomgun" for the vehicles: AMV-7 Marshall, CRV-6e Bobcat, IFV-6c Panther and IF-6a Cheetah.
A simple burst with a normal gun on the commander optics sets the hull and the main turret into the "badly damaged" state.
Also a lot of lights have duplicate names (can be found on almost all armored vehicles):
"#light_l",
"#light_l", <----
"#light_l2",
"#light_r",
"#light_r", <----
"#light_r2"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 ;)-
4
-
2
-
5 minutes ago, Strike_NOR said:Another reason a brewup/cookoff/fire/smoke effect would fit well into the game. Because right now the vehicle seems fine when they all eject. Then boom outta nowhere.
While on the subject, could they perhaps disembark in a queue? Like from transports, one at a time? These are like olympic champions in synchronized ejection. :)
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.
-
6
-
4
-
7
-
-
On 2/25/2018 at 2:42 AM, lex__1 said:Tell me, is it possible to model the destruction of APFSDS when it penetrates obstacles? Create probability of penetration into obstacles for APFSDS depending on:
- Obstacles
- Distance
- Speed APFSDS
- Power APFSDS
Or is it difficult and will not be realized?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.
On 2/25/2018 at 12:07 PM, pr9inichek said:@Asheara and Dev Team thx for this Update.
Please check suggestions and issues below:
1) Rename some hitpoints
era_l_t_1_point = *hit_era_top_left_1_point
era_l_t_2_point = *hit_era_top_left_2_point
era_r_t_1_point = *hit_era_top_right_1_point
era_r_t_2_point = *hit_era_top_right_2_point
era_f_point = *hit_era_front_point
era_l_1_point = *hit_era_left_1_point
era_l_2_point = *hit_era_left_2_point
era_r_1_point = *hit_era_right_1_point
era_r_2_point = *hit_era_right_2_point
2) Destroy any hit = Destroy visual of Hull in vehicle
Example: Fuel is down = Visual Hull is too
3) Destroing Commander Gun haven't visual effect...
4) Destroing Main Gun haven't block shot from it...
5) Destroing ENG haven't block the ability to move
6) AI can proper Damaged Gun
7) Very bad render for Fire ball :(
8) Crew automatic get out when Hull is down
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?
-
3
-
1
-
-
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!
On 2/23/2018 at 11:32 AM, Strike_NOR said:Hi, thanks for continuing to clarify and work with our feedback.
I'm basically trying to make out what potential this component based system has for the community.
I have read through the old guide, and tried to apply the knowledge there to the component system and I have a really simple setup to ask about.
Consider the following setup:
Am I correct to understand:
- Modders can now create as many new component and ammo types as they wish, and define how they interact?
- These new armor components can be stacked and placed freely as in the above image?
- Thickness of components are disregarded, but since speed and hit values are influenced this heavily influences the projectiles ability to penetrate the firegeometry?
- Vehicles can be set up so that penetrating fire-geometry does not damage global health, but an internal "hithull" firegeometry/hitpoint combo can simulate "ammo rack" (or other critical part) leading to instant destruction?
I hope I made myself clear in the above points :)
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.
On 2/23/2018 at 2:35 PM, Night515 said:@Asheara I suppose it's safe to ask this, are there any plans to give the existing tanks different ammo such as HEAT?
Nothing I know of. I don't think anything like that will happen.
On 2/23/2018 at 2:40 PM, HaseDesTodes said:i am currently doing some damage testing and i noticed some thing
getAllHitPointsDamage for a T100 (didn't test anything else yet) gives me
there is a ' "" ' where a 'hit_trackr_point' is probably supposed to be
Thank you very much! There was a typo in the named selection. Fixed now.
On 2/24/2018 at 12:15 AM, x3kj said:Too much talking, not enough doing :P
I started my own extended damage system (dealing with critical post penetration effects) starting at end of 2016. Featurelist is almost complete, only few things missing and multiplayer validation needs to be done (folks from IF3 team helped with initial testing and MP compatibility). But we were holding off for a long time, waiting for tank dlc. Seems it will have to be reactivated all now. It only works for purpose build vehicles and configs (requires model adjustement), can't just plug and play. Plus ammo damage and vehicle armor needs to be totally rebalanced because of the annoying "damage spilling through armor" from high hit values. I'm not sure if the latter can be avoided now with the component system. Rebalancing is not an issue for me because i have "total freedom" with my total conversion, but for others trying to integrate vanilla and 3rd party stuff it's problematic and mostly impossible. Maybe the rebalancing can be avoided with components now, but i need answers to the very specific questions i posted to be able to determine the effect and implications of new changes on this system @Asheara .
You can see some of the "critical" effects like fire and ammo explosion in this old video (it's a bit biased towards instant-effects, because i know where the weak points are and the guns dont have dispersion)
Unnecessarily expensive because there is a better way to create penetrating jets, or because HEAT damage is intented to be caused differently? I would prefer a simulated jet over a bunch of radius calculations and hit values ...
Talking expensive - can you give a ballpark figure how much more expensive submunition is compared to a regular projectile (assuming a carrier projectile that spawns a single submunition projectile)?
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-
2
-
3
-
1 hour ago, mondkalb said:Heya @Asheara please consider scalability of the system for community warhead types by adding baseclasses to
class Armor_CAGE class Armor_ERA_Heavy class Armor_ERA_Light
A class Default for these to inherit from.
This way community creators can simply add their own Warhead types to class Default and rest assured that all other Official and Community-Made Armor-Simulations (that inherit correctly from class Default) will have the new Warheads, too.
An easy way to establish compatibility across various mods without requiring explicit compatibility class patching.
A baseclass will make this a lot easier to config-patch, too.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 ;)
-
5
-
3
-
-
16 minutes ago, dragon01 said:Actually, driving a tank off a cliff may kill the crew, but it should cause the tank to explode unless the ammo is not secured properly. I'd suggest that for ammo racks, they should use the RHS solution - "hull" hitpoint would represent ammunition. That way, tanks won't explode from shots to the tracks or to the engine (which is silly).
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.
-
1
-
1
-
3
-
-
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!
-
6
-
4
-
-
14 hours ago, instagoat said:One major problem with A3 vehicle ammunition is ricochets. I have tested the Kuma, Slammer and T-100 extensively, firing from distances of 500 - 2000 meters, and found very odd behaviour when encountering angled surfaces.
Tank rounds need to be -way- less bouncy. What often happens is that the projectile shatters, and the tracer goes flying off while the penetrator in the front of the round continues through the armor.
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.
14 hours ago, SuicideKing said:First of all, tanks a lot for this update! ;-)
Of course, i excitedly checked stuff out, and thus have some initial feedback.
Kamysh + slat cage vs PCML from the side
- The slat armour on the opposite side also gets blown off.
Mora + cage vs PCML from the side
- DIR works intuitively (low damage, cage blown off on one side, no hit point damage)
- TOP works as expected when it comes to overall damage value. however hit point damage is strange - hitting it from the right damages the left track??
Ooops, will need to look into it. Damaging the opposite side is not desirable, thanks for feedback!
13 hours ago, scavenjer said:Right, another round of testing this time using Varsuk:
- HEAT blows up quite a lot of the ERA on the slammer UP (and Varsuk UFP as well) https://imgur.com/a/2GKvW maybe less should blow up at once?
- HE agains blows up all ERA on the entire vehicle even ERA that's on the other side of the tank.
- after the ERA has been blown off, HEAT still does no damage to the side of the slammer UP, and for some reason APFSDS does only 50% damage from the side (90° angle), yet when I tired it on a slammer UP with ERA it one shotted it!.
- Neither HEAT from the Varsuk nor HE seem to destroy the camouflage netting on the Kuma (side shots directly on netting)
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.
13 hours ago, .kju said:can we get docu on CfgArmorSimulations please - or is it essentially hardcoded engine functionality and not extendable anyhow?
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 :)
-
4
-
5
-
Greetings!
Many of you know that in our damage model's current state the calculation of the damage dealt can be quite unpredictable at times. Therefore, we're really happy to announce the new component system, which will significantly reduce this problem and increase the transparency of the damage dealt. Calculating a round's penetration will be much more precise. Furthermore, there are several smaller features to improve Arma 3's quality-of-life for our dear community creators. The intention is to make their job of implementing the damage model easier. We do this by decreasing the amount of variables they had to take into consideration thus far and which often fell under the category of 'black magic'. However, the number one game-changer when it comes to this feature is the simulation of armor types. This involves the ability to create multiple types of protection, which can even react differently to different ammunition types. This opens the door to many new gameplay possibilities, and gives the player the option to select more efficient ammunition against a certain type of armor. And while we ourselves will be using this in a relatively modest way that is still understandable for the majority of players, the possibilities for the community creators are virtually endless.That being said, I'd like to encourage you to give feedback. The numbers are still a prototype and need to be tweaked - after all, thanks to the component system it will work a bit differently.
Things I'd like to bring to your attention are:
- The component system - simulation of AP rounds should be much more accurate, while the spheres are still there for the explosive damage. Passthrough should also work more deterministic than before
- The armor simulations - the vehicles have been given passing protection in form of SLAT and ERA armor, while there are currently three types (SLAT, Light ERA and Heavy ERA), which should have some differences between ammunition (we also have 4 types of ammunition - AP, HE, HEAT and Tandem Heat). We're aware that current configuration is not yet ideal, but we'd appreciate your help in pointing out the issues.
- The damage visuals - compared to previous two it's a minor thing and not a game changer, but I believe that things like destroyed ERA or semi-damaged SLAT would make your Arma immersion a lot better. This should already work correctly in all cases, therefore if you find something which doesn't, let us know!
-
30
-
9
-
On 6/15/2017 at 1:58 AM, pierremgi said:Hi, thank you for this work.
Is there something scheduled for making classes more consistent with the expected return of some commands?
Not easy for me to explain that in English. I remark the assets are coming from different native addons: A3_Data_F, A3_Roads_F, A3_Structures_F....
Some of them are "reserved", others are "public", not saying, you can have them embedded or map in edited.... Nothing wrong as far.
But , just focusing on what we call "building", the vocabulary may also vary: structure, building, house....
The problem is the return values of main commands like nearObjects, nearTerrainObjects, nearestObject, allMissionObjects, nearestBuilding... don't work with the same expected classes (or even no classes at all) of objects.
For example, it's totally absurd that each runway edge lights can be returned as houses. With consequence, the nearestBuilding command is one of the most demanding command for CPU load, when it shouldn't. House and building terms are not enough distinctive.
Other problem: did you ever test how many "type names" ("POWER LINES", "HOSPITAL"..) are truly returning something with nearestTerrainObjects, on your native Arma3 maps (Altis,Stratis,Tanoa) ? Not so much..
I guess a probable heritage of former classes coming from the beginning of Arma. But right now, as far as you want to detect some house (I mean something with door and window and roof) you must test the command/function + the parameters which could give you the expected result... and accept, most of the time, a weird array of unwanted objects, just loading the bark for nuts.
Not sure to be as clear as I would like. Please make the commands / functions more predictable in regard of the expected result: house for house (livable), building for anything in concrete,stone,brick... with a static "urban" destination, lamps for any kind of lamps,... no matter with embedded or edited considerations.
(Please replace the comfort of usage at the core of scripting instead of stacking more and more commands to patch some results).
For Arma IV, perhaps?
Hey,
unfortunately, there's nothing that's going to be done about this. I don't know how precisely is the script implemented, however how this works is bit mysterious and would require a lot of reworking. As you said, perhaps in the future :)On 8/3/2017 at 5:28 PM, panduhh said:I'd like to help the cause but the relevant wiki pages are protected (only Users may edit). The wiki does not appear to have a link to create a new account. I already have a BI account (for the fourums, obviously and for the Store).
Hello,
glad you're interested! Indeed, there's no link, the accounts are created by dwarden. If you'd like to have an account, write an email to dwarden@bistudio.com, to apply for account on community.bistudio.com and give him the desired username :)
Best of luck!-
1
-
-
On 5/31/2017 at 4:32 PM, .kju said:@Asheara great! can you tell the name of the function please
Of course, the function can be found as (BIS_fnc_)exportCfgVehiclesAssetDB :)
The use case of the function in in the comment at the beginning of the function.-
3
-
-
14 hours ago, classic said:I think that it would be wonderfull If there are all the preview images
That's why I'm encouraging everyone to add them, because unfortunately, the script for creating these isn't perfect.
14 hours ago, gibfender said:This looks great - will the new functions be able to output in anything other than wiki markup? I used the old one to maintain a classnames spreadsheet for my groups modset but that involved pasting the output into a wiki page and copy-pasting the table into a spreadsheet.
Well, the function has been primarily designed to put out the wiki markup, I didn't really think about anything else, however... the wiki markup syntax has parts of the code making the header at the beginning and then taking all variables and putting them into the wiki markup at the very end, so it should be easy to modify :) However, if there's any help you'd need with this, let me know.
13 hours ago, hascoman said:Are animations and doors removed?
Yes, they are. As I've been doing sort of overhaul of "features" column i was trying to sift through what was needed, what could be added instead and prevent some features overload (vehicles already have quite a list) and identify what would be more useful things to display. However, as I said, I'm open to feedback - it's community who knows better what do they want or need than I am ;)
12 hours ago, .kju said:Will you release the function to create the wiki markup please. Nice work
Yes, it should be in today's release in devbranch :)
-
2
-
-
Greetings Armaholics,
it is my pleasure to announce that we've have updated the asset database on community wiki - https://community.bistudio.com/wiki/Arma_3_AssetsExcept the part, where it was expanded for Malden DLC and Jets DLC assets, there is also new script to generate the "Objects" part, and it was split to several smaller pages to fit. Object features are now generated automatically.
I'll be happy to hear some feedback, especially if there are other things that the community could use - they can always be added! :)Also, as you see, there are not pictures for everything (and not all might be 100% correct). Therefore I'd like to encourage you to add or update any missing or incorrect pictures. The picture's filename is the object's classname, and it is case sensitive, therefore it might be better to copy the name from the database page itself. Pictures are in jpg format.
Enjoy, and I hope this update will be beneficial to you all.
-
16
-
1
-
-
Greetings,
I've published the documentation on how the dynamic airports are working, so feel free to take a look and (mis)use it for your mods :)
https://community.bistudio.com/wiki/Dynamic_Airport_ConfigurationAlso, if there are any questions regarding the USS Freedom data, how is it assembled etc., fire at will! I'll be happy to help clear any confusion, so you can make the mods even more awesome :)
-
6
-
-
Unfortunately, I am not aware of any engine functionality such as this. :(
I've verified it with our programmers as well, and I certainly wouldn't mind to pimp the damage model to perfection. However, as far as I know it's not engine based, I don't have any parameters for such shinies, must have happened on the scripting level in the mission itself.However, I agree it would be beautiful. There are still some things I'd like to do with these, but... I'm not good with the firebending ;)
-
2
-
-
The guide for Jets hitpoints is finally here! \o/
Good luck and enjoy :)
https://community.bistudio.com/wiki/Arma_3_Jets_Hitpoint_Configuration-
4
-
-
I see no problem in these sources to be used elsewhere, depends on the model, therefore it's difficult for me to give pointers, however - it was used only on Wipeout because it was the only one having airbrakes like that.
Originally, for the ailerons and subsequently the airbrakes were used following engine sources:
- aileron
- aileronT
- aileronB
Those have now also damage variants as written above, because it looked quite strange when you have damaged aileron, but the airbrakes part kept moving as if nothing had happened :D
I am not certain whether this reply was helpful, but... the sources exist, they are defined in the engine, and I see no reason why they couldn't be used elsewhere, it wasn't just exactly needed before :) Both sources written in this or previous posts are available for use, depending which one would be more suitable for you.
For the gear - no, there is no HitGear hitpoint at all. What is seen in the game as separate hitpoint category and possibility of damaging them is fully handled by the engine. I would compare it a bit to the lights - they are also not in the Hitpoints subclass.
I'm not certain how you have it configured, and whether it works, depending whether you have the physX wheels implemented on your plane.-
4
-
Dear hitpoints enthusiasts,
I'm bringing you an update! I've been trying to balance some hitpoint values as I've promised earlier. They'll be coming with the next devbranch, and for now, affecting following planes:
- Wipeout (Plane_CAS_01)
- Neophron (Plane_CAS_02)
- Buzzard (Plane_Fighter_03)
The hull shouldn't be as weak as were the objections before, however I'll be happy for more feedback.
Remaining planes should be COMING SOON(tm). Next ones I'll focus on are the fighter jets coming with the DLC, Black Wasp, Shikra and Gryphon, so it can be tested all together, but please have patience with me :)
On 4/23/2017 at 0:55 AM, hcpookie said:Is there any directive or BIKI article describing the model needs for hitpoints? Should I presume they are similar to other hitpoints in that it needs:
- model.cfg section- hit-points LOD selection
- any visual LOD / shadow LOD selection
Does it need a matching selection in FireGEO?
Does it need definition in config.cpp class HitPoints?Hello,
there is one article about hitpoints, https://community.bistudio.com/wiki/Arma_3_Damage_Description, however, this one won't be that helpful I'm afraid :)
I've been tasked with creating such documentation for community (especially for Jets edition) and I'm really sorry that it's not yet done, seeing you've got the content to be seen in devbranch already. So I'll try to shed as much light as I can here, feel free to ask any questions.Yes, they work the same as other hitpoints. Meaning, they need:
- selections in hitpoint LOD ("name" parameter in config)
- selections in visual LODs ("visual" parameter in config)
- names of selections in visual LODs in model.cfg sections
- HitPoints class in config.cpp
- change some of the animation sources
- no, selection in FireGeometry is not necessary
There are several hitpoint class names, which are supported by the engine and are used in the plane upgrades. Some of them have specific naming for the gameplay features.
- HitHull
- HitEngine
- HitEngine2
- HitFuel
- HitFuel2
- HitAvionics
- HitLAileron
- HitRAileron
- HitLCRudder
- HitRRudder
- HitLCElevator
- HitRElevator
With HitAvionics, you'll need to make the animation for turning off the screen.
With any flight controls, you'll need to change some of the animation sources to the damage version. New engine sources for these purpose are following:
- aileronLeftDamaged
- aileronRightDamaged
- aileronTLeftDamaged
- aileronBLeftDamaged
- aileronTRightDamaged
- aileronBRightDamaged
- rudderLeftCenterDamaged
- rudderRightDamaged
- elevatorLeftCenterDamaged
- elevatorRightDamaged
Note: AileronT and AileronB sources were used only for Wipeout for the air brakes, as they are on the ailerons
Once I'll have the documentation ready, I'll post the link here, but having my hands full right now, I'm sorry once again :)
-
11
Tanks - Damage improvements
in ARMA 3 - DEVELOPMENT BRANCH
Posted
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)
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!