Jump to content


  • Content count

  • Joined

  • Last visited

  • Medals

  • Medals

Community Reputation

1131 Excellent

About x3kj

  • Rank
    Warrant Officer

Profile Information

  • Gender
    Not Telling
  1. Funny & interesting videos

    Sherp offroad adventure - cool scenes
  2. https://community.bistudio.com/wiki/LOD 4-6 resolution lods (for larger objects) 2 shadow lod several collision lods
  3. Large Static Models

    Is that your geometry LOD you shown there in the resolution LOD? If yes, you should optimize it. If geometry LOD looks beautifull it is a bad LOD - it must be as simple as possible. The railing is way too detailed, also the "mushrooms". Put that in the fireGeo if you really must (but reduce railing to 3 or 4 edgesat most around the circumference ). In geo LOD such detail does not belong, there is no point having a "round rail" in there. It gives no benefit for collision with humans or vehicles, but it costs more performance. The mushrooms should be simple cubes (if at all) for example. For PhysX LOD you should propably even delete all the vertical pieces of the rails (it gets rid of a huge amount of componentXX's that need to be checked for collision), because they have minimal effect.
  4. you can always write yourself a max script to generate a model.cfg ... if you learn max script first...
  5. Days without connection to the outside world can also be beneficial sometimes... i got pretty far with figuring out the first and smallest wall system type (which would used for small outposts/ bases). Still WIP obviously (esp. the vehicle firing element) and incomplete (e.g. there are no cornerpieces yet). The wall has regular parapet like 'ordinary' walls, but also integrated trench for protection during bombardments. 95% are already textured with the pillbox texture shown previously - pretty good mileage out of one texture i say. For 40k setting the merger with the trench made the most sense to me. Without it the troops would be super exposed to shells that fly over the wall and explode in the back. Plus when something manages to flank fire the wall soldiers have a chance of survival
  6. Why would it make sense? It simply doesn't. You can only use bipods in the right situation, when the terrain permits. You cant use it all the time, especially not when firing high into the air. So why should Arma always give bipod bonus when in prone? Auto deployment is impractical. Bipods have movement limits and different rotation points than regular movement. Extend the limits where you get weapon resting bonus is a better compromise here. I agree with @da12thMonkey Downward firing is what is the problem of the bipod ingame. In prone, but also in the other stances. In many cases players are at a disadvantage when they are standing on a plateau that is higher than the enemy is at, since they cant use bipods. This is completely the opposite to real life. IRL enemy can't use bipods in prone or low stances on lower ground against enemies higher up. They always need an object to rest bipod on to be able to aim up. IRL, in prone and semi crouch to crouch there is always a way to fire over the edge of a mountain or plateau using bipods. (provided it is straight and not sloped downwards). You can kneel and deploy your weapon bipod on the ground to fire downwards at big negative angle IRL. In arma you are limited to prone deployment. Making firing upwards easier with bipod seems illogical. It should be the opposite direction that is "relaxed" in its limitations. Advantages and disadvantages from terrain slopes and height difference needs to be considered in real battle and that should be mirrored as good as possible in Arma. Otherwise we might as well revise the game concepts... from King of the Hill to King of the Valley...
  7. [CTI,TvT,CooP] Dissension

    Maybe it's a bit expensive to check, but maybe another solution for spawning AI of towns (i use town for simplification here, but it could be any capture location) could be dynamic based on proximity of enemy units (those that trigger spawning), so that they don't spawn behind the intruders and also not directly next to them. A spawning-safezone sector (like the piece of a pie, going from the capture enter) around intruders basically, . Another possible alternative: Deploy a couple of military buildings in and around the town/location. Each of those buildings units can spawn inside and then walk out. That means it will not be entirely unexpected where they appear from and they won't just pop in in plain sight. On the outskirts there could be tents or some other smaller building. The closer you get to the center of capture, the larger the military building could be. And the more units could be expected to exit from there. This also provides the opportunity to stagger the spawning, so that new units can spawn mid town-battle for the AI town defenders to replenish their numbers - ideally in a location that is least contested of course. If the buildings cant be looked inside of, nobody will notice someone spawning in it, unless they are in the building themself. That said, it needs to be possible to disable a building from spawning entirely (e.g. capture, or maybe also destruction from inside via explosion charges or something like that). Otherwise attackers still have to worry about units spawning from the place they already cleared, once they get further away on their mission to clear the town. Maybe another idea is to reduce number of AI per town slightly, but send instead one or two groups of reinforcement from another location via transport (just one or two - not more). Number and type of reinforcement could depend on size of town that sends it. this is a good idea. 2 Man patrols - not for the purpose of killing the enemy. They just need to discover an enemy and alert the stationed defenders attacking team. The attacking team is a larger team, which responds to things the patrol spotted (or got killed by). This is also pretty realistic i think. Static overwatches + a few patrols to control and close the gap in static overwatch (and be less predictable than static overwatches) + mobile combat teams at the ready to respond. The combat team can then spawn in in case of need (again, maybe inside a baracks building or something like that).
  8. arma3 is so sick

    We have no time for stupid rant posts in the development forum. State your problem or question objectively in the right place (Arma Editing) , civilized, without ranting, and people will help if they can.
  9. To repeat my question again - Whats the purpose of those selections for tankX? Is it still important? First time it was introduced way back when, i think it was to help with climbing ability - which now technically is not necessary (propably?) because there is fake acceleration helper force. What can we expect from these selections in terms of function and behaviour and what do we need to keep in mind when modelling the components? Are there specific things to avoid there?
  10. @kllrt please dont forget to update A3 sample models with the head changes
  11. Documentaries Chernobyl 1986

    Channel that has several recordings inside sarcophagus https://www.youtube.com/channel/UC0bOfQEN80hIbdEECDwLyJw/videos
  12. Photogrammetry

    better is the wrong word. It's the only option available - with the limitations i mentioned.
  13. Photogrammetry

    I have the impression that this is unfit for any detail, using a pure photogrammetry setup. Yes you can get the scale and basic shape and all well, but the actual detail (those that matter) will not transfer across properly using low grade setups. So you will end up having to build an entirely new model on top of it, LP and HP by hand and remodel all the detail, because thats actually easier and has better results than trying to repair/transform the scan data into something you can use. It's mostly used for props in the industry - which makes sense. Nobody will want to waste their time modelling a dozends of objects to assemble a virtaul heap of garbage for example - so they scan it in, bake it down into LP/texture - great. "Hero assets" (weapons, vehicles, characters) generally not scanned - at least not with low-end capturing equipment and software. Definitely has it's uses, and worth trying for yourself, but dont expect too much from it. The actual high grade stuff uses laser scanners to get the surface detail properly, and combines that with photos to overlay them for the texture. There are compact hand aparatii that can do this (seen at a tech convention 2 years ago) but i dont remember what their price was back then.
  14. AI Driving - Feedback topic

    I agree with pierremgi, blaming assets is not fair (because with current DLC model, which imo is the most consumer friendly in the industry, assets are the only reason to buy a DLC - which also support development) Thats one of the most core issues with this hole thing imo. Nobody other than devs can do something about the problem, because it's all inaccessible and there is no way to override driving behaviours efficiently with custom logic. The script commands (like doMove etc) are insufficient for dealing with this. I'm expecting/hoping for improvements in future games in regards for AI driving. But i'm also hoping of improvements in accessability of that logic from the outside. Eventhandlers for stuff related to driving routines for example - detected obstacle, or detected crash, change of move order, etc . And also for 2 distinct ways of exerting controll over AI externally in scripts - "by command" (like it is now with commands "fire at thing X", "move to pos Y") and "direct" (which forcibly interrupts the logic chain in order to be able to do a specific thing exactly and precisely by simulating player inputs. Like pressing the key to move forward for an exact amount of time. ). Right now we have no direct control over AI driving actions (increase throttle, stop, steer left/right etc). It can be done somewhat on command level - which breaks in certain circumstances. E.g. you can order tanks via https://community.bistudio.com/wiki/sendSimpleCommand but such commands are only accepted in special conditions - namely when AI subordinate follows the owning player. Not when it is told to stop or is told to move somewhere by the player. I have been running into this problem when trying to get AI to turn into a specific direction in my attempt at a custom artillery script (https://www.youtube.com/watch?v=uKGzWkKDwdY).
  15. HUZZAH! I had already written it off as forever broken ... today is a great day