Jump to content

h -

  • Content count

  • Joined

  • Last visited

  • Medals

  • Medals

Community Reputation

58 Excellent


About h -

  • Rank
    Master Sergeant

Contact Methods

  • Website URL

Profile Information

  • Gender
    Not Telling
  • Location

Recent Profile Visitors

415 profile views
  1. Flare Illumination

    Completely forgot about this one.. No idea what the values were before but the intensity of CfgLights class FlareLight is quite massive (outside the int range -> intensity = 1e+007 = 1^7 = 10 000 000) but because the attenuation values it doesn't actually illuminate anything no matter how insanely high you set the intensity the light simply dies off too close to the source.. As it's called 'intensity' I guess the value is in candelas (intensity of a light source, 10 000 000 candelas = (pretty much) 10 000 000 lumens) which basically means "the brightness of the light at source" so the FlareLight is actually pretty damn bright, it just doesn't illuminate anything, which means claiming that the flares aren't bright enough is false
  2. Flare Illumination

    Sounds like a plan. And if using Grumpy's methods of getting the color etc data those could be stored in the lightpoint array at mision init as well for faster referencing EDIT: Or a separate array, sorted by type or something.
  3. Flare Illumination

    "SetLighting" the flare model doesn't work, IIRC tried it at some point.. :P wouldn't call mine a fix, just something simple I used in a very specific situation.
  4. Flare Illumination

    I guess you've already tried just creating a new light for the flare? Dunno how "cost effective" and fiddly that would be in MP though Been using this sort of thing myself sometimes: player addEventHandler ["FiredMan",{ private _scpt = (_this select 6) spawn { private _timmeh = time; waitUntil { time - _timmeh >= 3; }; private _foo = "#lightpoint" createVehicle (getPosASL _this); _foo attachTo [_this, [0, 0, 0]]; _foo setLightColor [1, 1, 1]; _foo setLightAmbient [1, 1, 1]; _foo setLightIntensity 100000; _foo setLightUseFlare true; _foo setLightFlareSize 10; _foo setLightFlareMaxDistance 600; _foo setLightDayLight true; _foo setLightAttenuation [4, 0, 0, 0.2, 1000, 2000]; waitUntil { sleep 0.1; !alive _this; }; deletevehicle _foo; }; }];
  5. AI Discussion (dev branch)

    Odd, for me the diamond formation is the only one in which the AI won't stay behind OCDing about enemies, even on combat. On any other formation it's the bounding overwatch "Go I'll cover" stuff.. This.................................... The AI has a serious scope fetish so best to remove anything that can magnify from their inventory. And never ever give an AT with other than iron sights to an AI... Or a sidearm..
  6. I didn't even realize this was an issue as hadn't played the game in a while, was wondering when playing Tacops that was this really this slow always.. But yup, loading times are basically like lightning now compared to a few days ago.
  7. inAreaArray is nice for this, use the first syntax with nearObjects: - Search around the trigger position - Use "All" as types, otherwise honeybees and terrain objects may interfere. Search radius is trigger area - nearObjects also finds the trigger itself so remove it from the search result - use that final nearObjects result with inAreaArray boxTrigger_01 and count the resulting array - if count == 0 --> free to create wheel
  8. Keyframe animation system in DEV.

    Nope. Appears that I was doing it the correct way when testing last weekend but with same results -> not even the red line to indicate anim path.. :(
  9. Forums Upgrade

    Indeed, something has happened because now this has been running smooth as... ..smooth. First time since forever. All possible body appendages crossed it stays this way.
  10. Forums Upgrade

    Clearly the servers have to be killed with fire. 502/504 gateways of annihilation for moths now..
  11. Fixed in the latest dev (143722): "Fixed: Warning messages connected to the set3DENMissionAttribute script command were not correct " Obviously stable is stil screwed :(
  12. - disable/enableAI "WEAPONAIM" - seek & destroy waypoint (error in rpt, not on screen). Shows at least when loading a scenario with S&D waypoint(s) into Eden - set3DENMissionAttribute/s with custom attributes
  13. AI Discussion (dev branch)

    Well, it's half-fake as it still makes the AI forget the target Since for the longest time knowsAbout was the only way to tap into the AI so we've been asking a way to reset it ever since OFP and forgetTarget finally does that after what, 15 years of asking..
  14. AI Discussion (dev branch)

    Speaking of AI related scripting: Targets is nice command but clearTargets would make it nicer, or that forgetTarget would clear the forgotten target out of it. AFAIK now even if you make an AI forgetTarget a target it's still in it's targets array and stays there for some unknown engine defined amount of time.. The command reveal also behaves oddly, if you just dood reveal [target, 1] dood gets too precise position information of the target = in 5m offset. Whereas if dood gains knowledge of the enemy "naturally" at knowsAbout of 1 the position offset is hundreds of meters (checked with targetKnowledge).. To fix this you have to first reveal the target with 0.105 or less and then with 1 and you get the "natural" position data. Could be nice if the command did the natural way by default.. I suggested that years ago with no luck (was just suggesting with name currentTarget, but whatever). :( Maybe in the next engine then. This is really infuriating. They also seem to completely lack any target prioritizing other than how scawy the target is: the AI's scope fetish results AT (when the AT has a magnifying sight) guys screaming about armored targets 800m away while in firefight with infantry 100m away. Of course getting killed because they're watching something else entirely than focusing on the fight at hand, or even engaging and missing the armored target, getting killed by it and thus drawing the armor into the fight as well..
  15. And to make matters worse the counter has bullet proof air inside it, shooting at the glass part makes glass shattering sound and shards are flying but the head behind the air stays intact..