johnnyboy

Member
  • Content count

    863
  • Joined

  • Last visited

  • Medals

Community Reputation

399 Excellent

5 Followers

About johnnyboy

  • Rank
    First Sergeant

Profile Information

  • Gender
    Not Telling
  • Location
    Silicon Valley
  1. I don't know. You'd have to experiment. I'm guessing animals only have one texture, but I don't know for sure.
  2. I think the wheel Action menu still works. In the init.sqf, you see this code: // ************************************************************************** // Create dog and have him follow player // ************************************************************************** _dogMenu = [] spawn {sleep 2; _d=[player] call JBOY_fnc_DogDisplayEH;}; // Add dog menu to player dog1 = [handler1, "Fin_tricolour_F", (handler1 modelToWorld [2,2,0]), true] call JBOY_dog_create; // Create dog. 4th parameter true means use Johnnyboy voice for commands. nul = [dog1, handler1, 2.5] execVM "JBOY_Dog\JBOY_dogCommand.sqf"; // Start command listener for dog //nul = [dog1, handler1] execVM "JBOY_Dog\JBOY_dog_assign_actions.sqf"; // if dog has handler, assign action menu to handler _n=[] spawn {sleep 2; dog1 setVariable ["vCommand", 'sit', true]}; // Issue first command to dog (sit, heel, stay, etc. Sleep to allow dog to be initialized first. Change this to the following: // ************************************************************************** // Create dog and have him follow player // ************************************************************************** //_dogMenu = [] spawn {sleep 2; _d=[player] call JBOY_fnc_DogDisplayEH;}; // Add dog menu to player dog1 = [handler1, "Fin_tricolour_F", (handler1 modelToWorld [2,2,0]), true] call JBOY_dog_create; // Create dog. 4th parameter true means use Johnnyboy voice for commands. nul = [dog1, handler1, 2.5] execVM "JBOY_Dog\JBOY_dogCommand.sqf"; // Start command listener for dog nul = [dog1, handler1] execVM "JBOY_Dog\JBOY_dog_assign_actions.sqf"; // if dog has handler, assign action menu to handler _n=[] spawn {sleep 2; dog1 setVariable ["vCommand", 'sit', true]}; // Issue first command to dog (sit, heel, stay, etc. Sleep to allow dog to be initialized first. The change above commented out the new Key menu (JBOY_func_DogDisplayEH), and uncommented the old wheel action menu (JBOY_dog_assign_actions.sqf); I hope that works, not 100% sure. The newer Actions like Track might not be in that old menu, so you may have to modifiy it.
  3. @madpat3: The Sphere was for debugging purposes to mark who was pack leader. To remove the sphere, in the init.sqf, change this line from: JBOY_DEBUG = True; to: JBOY_DEBUG= False; Yes. Look in script JBOY_dog_create.sqf, and you will see where I add a HandleDamage eventhandler to the dogs where I apply a different texture with blood stains on the fur to the dog. Look at the .jpg files in JBOY_Dog\Textures\ folder and you will see jpgs for each dog type (alsation or the other one) and color of the dog. You could make your own jpgs to give different marking, colorings to dogs if you wanted. if (((getObjectTextures _dog select 0) find "dogbloodneck")>=0) then { _dog setobjecttextureGlobal [0,"JBOY_Dog\Textures\dogBloodNeck2Hole" + (typeOf _dog)+".jpg"]; // neck blood + bullet holes } else { _dog setobjecttextureGlobal [0,"JBOY_Dog\Textures\dogBulletHole2" + (typeOf _dog)+".jpg"]; // bullet holes only };
  4. I feel your pain. I fear every new version release will break my scripts. Is the Height above the floor the same for all objects? Or is it the same for all buildings. If the height offset is the same, maybe you can write a repositioning script that searches for objects near buidings and lowers them. If you have a limited set of affected object types, maybe its doable. The risk of course is it will affect correctly placed objects and bury them. Sounds like a huge bummer. Sorry dude.
  5. I hope you're right about 1.68 fixing this. But I just read the changelog thoroughly (and search for "combat" and "ai") and saw no reference to this fix.
  6. I recommend doWatch rather than setDir, so if player observes the unit, the unit doesn't magically/instantly face the direction. I like CreateProduct's heading variable suggestion, so maybe follow his suggestion, but replace the setdir with this: # unit will turn to watch a position 10 meters out in direction _heading _targetUnit dowatch ([_targetUnit, 10, _heading] call BIS_fnc_relPos);
  7. Now that I think about it, regarding " You are then in control of the smoke particles, and can track their positions. "...I don't know for sure if you can track the particle positions or not. I've always had a weak understanding of particles and Drop command (although I have used it a few times). Good luck.
  8. Got it. Then I think you need the near-miss technique for the auto-cannons. With trial and error, you can determine how far to tweak direction of projectile for a near miss. And by tweaking Z velocity lower or higher, you can alter near miss above and below your player chopper. Another option is to attach some hidden targets to chopper (above, below, in front of , behind). Then reveal the hidden targets to the auto-cannons and order them to fire. You could setCaptive True on the player chopper so they don't target it. I think that might be easier than calculating near miss trajectories. My lawyer, @das attorney, posted here that when using an invisible target, you need to createVehicleCrew for the invisible target, so AI will fire on it.
  9. That's a good idea. You are then in control of the smoke particles, and can track their positions. You could potentially still use a smoke grenade (if you like the look better than the chemlight), but replace it after it lands with a static one using a weaponHolder. Then make your own smoke on that position.
  10. Detecting particles sounds ideal. But if that doesn't work out, I think you could approximate it based on: smoke grenade position Wind direction Wind speed Duration (small cone of smoke grows and drifts over time, then fades away) You could then calculate a "cone" zone where smoke is likely to be. To test you could create helper object spheres in your calculated cone zone to see if they line up visually with where the smoke is.
  11. Hey @madrussian, thanks for taking this on and documenting it thoroughly. Please do send it to the A3 feedback tracker. This problem has plagued us all forever. In my Property of Mabunga mission, I set up the East and West rescue teams to search the swamp area via sending them to a series of marker positions (if the team was not lead by a player). It pissed me off that they would be so slow after first combat contact. I ended up making my own script to disableAI FSM and send them in 100m increments towards next marker. I would send group leader first, and then calculate positions around him to send the remaining group members (this could be extended to mimic formation positions BTW). They would then wait 30 seconds or so at each movepoint, before sending them to the next one. This worked pretty well, but has the disadvantage of units not turning and firing properly while FSM is disabled. But they will engage enemies ahead of them. And they would engage somewhat during their 30 second pauses. Once their search pattern put them within 150 meters of an enemy pirate camp, I would stop the movement script, reenableAI FSM, and give them a Move waypoint at the pirate camp. Their normal combat behaviour was then active for the assault on the camp. I wonder if you toggle DisableAI FSM periodically you can get a better result. When not in Combat mode, you disableai FSM to get them moving. When contact occurs, re-eanable FSM until NearEnemies is zero. Once skirmish is over (nearEnemies zero), disableAI FSM again so they move to next wp. Its sad we have to go to these lengths though, so I hope BIS can fix it. If your analysis revealed there is a timer on "waiting time before safe to move again", then maybe it could be an easy fix for BIS.
  12. If missle is deleted it is not visible. For small arms fire, deleting projectiles is fine, as you still hear the shots and see the muzzle flashes. For missles, deleting the projectiles is visually bad IMO. For that I would alter missle direction. I would also consider setting the player chopper to invincible (allowdamage=false). Having bullets hit the chopper is good for immersion, and bullets shouldn't bring the chopper down anyway. For missles, I would alter direction so you have near misses (visually exciting).
  13. You could detect smoke grenade position, and then affect players who are near the grenade. If you want to get real fancy, then you take wind direction into account. For detecting gas grenade, put a fired eventhandler on the gas grenade thrower. Code in the eventhandler would find smoke grenade object thrown, and call a script that lives as long as the smoke grenade is producing smoke (you could set this time as a number of seconds). Loop to detect any players or ai near smoke grenade, and execute your spazzOut script on them. BTW, I like the idea of the gas grenade and spazzOut script, so please post your solution when its done.
  14. I named 2 static launchers shooter1 and shooter2 in the editor. And I placed that code in the init.sqf. Note I am using the Fired EventHandler mentioned by his Royal Grumpiness. You could take my code and simply delete the missile/bullet instead of altering its direction. Use deleteVehicle to delete bullet or missle.
  15. This is close to what you are asking for. I used it on an AI static missle launcher that was targeting player zodiacs. When fired, missle is detected and direction and speed of missle altered. Tweak it to your liking. shooter1 and shooter2 were the names of the static AI launchers placed in editor. // ********************************************************************** // Alter path of missles // ********************************************************************** { _x addEventHandler ["Fired", { _null = _this spawn { _missile = _this select 6; _vel = velocity _missile; _dir_modifier = -3.5 + random(6); if (_dir_modifier >= -1 or _dir_modifier <= 1) then { _dir_modifier = _dir_modifier * 2; }; _dir = (direction _missile) + _dir_modifier; _speed = speed _missile; _velX = velocity _missile select 0; _velY = velocity _missile select 1; _velZ = velocity _missile select 2; _speed = _speed / 3; _z_modifier = 2.5 + random(3); _dir_modifier = _dir_modifier * 2; _missile setVelocity [_speed * sin(_dir), _speed * cos(_dir), (_vel select 2)+_z_modifier]; }; }]; } foreach [shooter1, shooter2];