Jump to content

Rydygier

Member
  • Content Count

    4805
  • Joined

  • Last visited

  • Medals

  • Medals

Everything posted by Rydygier

  1. Thanks! Could you provide that exact Tanoa mission for testing, please? Be sure, it's vanilla, if so.
  2. 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?
  3. Frankly I didn't think to test this. Must figure out something. 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. 🙂
  4. 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.
  5. 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. 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.
  6. 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...).
  7. 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.
  8. 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...
  9. 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.
  10. 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.
  11. 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. 😕
  12. 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.
  13. 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.
  14. NearestObjects for sure? Because this: https://community.bistudio.com/wiki/nearestTerrainObjects provides such filters.
  15. So, you're saying, same thing, as with HAS feature, happens also with vanilla respawn module?
  16. 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).
  17. 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?
  18. 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:
  19. Introduction In these war torn lands no one cares for common people. The locals fall victim to unpunished bandits who plunder the peasants without mercy and murder the resisting. Inhabitants of this village became so desperate, they decided rather to die in defence than to endure suffering any longer. Still, they are simple folk, not familiar with combat. Therefore they decided to seek help of the ronins, masterless samurai. Namely those of them hungry enough to work for food, because villagers have no any valuables to offer. They found seven volunteers. These dangerous people were feared in the village, but ready to die in defence of the helpless. Without a payment, not expecting any gratitude, without hesitation... Video Details This scenario is simple, quick-to-play MP mode, where players job is to save village from brutal bandits attack. Although it can be played solo, SP even, it is meant for COOP. This is my very first project of such nature, I never made anything MP-focused before and that's exactly why I wanted to create just once something of that kind. The village is picked each play at random from any proper locations found on the map (Altis, although porting to other maps should be very easy). Randomized is also available gear (the content from owned DLCs and loaded mods should be potentially included) and hostiles. Scenario includes several mission parameters, that allow to customize the tactical and enviromental factors from the lobby. Melee mode requires KA Weapons Pack NEW (melee mode will autodisable if mod not present). It should be considered experimental, fun mode, work best in solo gameplay, there may be glitches for non-server players. Rules: 1. Players start inside the safe zone. As long any player is out of the safe zone, the countdown is going to zero. 2. When the countdown is ended, the safe zone is removed and the attacks will begin soon. 3. Players can arm themselves from the boxes located in the center of the safe zone, at the flagpole. 4. Bandits will attack from random directions in random waves. 5. If too many villagers die - the mission is lost. 6. If all samurai are dead - the mission is lost. 7. If all bandits are dead - the mission is won. 8. Civilians will 'shout' about known hostiles near using 3D exclamation mark icon over their heads. Color of the mark indicates how close the enemy is (green - far, yellow - close, red - very close). 9. Player names change colors depending on player's status: dead - dark red; generating noise/speaking - white; incapacitated - purple-red; no ammo - yellow; critical wounds - reddish; serious wounds - purpleish; moderate wounds - blueish; all OK - blue. 10. There's no respawn, only spectating mode after death, but revival is often possible. Porting: Need to be confirmed yet, but seems, that porting is as easy, as changing map name in mission folder name, so for example: SevenSamurai.Altis -> SevenSamurai.Tanoa. Target map should have some "NameVillage" locations with at least 20 enterable buildings in 150 meters radius around. Download Seven Samurai 1.02 (Dropbox) Seven Samurai 1.02 (Steam Workshop) Seven Samurai 1.02 - open folder (Dropbox) The Magnificent Seven spin-off Notes The basic premise is based on Seven Samurai movie by Akira Kurosawa. This project is my humble homage to this movie in fact. I highly recommend to watch this classic, it is great, highly inspiring piece of art and also knowing it helps you feel and tune in better during the gameplay. It may be easy to die in this battle, so remember - do not feel bad about your death. It is anticipated and welcomed. You're a samurai, and this is a good, honorable death, such is your way. Savor such a noble end of life! Credits & licenses Scenario utilizes slightly customized A3 Wounding System - AIS Revive by @Psychobastard. My thanks to: @Gunter Severloh for testing, video overview and some good advices. Katana for melee mode from KA Weapons Pack NEW by KICKASS. Additional sound effects (edited: stereo to mono, normalized, most shortened/cut fragments) from: 1. http://soundbible.com/ By: Mike Koenig, Sound Explorer: Attribution 3.0 license, Vladimir: Public Domain license, man: Sampling Plus 1.0 license; 2. https://www.zapsplat.com By: ZapSplat, Audio Hero, PMSFX: ZapSplat's standard license, Still North Media: CC0 1.0 Universal license. Changelog Terms of Use
  20. Well, if available, a carpet may replace a broom for CSAT mages, they're mostly Persians after all... 🙂
  21. Updated to v0.62: - small fix in the code restoring proper spellbook GUI work after resuming saved game.
  22. 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.
  23. And after short test it seems to work, for sure for the player... but as I see for example HWS specificity makes some adjustements in Rincewinder necessary.
  24. Ha ha, good one! In fact I certainly plan to try both together (it was long since I actually play Pilgrimage...).
  25. Any obejct that has a class and is detected by nearestObjects command should work. How looks your RYD_HAS_SignalClassesNight array? How exactly looks ignoring? Reaction wouldn't be immediate, there's some delay between making a signal and loitering chopper reaction. Also this matters: RYD_HAS_SignalSearchRadius = 150;//how far around call position heli should search for proper signal to land. Avoid too big values (CPU heavy) Common, default signals are flare and smoke grenades (all of "SmokeShellGreen" and "FlareBase" kind at night and "SmokeShell" and "FlareBase" at day).
×