Jump to content


  • Content Count

  • Joined

  • Last visited

  • Medals

  • Medals

Everything posted by x3kj

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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
  6. 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.
  7. 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.
  8. 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 ...)
  9. 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)
  10. Apologies, then i was simply out of date. Didnt check wiki since i made that ticket.
  11. it was never documented... but i can understand - its not so important in the grand scheme anyhow
  12. 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
  13. 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.
  14. 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).
  15. x3kj

    AI Discussion (dev branch)

    Have you created a bug report on the feedbag site ? You can attach missions there https://feedback.bistudio.com/project/view/1/
  16. vehicle driving in a curve ("banana"), even when you are not steering (esp. pronounced at low speeds)
  17. The config parameters latStiffX, latStiffY and longitudinalStiffnessPerUnitGravity can lead to this. Their purpose is a bit hard to explain, to tell the truth I recommend reading nvidias "programmers" tuning guide for physx vehicles - its not 100% identical to BI's stuff but lets say 95% - the names are also not matching 1:1 but you should get the idea https://docs.nvidia.com/gameworks/content/gameworkslibrary/physx/guide/3.3.4/Manual/Vehicles.html#tuning-guide frictionVsSlipGraph array can also be cause of this (if defined) / can mitigate it somewhat, but can have unintended sideffects ("banana drive bug")
  18. 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:
  19. x3kj

    Flight instruments?

    you dont find anything because animating cockpit instruments is exactly the same as animating flaps or rudder. You simply define the animation in model.cfg (e.g. a rotation), give it an axis in the model via memory point (e.g. the center of a dial), and assign a selection in view pilot LOD (e.g. the indicator on a dial). Then you select an appropriate animation source that drives the animation, and done.
  20. Another Head Gear Concept, Plasmalauncher WIP
  21. fantastic, much appreciated
  22. Idk if it's of use to anyone, but i made a python script to convert greyscale images to .asc format for importing into terrain builder. I use it to convert 16bit .tif images out of substance designer to .asc, because L3DT and TB dont like the format that much / require manual twiddling everytime You can also try other image formats (the library supports a plethora of other formats) - just change myheightmap.tif to myheightmap.png or whatever. I have only tested it for my particular use case however and i'm no expert on that library or python in general (in fact, this is my first ever python script). How to execute? If you are a dummy like me and dont know how to Python or sudo - install anaconda distribution, it has all the necessary libraries, then launch spyder tool (that comes with it) and open the file, then run it with F5. Yes it's overkill but its single click... edit the user inputs as applicable to your use case Notes: Sea level is 0 meter min/max elevation are the 0% and 100% grey value in the image format. It doesnt auto-level the image. Image resolution doesnt have to be square or 2^n - wether TB or other tools like it or not i have no idea Conversion on 4k maps takes a while (wait until "###Conversion done###" appears in the console) use at own risk... import numpy as np from pathlib import Path import imageio as io ### user inputs ### filepath = Path("""P:/myheightmap.tif""") outputpath = Path ("""P:/output.asc""") #attention - any existing file with same name is overwritten hmax = 1000.0 #Input max Elevation (in meter) hmin = -200.0 #Input min Elevation (in meter) twidth = 2000.0 #Input mapsize (width in meter) limit = 2**16 #max grey value of file (16bit-> 2**16, 8bit-> 2**8) ########## load image ################ arr = io.imread(filepath) arr = np.array(arr, np.float32) adim = arr.shape # dimension of array - returns [Height, Width] cellsize = float(adim[1]/twidth) print ('Image Resolution:'+str(arr.shape)+' Cellsize:'+str(cellsize)) ########## write to file ################ file = open(outputpath,'wt') # wt - write mode, text mode. Overwrites any existing file ###file header file.write('ncols '+str(adim[1])+'\n') file.write('nrows '+str(adim[0])+'\n') file.write('xllcorner 200000.0\n') file.write('yllcorner 0.000000\n') file.write('cellsize '+str(cellsize)+'\n') file.write('NODATA_value -9999\n') ###body for y in range (0, adim[0]): # -1 is not necessary because in case adim[0]= 3 then range is [0,1,2] -> 3 is not in the range line =str() # empty string for x in range (0, adim[1]): arr[y,x] = round (hmin + (arr[y,x] / limit) * (hmax - hmin), 2) # note: numpy arrays are [y,x] whereas default python is [y][x] line+='{:.2f}'.format( arr[y,x] ) #format string to show 2 decimals if (x < adim[1]-1): line+=' ' line+='\n' file.write(line) ## file end file.close() print ('### CONVERSION DONE ###') Cheers, X3KJ
  23. The description for this situation is "intersecting geometry". If the angle between the plates that penetrate each other is 90° its usually no problem. If the angle is small however, z-fighting (flickering) can occur at the edge
  24. x3kj

    AI Discussion (dev branch)

    Found a player exploit, to stop AI from reacting to shots ... please have a look at it https://feedback.bistudio.com/T149579
  25. Yes infantry damage system is just damage - means extra hitpoints, hit / armor are the most relevant. Soldiers have very similar firegeometry (basically just parts that are meat material, or meat+bones material etc) - and armor does not influence the fire geometry. Therefore caliber is mostly irrelevant - EXCEPT when the caliber is sufficient to completely penetrate (see Case A in Damage vs. Penetration in the damage description) - in which case the described reduction of damage is observed. Pass through is for global armor (global health). If global health is 0, the vehicle/soldier dies. Contribution of individual hitpoints to global armor is determined by passthrough of the soldier hitpoint config, modified by passthrough of the armor. Problem is - it is highly unpredictable what happens due to the combination of issues. See direct damage description in https://feedback.bistudio.com/T120542 Based on my tests i have 0 confidence in global health mechanic, because i observed weird oddities even with passthrough set at 0 for everything. So take away this - Infantry damage is imperfect. If you want to improve it you have to trial and error a lot and base all decisions on ingame tests. Unfortunately. The issues can be somewhat remedied by a complete rebalance... Muzzle velocity is defined in magazine class, can be modified (or overruled) by weapon https://community.bistudio.com/wiki/CfgMagazines_Config_Reference#initSpeed.3D900