Jump to content

chris77

Member
  • Content count

    21
  • Joined

  • Last visited

  • Medals

Community Reputation

11 Good

About chris77

  • Rank
    Private First Class
  1. Mig-21 PFM (Fishbed-F)

    Who uses autopilot? ;) Might want to increase the angle of incidence a little. This could help people who are not using TrackIR see the runway better during approach.
  2. Mig-21 PFM (Fishbed-F)

    I apologize. Config deleted.
  3. Mig-21 PFM (Fishbed-F)

    *deleted*
  4. Never mind. Just had an epiphany. I initialized all playable soldiers with this disableAI "ALL"; and apparently the dedicated server doesn't like that for human players. Removed that init and problem was fixed.
  5. Hi guys, I'm currently confronted with a really strange problem that I can't solve on my own. No vehicle in my mission can move its turret if it's operated by a human player and run on a dedicated server. AI can turn the turrets just fine. It doesn't matter if it's a stock BIS vehicle or an addon vehicle (tested with RHS addons). The funny thing is I'm only working on a half-finished logistics script which doesn't even touch technicals, APCs, tanks or attack helicopters except tacking on a setVariable [ "VVD_processed", "OK" ]. It only happens on a dedicated server too, when running the mission locally or in the editor everything is fine. I'd really appreciate if someone could help me out with this. I have a mostly addon-less version, hopefully I can attach it once I've posted this. Mission is playable online on unshaved-coop.de:2302 if you'd like to see for yourself quickly. Only dependencies are CBA and MCC Sandbox. P.S. Looks like I can't attach files, but here is a download link.
  6. Mig-21 PFM (Fishbed-F)

    I confirm the bad handling with the 1.1 version (unable to get the 1.0 version) with ArmA III 1.66.139586. It turns and performs worse than a transport plane, although I can get it airborne at full flaps and afterburners. I was unable to get even nearly similar performance out of the MiG when put into similar situations as in ampersand38's video. Unfortunately I know nothing about ArmA's flight model to suggest a fix.
  7. Realistic repair script

    I'm making good use of this repair script in my logistics addon. While debugging some issues reported by my testers I found there is a locality issue in the repair script regarding setHitpointDamage. You need to run this command on the client where the vehicle is local and that's not always where the repair script is running, for example the vehicle could be local to the dedicated server. I fixed it for myself like this: zlt_fnc_mpSetHitpointDamage = { private [ "_vehicle", "_hitpoint", "_points" ]; _vehicle = [ _this, 0 ] call BIS_fnc_param; _hitpoint = [ _this, 1 ] call BIS_fnc_param; _points = [ _this, 2 ] call BIS_fnc_param; _vehicle setHitpointDamage [ _hitpoint, _points ]; }; zlt_fnc_partrepair = { private "_veh"; _veh = [_this, 0] call BIS_fnc_param; if (isNil {_veh} ) exitWith {}; { _dmg = (_veh getHitPointDamage _x); if (not isNil {_dmg}) then { if ( _dmg > 0.64 ) then { if (_x in zlt_hardRepairParts) then { [ _veh , _x, 0.64 ] remoteExec [ "zlt_fnc_mpSetHitpointDamage", _veh, false ]; } else { [ _veh , _x, 0 ] remoteExec [ "zlt_fnc_mpSetHitpointDamage", _veh, false ]; }; _veh setPosATL [ (getPosATL _veh) select 0, (getPosATL _veh) select 1, 0 ]; }; }; } foreach zlt_repair_hps; }; I'm using the new remoteExec function to have the setHitpointDamage function run on the client where the vehicle is local.
  8. This seems to have been "fixed" since 1.32.127785. Cargo ramp no longer animates.
  9. I am going with the last solution now. It is just simple linear Algebra. However the situation is complicated by the weapons/munitions/grenade/launchers/special boxes having disproportionally larger bounding boxes than their actual 3D models. I have collected the minimum and maximum vertices for more appropriate bounding boxes for placement checking: \A3\weapons_F\AmmoBoxes\WpnsBox_long_F [ -0.805605, -0.16573, -0.1892087 ] [ 0.805605, 0.16573, 0.1892087 ] \A3\weapons_F\AmmoBoxes\WpnsBox_large_F [ -0.805605, -0.331085, -0.1892087 ] [ 0.805605, 0.331085, 0.1892087 ] \A3\weapons_F\AmmoBoxes\WpnsBox_F [ -0.532798, -0.331085, -0.1892087 ] [ 0.532798, 0.331085, 0.1892087 ] \A3\weapons_F\AmmoBoxes\AmmoBox_F [ -0.220985, -0.331085, -0.319649 ] [ 0.220985, 0.331085, 0.319649 ]
  10. Thank you for your quick replies, Tajin and Killzone Kid. Checking the bounding boxes for the cargo is not that difficult. It is just that they are always cubic so you cannot stack round objects like barrels densely. However I am willing to settle with that for sake of simplicity. I have seen the EPE event handlers, however from the description I gather they fire when the collision is already happening. Good idea but unfortunately that would be too late. The concave nature of the back of a truck or the interior of the MH-47 are the most difficult hurdle. I think a reasonable approach would be defining cargo area boxes with checks running against cargo in hand, cargo area and attached cargo bounding boxes. This would be somewhat more CPU-intensive. A PhysX-based collision detection would have been nice since it runs on the graphics card and all the data needed is already there. I am aiming for low performance impact and good MP performance. I probably need to scale back a little and not allow carried cargo inside the bounding boxes of vehicles and switch to automatic stowing of cargo using rasters of cargo positions in combination with individual bounding box checking when loading the cargo. This should cause no discernible performance impact while still allowing mixed cargo loading at the expense of cargo density since this approach does not always provide the tightest cargo packing. And on a personal note: Thank you for your tutorials, Killzone Kid. They helped me a lot with understanding the inner workings of ArmA.
  11. When carrying an object using attachTo it is possible to place it partially or fully into another object and release it. This almost always leads to violent bouncing and explosions of things that I would rather not have bounce around/explode. Background information: I am working on a set of scripts that allow me to freely load vehicles. Grab something, walk up and into the vehicle (kyo's excellent MH-47E specifically) and put it down. Through some mathemagics I will get the attachment point and fix the cargo to the transporter. However since attached objects are somewhat transcendent it is possible to stack cargo inside each other. Also I could carry in objects that would not even fit through the cargo door. In order to prevent all of this I would need a means to check for collisions not relying on bounding boxes. They're much too coarse for this purpose. I would probably need some kind of PhysX collision checking, I guess. Is this even possible? The Biki has functions for enabling and disabling collision checking which is nice, but not really what I am looking for. I also do not want to use hit/damage events because I want to prevent potential collisions in the first place.
  12. Thank you for the advice, Attorney and JShock. I have made more discoveries: While the action disappears from the soldier, it stays on a crate I placed nearby with the same init. Also the mission I am editing is an Alive mission. Alive has a module (Alive Profile System) that despawns infantry after you reach a certain distance. Documentation is somewhat sparse but I discovered that you can change the modules behaviour. Currently it is set to "Only profile synced units" so it should not profile my static NPCs but appearantly still does. When respawning them again it seems like it does not reproduce the init string of the unit. I think this might be an Alive issue instead of a Linux server issue. For now I am naming the static NPCs, hopefully the profile module will leave them alone now.
  13. There is a problem in a dedicated MP mission that puzzles me. I have a static, stand-alone soldier with his init set up like this: this allowDamage false; this disableAI "MOVE"; this disableAI "FSM"; this enableSimulation false; this addAction ["<t color='FFFF00'>Some action</t>", ""]; His only purpose is to stand there, unmovable and indestructible and provide an action to players. When I test the mission in editor it is fine and non-dedicated MP as well. However if the mission is run on a dedicated Linux server after the mission is running for a few hours this solder loses the action. For everybody on the server. Even players who join later do not get the action. Rejoining does not help either. From what I read about locality the following should happen: Player joins the server, map initializes client-side. Since this is defined in the unit's init string in the mission file it is executed on each and every client once when it loads the map. Thus every player should have this action attached locally to this soldier. Soldier locality is server because soldier is not in the same group as the player. That should not be an issue because for addAction the arguments are global meaning the soldier doesn't have to be local to the client for addAction to work. I am probably understanding something wrong, but I have no idea what it is and I have run out of options to try. Any experienced mission designer have an idea for me?
  14. Is there a way to prevent Ammo Trucks and Vehicle Ammo Boxes from automatically resupplying nearby vehicles? Intuitively I looked at the event handlers, but it seems there are is no suitable event for that. Is there an as of yet undocumented way to "castrate" that functionality out in the mission scripting scope or would I have to go the addon route and define a custom vehicle config?
×