Jump to content
Bohemia Interactive Forums

Rydygier

Member
 View Profile  See their activity

  • Content Count

    4805

  • Joined

  • Last visited

  • Medals

  • Medals

Posts posted by Rydygier

  1. Posted

    Thanks, yeah, one of those projects, where I stopped accepting big requests, because started to have problems with unpredicted consequences of the changes. The code has grown too complex. 🙂

     

    AFAIK - depends. I mean, it should be possible to auto-embark AIs only, order the heli to fly somewhere, then auto-disembark them, also via fast roping (yes, optional, atm less reliable, than I would like though, apparently...):

      

    RYD_HAS_AutoInOut = true;//if all RYD_HAS_STT units should be sent to embark/disembark RYD_HAS_Chopper automatically. Doesn't affect fast roping, which is always automatic

     

    Thing is, someone - basically a player - has to call the heli for the HAS task and pick the destination after embarking. There's no AI routine for that parts like, say, it is in Hetman. In order to automatize those steps extra coding would be necessary. Also auto embark/disembark wasn't tested very thoroughly, not quite sure, how reliable it is. 

  2. Posted

    As someone said to me and I confirmed just now, setWantedRPMRTD command seems "to push" RPM in proper direction (and probably with actual rate necessary to change RPM from current to desired value in provided time), just fails to stop at desired value, goes in linear manner indefinitely (?), therefore in order to use it to keep RPM at desired level one need to repeat that command all the time, as it seems.

  3. Posted

    So, it may be due to my undisputed ignorance as for AFM topic, basically using this first time in my life, still, I had a reason to test some of these commands, and either these are bugged, either I do not know, how to use them properly. 

     

    First, enabled AFM in the game options, then in the scenario entered Hummingbird, used "engine ON" mouse action and watched:

      

      enginesRpmRTD (vehicle player) 

     

    via the console. It reached [4000] and stabilized, so far so good. 

     

    Then used this:

      

    vehicle player setWantedRPMRTD [2500, 10, 0];

     

    Expected value after 10 seconds is [2500], as I understand. But instead this value started to drop probably without end, I stopped the test below.... [-9000]. Yes, negative value, and dropping. 

     

    Any ideas, how to reliably control heli's RPM via SQF in AFM 🙂 or I am doomed?

     

     

    BTW tried also 

      

    (vehicle player) setEngineRPMRTD [2500, -1];

     

    does nothing at all as far, as I see. Also this:

      

    stopEngineRTD

    works in immediate manner (the heli freezes immediately). It's intended behavior?

     

    Is there any RTD equivalent for usual engineOn command?

     

  4. Posted

    4 hours ago, Gunter Severloh said:

    Odd, Rydygier may ask for a repro for that only warning you

     

    Yep, I may, and vanilla of course. 🙂 Since it doesn't occur in my SP tests, IIRC, it may be some other MP thing or another VCOM interference of some sort.

     

    4 hours ago, phronk said:

    Also fast roping into an area kicked out the person who called the transport and they died. Everyone else (players) nside wasn't able to fastrope out and the heli took off to RTB.

     

    I always had limited possibility to test & debug stuff in MP and no real conditions to do so with more, than one player (no way to do so effectively), so MP environment is always more risky for HAS. There are issues not present in SP like locality and desyncs/lags/high pings etc. On the top of that there's always a risk of third party script/mod interference, game bugs and mission maker set up mistakes to make things even more foggy. And particularly fast roping part is sensitive to MP-specific issues, not all can be fixed here. I'll try, what I can, when I find more time, but it never was and, I dare to say, it likely never will be recommended option for MP gameplay. I know, I know, players like it, because it's... "tacticool" is the word? But in sake of smooth gameplay I always recommend touchdown option, fast roping, technically, is highly capricious ornament. 

    • Like 1
    • Haha 1

  5. Posted

    OK, I ran it once and I saw the first issue, with delayed/troublesome take off, it rather can't be explained by exec delays, so I have something to debug probably here. As for fast roping, in this run all went smooth and without any weird stuff, so this one possibly could be caused by exec delays, which aren't here, since you cleared the scenario from any other scripts, that could cause such delays I assume? But this was just a single run, I'll try find time next week to do proper debugging using this.

  6. Posted

    OK, from the footage I can guess some things.

     

    One, the delay between you selected destination and the time, the heli takes off likely may be caused by the map specifics. I must check this in the code, but in general, after you click, it searches around that click to find a position with enough free space. It is quite thorough, calculation-heavy part and tries until reaches farther, than 250 meters from the clicked pos, so if the map is object-intensive, like Tanoa, and there may be no such position to be found at all, then actually clicked position is used after all, but all that futile searching takes some time. To limit/avoid that try to reduce this value in the module settings: "Obstacles search radius (meters)". Maybe even to 0 (in such case, if you click a position occupied by any map object, you'll be dropped onto it, it may be harmless bush or a building).

     

    As for fast roping issues itself, not sure, but it looks, like the logic itself works, but suffers from serious exec delays, and this part of the code is sensitive to those. Same reason may also contribute to the previous point about searching free space delay.

     

    That much I can tell without actual testing the scenario myself, if you wish to link it. Some cool looking stuff - that scenario - BTW. 🙂 

  8. Posted

    22 hours ago, Gunter Severloh said:

    Again this could have nothing to do with HAS

     

    That should be possible to verify easily. Assuming, it happens consistently, edit your mission by removing HAS from it (deleting module should suffice), do not touch anything else, leave it, as it was. Then run it and try several times to do, what previously was causing the explosion.

  10. Posted

    Some time ago I saw this in my tests - I was entering the heli directly at the base position, without calling it, and it was exploding immediatelly after I got in (so it wasn't neither an AI neither spawned dynamically unit neither any mods involved). IIRC, it stays an unsolved mystery and if HAS is to blame here, stays unclear too. Could be specific to MP although not sure. Smells like kind of exotic game bug though, I mean, there's nothing in the HAS code, that possibly could damage the chopper in terms of commands used, except for that bug with multiple respawns. 

  11. Posted

    Great. Also describe your usual steps, like: "I'm using 0-8-1 to call the transport, I drop the smoke, when asked for, we all board in, when landed, then I choose fast rope extraction at (destination here), then we go, then shit happens". Including extra stuff like adding mid-waypoints or changing flight ceiling, any errors showing up or weird stuff going on etc. If you have RPT logs from such attempt - may be helpful too, as always. 🙂

  13. Posted

    There was few similar reports in the past, as I see (that parts of the code didn't change since), although I do not see this in my tests. Some clarification questions:

     

    Singleplayer or multiplayer? May be hard to fix, if due to MP issues.

    Happens also without any mods?

    Happens in the plain test of demo scenario included here? Compare differences between it and your set up if not.

    All units in the chopper are properly synced with the module?

  14. Posted

    22 minutes ago, Gunter Severloh said:

    Wondering if you have it where if the inventory is open then the right click to open the spell book is disabled.

     

    Frankly I didn't think to test this. Must figure out something. 

     

    22 minutes ago, Gunter Severloh said:

    i been getting that alot with the fireball

     

    This, or, in case of fireball, there's additional LOS check between mage and the target, but if failed, spell doesn't even start.

     

    Thanks for the ideas! Will be considered. 🙂

     

     

  15. Posted

    HAS 1.96wip2

     

    Added some code in order to prevent multiplied heli respawn bug - it may help. If not, there are also added some RPT logs, that may help to find the reason. That bug was happening to me sometimes (not always) server side too, even in SP, not tested client side before nor after fixes.

    I'll be grateful if anyone test this ASAP, new HAS version should be released till the end of this week, later I may be busy for longer time. 

    • Like 1

  16. Posted

    2 hours ago, Gunter Severloh said:

    like not one key responds

    on the whole keyboard, i can hear the spell book opening and such but theres nothing coming up for spells, just the info at the bottom of the screen shows.

     

    Did you perhaps play in editor and use restart button during pending mission at least once? This mod/script each run adds some eventhandlers to the main mission GUI display (display 46), editor's restart apparently doesn't clear them, so they're doubled and therefore I saw, what you described in such case. In editor you need to actually exit mission preview and start it anew instead of plain restarting to avoid that. I consider this more an editor issue, than mod's, but if I find any solution to it, I'l apply it. 

     

    2 hours ago, Gunter Severloh said:

    is to only make those spells available (seen) based on the level your at

    and not have any of the next level spells show until you reach that level.

     

    It is that way. You see only spells, your level allows, so if you're on the 1st level, there's only few of them visible. Some of them may be inactive, if you can't affor their mana cost. 

     

     

     

     

     

     

  17. Posted

    Updated to v0.7:

     

    Repeated previous wip changelog:

    - 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 audiovisual 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);

     

    New after wip version:

    - new config variable for adjusting general light effects brightness (RCW_BrightnessM, non-negative number, multiplier, 1 by default);

    - AI spell casting choices routine rewritten in order to make AI BM's spell usage a bit more thoughtful (for example expect resistance spell to be usual first choice in danger...). 

  18. Posted

    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. 

    • Like 3

  19. Posted

    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...

     

    7 hours ago, Gunter Severloh said:

    An idea for when a mage is killed and they die with a crazy effect, i wonder if along with the current effect that a

     damaging explosion could occur, like on the level of a gbu hitting the exact spot, or even artillery round, would make for an epic run for your life

     hes going to go feeling, would be like something like from the movie predator where when it knows its going to die it self detonates with a small nuke.

     

    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...

    • Like 1

  20. Posted

    On 10/23/2020 at 11:41 AM, Rydygier said:

    also seems, that treshold depends on the light color, which adds another layer of complexicity.

     

    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. 

     

     

     

  21. Posted

    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. 😕

    • Like 1

  22. Posted

    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:

     

    Spoiler

     

    Midnight - coefficient = 1

    eq-midnight.jpg

     

    Noon - coefficient = 28.5262

    eq-noon.jpg

     

    Noon - without coefficient (native brightness of 1):

    eq-noon2.jpg

     

     

     

    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. 

    • Like 5

  23. Posted

    2 hours ago, Alert23 said:

    And would it be possible to check if a bullet will 100% hit a target? 

     

    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.

    • Like 1

  24. Posted

    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. 

    • Thanks 1
×