Jump to content

Rydygier

Member
  • Content count

    3928
  • Joined

  • Last visited

  • Medals

  • Medals

Community Reputation

443 Excellent

About Rydygier

Profile Information

  • Gender
    Male
  • Location
    Poland, Pomerania

Contact Methods

  • Biography
    I was born, now I live and I will die someday.
  • Google+
    +Rydygjer
  • Steam url id
    rydygier
  • Linkedin
    witold-narwojsz-534183119

Recent Profile Visitors

1326 profile views
  1. [SP] HETMAN: War Stories

    Sorry to hear, maybe indeed the reason is PC specs. Seems, that slowing down typing isn't cause of the problem, just side symptom and further manipulating with it won't make a difference, if total removal didn't help. On my PC in the "noIntro" version, after confirming the parameters and after loading screen is completed, I just appear already as randomly chosen unit, I have pop-ups about support options, after a while Hetman starts and things are going on as usual.
  2. [SP] HETMAN: War Stories

    Well, luckilly, this can be done in no time, so despite lack of time for Arma - I did. Here is HWS version without typing/camera flight intro sequence: HWS no intro I'm curious though, if this indeed will help for your problem (can't say since I do not experience it anyway), or perhaps lags will now extend to the next minutes of gameplay.
  3. Angels fall first - Early Access

    It brought my attention today because of discount. Is it worth of time as for SP experience? Seems strongly MP focused. What interested me most, despite being "just a shooter", not close to Arma's mil-sim approach, it's still closer to imaginary "SF Arma" from all games I've ever seen, and you actually can board a ship or station and fight inside, fly, walk the planet surface, ride a vehicle, whatever. Game seems limitless in this aspect, which AFAIK is pretty unique. Too frantic for my taste though. Is there any noticeable lore you can immerse into, or any kind of narration, context, a plot or just random, generic matches without any background?
  4. Perhaps, just for me it's a shame, NMS is probably closest, yet still not that, I would love to experience in such kind of game. BTW It was closer to my ideal, when devs was talking about NMS during development, than it appeared to be after release. Casual sightseeing with some more or less weird distractions is not exactly what I'm dreaming about, yet close enough to make me dream.
  5. I understand him very well. Same problem here. It should be about genuine discovery; to go, where no one go before, to see, what no one saw before, devs included. But instead, as for the feeling, it's rather about "tourism". One of the bigger cons of NMS. NMS is much better after last update, although personally I still wait for more updates, some crucial to me aspects still beg for a lot of attention (fauna "ecosystem" is a bad joke for example, a placeholder at best).
  6. [SP] HETMAN: War Stories

    In HAL it is disabled by default, but for HWS I enabled it. This way, in the init.sqf: RydHQ_CargoFind = 1;RydHQB_CargoFind = 1;, so you don't need to enable it. Note however, even if at the moment there is some not busy cargo vehicle, all other conditions described in 5.4 have to be met. If so, then after your group is tasked with proper kind of mission, it will wait at some position till cargo vehicle arrive, then all should get "embark" order etc. Could be less reliable with aerial vehicles, for example sometimes they tend to go up too soon or even fail to land.
  7. [SP] HETMAN: War Stories

    Some general rules you may find in the HAL manual (see chapters 5.4, 5.5 and 5.11). Assuming, all works, as should. Apart from that, of course, proper support/arty unit must be present on the map, which is heavily random, but rather scarce IIRC, so even, if there is such vehicle, it's good chance, it's busy already. In general, due to many factors both scripted and dynamically appeared due to organized chaos of the course of events don't treat support as something sure, reliable, immediate etc. Likely many of the support calls, you saw, wasn't satisfied either. Rather be happy, if/when it happen. I think, most often you should see arty support, because they at least don't need to reach destination of supported troops. But then again, arty is rather rare, conditions of usage rather strict and possible targets often many to choose from. Using RydHQ_Debug = true;RydHQB_Debug = true; at least allows to see on the map currently prepared/conducted fire missions. An example. Just tried three times. 1st - no arty, no logistical support present (judging by military markers on the map), but there was some choppers. 2nd - no arty, one repair vehicle present, that's all. 3rd time was with single Scorcher unit on our side. Enemy was far, took defensive position, my group was on recon before the attack. Knowing thanks to debug markers, where enemies are, I detoured a bit and personally spotted and (automatically) informed HQ about hostile truck. There was no other targets known and this one met all the conditions, so HQ soon assigned fire mission (radio message + green comm text on the map), rounds was shot, target was destroyed. Pretty satisfying. That's how it was looking: This way it works in HAL/HWS.
  8. WeaponSights Zoom

    Great. :) Just to make the principle here as clear, as possible: The class after ":" is the class, from which the class before ":" inherits all its values except those, you are changing for it (zoom values in this case). The class after ":" is/should be a class just one step higher in the hierarchy, that the class before ":". An example: Let's some "classA" is: classA { valA = 1; valB = 2; valC = 3; }; Now, if you do this: classB: classA { valC = 4; valD = 5; }; The resulting config of "classB" will become: classB { valA = 1; valB = 2; valC = 4; valD = 5; }; (you changed one of inherited entries (valC) and added one new (valD), the rest (valA, valB) is inherited not changed from classA). That's what I know. In your case, you needed to inherit the class, you was editing, from the class, where entry defining magazines was defined, but instead it was inherited from the other, few steps higher class, where such magazines list wasn't yet defined.
  9. WeaponSights Zoom

    I can only throw some guesses here, not the config specialist. My blind theory is about this bolded line: class rhs_weap_m4 : Rifle_Base_F Maybe in fact rhs_weap_m4 isn't direct inheritor of Rifle_Base_F, but there's something inbetween, where RHS magazines are defined? Did you tried instead: class rhs_weap_m4_Base; class rhs_weap_m4 : rhs_weap_m4_Base Because from the link, you gave, RHS magazines for rhs_weap_m4 are apparently defined in the rhs_weap_m4_Base class, not Rifle_Base_F (obviously, since Rifle_Base_F is vanilla class). Seems to me, you omitted the step, where proper magazines are defined. Only guessing though, wasn't even awared, such "bypass" via changing mother class is possible.
  10. Yes, a group name. Like: RydFFE_NoControl = [GroupName_1, GroupName_2,SomeOtherGroupName];
  11. [SP] HETMAN: War Stories

    If it types forewer, then something went wrong on your end, because normally it doesn't take long. No idea, what. To remove this part some changes in scripts are required (thus some scripting skills). Also lags may be still present, if not caused by typing itself. If you wish to try, edit init.sqf at lines 2154-2176, perhaps this way (not tested): RYD_init_cam camSetRelPos [0,100,1000]; RYD_init_cam camCommit 0.5; RYD_WS_Typed = true; /* [ [ [_briefing,nil] ], nil, nil, nil ] spawn RYD_BIS_fnc_typeText;*/ sleep 0.5; [] execVM "RydHQInit.sqf"; RYD_init_cam camSetTarget _vh; RYD_init_cam camSetPos ((_vh modelToWorld [0,-35 - (_maxHeight - _targetHeight),_maxHeight - _targetHeight + 10])); RYD_init_cam camCommit 1.0; sleep 1.0;
  12. [SP] Pilgrimage

    Yep, COOP still is WIP, and since I've no time for Arma, sadly, my version will stay in current state for now.
  13. [SP] HETMAN: War Stories

    It's not your call. :) It is silently assumed, any group in need is calling for support. If transport, artillery or air units are randomized to be present and fight on your side, then it is up to HAL's AI, when where and how to use them. So you may get such assistance, if your HQ so decides.
  14. HETMAN - Artificial Leader

    Not sure, why you have "\RYD_HAL\" in your RydHQInit.sqf, but that's the cause, why scripts can't be read, and reason of consequtive HAL's error logs in your RPT. First "\" is the reason, to be exact, that is proper, when scripts are run from inside of pbo/addon, but not from the mission folder. Solution is simple - remove this \, so instead you will get: RYD_Path = "RYD_HAL\" that should work with scripts stored inside RYD_HAL folder located inside mission folder.
  15. HETMAN - Artificial Leader

    Demo mission is supposed to be run with the addon version of HAL, thus no Hetman scripts inside mission folder. If however you run script version of the HAL (so without the HAL addon), all scripts from "Script version" have to be pasted into mission folder. I hope, you don't try to run simulatnously addon AND script versions, these are mutually exclusive. :) Addon contains same scripts, so replaces scripts inside mission folder and vice versa. Yes. Plus stuff on the map of course (Leader, objectives, troops to be commanded). As for the init.sqf, you may check, if it even reaches the last line, perhaps it is stuck or exits somewhere earlier. So either add line diag_log "checking"; just above last line, run the mission and see, if inside RPT there's "checking" log, either temporarily remove everything from the init.sqf but the last line or move the last line to the very first line and test. Easier to see, if HAL works, if you use RydHQDebug = true; Just to be clear, Hetman =/= HWS. HWS is complete scenario, that contain Hetman but also more stuff. Faction shouldn't be a problem, side is what matters - Leader has to be of the same/allied side, as commanded groups. That is west, east or independent. Civilian/POW side excluded.
×