Jump to content

madrussian

Member
  • Content Count

    923
  • Joined

  • Last visited

  • Medals

Everything posted by madrussian

  1. I need to detect and stop the impact of a mortar. Create a “dud” if you will. Any ideas? Some background: I originally wrote a simple mortar script which randomly creates a bunch of explosions directly on the ground. I’m replacing that script with an improved script using real mortars that travel through the air from origin to target. I create them via createVehicle, position at the virtual artillery source via setPosASL, use kinematic equations to determine a firing solution (aka trajectory), and sent on their way via setVelocity. Finished the script and everything works great, mortars fly to exactly where I want them. Here’s where the trouble starts. The whole reason I wanted real flying mortars is for that whistle sound, so the players have some warning that a round is incoming. Fortunately, the whistle sound works great for the player whose machine created the mortar. Unfortunately, the whistle sound is entirely missing for every other player, defeating the entire point of the new script. So my idea now is to send a mortar round on every machine, hoping that all players will hear the whistle. Fortunately, this works! All players hear the whistle! Now I just need to send one real mortar round (for the player that called in the mortar), and a bunch of “duds” for the other players. I need help with the “duds”. So here’s the question: Anyone know how to stop the impact of a mortar (preferably via simple command or EH)? (P.S - I’d like to keep this clean and avoid looping scripts, but happy to hear any & all ideas.)
  2. 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?)
  3. I'm developing an AI system, and need to get the types of various buildings. This is usually trivial, as one can use the nearestObjects or cursorTarget commands. But on Dingor Island, turns out certain buildings are actually (apparently) technically terrain objects. There are at least two of these I know about: the large apartment style buildings (which come in 3 different heights) and these small wooden huts. For my AI system to work properly, these terrain object buildings are no good, and I need regular buildings instead. The main problem is, that typeOf on these terrain obj buildings doesn't work (returns empty strings). Thankfully I've succeeded in detecting and swapping out the large apartment buildings, like this: Detect all terrain objects via nearestTerrainObjects (within the desired area). Get the string of each of those objects. (Because, again typeOf won't work on these terrain objects) Get all the terrain objs within that set where substring "ibrpanenak" is present (which I guess "panenak" is Czech for apartment). Hide the offending buildings via hideObjectGlobal, and place in usable (i.e. normal, non terrain obj) building that's essentially the same thing with a different texture, in this case building type "Land_Panelak1_Grey". So far so good. But then unfortunately, I tried this same method for the little wooden huts, and turns out the string of these particular terrain obj buildings don't return anything useful (only substring "house", which of course is the base class for most buildings). Couple questions: Anyone know where terrain objs are defined in the config? (I suspect cfgVehicles, but have not been able to prove this, seeing as I can't actually get the types for these particular "building terrain objects".) If these "building terrain objects" are actually defined within cfgVehicles, that means they must have a type. How can I get their type? OK, that's it. I welcome any and all help, even with simple things I may have missed. 🙂
  4. Thanks, I just checked and "Land_Hut01" (... to 06) use different models than our "house.p3d" hut. Which is fine, but the "house.p3d" huts in Melana Resort are special, because they offer 360 degree defense (via the windows & door on all sides). My AI system uses buildings, and every building needs a type in order to be used. And I was trying to make sure all 360 degree defense buildings can be used. I suppose I could re-write a good bit of my code so it can handle "terrain object" (aka type-less) buildings too. But probably not worth it for a silly wooden hut. On the other hand, if I start finding a whole bunch of these "terrain object" buildings then will have to rethink it. And btw - There are a ton of panelaks on Dingor, so this "terrain object building" phenomenon might be more prevalent than we might otherwise suspect. In the mean time, will do a quick query sooner or later and see if any cfgVehicles buildings use that "house.p3d" hut model (again for it's nice 360 degree defense), and if possible auto-replace like with those panelaks. Thanks for info & ideas guys!
  5. Wow thanks, that's quite a detailed response! Looks like it will probably work. Btw- Not necessarily going for speed for this building replacement routine. It's more for the demo mission, just to get the right buildings in place (and only happening in a smaller area). But yes, definitely nice to know which is quicker. 🙂
  6. Thanks, yes that's pretty much exactly what I'm doing for those panelaks (small, medium and large). With those, I happened to get lucky because even though panelak.p3d objs have no type name, I knew of the equivalent building(s) type to replace them with. (I was using str command instead of getModelInfo in my method though. Thanks to you guys, I know how to use getModelInfo effectively now too.) It's those wooden huts I'm having trouble with. If we assume for a moment that they have no type (which I'll confirm soon), the problem is I know of no equivalent cfgVehicles type to replace them with. (If your curious about which huts I'm talking about, they are on Dingor Island at the Melana Resort, which is along the NE corner of the big airport to the south, which itself is just east of Calamar.)
  7. Wow, that is mighty useful indeed! (If anyone hasn't seen his video, please do click on that link.) Sounds like your tool is just the thing, to be able to tell immediately whether these huts have a type or not. Super handy advise, thanks! Ok so, if I ever want to determine via script whether a terrain obj has a type or not, sounds like I'd want to: Use getModelInfo on the terrain obj to get the model string, and then perhaps query cfgVehicles for types using that model (via some property, probably model or similar)? And if query comes up empty, that should tell me that no cfgVehicles types use that model? ^ Does this sound reasonable, or is there a simpler way to do this (again via script)?
  8. 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?
  9. 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!
  10. 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?
  11. Stumped at the moment by A3 issue. This one's pretty simple to recreate and witness. Running doFollow on a group of men in a vehicle (in this case my own squad), causes all the mounted cargo guys to disembark the vehicle. [Note that the Fire From Vehicle (FFV) guys stay mounted.] I absolutely need to use doFollow as part of a Regroup script for my Group Linked Respawn system. But I can't have men errantly disembarking like this! I have tried numerous things to keep them in their seats: allowGetIn true, orderGetIn true, getting their cargo index via getCargoIndex and reassigning it back to them via assignAsCargoIndex, then directly moving them back to own seat via moveInCargo [_vehic, _cargoIdx]. I even tried disableAI "ALL" on all my mounted subordinates before calling the doFollow. But still, the cargo guys keep bailing out. Anyone else run into this? Any ideas on how use doFollow without it ejecting your (cargo) subordinates from their vehicles? I welcome any and all help, inc simple things I may have missed. Thanks!
  12. 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.)
  13. 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. 🙂
  14. 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.) 😄
  15. 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.
  16. 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!
  17. 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!
  18. 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.
  19. 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. 🙂
  20. 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:
  21. Blasting away the limitations of classic Group Respawn, taking mission dynamics and customization to the next level, I proudly present “Fight Back!” My goal was to create a dynamic mission that would completely surprise on every playthrough, and I got a little carried away. Fast forward 3 years... Well long story short, please try it out and let me know what you think! Major Features Battle a vicious & cunning enemy AI, hell bent on your destruction. Customize your playthrough with easy & flexible Start Menu. Locate and Enlist Fighters who join your group and give life to your cause. Strike Back and complete Major Objectives, awarding you essential Assets & Manpower. Build a small army (if you can), and marshal your forces in a desperate struggle against the odds. Command your newly acquired army via a simple & intuitive map-based system. Optimize your own personal squad with essential Voiced Commands (optional). Call in devastating Supports, including brutal WW2 style Bomb Runs. Win a stunning Total Victory or suffer a crippling Total Defeat. Wage the entire epic battle (playthrough) in one sitting (~50 min or less). Minor Features Play in SP and MP (works equally well in SP, Hosted Server, & Dedicated Server), all with a single mission file. Defend your hidden base. Lose your base, and all is lost! Activate the Home Guard, which will defend your base to the last man. Engage in Asymmetric War. The players and the AI enemy have surprisingly different objectives, creating a dynamic and deadly battlespace bursting with possibilities. Survive (if you can) with Limited Lives using my custom flexible Group Linked Respawn system. Engage a fully integrated and voiced Custom Supports system. Importantly, your supports persist upon your death and takeover as a new unit (even if you were killed mid-way through calling them!) Track, locate, and dispatch a quick and wily collaborator who will run like hell. Free civilian captives & rescue vulnerable colonists, who will gift you important vehicles. Steal enemy supplies, and transport them home for base defense. Experience a dynamic & fluid enemy AI with direction and purpose. Fight Back and defeat the blitz (or die trying). This mission is similar to CTI (on a smaller scale), only you “build” by winning. Please read through the briefing 1st time before playing, as the respawn system is pretty ground-breaking (in a positive way) and probably quite different from anything you’ve played before. This mission plays better with content mods! It’s geared for CUP, RHS, IFA3, FOW (supplemental to IFA3), Unsung (including Unsung’s DSAI), and OPTRE. Update: Global Mobilization fully supported! When playing with GM, please see notes below on how to properly select support faction, to ensure your air assets are as “era appropriate” as possible. All of these mods & DLCs are optional of course. It should work with any unit and vehicle mods (as it scans the configs for unit and vehicle types), but if you’re having an issue with a particular mod, please let me know and I’ll see what I can do. Also, it might have issues with mods that use the custom radio script commands (mere speculation based on my use of those commands). ATTENTION – Please do NOT run with AI mods installed. I love AI mods too! But this mission relies on completely fluid AI and every AI mod I’ve tried has caused big problems. If you’re not convinced, please read this: Once johnnyboy finishes his “JBOY AI Scripted CQB Path” and we have most of the buildings in the game mapped out, I definitely hope to include the combined system here in this mission (maintaining AI’s fluidity, etc). Porting to New Terrains Again, this mission relies on completely fluid AI. It takes thorough playtesting and knowhow to set this mission up for particular terrains. It works beautifully on certain terrains (once set up), while on other terrains it simply does not work at all. I have a very good handle on which are which, and have this mission working on 50+ terrains so far (certainly more than I have released), and can always release more. Also, some were quick to set up (~3 minutes), while some took forever. For instance, latest Lingor took me 10+ hours to set up and is bat-shit crazy to look at in the editor, but it sure works great now! If you’re curious on whether this mission will work on a terrain or not, simply ask and I’ll do my best to let you know. Anyhow enough talk, please try it out! Have fun and if you have feedback, I’m very interested in hearing! Gameplay Screenshots "Choose Your Adventure"  "Catching Some Air on the way to First Objective" "Say Hello to my Little Friend" "Nazis, I hate these guys..." "Truck?!? What truck?" "On the Move" "Here Come the Bombers" "Knockout" "Lone Survivor" "Quick, he's getting away!" "You can run..." "But you can't hide." "Ambush" "All Quiet on the Western Front" "Hold the Line" "Let's get these civilians to safety" "Did someone order Napalm?" "War is Hell" "Inside Dante's Inferno" "The Bitter End"  The Briefing Required Addons 1. Community Based Addons – Don't forget this one! 2. MRU Mission Assets – Contains all the sound effects (plus small ammo type the bombs need to work properly) Highly Recommended Addons (Optional) 1. Flashpoint Music Pack – Gotta love that old OFP music! Don’t know about you, but every time I listen it speaks to my very soul. When this addon is detected, a random track will automatically play on mission startup (customizable in Start Menu) 2. MRU IFA3 Revert Soldier FOVs – Re-adjusts IFA3 soldier FOVs back to vanilla levels. This mission was created and adjusted for difficulty prior to IFA3 introducing limited soldier FOVs, and this addon helps restore mission difficulty to intended levels. 3. MRU IFA3 Reduce Soldier Armor – Same thing as IFA3 “Revert Soldier FOVs”, but with soldier armor protections. Imo, makes this mission more enjoyable & fair. Of course, to each his own! 4. MRU Animation Fix – If you have your ArmA3 keybinds setup like mine and try to go from stopped and kneeling with rifle directly to sprint with rifle, you’ll see a broken animation transition. This addon fixes that! (CUP used to fix this broken animation transition, but not anymore due to one of their recent updates, so I created this little fix addon.) Mission Downloads Subscribe on Steam, with 52 terrains now and counting! Note - For the best initial experience, consider playing first on a BIS terrain or the excellent Isla Duala. These terrains have towns & buildings mostly spread out evenly and always make for a great run. Note - I developed this mission on Chernarus (Summer). Here are all the mission links (by terrain): Altis Chernarus (Summer) Chernarus (Winter) Malden Takistan Tanoa United Sahrani Zargabad Aachen Outskirts Afghan Villiage Aliabad Anizay Bariga Beketov Caribou Frontier Crossroads Bocage Fallujah Fata Hazar Kot Hellanmaa Helvantis Ihantala Ihantala (Winter) Isla Abramia Isla Duala Kranorus Kujari Kunduz Leskovets Lingor Lingor (Desert) Lythium Napf Napf (Winter) Neaville Neaville (Winter) Palau Panthera Panthera (Winter) Pecher Porquerolles Roche Ruha Saint Kapaulio Summa Summa (Winter) Thirsk Thirsk (Winter) Trava Vidda VT5 Zarzibash
  22. 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.
  23. 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!
  24. Putting the finishing touches on my dynamic mission (release hopefully today or within mere days now!) OK, so I read through Mission Presentation page, and learned I needed to created proper overview and loading screens (1024 x 512 res), which I did (and they look nice and professional, if I do say so). Then I read through "description.ext" page and I set all the appropriate variables in my "description.ext" (as far as I can tell). Note that I'd like to make all my Overview and Loading screen changes inside "description.ext" and change nothing in the Eden Editor (via "Attributes" -> "General") if possible, because I have perhaps 30 terrains I've ported my mission to, and keeping these updates to Overview and Loading inside "description.ext" (only) will keep the porting process to a simple copy/paste! Now in editor I reload the mission, and perform "Export to Single Player" and "Export to Multiplayer". At this point, I exit editor and try opening mission from Main Menu, to inspect my changes. In MP Browser, I see my new Overview screen with the title and description (and author), and everything looks correct! Good so far, so I select mission and fire it up, and see my new Loading screen with the title and description, and again everything looks correct! So good to go for MP. Now I go back to Main Menu and check out SP (via Single Player -> Scenarios). I see my exported mission, but the name is not my chosen mission name, and is (unfortunately) simply the file name of the mission file. I select it and there's no overview picture (static only), and the author says "Unknown Community Author". In my "description.ext", I have set all these related variables: author, briefingName, overviewPicture, overviewText, overviewTextLocked, onLoadName, loadScreen, and onLoadMission. Again it's working for MP... so kinda stumped atm. So the question is: How do I get the Overview screen to work correctly in Single Player -> Scenarios? I welcome any and all help, even simple things I may have missed, thanks.
  25. @kremator - Sounds good & will keep you in the loop! OK you should have a PM with those missions. 😉
×