Jump to content


  • Content Count

  • Joined

  • Last visited

  • Medals

  • Medals

Community Reputation

1240 Excellent

About x3kj

  • Rank
    Warrant Officer

Profile Information

  • Gender
    Not Telling

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. I dont understand what you are trying to say here, i dont think you understood what i was suggesting. How many bones and animations do you actually use per blade ? If i needed to make blades bend downward from gravity/lift, i need exactly 1 bone and 1 animation. Not per blade, but for all blades together. No matter how many blades. If you need more, then you are not doing what i suggested to you. At 120rpm you cant see individual blades anyway IRL. Thats why most people replace modelled blades at higher rotation speed with a blurry texture representation that rotates a lot slower, saving performance
  2. Yes bone limit should be 255 or so. You cant go above it. To me it looks like you have many unnecessary bones and animations. No its not possible to make nonlinear deformation via model.cfg. However - you can do nonlinear deformation by "weighting" to bones - the same method that is used in characters. So you can make a bone move by 100% the distance of a translation. And another point moves only 50% as far as the bone moves, if it is weighted 0.5 to that bone . That means for all blades you can get by with just 1 bone. What program do you model in?
  3. LemonBrosGaming wrote on discord to this question:
  4. Note that VR map Lighting makes everything look extra shiny, way more than what you will see on Altis Lighting for example. Tuning shinyness to look good on VR map isnt a good idea.
  5. Check your UV's if every piece is unwrapped properly (and make sure the vertices of a face are not all in the same position inside the UV) BTW this issue will not prevent you from loading the model ingame for testing (just saying) - but it should be fixed regardless to prevent error spam in log files.
  6. no, not possible (at least at present). Workarounds can be used (by creating additional config turrets without stabilisation and scripts to swap between turrets and lock them), but its not as easy.
  7. does the iskander actually behave like normal artillery / is fired by player using normal firing controls? Or ar there actions you have to click as player? doArtilleryFire probably only works if the unit actually can fire via ballistic computer, and has the required config paramters to be able to be used like that (i think it was something along the lines of "artillerysupport = 1" or "availableForFireSupport" or something like that...). If its fired otherwise (e.g. by an action or some custom ui dialog), then you need to find out in config what actions are used for firing and what scripts they perform. Then call those scripts manually.
  8. bug i've encountered with disabling FFV firing via https://community.bistudio.com/wiki/enablePersonTurret - looks like camera doesnt accept the defined animations when FFV is disabled and can then show in the wrong direction or uses the wrong movement limits https://feedback.bistudio.com/T155901
  9. Just something we collectively found out in A3 discord editing section. Dunno if you already have stuff comment on this, havent checked everything. If an AI is squadleader, disembarking AI units via any script command from vehicle (including static weapons) always leads to them walking ~10m away from vehicle before continuing any other orders (Distance depends on vehicle size). This can lead to problems if the vehicle is inside / on top of a building (as it may want to walk outside the building first) or in a tight space. Only exception is moveOut script command - then they wont walk 10m away. But with moveOut specific character animations are not played (e.g. not plane getout animation, but generic "getoutHigh/Low/Medium" are played) and vehicleDoors dont animate if the animation exists. You can break the "walk 10m away" issue on AI squadleaders by eventhandlers on vehicle (thanks to Leopard20 for solution). Add to init field of vehicle in question. this addEventHandler ["GetOut", { params ["_veh", "", "_unit"]; if (!isPlayer _unit) then { _unit addEventHandler ["AnimStateChanged", { params ["_unit", "_anim"]; if (_anim select [0,4] == "amov") then { _unit playActionNow "STOP"; [_unit] joinSilent group _unit; doStop _unit; _unit removeEventHandler ["AnimStateChanged", _thisEventHandler]; }; }]; }; }]; If you are player squadleading AI, using > unit action ["eject",vehicle unit]< will not lead to them walking 10m away. Another peculiarity - pilots under player command sometimes cant execute an eject action. Another peculiarity - cargo passengers (that are not personturrets) will not be targeted at by enemies, even if the rest of the crew are vulnerable by config. Only the vehicle (e.g. an open transport truck) may be targeted by grenades/RPG, and the driver will be shot at with rifles. As soon as the cargo exits, they will be fired upon of course.
  10. Note that the size limit is only in width, not in height. I've been brainstorming and musing with ideas of a large city map myself over the years, prototyping with ideas/ designs (relating to my total conversion). My opinion/conclusion is that a great variety in verticality (meaning - different height levels that you can actually access gameplay wise) makes for much more interesting gameplay, than just rows and rows of housing blocks. To achieve this is a challenge however - and imo is strongly tied to custom building models. Complete access to a buildings interior may be sacrifised for better performance / to have more buildings. E.g. only the 2 bottom floors, maybe 1-2 parts in the middle and the roof being accessable on certain buildings that have great height. Also, if every floor of a building could be accessed, the map's play area would be so large that for the small conflicts we can only play it becomes too large (~100 infantry, maybe <200 with AI for really strong server/ robust headless client setup) . free space - well depends entirely on how "megacity like" he wants it to feel. If he wants realistic immitation of a realworld city - yeah, some space would make sense. If it should feel very crowded the leaving a lot of space would not be good. However, the crossing between different onces can be done by fences - and having not just the building itself be fenced, but also include storage areas (that have material storages/ clutter / containers or stuff like that) which provide a bit of "free air" between the walls of the buildings - if that makes sense. Canals are awesome, but achieving them ingame comes with cost of covering large areas with large concrete blocks, where AI cant walk freely on - as you have to lower the actual terrain for the canals. Making extremely steep terrain drops can lead to glitches (character dies when walking on a building on to of that terrain drop), thats why you need large blocks that cover the sides of the canals - which come with their own problems (such as AI vehicles not being able to traverse them properly). Best way propably is to use houses as canal boundaries instead of streets. Best way to justify very tightly packed buildings is by having the city surrounded by large walls (that is, if you are fine with fictional, non-contemporary city design). Medieval cities where also extremely packed, because everything outside the walls was vulnerable. Walls also aid as perfect line of sight blockers (geometric occluders) to the outside/inside of the city, at least when you are on ground level - which should aid performance, esp. if the city becomes really big. Multiple sectors could be divided by walls.
  11. i encountered the same issue yesterday evening. I'll let you know, should i find the solution before someone else does. (Not particularly likely though... someone hijacked my PC and secretly installed Cyberpunk2077 :D ...)
  12. Apologies, then i was simply out of date. Didnt check wiki since i made that ticket.
  13. it was never documented... but i can understand - its not so important in the grand scheme anyhow
  14. There it is https://feedback.bistudio.com/T154411 i'm going to use this opportunity to throw my older tickets regarding weapons at at the wall, in the hope that something sticks 1) Bug - model of "shotShell" simulation projectiles is not displayed for initspeeds> 330m/s . See 1st part of this ticket https://feedback.bistudio.com/T125167 shotBullet is no alternative, as model does not update orientation with current projectile vector. Rockets display correctly but are less than ideal because of weird ballistics and require submunition for penetrations. 2) Explosive hit propability feature to tone down unrealistic artillery lethality - https://feedback.bistudio.com/T116969 (part of "the big bad four" issues in damage modeling https://feedback.bistudio.com/T120542), Dslyecxi agrees btw 3) Feature to support weapon systems with multiple synchronized/ alternating fire , and/or high burst rpm but low mag capacity - https://feedback.bistudio.com/T123542 currently only possible with using lots of magazines (which leads to problems in performance or AI (cant remember) - reyhard alluded to this) 4) Feature for variable Ammo per Magazine (mixed ammo belts) https://feedback.bistudio.com/T82246 5) Bug - Explosive shells can explode multiple times, when deflecting of something -> suggestion to prevent explosion in case of deflection. Other nice to have's included. https://feedback.bistudio.com/T82243 6) Optimization (maybe) - handleDamage EH fires for every hitpoint of the vehicle instead of just damaged hitpoints https://feedback.bistudio.com/T124814
  15. Amusement park? In a Mega City? Sounds way too utopian for my liking 😄 Nono, we no space for pleasentries in Dystopia Prime - must cram everything with hab blocks and corporate buildings and fill the gaps with slums and garbage Looking forward to it, i'm most curious how it will run and how AI suitable it will turn out.