x3kj

For making structures and also maps, that work well ingame it's important to know what metrics the infantry has, what it can navigate and so on. Today i made some tests with following results: Wall heigth: 50cm - look over:"high prone", shootover: "high prone", totally covered: "regular prone" 80cm - look over:"regular crouch", shootover:"regular crouch", totally covered:"high prone" (the sitting animation). Bipod deployable. 110cm - look over:"high crouch", shootover:"high crouch", totally covered:"low crouch". Bipod deployable. 130cm - look over:"low stand", shootover:"regular stand", totally covered:"high crouch". Bipod deployable. 145cm - look over:"stand", shootover:"high stand", totally covered:"high crouch". Bipod deployable. the heigths listed here are the VR Obstacle objects, you can use them as reference totally covered and shoot over depends on what heigth the target is at. I used Infantry targets at same heigth (flat VR map) at 100m as reference for this. Ceiling/ Gap heigth (e.g. in a fence, wall, door frame or room height) 20cm - can shoot below in "low prone", enemy feet past 50m barely hittable 50cm - minimum for moving through in prone 110cm - minimum for moving through in crouch, BUT bad clipping with head. Better use 120cm 170cm - minimum for moveing through in standing, BUT bad clipping with head. Better use 180cm (no clipping, even in high stand) Corridor Width: 90cm - minimum width for walking through. Turning in "regular stand" and "regular crouch" is possible but very twitchy (due to wall collisions of the weapon). Better use 100cm. Crouched turning causes head to clip through wall 130cm - minimum for turning in "low crouch" and "high crouch" (but twitchy). Better use 140cm. 170cm - minimum for turning in "regular prone", but twitchy (only is gone at 200cm). No "high prone" or "low prone" turning possible. 200cm - minimum for turning in "high prone" and "low prone" , no twitching. Corridor Width - walking past another standing soldier close to the wall, both facing along the corridor: 150cm - only using "step" function - pretty glitchy. 160cm - only using "step" but only 1 step required 180cm - passing without "step" possible. note that depending on orientation and stance of both soldiers, it may be easier or harder to pass When 2 seperate buildings/objects walls are 180cm apart from each other, the AI seems to be able to navigate this corridor (better use 2m in this case though). For interior of buildings (with paths LOD and roadway LOD) smaller corridors are no issue for AI, because they can walk through Geometry when on a path The tests where conducted with the 1x1x1m VR Block, and the 10x5x4m VR Block. So if their geometry doesnt properly match these results are slightly sqewed. Edit: It seems that for the VR Block skews the results a little bit (or the crouched stance got increased geometry model in some patch). I was not able to turn 360° in a gap of 1m in regular crouched stance inside a building. 1.1meter is fine however. Weapon Deployment Limits: You can definitely deploy weapons between 0.8m heigth (maybe even lower) and 1.45 meter heigth (maybe even higher). You need minimum clearance for the muzzle when deployed. Imagine you place a 130cm tall "resting block" in front of a 2m tall wall and you try to deploy the weapon on the resting block, facing in the direction of the wall. You will only be able to deploy if the space between restingblock and wall is somewhere between 35cm and 40cm (37.5cm worked in my case). Of note here is that this space needs to be in the firegeometry LOD, normal geometry LOD does not affect this particular case. Walkable Slope: Slope angle on Roadway LOD to be still walkable up to 50° from horizontal - no problem getting on the slope and walking on it at least up to 65° from horizontal (possibly steeper, test stopped at 65°) - can walk on the slope itself, but difficulty getting on it from horizontal level. Without using "step over" key (or glitching/walking diagonal) it's not possible to get on the slope from a horizontal place, when standing at the bottom. Generally avoid steep slopes where possible, because infantry are "turboboosted" when walking up or down (looks real goofy), as their walking speed is constant and referenced to the horizontal plane. Feel free to contribute 🙂

Hey guys, does anybody know of a way to rotate a tank on the spot by AI commands? (not by using any setdir or similar command) I'm trying to get self propelled with limited traverse angle to work, so i need the driver to adjust orientation when gun traverse limit is reached

Samarsk Uprising - An unofficial Warhammer 40k Modification for Arma 3 This mod is 100% fan-made, unofficial and strictly non-profit. The mod is neither associated to, nor endorsed by Games Workshop. All assets you see originate either from Arma 3 directly or where made completely from scratch by the creators of this mod. What is Samarsk Uprising? It is an unofficial, fan made, total conversion (TC) project set in the SciFi Universe of Warhammer 40.000. It is a project X3KJ started in earnest about 3 years ago, though some precursor work dates back 5 years. The purpose of this project is to portray a particular made-up conflict (the Samarsk Uprising) between soldiers of the Imperium and Chaos Renegades in the 40k Universe in the most believable (IRL and "in universe") and immersive way possible. At the same time, staying true to the established lore and design as close as possible is of paramount importance. Where did the inspiration come from? X3KJ: "As a long time 40k fan and collector (half of my life at present to be precise) and modder i always wanted to do a game mod for it eventually. When i played the Arma 2 warfare game mode the first time i knew exactly that this was the perfect environment for such a project. I’ve read various Black Library novels and a couple of Forgeworld campaign books along the way. The attention to detail in these is incredible, something that official 40k games and unofficial mods have not yet been able to capture in any way. With this project I aim to do precisely this - capture the detail you could expect from a good novel/ short story/ movie inside a real scale environment. This does mean however, that the scope that the mod can cover is limited." What is the currently planned scope of the Project? Instead of a generic “40k mod”, this TC will deal with one particular conflict, the Samarsk Uprising on a mining world in 544.M41. It is an invented conflict, to not step on the toes of official background and to have some creative liberties. The plot (which hasn’t been developed very much atm., but will be refined and iterated as the project goes) has the purpose to provide immersion, context and stronger inspiration for the people working on this project - and maybe also for players themself. The conflict is between the Imperium of Man and the Chaos Renegades, with the planetary defense forces in the middle of it. Xenos (“alien races”) involvement prior to completion of the current scope is not planned - it would result in less productivity when resources are spread thin. Also, it's a nice break from the "standard 40k video game plots" which repeatedly end in some cesspool of a plot where they try to sell us that 4+ races/factions all are after the same thing on this single planet in the universe. This is not a mod that tries to gobble up all that somehow represents 40k by all means possible. A good, highly detailed and consistent standard of quality is the goal. Also, the gameplay will not be simplified or “arcade-ified” over vanilla Arma 3. Quite the opposite is the case - when it becomes necessary/ makes sense, certain areas will be made more detailed and refined compared to vanilla, without making it cumbersome or difficult to use however. What is the status of the project? When attemtping to work on such a project in a team it is important to establish guidelines of how things look, feel, function etc. This is crucial, otherwise (talking from experience) there will be no consistency and many discussions will surface about trivial things - which mostly just produce nothing but hot air. Finding a common denominator is very difficult, especially when a scifi IP which has never really payed attention to finer details, is transformed into something more realistic. Ask 10 fans about how 40k should be like in (somewhat) realistic terms. You will get 10 different answers. For this reason i (X3KJ) have worked for about 3.5 years on models alone, figuring out how things could be made functional and which direction would be feasible given the circumstances (limited time, Arma engine). A lot of work has gone into figuring out how to make the models more realistic and sensible, without compromising their original look or feel too much. If you want to read up on some of the details/ progress of this work you can glimpse at the warseer log Various playable assetts (tanks, hand weapons, imperial guard uniform,...) are the result of this work, including many more WIP models. Now, with the foundation established (by example, not by word) the playable content needs to be refined and extended to get at least two player factions together. Effects need to be created (visual and audio) and the environment needs to be designed and created, which includes structures, prop models, and a map. Furthermore we are looking to add gameplay features which complement the 40k setting and create new solutions to get around certain restrictions of Arma. How can you help? This project isn’t possible to bring to a releasable state without additional manpower. Therefore we are looking for people who like the direction this project is going (we would suggest reading through the log) and can lend a hand. So if you are a content creator and interested, contact us, or come join the discord channel. There is a need for about anything one can think of: Terrain makers, Modellers, Texture Artists, Concept Artists, Scripters, Config Coders, Audio Artists, VFX Artists, Animators, Mission Makers, Writers, etc. You don’t need to be a professional, but a certain minimum experience in your chosen field(s) is necessary, as we don’t have the manpower/time to teach you from the ground up (yet?). We also have a need for a data server (e.g. a SVN or Git repository). If you can help with providing one and/or administrating/ setting one up, it would be most appreciated. Please don’t ask being alpha/ play tester, unless you can also work with configs to help fix or implement things yourself. We will announce when we need dedicated testers. There is no que or reserve slot for beeing play tester either. When will this be released? We asked our crystal ball, but it engaged self-destruction - simply put: Impossible to tell right now. We are always excited when we can show new stuff, so you can be sure to hear about it when there will be a timeframe for a release. Until that is the case, please be patient. Some may wonder if this will fail like the other 2+ attempts of other groups at a W40k mod for A3. Who knows, we are not farseers. However, this idea isn’t just a brainfart from yesterday, and we know from experience how demanding and challenging a total conversion is. X3KJ for example worked 5 years on modding X3:Terran Conflict, 3.5 years of that on the "X-Tended: Terran Conflict" total conversion. Current Team: X3KJ - Models, textures, animations, configs, stupid ideas and everything else recent volunteers: Genghis Steve - Models, textures, configs nightovizard - Maps Testarossa - Models, textures ComatoseBadger - Models, textures Dedmen - Scripts, models, textures Ranger - textures, map work RichardsD - models, textures ex developer/contributors: MartinezFG11 - Models, textures, configs, anims (Binoculars, Brockers Stubber) Zephyrsouza - Models (HP Model for Tanker+Sergeant Hat) Special Thanks Hatchet, Kiory, Mikero, reyhard, Pufu and all the other helpful folks on BIF and discord creator channels. The Arma WW2/ IFA 3 project team for scripting advise and support on MP compatibility of the extended damage system for vehicles. All 40k Lexicanum Wiki contributors BIS for this great platform and the continuing updates Everyone who provided moral support =) .. to be continued .. Visit our discord channel: Visit our Mod DB page:

Substance (designer and also painter) have options to bake lighting into the textures too (can look much better than just applying ambient occlusion and curvature, especially for shiny metal), but its tricky to find a good lighting setting and environment map that doesnt overdo it and still looks somewhat believable when only lit indirectly.

I reuploaded it

https://community.bistudio.com/wiki/Section_Count unwanted sections can happen a lot when adding parts to a p3d or during copy paste inside p3d.

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

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?

LemonBrosGaming wrote on discord to this question:

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.

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.

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.

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.

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

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.

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.

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 ...)

Found this patent text mentioned on the web somewhere: "HIGH FREQUENCY GRAVITATIONAL WAVE GENERATOR" I have no idea if it is legit... at least the amount of patent-lingo-bullshit checks out 😄 Its very intriguing, seeing they made videos of "flying tic tac" public not too long ago. (for reference https://www.youtube.com/watch?v=tf1uLwUTDA0 ), there have also been claims of a navy contractor to have witnessed the observation of "USO" (unidentified submarine object) onboard a submarine that move way too fast to be of any known.vessel (https://www.youtube.com/watch?v=PcDwHxTbGTk ). The observations match the movement abilities that are adressed by the patent(s) as being possible due to some vacuum generated around the vessel, which allows it to pass trough any medium without resistance. With trillions of $ disappearing in government funding i wouldnt be shocked if they are trying to build a fleet of these "ufo". here are other patents with us navy as assignee (with the purpose of license-free manufacturing and usage of vessels using those inventions) https://patents.google.com/patent/US10144532B2 Craft using an inertial mass reduction device https://patents.google.com/patent/US20180229864A1 Plasma Compression Fusion Device https://patents.google.com/patent/US20190058105A1 Piezoelectricity-induced Room Temperature Superconductor edit: i found some site that gives info on the inventor listed for those patents https://hyperspace.engineer/ edit2: (note, i would disregard all of the other patents from other authors on that site... they just seem like gibberish rubbish)

Apologies, then i was simply out of date. Didnt check wiki since i made that ticket.

it was never documented... but i can understand - its not so important in the grand scheme anyhow

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

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.

whooho update 👌 @Dedmen @killzone_kid Would it be possible to add 2 more script commands that do the same for turret elevation and traverse? Because right now (unless i missed something) you cant directly influence turret/gun orientation via scripts on non UGV turrets - but it would be super useful to have for fire control systems, or the "simple" feature where a gun (e.g. artillery) has to elevate to horizontal before reloading and then back again... Or custom turret damage (e.g. gun being stuck in last position, rather than the "sad barrel" feature) Yes one can do some dirty tricks with piling animations on top of each other in the model as workarounds, but it gets complicated and dirty (hiding/unhiding copies of the turrets just so you can remove user inputs etc, including turret indicators etc).

Have you created a bug report on the feedbag site ? You can attach missions there https://feedback.bistudio.com/project/view/1/

vehicle driving in a curve ("banana"), even when you are not steering (esp. pronounced at low speeds)