Jump to content

x3kj

Member
  • Content count

    2505
  • Joined

  • Last visited

  • Medals

  • Medals

Community Reputation

1064 Excellent

About x3kj

  • Rank
    Warrant Officer

Profile Information

  • Gender
    Not Telling
  1. whats the problem? you can still look around with mouse if you use joystick. I do it all the time. If you dont want head tracking, and not control view with left hand, you either need to use your feet or grow another right hand...
  2. AI Discussion (dev branch)

    Mission designers 'ease of mind' to not have to test or worry about a linear mission working with all possible difficulty settings. It's a legitimate issue of course. But it doesn't take one thing into account: There are other missions than linear ones. And the way it was adressed made it better for linear missions ("follow muh plot!") and worse for all dynamic/ non linear missions where user customizability was intended. And this makes it objectively a bad solution, because there is a better way to adress the linear mission's designers issue without screwing all the rest over. Instead of removing the option entirely they could have made "mission designers values" for the AI sliders per mission, that define which setting the mission has by default. If the player modifies it he gets a warning "blabla not within specifications blabla, may not work as designed". Problem solved. Decision is in hands of the player to "break" the balance or not. Mission designer can give his specifications (or not, in case custom values are supported). I explained this when it was freshly announced, no answer, no reaction. Edit: With the introduction of modes for missiles the values for AI weaponranges have become slightly confusing... What effect do the min/mid/maxRange values have when they are defined in just the "base weapon", instead of in the modes? example - cfgweapons class missiles_titan_AA -> it inherits the modes from missiles_titan (that have ai ranges defined in them), but also defines a range set for the base weapon ?
  3. But what exactly does it do, when compared to it's non-magic counterpart "damping"? Why do all wheels have dampingInAir instead of just those that are permamently in the air (in the current configurations)? Is the role of regular damping parameter still that of physx default (mDampinRate i assume)? How does dampingrateinair interface with this system - does it modify the dampingrate of a wheel under certain conditions, or does it apply always? And how does it apply it's value? Why is it possible that a system intended for retarding (damping) wheel speed results in forces that propell it forwards? All calculations and inputs for mass, moi etc are utterly pointless when there is one pink elefant value that just does <whatever> and nobody knows what exactly. IRL the vehicles are damped regularly, but all the damping forces come from 1-2 wheels per side. The rest do not contribute anything to suspension damping. So in a sense, 1-2wheels are overdamped (for the spring it uses) but normally damped when all spring forces are counted together. That is not the same as no damping ;) If you look very closely at the suspension movements of this jumping t-90 you can see how the first two wheels and the last one do not wobble when it got into the air -> those ought to have suspension. The other three wheels wobble a great deal in the air. This results in a behaviour difference when the vehicle rocks back and forth, as the first and last wheels can lift of the ground, thus cant contribute to damping momentarily.
  4. AI Discussion (dev branch)

    What i don't understand is that directly after the refactoring thing was made public you got the same feedback about the problems with this new approach you get now from multiple people but it was never answered in any way, shape or form. When a new concept doesn't hold up to criticism from outside the "development bubble", why is it pushed through? This is the lesson you should be taking away from this. Also, maybe consider public discussion of concepts before they are actually started - specifically when they are for changing a current system that is supposed to address 'perceived problems' of creators - even more specifically when it's to do with removing control options for them.
  5. AI Driving - Feedback topic

    Please give us script commands to directly control AI drivers via script - essentially mimicing the controls you have as human commander in your vehicle, but as "remote" so to speak. This would allow us to create custom driving behaviour for short periods, where the default pathing AI either failed or simply doesn't work for this (e.g. reverse driving for cars and tanks, or turning a tank on the spot to change armor towards some threat). The combat/engagement behaviour of AI tanks is really not up to the task and destroys all authenticity unfortunately. To fix that we need ways to control vehicles directly for short periods, without relying on the path finding logic. Access to path finding logic would also be something of course, but i expect that's propably not feasible? And adding new features into that by us (e.g. reverse driving) is propably not doable either i suspect? Really, i'm not picky, i take any improvement in this area i can get... it's that significant imo. The best armor simulation is not worth a damn in non-pure-PvP, if AI doesn't care one bit about it's orientation dependant protection.
  6. Could you clarify why the enginePower parameter is important? After all, it is deducable by max/min omega, max torque and the torque-curve. P = M * omega dampingRateInAir is missing (unless this was made obsolete?). I would appreciate an indepth description how and what that value does exactly. It is possible to break physx with wrong values (MOI and dampingrateInAir not beeing balanced out), where the tank will accelerate on it's own at 0% throttle - so it would be good to know what exactly it does. From my experience clutch strength for tanks, a starting value of 10 is whoefully inadequate. 30-40 is better. On the other hand, if clutch strength values are too high it will become noticeable because the vehicle will jerk whenever it changes gears. Switchtimes near and above 1 seconds (for tanks) produced handling problems in the past, because during switching you can't steer. Idk if that changed when changing the steering system, but i would guess not. The faster the tank the more problematic the issue. Also problematic when the gearbox can't decide if its liking one gear or the other more for a certain terrain grade. driveOnComponents and the other driveOn thing (i forgot) is also missing - it would be good to have clarification for this as well, how it behaves currently / what those things do. Btw: Real contemporary tanks up until recently didn't have dampers on all roadwheels in the suspension. Mostly it was just the first and last, or the first two and last, or just the first two wheels that have dampers. This is what results in "springy" look when they drive up a step. Idk how the current situation is, but i strongly suspect since the majority still uses old chassis that this was not changed for most.
  7. I thought directionality of sound for ground vehicles was a feature that was beeing worked on?
  8. BUG i noticed with animations when holding a missile launcher: open inventory remove magazine of your main rifle and drop it on the ground pick the magazine from the ground and put it in your main rifle your guy will reload the rifle with the left hand (rifle floats in the air), while right hand holds the launcher No mods.
  9. A delay (time to wait) for transitioning vehicle positions would be really what's needed most here - not only for switching seats internally, but also for entering and exiting. It's entirely ok for tank commander to switch to gunner and driver at his discretion - but it shouldn't be at warpspeed. Warpspeed entering/exiting/position changing, as well as the stealth aspect of it (no sound or animation happening to warn people around that something is happening) is what leads to the typical and ridiculous game situations near vehicles, that are so common in arcade shooters like Battlefield, Planetside, etc. AT guy sneaks around tank to place mine or whatever, Driver stealthily warps out of the vehicle, shoots AT guy with SMG, warps into tank commander position, shoots some other dude with MG, warps to maingunner and blasts a vehicle... Over a period of 10 seconds. This is completely unbefitting to arma. Plus it's very frustrating for people who go up against vehicles - in all those games that are affected, not just arma. Some positions just cant interchange without exiting the vehicle. E.g. jeeps and also helicopter gunship pilot/copilot. For tanks this is often not the case, but where it is the case it should be implemented. It's a design limitation of that tank and plays to it's weaknesses.
  10. why of all things is a wednesday the most inconvenient time ? ...
  11. Tanks - Damage improvements

    @oukej@Asheara A few weeks ago i saw a changelog regarding the "repair"/ reintroduction of the fuel damage to cars and tanks. Could we get some details about what the conditions for this are? Is it hardcoded to HitFuel class? Can it safely be disabled by a config parameter (haven't found any that looked the part) or not defining a HitFuel class (and instead rename it) ? What is the treshold value where fuel loss starts to happen? What is the formula for rate of fuel loss? There could be some implications for the various refueling scripts out there, and also for damage scripts of course.
  12. Documentaries Chernobyl 1986

    I found another short video (in russian) - i dont understand what it says, but there are a few original recordings you don't normally see
  13. Arma lags too much, pelase help

    if you get lags while driving around or flying around by plane (or with editor camera) , then its hard drive related -> read speed is too slow to load all the data. If you get lags and low fps in combat while beeing mostly stationary then it's not the HDD. Using too high object draw distance can have massive effects on performance. Badly optimized missions are also sometimes the cause of poor performance on Multiplayer servers.
  14. Tanks - Damage improvements

    @oukej@Asheara I've read the changelogs regarding bullet ricochet and post penetration angles. I have two questions regarding that change: What is the current maximum angle deviation when the bullet exits from penetrated fire geo, and what does it depend on anything (material properties? impact angle?) and is it dependant on bullet configsettings in some way? If the answer is no, could the post penetration (exit direction after penetration) be made configurable per projectile in the form of defining the maximum allowable deviation angle from bullet traveldiraction before penetration? Because there are use cases where projectiles don't change angle on penetration, such as HEAT jets, rail guns and and direct energy weapons (lasers). It would be beneficial to have this configurable -> a simple flag in the form switching direction change after penetration on/off would also suffice. Not only is it more true for simulation and damage mechanics, in my case it is extremely obvious visually - where a direct energy weapons has a fairly long tracer. When they penetrate and change direction, you see the tracer changing direction inside the object (because of its length) and that looks totally whacky.
  15. longest kill -> usually what they dont mention in the press and anecdotes is how many tries it took, and what the propability of success rate was. The margin between longest kill and irresponsible waste of ammo is slim. Technically there is no reason that in 2035 tanks do not possess the computing algorithms (because the hardware is already there, or only missing very little) that tanks can track any optical target automatically and engage automatically - one shot sniping anything in vision range. It is still a game however that needs to be played.
×