Jump to content

x3kj

Member
  • Content Count

    2605
  • Joined

  • Last visited

  • Medals

  • Medals

Everything posted by x3kj

  1. In Arma Gravity constant is 9.81 There are multiple ballistic calculators for Arma in form of excel macro tables, Julie. Just google for them.
  2. They said they are open - however, considering they want to limit it to ~5 DLC per year, trying to sell just a single vehicle would be underwhelming and i doubt it would be popular. A pack of similar vehicles and logical additions is what jet DLC was - and i guess that would be more acceptable to people than "here, i made a thing" DLC. Terrain assetts could be a DLC as well... only difficulty is for terrain creators, but i guess they could be provided with lower detailed object proxies for map placement Expecting to make a living is an optimistic gamble. Although BIS haven't given contract details, this is not creators club where Bethesda pays you to make something. You make it and you get a cut when it sells.
  3. And what about source code modifications?
  4. This is very messy. If model shape allows, i would suggest to make a cylinder with as many faces as you have maximum ammo. Everytime ammo changes, you rotate the cylinder. 1 animation instead of Number X. https://community.bistudio.com/wiki/Model_Config#Animation_sources revolving increases, ammo decreases.
  5. Another thing i'm wondering: How does continued development of a DLC3P (O?) post it's release work? Is this a thing, or should the content be fully complete before release (apart from bugfixes)?
  6. I'm very happy that BI goes this step :) Question: Is all content bound to what you can do with modding alone? Or is it also possible to get access to and modify source code of the game (provided an agreement has been signed)?
  7. So you mean you want to volunteer to create the map ? =) Current team size is listed in the very first post and it is still effectively 1 (the volunteers are on and off - all work on other mods primarily)
  8. So in the last months i've been thinking and concepting how buildings/ structures in general look and work on my chosen planet, what metrics are necessary for them to function as desired and how to create a model system that allows time effective creation of many assetts. This is quite a complex topic, which is a bit too much to go into full detail here. Part of the concepting also involves defensive structures (walls, fortifications, ...). I want my world to be believable and for that it requires it to function. This means i also had to consider which weapons these structures would have to withstand, and what weapons would possibly be used from inside them. Basically it meant, that i had to fill out the gap between infantry mortar and basilisk that i hadn't specified yet with the other common artillery weapons used in 40k, and extend it with common Siege weaponry. here are two results of the tinkering and modelling that was involved in this process: Medusa WIP, and finished Infantry mortar with functional sight unit
  9. x3kj

    Global Mobilization

    fantastic stuff guys, looking forward for more
  10. Recoil force onto vehicles thus far was proportional to their hit value (=damage). They never gave us any formula to calculate it. Recently they introduced the muzzleimpulse modifier, with which the automatically calculated hit-value dependant. It's still a completely backwards method, as i've described a few posts earlier.
  11. Solution for wrongly perceived problem A: what if we had a solution for A. Ingenious... Speedcontroll does not only result in arkward handling, but it will be even more error prone. Speedcontroll is not the problem and not the solution. Try driving a car in the city exclusively with cruise controll and you will know why... or better not, for the sake of everyone else.
  12. If you want better simulation fidelity you also need to put in more time and knowledge when configuring your vehicle. If a simulation was to simulate every aspect of RL cars, you would have to be a team of realworld car engineers to be able to set up the car's simulation to achieve whatever performance you desired...To know what config results are necessary to achieve certain performance set by some slider or condition with so many variables means you already have to know the solution before you entered what you where even looking for... So the answer is 42. Same parallel as with AI - if the developer is a poor tactician, his AI will also be poor in tactical decisions (unless it relies evolution via trial&error).
  13. x3kj

    Visual Upgrade – Feedback

    Nick couldn't have been chosen more appropriate for this post well done Pub server players running off for the next shingy things (PUBG, ...).
  14. x3kj

    Tanks - Autoloader Wish

    I understand the issue, but what gave you the idea that having a loader or logistics would make teamwork better? If anything, developing game mechanic systems and game modes that allow players to easily coordinate tactically without language barrier and without requiring voice chat and also encourage it. This would be the key to more and better teamwork. This would benefit the game. Logistics and stuff like dedicated loaders are just menial tasks that in of themself do not contribute anything positive to the overal employment /coordination of units or tactical/ strategical thinking in battle. It would end up like the stamina system - on most pub servers admins disable it/ don't use it so players can all run around with 50kg of gear.
  15. Speedcontroll is practically not feasible. I think the most practical solution here would be to build a curve into analog throttle for ground vehicles. In 0 to 0.2 range (as first guess) it should be much less sensitive while beeing linear from 0.2 to 1.0 If i want to drive very slowly with my joystick with integrated analog throttle, i have to increase the throttle from zero by less than a millimeter. With a more agressive exponential behaviour i could move the throttle much further forward. Now the core problem i would attribute to the issue that the engine does not provide brake torque whenever the wheels turn faster than the engine would allow to. This means that no matter how the engine rpm is, it will always provide torque for acceleration. I also have some doubts about the BIS implementation of whatever "dampingrateInAir" parameter is supposed to be in configs
  16. x3kj

    Russia General

    To me it's screamingly obvious that, whoever holds the most power over there, did not get the puppet they wanted in the election of the people. So they resort to making politics by different means to achieve whatever they wanted.
  17. "now"? It has been like this for ages. I disliked it when it was first introduced back then, but didnt say anything - mostly because i don't use vanilla content other than for testing stuff out. Personally i would remove these animations. When it's not doable properly in the available time with available ressources, it's better to accept defeat and make notes for next round of engine improvements (Enfusion...).
  18. This would require something that is technically extremely similar to cloth simulation, except that the movement would be restricted to certain axis of movements and pieces would be rigid. Extremely unlikely to be implemented just for this i would predict.
  19. They flap via "g-force" animation sources. Problem is - these sources are immediate. But swinging objects would oscillate after the force has been applied. This is why it looks arkward. They instantly snap according to whatever maximum has just been detected and snap back just as suddenly.
  20. So here's the video of my second issue that i have no idea how it could be possibly fixed. When driving forward with steady speed, the animation speed is not steady - it slows down and gets faster at random. In general track speed is too slow compared to before. Right and left side move very differently, even when traveling straight forward. Note the EPE dialog - the average wheelspeed is also varying - which appears to be the core issue. However the track animations looked spot on before the recent physx update and A3 engine modifications. Is there any way i could help with analysis of this problem? Whenever the "jump" glitch happens the track animation can also glitch out, so it moves very rapidly and in completely wrong directions at times, and also while standing. I had it yesterday while i wasn't recording. When i tried to reproduce it again while recording i managed 3 "jump glitch" within 30mins of driving around but the tracks behaved normally afterwards. On monday when i tried the kuma and my custom vehicle it happened as well - on the kuma the track animation just froze in place. I created a frame by frame screenshot of one of the jump glitches. Here is the video (glitch at 1:07) Here are the frame by frame screens It's interesting to see that in the frame before anomalies are visible (2nd picture) , you can see that the RPM behind the gear ratios is negative, even though the vehicle is traveling forward. As if there is a leading sign error in the code somewhere. Immediately after (3rd picture) you see ridiculous wheel speeds and engine RPM drops to 0 even though thrust is 1.0 and ThrustR and ThrustL are both positive as well. Then the ridiculous wheel speeds drop. No visible anomaly in vehicle movement visible at this point. Then RPM values reverse once again -> next frame again insane wheel speeds but also very visible movement glitch.
  21. x3kj

    Forums Upgrade

    I'm getting 502 gateway errors as well on PC with firefox.
  22. @oukej could you explain where and how the recoil force is applied? Is it the hull? I find this factoring and stuff totally arkward, especially torque.. imo this has no justification for beeing so obstruse. All the information about firing direction and muzzle position is defined in configs. These can easily be used as application point for recoil forces. Instead of fudging it with torque and force on the hull it's much easier and reliable to just apply the force directly at the point where it originated (the barrel / muzzle). Currently with muzzleimpulse, everytime you change hit values you have to re-trial&error the "fudge factor". It'd be much easer to define an absolute force in the bullet (or magazine) and then apply a factor to the muzzle class of a weapon (to be able to allow different firing modes with different recoil - e.g. artillery). Case in point - i had converted back to muzzle impulse after it was configurable. But i noted that vehicles sometimes just stayed in the air for prolonged time for whatever reason. And i didn't have the impression that the direction of the force was accurate to the firing direction at all times. Configuring was also a pain. So i re-converted back to applying setforce script on the barrel via fired EH... works much much much better. Plus you can easily "preview" it via script whereas with that fudge factoring you have to constantly reload the config via diag.exe.
  23. PhysX default drive model is incapable of inhibiting movement of the wheels by the engine (no engine braking) to my knowledge. The resistance of movement is also pretty low on tanks compared to their engine power - i would say. To drive at very slow speed you have to apply thrust in the range of 0.001 to 0.02 iirc. Almost impossible to do reliably with a gamepad for example, even with maximum exponential behaviour in controller settings. If i had to guess it's propably also deeply connected to how movement resistance is implemented for tanks by BIS (does not use the standard PhysX parameters for damping). At slow speeds the simulation is also pretty inaccurate for whatever reason. This is why there is a specific speed that counts as "slow enough" to enforce a stop and set all velocities to 0 (which for BIS vehicles is default of 10km/h iirc). Core reason is the change of sticky friction and dynamic friction, that they've (Nvidia) hardcoded to prevent vehicle sliding when wheels are at speeds close to zero. Transition from sticky to dynamic friction isn't really performant to compute. I know it can be implemented fairly well technically by using a tanh^2 function, but idk how much more performance that would cost compared to current version. Also, it would require major rewrites of the physx library by BIS - and i doubt they have the time to invest there. Bad idea imo. And no if you port to tanks you would have thrust instead of speed as controll. If you want like you say speed controll BIS would have to provide an algorithm that brakes/accelerates whenever you are not at the desired speed. This is very tricky to get right. You would likely have the same dilemma as with the current auto gearbox - constantly switching up and down even if you don't want to. The algorithm would likely constantly break/accelerate to keep desired speed, leading to choppy action. Both methods (thrust and speed % controll) makes precision driving very counterintuitive as well with M+KB. Just to highlight: VTOL landing has become much trickier to do accurately with the new controll method and M+KB, because you cant finely controll the increase/decrease of %.
×