Jump to content

Rydygier

Member
  • Content Count

    4662
  • Joined

  • Last visited

  • Medals

  • Medals

Community Reputation

1182 Excellent

About Rydygier

  • Rank
    Second Lieutenant

Profile Information

  • Gender
    Male
  • Location
    Poland, Pomerania

Contact Methods

  • Twitter
    _Rydygier_
  • Google+
    +Rydygjer
  • Steam url id
    rydygier
  • Linkedin
    witold-narwojsz-534183119

Recent Profile Visitors

4651 profile views
  1. I see, there may be still some work required for example around how the AI uses spells (like why to cast lights, if someone else casted them already and there's plenty of light around etc.), but if anyone interested, here's "amplified" update wip demo: Rincewinder 0.7wip1 In short: - every spell reviewed, adjusted, changed, improved, bigger variety of booms added etc. ; - if you have a spell selected (name is white) you can use mouse wheel to control, how much mana you wish to spend, this way you can amplify every spell, which in general means, it will do, whatever it does, longer, wider, brighter, stronger etc. but also it becomes harder to harness, which means a risk of not desired side effects like too wide spread, too early detonations, hostile to all creatures etc. Mage's experience will reduce that backfire. Details I'll leave to your experiments; - most spells, that was producing some effect in the mage-centric area (meteor shower, ice storm, sky candle etc.) now by default are focused rather in the area roughly ahead of the player which should make them more tactically useful - easier to control, where the spell will be manifested, easier to avoid friendly fire or self-inflicted damage... Unless amplified too much; - the most changed spell is airlift, now the broom (or the carpet if mage is CSAT) can be semi-controlled by mouse movements, but it is also "homing" towards clicked target position. Flight and effects rewritten; - some changes in the spellbook GUI, mostly easier picking the target (less precision required); - AI can amplify their spells too if they see fit, also now they are limited to mana level, which wasn't the case earlier; - new audiovisiual effects/details accompanying some explosions, fire effects etc. - earth elemental now can throw exploding rocks; - dragons on the top of mundane weaponry got also actual fire breath attack; - additional, delayed explosion at BM's death spot, as requested, with small AI routine for near AIs, that may flee from the BM's body depending on various factors. Size of explosion should semi-randomly depend on BM's experience (potence); - as a part of my (wip) experiments with daylight visuals, all seems to be brighter. That may be a good thing? - anything else, I forgot... Release is planned soon, not quite sure, when exactly.
  2. Currently I'm finishing 0.7 update, all the spells reviewed, amplify functionality added (not sure, if for the AI too, maybe later, maybe now), enriched some FX and combat-effective aspects, anyway, these days I should spent on testing every spell one by one, so if anything doesn't work - I should spot this. The only thing, that I planned, but probably will not happen, is making light effects anyhow more prominent in daylight, there are serious complications with how the A3 engine handles this topic... Haha, you don't need to convince me, that more explosions is good thing. I'm already adding more power of that sort to some spells, adding actual explosion to Battle Mage's (Magticians? Spelloperators? How this sound to native English ear? Other ideas anyone?) will be consistent. Of course need to be delayed, if near player should get any chance to run for his life...
  3. So far tested for blue component solely, and the relation between this value and actual visibility brightness treshold (VT) seems to be: VT * ((1/blue)^0.5), at least for ALB=28526.2. Also seems, that R and G components in this regard "weight" more, than B for some reason. This rabbit hole appears to become deeper, than I planned to dive... 🙂 EDIT: For ALB=28526.2 VT (minimal light source brightness to make it visible at all) looks like: [r,0,0]: 4.368189 * ((1/r)^0.5) [0,g,0]: 3.117583 * ((1/g)^0.5) [0,0,b]: 7.074318 * ((1/b)^0.5) so the green component seems to "weight" more, than r or b and r - more than b. For ALB= ~1000 VT (x28,5262 less) [r,0,0]: 0.817855 * ((1/r)^0.5) (x5,3410 less) [0,g,0]: 0.583704 * ((1/g)^0.5) (x5,3410 less) [0,0,b]: 1.324523 * ((1/b)^0.5) (x5,3410 less) some consistency at last... Note, (28,5262^0.5) = 5,34099. So in these cases rising the Ambient Light Brightness X times rises the Visibility Brigthness Treshold of custom light source (square root of X) times. One mystery, that remains (apart from the main question - why there's such hard treshold in the first place...): why r,g,b have different tresholds. Time to try some r,g,b mixes, I guess.
  4. Apparently there's some hard treshold of final custom light brightness (CLB) required for certain "ambient light brightness" (ALB). Below this treshold custom light is not visible (immediate disappearance, not fluid fading, thus above function will not ensure constant light visibility for native brightness < 1 - values was calibrated for 1). For example, full daylight for Altis or Tanoa means ALB=28526.2 (constant most of the day except sunrise and sunset, 2048 for VR map), for this ALB CLB treshold seems to be: ~7.074318 (custom light need to be at least of this brightness to be visible - light up any surface - at all). This treshold is different for lower ALB, but the change seems not linear, so the ratio between ALB and CLB treshold isn't constant. Pity, linear change/constant ratio would make things easier. Nitpicking investigation continues... EDIT: also seems, that treshold depends on the light color, which adds another layer of complexicity. 😕
  5. I'm trying to make custom light source's impact on surrounding environment/objects at daylight as close, as during night conditions, as possible (for human eye). As a criteria I'm using subjective visiblity range of blue light tint on the surfaces around the light source. This code seems to work along described lines: RYD_LightEqualizer = { private _lght = getLighting select 1;//ambientLightBrightness if ((_lght > 570.06) and {(_lght < 1754.41)}) then { (linearConversion [570.06, 1754.41, _lght, 1.2808, 1.7545, false]) } else { ((_lght/1000) max 1) }; }; used like this: _someBrightness = 1; _brCoeff = [] call RYD_LightEqualizer; _someLightSource setLightBrightness (_someBrightness * _brCoeff); Exemplary result for native brightness 1: So, if anyone wants, can use it. But, as you can see, there's a certain (determined empirically) range of ambient light brightness values (happening at some time during sunrise and sunset), where general formula - (_lght/1000) max 1 - doesn't suffice (light not visible during that period) which enforced patching with linearConversion part. I could use any advice/improvement to avoid such patching and to have rather one, always working formula (and other good ideas, if any). PS code was tested on Altis with an assumption, it is the same on every map, but wasn't tested on other maps. Also overcast seem irrelevant as for ambient light brightness value.
  6. AFAIK no. You would need not only to calculate exact bullet's flight trajectory in advance (which, even if doable in exact manner somehow, may take considerable in this contex time), but also to know in advance, what the AI would do during the bullet flight (exact target movement and silhuette changes), not only targetted AI, but also other, that can block the bullet path.
  7. Perhaps you could monitor distance between the bullet and the shooter and exit bulletcam as soon this distance becomes bigger than the distance between the shooter and the target, which usually means, the bullet passed/missed the target. Homing/manually controlled missiles may be an exception sometimes, I guess, but since it is about shooting at foot mobiles specifically, that shouldn't be a problem.
  8. NearestObjects for sure? Because this: https://community.bistudio.com/wiki/nearestTerrainObjects provides such filters.
  9. So, you're saying, same thing, as with HAS feature, happens also with vanilla respawn module?
  10. Yep, but you're saing, there's one additional heli in your case. He said about 10 or more. If the exact number would correspond to the number of connected PC machines, it could give some clue about the cause (like code meant for server only being executed on every machine; if not - it at least exclude one possible cause).
  11. Frankly passed too long time, and I managed to forgot details about this issue, I probably should revisit the code in case, I can figure something new now, maybe one day... How many PCs was participating in the gameplay? To be exact - was that number equal to amount of respawned helis?
  12. Rydygier

    [COOP] Seven Samurai

    @icewindo, so good so see you around, it was years since last time! 🙂 Thanks for the tip. Googled some footage, animations look awesome indeed, requires a mod of course, could be optional though. I'll explore this deeper. As na offtopic, you may be interested also in this, old good times, eh:
  13. Well, if available, a carpet may replace a broom for CSAT mages, they're mostly Persians after all... 🙂
  14. Updated to v0.62: - small fix in the code restoring proper spellbook GUI work after resuming saved game.
  15. Updated to v0.61: - userconfig replaced by CBA solution in game: CONFIGURE ADDONS button at init map screen; - new init settings for experience gain rate and initial player level; - improved compatibility with dynamic scenarios etc. (switching units, spawns mid-game, resuming saved game...); - updated manual; - various code improvements.
×