Jump to content


  • Content Count

  • Joined

  • Last visited

  • Medals

Community Reputation

283 Excellent


About madrussian

  • Rank
    First Sergeant

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. madrussian

    Patching bad Stairs

    Back at-cha. 😉 OK, I just tried this for both selections on my VR box (with and without that setObjectMaterialGlobal from my snippet above), and unfortunately both main part & trim stayed original colors (grey and white). Good trick to know though, will try that first next time I need to hide something. Also, makes me wonder what the difference is in objs that will hide with "" vs ones that won't. Also, I agree since putting this obj under the stairs, don't necessarily need to hide it. Only, I think one end may have to come up above stairs level slightly to work... not sure on that bit yet. Will try those pallets too! That sounds intriguing, will have a look. (Happen to know the obj type?) Good idea, will try it thanks!
  2. madrussian

    Patching bad Stairs

    Quick update, I think I can use setObjectTextureGlobal to hide my object, doing something like this: _texture = "#(rgb,8,8,3)color(0,0,0,0)"; _obj setObjectTextureGlobal [0, _texture]; Only I just tried it and that texture is apparently black. Anyone know where this texture format is defined? Edit: OK I found these "procedural textures" defined here. Edit 2: So my object (for starters) is "Land_VR_Block_05_F", a giant VR block. By default it's light grey with white trim. I confirm it has two textures via getObjectTextures. Now I can turn the object completely black via: _obj setObjectMaterialGlobal [0, "\a3\data_f\default.rvmat"]; _obj setObjectMaterialGlobal [1, "\a3\data_f\default.rvmat"]; _clearTexture = "#(rgb,8,8,3)color(0,0,0,0)"; _obj setObjectTextureGlobal [0, _clearTexture]; _obj setObjectTextureGlobal [1, _clearTexture]; Of course though, I need it to be transparent! Reading up on "procedural texture", I find the (0,0,0,0) part is (Red, Green, Blue, Alpha). My Alpha is 0, so seems the object should be invisible. But unfortunately it's still visible (again completely colored black). Any ideas?
  3. Looking for ways to remedy bad staircases in a few particular (older) building types. Using forced movement (via _unit disableAI "PATH"; _unit disableAI "ANIM"; _unit playAction "WalkF";), and the unit sometimes passes through the stairs and ends up trapped in the area below the stairs. (Poor soul.) I have a looping floor detection remedy in place for cases in old buildings where the unit falls half-way through the floor, in which case it pop... pops him back out. The floor detection remedy runs at a low frequency, so isn't really designed to catch cases where the unit falls (or otherwise passes) completely through the floor (like with these stairs). I'd like to try to place an invisible object with a walkable surface under the stairs to see if that catches the AIs that would otherwise fall though. The questions are: Anyone know of an object type in the game, which is invisible and has a walkable surface? Anyone know way to make an (otherwise visible) object invisible but still walkable?
  4. For the record, I never really overcame this issue. Also iirc, I did try all the vehicle locking commands too (but memory's a bit fuzzy on that now, so you may want to try it). The workaround I settled on for my Regroup script was to simply never doFollow mounted cargo guys (except FFV guys)... ever! (I mentioned a workaround where I was "teleporting the cargo guys out and back in directly after the doFollow", but that looked pretty ridiculous visually plus came with other unwanted side-effects.) I like kju's idea of simplified commands to accomplish these ends... especially dissolveSubGroup(s). (Or of course a fix for doFollow.)
  5. madrussian

    Alternative to assignedTarget

    Thanks, that's exactly what the doc ordered. Quick summary from the report (for those interested): Looks like two others had my exact issue with getAttackTarget for AI led groups, and like it currently works correctly for player squad AI. Very nice, there is hope still. 🙂
  6. madrussian

    allowFleeing default value?

    ^ Btw - I'm not disputing any of this (and thanks for weighing in!), just letting you all know my observations. Seems there is perhaps a bit more to the underlying fleeing formula(s), considering my test results. Also, I should have mentioned I ran those tests with one single mod loaded (CBA), which made it easier to observe everything unfold.
  7. madrussian

    Alternative to assignedTarget

    Quick follow-up, finally checked out the getAttackTarget command (running Development Build 1.99.146550). Result is quite disappointing. In short, getAttackTarget appears to be operating like an simple alias for assignedTarget. Specifically, same test as before: ^ Only now I also added green rays from unit to their getAttackTarget (slightly offset upward from the red rays so the two rays don't overlap). In my experience, the only time I see the green rays (for getAttackTarget) is when red rays (for assignedTarget) are already showing. In this case, both red rays and green rays appear at the same time (and always to the same target). [Also, I checked my code several times to ensure red ray points to assignedTarget and green ray points to getAttackTarget.] Next, I also independently monitored these units and verified that getAttackTarget returns objNull until assignedTarget actually returns a target, and then at that moment getAttackTarget also returns that same target. Even in cases where the unit was focused and shooting on me for some time well prior to me becoming his assignedTarget. I reread the getAttackTarget command description, which says: And the example given is: In summary, (at least at present) appears getAttackTarget command does NOT work as advertised (in the example anyhow). ^ Curious if someone else can confirm what I'm seeing in-game? (Important - Perhaps the description of getAttackTarget is actually correct, and this command will indeed return the target he is engaging, but he will aim and fire at other targets along along the way during his engagement of his main target.) Meanwhile, back to the original question: How to find out via script command who a AI unit is targeting, when he is obviously aiming at (& shooting at) an enemy unit, but he has no assignedTarget? Surely there is a way? Otherwise, if everyone is simply using assignedTarget, seems to me that can't be very efficient or proper for current AI mods. We need to know who these AIs are aiming at!
  8. madrussian

    allowFleeing default value?

    OK, I did some independent investigation. Two very different tests, with somewhat different results. Goals: Test kju's hypothosis (see post immediately prior to this one) Attempt to determine the default value for allowFleeing Btw - We've managed to reverse engineer the mystical skillFinal formula, so why not this too? Test #1 - Fleeing resulting from systematic unit deletion only (This test was actually performed 2nd and yielded more specific results.) First, two input values are set: _setCourage (sets every unit's "courage" skill to this value, when nil does nothing) _setAllowFleeing (sets every unit's allowFleeing to this value, when nil does nothing) On the VR Map, automated test repeatedly does the following: 1. Creates 16 west groups, each with 10 units, equally spaced around the map in a grid pattern (4 rows of 4 groups per row), each group so far away from each other that they should have absolutely no impact on each other. (160 units are created each round.) 2. Applies the _setCourage value to every unit via: if (! (isNil "_setCourage")) then { _unit setSkill ["courage", _setCourage]; }; 3. Applies the _setAllowFleeing value to every unit via: if (! (isNil "_setAllowFleeing")) then { _unit allowFleeing _setAllowFleeing; }; 4. Once all groups are created, the groups each have 1 man deleted, then for 0.2 seconds fleeing units are counted, then 1 more man deleted, then for 0.2 seconds fleeing units are counted, and this process repeats until only 1 man per group remains. 5. The total number of fleeing units is counted and reported. (Note that upon a unit being counted as fleeing, he is flagged and not counted again.) Result is between 0-160 fleeing units. 6. All units and groups are deleted, followed by meticulous (automated) checking to ensure all the test units & groups actually got deleted. (i.e original clean state is achieved). Observations & Results: 1. When courage is set, the units' courage has no bearing on the number of units recorded fleeing. This is true when allowFleeing is also set, and also true when allowFleeing remains completely untouched. Specifically: 2. When allowFleeing is set, it has a direct impact on the test. Specifically: ^ Note that for these particular _setAllowFleeing tests, these results are consistent no matter what courage is set to. ^ Note that for _setAllowFleeing 0 through 0.4, I indicate that "0 or X" men were counted as fleeing. Turns out tweaking one small detail of this test produces one result or the other. For _setAllowFleeing 0 through 0.4, when a specific (non-leader) is selected for deletion (see step #4 above in the test steps) like last in the group's units array or first non-leader unit in the group's units array, this (apparently) always results in 0 units fleeing. However, when a random group unit is selected for deletion, this (apparently) always results in the higher number of listed units fleeing. I know, this looks (& sounds) like some straight up quantum-entanglement-double-slit-observer-quirkiness or the like. Importantly though, I assure you these results are very consistent. Also note that for _setAllowFleeing 0.5 through 1, the results (apparently) always exactly match what you see above (thus I didn't mention "or" for these). 3. Based on this test alone, we can conclude that the default value for allowFleeing is 0.6! (because running the test with allowFleeing left untouched results in exactly 80 men fleeing, and also running the test with allowFleeing 0.6 also results in exactly 80 men fleeing ... along with all of this being completely independent of "courage" skill) ... Not so fast though! We have another test. Test #2 - Fleeing resulting from Actual Battle (This test was actually performed first, and the results are unfortunately a bit muddier.) On the Stratis Map, automated test repeatedly does the following: 1. Creates 8 west groups and 8 east group (8 units per group, using "Rifle Squad" composition). So 64 vs 64 men, for a total of 128. 2. Applies the _setCourage value to every unit via: if (! (isNil "_setCourage")) then { _unit setSkill ["courage", _setCourage]; }; 3. Applies the _setAllowFleeing value to every unit via: if (! (isNil "_setAllowFleeing")) then { _unit allowFleeing _setAllowFleeing; }; 4. Gives all groups a move orders towards opposing enemy group. (Note at this point every time I increased game speed to 4x manually via the provided key.) 5. The total number of fleeing units is automatically counted. (Note that upon a unit being counted as fleeing, he is flagged and not counted again.) Result is between 0-128 fleeing units. 6. The groups are allowed to battle until 1/4 of the total number (32 men) are killed leaving 96 alive, and at this point the results are automatically recorded. (A 180 sec timeout is provided for cases in which they won't fight, which in these cases all or too many units are fleeing.) 7. All units and groups are deleted, followed by (automated) checking to ensure all the test units & groups actually got deleted. (i.e original clean state is achieved) I ran this test over 1000 times, trying to establish the correlation between courage and allowFleeing (if any) and to hone in on the elusive default allowFleeing value! Here are the inputs & results: Observations & Results: 1. Very early in these test runs, I could tell that (in actual battle) both courage and allowFleeing impact a unit's propensity to flee, and that allowFleeing has a far greater impact. 2. I made a spreadsheet with multiple tabs to establish average fleeing values at various levels. It's pretty messy, and I'll spare you the gory details (unless someone really wants to see it). Instead if you simply scroll down through the results spoiler above, you'll see me honing in towards the default allowFleeing value. 3. Early in the testing I was doing 11 battle instances per game run (checking out courage over 0-1 values in 0.1 increments while keeping allowFleeing consistent -or- conversely checking out allowFleeing over 0-1 values in 0.1 increments while keeping courage consistent). However this test is apparently somewhat imperfect, as I could tell equivalent units (assigned the same courage and allowFleeing combos) were fleeing somewhat less over a single game run instance, as the number of battles increased. Once I noticed this, I started testing 50 battles per game run with consistent courage and allowFleeing combos. You'll see this starting with test run #300. 4. Based on this (battle) test alone, (at least when courage is 0.5) the default value of allowFleeing is ~0.525! So we have competing default allowFleeing results of 0.6 and 0.525... I really wish BIS could give us an allowFleeing alternate syntax that resets unit's allowFleeing to untouched, default state. Pretty please? 😄 If anyone has any related insight or otherwise, please let's hear it. Thanks!
  9. madrussian

    allowFleeing default value?

    Good info, yes I gathered that many factors affected when units break and flee, and assumed allowFleeing value was just one of the inputs. (Probably specifically having a big impact.) If this is true, then when I set to 0.5, should be exactly the same as setting to 1. (If I understand you correctly?) In fact, in my dynamic mission, I do set allowFleeing to different values (like 0.3, 0.2, and 0.1) based on the enemy order and thought I could tell a difference. But it wasn't a scientific test or anything. Anyhow, should be fairly easy to definitively prove or disprove.
  10. madrussian

    Alternative to assignedTarget

    I did see getAttackTarget when looking through all the target related commands, but something I read about that specific command on different command ref made me think it was for example, when an AT unit is going after a tank, the tank would be his "attack target", but he would target other units on the way to attacking tank. If getAttackTarget really returns what I'm describing in OP (getting the simple target), then I find it bizarre that anyone/everyone has managed to get by this long (since the beginning of the series) without it! Regardless, many thanks I will check it out and report back. 🙂
  11. Playing around with assignedTarget command, using some visual indicators and rays to see what's going on under the hood. I had always assumed that assignedTarget was how to tell who a given unit is targeting (and always used it this way), but appears this is actually only partly true and the implications are perplexing. Here the setup: It's just me the player facing off against a bunch of enemy, with player damage turned off so I can observe properly (aka without getting killed). So basically I have red rays being shown from all AI units to their assignedTargets. And when they don't have an assignedTarget, their red ray disappears. All enemies are aiming/shooting at me (again I'm the only one to shoot at), but only some of the enemy (perhaps 60%) have the red rays. So perhaps 40% of enemy dudes are aiming/shooting at me without me being their assignedTargets. The question is: For these remaining 40%, how do I get their target? (Btw - One conclusion I've reached based on this test is that assignedTarget is really about the leader assigning targets. Anyhow, how on earth do we simply get the actual target?)
  12. madrussian

    allowFleeing default value?

    Hey thanks for the idea! Let's see, I just found this related thread: If I'm reading this right, looks like somebody tried this very thing (courage subskill) and didn't see a correlation: Not to say I won't test this (courage correlation to fleeing) out myself, but seems fleeing is a pretty difficult thing to test. Would be nice to get a definitive answer from the devs. Anyhow two things would really come in handy: Knowing default value for allowFleeing A getter function for allowFleeing Bit more rationale for anyone interested:
  13. Greetings all. I'm creating some AI scripts, which need to disable certain AI features, like the following: _group enableAttack false; _unit disableAI "AUTOCOMBAT"; _unit disableAI "COVER"; _unit allowFleeing 0; So far so good. My AI can do it's many amazing thing(s)! However later, I want users to be able to turn off my AI and completely revert the group / unit(s) back to original states. So I am storing the original states like this: _group setVariable ["MRU_DAI_RestoreEnableAttack", attackEnabled _group]; _unit setVariable ["MRU_DAI_RestoreAutocombat", _unit checkAIFeature "AUTOCOMBAT"]; _unit setVariable ["MRU_DAI_RestoreCover", _unit checkAIFeature "COVER"]; _unit setVariable ["MRU_DAI_RestoreFleeing", 0.5]; ^ The problem is, the 0.5 for allowfleeing is a total guess on my part. So the question is: Anyone know what the game's default value for fleeing actually is (set-able via allowFleeing) or how to obtain it? I've been wondering about since... oh about the days of OFP. Description for allowFleeing specifies: But not what the dang default value is! (Hmmm... If no one knows maybe a kind dev could check it out real quick and report back? Then we could update the wiki for all to know.) 😄
  14. Hey thanks, and good to hear! Glad you are having fun. 😄 Let's see... I don't know about fair, but if you are looking for a serious challenge maybe try one of these: Play as FFI (French Forces of the Interior) vs enemy Wehrmacht. You will start outgunned big time. [Load with IFA3] Play as Takistani Locals vs enemy Armed Forces of the Russian Federation (perhaps on a fitting Old But Gold desert map... PR FATA comes to mind). [Load with CUP] Play as Syndikat (Bandits) vs enemy UNSCEF or Insurrectionists (perhaps on Tanoa), so you are fighting futuristic heavily armed & armored troops. [Load with Apex and OPTRE] Also, playing as IFA3 Red Army can be challenging because all the other major IFA3 factions start out with quick transportation (Jeeps or Kubelwagens). With Red Amy you'll get slower Studebaker & sluggish ZIS trucks, so it can be difficult to keep pace. (I could have given the Red Army US made Jeeps, but wanted them to feel different.) Also the Red Army's weapons seem to be outclassed by the Wehrmacht's, for most out the available maps, as Red Army has lots of PPSH submachine guns... great for CQC but not so much at longer range. To increase difficulty, consider playing on a terrain where the AI can more easily move it's vehicles around. For instance Tanoa is wonderful, but the AI vehicles get stuck back in the jungle on those dirt trails sometimes. So maybe pick a more fluid A2 terrain. Also, don't forget to fine tune the AI's SKILL and PRECISION under Settings -> Game Options -> Difficulty. This mission piggy-backs on these settings. For all those playing, curious what Player Faction / Enemy Faction / Terrain combos have you found particularly fun & interesting? 💡 If you're handy with scripts, in the mission folder open up "init.sqf" and add one or more of these variables at the top: // Use these to supplement the enemies' normal config-scanned man & vehicle types: //BUB_Mod_Occ_ExtraTroopTypes = []; //BUB_Mod_Res_ExtraTroopTypes = []; //BUB_Mod_Res_ExtraTroopTypes2 = []; //BUB_Mod_Sup_ExtraTroopTypes = []; //BUB_Mod_Civ_ExtraManTypes = []; //BUB_Mod_Occ_ExtraAA_Types = []; //BUB_Mod_Occ_ExtraTankTypes = []; //BUB_Mod_Occ_ExtraAPC_Types = []; //BUB_Mod_Occ_ExtraIFV_Types = []; //BUB_Mod_Occ_ExtraMRAP_Types = []; //BUB_Mod_Occ_ExtraArmedCarTypes = []; //BUB_Mod_Occ_ExtraTransportTypes = []; <- Troop Transports //BUB_Mod_Occ_ExtraFuelTruckTypes = []; // Use these to OVERRIDE the enemies' normal config-scanned man & vehicle types (and will also override the Extras above): //BUB_Mod_Occ_TroopTypes = []; //BUB_Mod_Res_TroopTypes = []; //BUB_Mod_Res_TroopTypes2 = []; //BUB_Mod_Sup_TroopTypes = []; //BUB_Mod_Civ_ManTypes = []; //BUB_Mod_Occ_LowThreatTypes = []; //BUB_Mod_Occ_MedThreatTypes = []; //BUB_Mod_Occ_HighThreatTypes = []; //BUB_Mod_Occ_TruckTypes = []; // <- Troop Transports //BUB_Mod_Occ_FuelTruckTypes = []; ^ Occ stands for Occupation (aka "enemy"), Res stands for Resistance (aka "player"), and Sup stands for Support. Thus... BUB_Mod_Occ_LowThreatTypes will override enemy's Armed Cars and MRAPs. BUB_Mod_Occ_MedThreatTypes will override enemy's APCs and IFVs. BUB_Mod_Occ_HighThreatTypes will override enemy's Tanks and AAs. So to address example of wanting more trucks with mounted weapons, you could eliminate APCs, IFVS, Tanks, and AAs completely, by setting all three of these variables to include only trucks with mounted weapons. ^ You won't technically get more enemy vehicles this way, but at least you can make the types fit your desired theme. Btw - Lol, you are the first person to mention this mission being too easy sometimes. If you'd like an option to up the pace of enemy vehicle deployment, I'll certainly add this in the next update. (Just say the word!) Also there are a whole lot more mod variables to tweak, if you're so inclined. Please see "Mods\_Reference\_ExampleMod.sqf" for a complete list. If you need any help figuring out how to make any of these mods work, just ask and we'll get it sorted.
  15. madrussian

    JBOY Bang Stick script

    Jungle time! I'm off to go track, hunt, and stick some spear hurlin' primitive natives with my new Bang Stick. Thanks j-boy!