tpw

Member
  • Content count

    2885
  • Joined

  • Last visited

  • Medals

Community Reputation

535 Excellent

About tpw

  • Rank
    Warrant Officer
  1. I didn't "kinda made it work", I made it work how I wanted it to :) . As I said, it was a balancing act. Snow density and spread vs time between emitter spawning vs radius vs chance of seeing snow in buildings vs CPU overhead Fiddle the settings to see if you get something that suits you better. Or not. Or wait for killzone. _snowEmitter setParticleRandom [0, [4,4,4], [0, 0, 0], 0, 0.01, [0, 0, 0, 0.1], 0, 0]; _snowEmitter setDropInterval 0.01; _rad = 12; // spawn emitters further away if under cover } else sleep 0.1;
  2. So I had a play around a bit more and the following code works pretty well and doesn't hammer the CPU too hard. Instead of spawning a single large snow emitter around the player and switching it off if the player is undercover, it now updates multiple positions around the player and spawns a smaller snow emitter at each position if the position is not under cover. It's a bit of a balancing act and not 100% perfect, occasionally you'll see a snowflake inside. I'll be incorporating this concept into TPW FOG shortly, but feel free to knock yourself out in the mean time. // Localised snow emitter fnc_emitter = { private ["_pos","_logic","_snowemitter"]; _pos = _this select 0; _logic = "logic" createVehicleLocal getpos player; _snowEmitter = "#particlesource" createVehicleLocal getpos player; _snowEmitter attachto [_logic,[0,0,0]]; _snowEmitter setParticleCircle [0.0, [0, 0, 0]]; _snowEmitter setParticleRandom [0, [4,4,4], [0, 0, 0], 0, 0.01, [0, 0, 0, 0.1], 0, 0]; _snowEmitter setParticleParams [["\A3\data_f\ParticleEffects\Universal\Universal", 16, 12, 13,1], "","Billboard", 1, 7, [0,0,0], [0,0,0], 1, 0.0000001, 0.000, 1.7,[0.07],[[1,1,1,1]],[0,1], 0.2, 1.2, "", "", _logic]; _snowEmitter setDropInterval 0.01; _logic setposasl _pos; sleep 0.5; deletevehicle _snowemitter; deletevehicle _logic; }; // Main loop _rad = 0; private ["_lowpos","_highpos","_spawnpos","_pos","_cover","_posx","_posy","_dist","_dir"]; while {true} do { // Is player under cover? _pos = eyepos player; _cover = _pos vectoradd [0,0,30]; if (lineintersects [_pos,_cover] || vehicle player != player) then { _rad = 12; // spawn emitters further away if under cover } else { _rad = 0; }; // Random position for emitter _dir = random 360; _dist = _rad + random 25; _posx = _dist * sin _dir; _posy = _dist * cos _dir; // Is emitter spawn position under cover? _lowpos = _pos vectoradd [_posx,_posy,0]; _highpos = _pos vectoradd [_posx,_posy,30]; if (!lineintersects [_lowpos,_highpos]) then { _spawnpos = _pos vectoradd [_posx,_posy,4]; [_spawnpos] spawn fnc_emitter; }; sleep 0.1; };
  3. Cheers redarmy, thanks for the heads up mate. I've never done the show/hide module thing, so never thought about this issue. Should be simple to correct. EDIT: Fixed, I'll release it in a day or so.
  4. Ahh my bad, didn't get exactly what you were asking. Please forgive me for @#$%ing trying. I guess a system that switched to placing numerous small snow particle emitters around the bounding box of a building when player entered it would work, but would indeed be a bit heavier.
  5. Blatant promotion: TPW MODS (TPW FOG) has a snow function which spawns snowflakes around the player as long as the player is not in a building. Here's modified version which doesn't rely on the other variables in TPW FOG. //SNOW FX tpw_fog_fnc_snow = { private ["_pos","_highpos","_snowemitter"]; while {true} do { if (overcast > 0.4 && alive player) then { 0 setrain 0; _pos = eyepos player; _highpos = [_pos select 0,_pos select 1,(_pos select 2) + 10]; if (!(lineintersects [_pos,_highpos]) || vehicle player != player || (eyepos player) select 2 < 0) then { _snowEmitter = "#particlesource" createVehicleLocal getpos player; _snowEmitter setParticleCircle [0.0, [0, 0, 0]]; _snowEmitter setParticleRandom [0, [10, 10, 7], [0, 0, 0], 0, 0.01, [0, 0, 0, 0.1], 0, 0]; _snowEmitter setParticleParams [["\A3\data_f\ParticleEffects\Universal\Universal", 16, 12, 13,1], "","Billboard", 1, 7, [0,0,0], [0,0,0], 1, 0.0000001, 0.000, 1.7,[0.07],[[1,1,1,1]],[0,1], 0.2, 1.2, "", "", vehicle player]; _snowEmitter setDropInterval 0.001; _snowEmitter attachto [vehicle player,[0,0,8]]; sleep 2; deletevehicle _snowemitter; }; }; sleep 1; }; }; Hope this helps.
  6. TPW MODS 20170111: https://dl.dropboxusercontent.com/u/481663/TPW_MODS_20170111.zip Changes: [AIR 1.32, ANIMALS 1.36, BOATS 1.33, CARS 1.50, CIVS 1.51, CROWD 1.04, SKIRMISH 1.36] Improved despawning of units to prevent glitches related to the updated createunit command in build 1.67. Reduced incidence of close crowd civs despawning in front of the player. [FURNITURE 1.02] Improved furniture despawning. [RAINFX 1.12] Fixed bug where rain droplet fx occasionally persisted after rain stopped / player under cover. Ground raindrop fx now use miniature reflective puddle objects rather than refractive particles. Just a bug fix release, mainly to address some irritating issues that had crept in during the 1.67 dev build process. Basically, despawning units out of groups often led to weird visual glitches - sometimes the entity despawned but left its model behind, sometimes the model despawned but left an invisible entity behind. This was particularly noticeable in TPW CROWDS, leading to a population of permanent mannequins and ghosts. I've addressed this by giving each civ its own group. Since there shouldn't be more than 25 or so civs at a given time, this leaves plenty of groups over for your combat needs. In any case, the group limit has been extended from 144 to 288 in 1.67 so will become less of a problem in the future.
  7. I think it might be related to the new creategroup command. Deleting units from large groups can lead to the issue, if I assign every unit to its own group then the issue goes away. I'll work on it more and come up with a repro.
  8. Thanks killzone. The code in the repro can indeed be made to delete things properly if I insert a sleep 0.02 after the deletevehicle. However the issues with the deletevehicle command occasionally deleting the entity but not its model definitely remain.
  9. Froggy, TPW CIVS/CROWDS already react to gunfire near the player by running to nearby houses. TPW SOAP also causes screams from nearby houses if there's nearby gunfire. Maybe there's some code in there that will help.
  10. Has anyone else noticed issues with the deletevehicle command being a bit flaky since the deleted eventhandler was introduced? In the last couple of days I've had a number of scripts of mine that rely on deleting entities start exhibiting sporadic weird behaviours, the worst of which is deletevehicle on an entity deleting the fact that it's an entity, but not deleting the actual object, which itself then becomes undeletable. It's not something that I can reliably reproduce but it is guaranteed to happen after a minute or two. Similarly I have scripts that rely on spawning emitters, for effects such as raindrops, stop working because the emitters are no longer being deleted appropriately. EDIT: Here's some code showing some additional weird behaviour. After spawning and deleting a number of civs, their invisible models persist. tpw_test_array = []; for "_i" from 1 to 20 do { _sqname = creategroup civilian; _civ = _sqname createUnit ["C_man_shorts_2_F_afro",position player, [], 0, "FORM"]; tpw_test_array pushback _civ; }; { deletevehicle _x; } foreach tpw_test_array; hint str (player nearentities 50);
  11. No I'm not. It's trivial to enable or disable any mod just by editing tpw_mods.hpp by hand. // HUD tpw_hud_active = 1; // 0 = inactive If you want to install python, then you can use tpw_settings.py which simplifies changing settings even further.
  12. TPW MODS 20170107: https://dl.dropboxusercontent.com/u/481663/TPW_MODS_20170107.zip Changes: [CORE 1.30] Additional Tanoan buildings added to habitable building list [FURNITURE 1.01] Furniture added to Altis/Stratis buildings. Fixed a few dodgy Tanoan object placement issues. Ok so that's the default Arma3 furnishing taken care of. Now I'll just sit here and pat myself on the back whilst waiting for people with actual talent to come up with some decent furniture templates. Thanks to those who've reported placement issues, much appreciated.
  13. Yep, crowd civs do indeed despawn when injured or killed, it's a design decision since they are really just window dressing. And depending on where you are they do indeed appear to pop in/out. I know it can look a bit iffy but the alternative is to melt down your CPU by not being harsh with culling them! Normal TPW CIV civs behave normally in this regard, but there's far fewer of them.
  14. The way the system works is to assign a template to a building via setvariable the first time it is scanned. Furniture is then spawned using this assigned template. Once the player is out of range the furniture is despawned. If the building subsequently comes into range again it spawns furniture from its assigned template, a new one is not chosen for it. So if the building is assigned a random template, it will always use that.