Search the Community
Showing results for tags 'unit'.
Found 8 results
-
The whole ME locks up and goes modal once the 'Group ID and makeup, renaming' is visible. Clicking anywhere off it, on the side inspector panel should hide it, and whilst it is open clicking any unit / group on the map (and scrolling/zooming the map) should be possible. As it is, if you have two units in two groups flying formation and you want to view this info, you have to click the first group, click the ? next to 'GROUP NAME' on the right inspector panel, then view it, then click the 'x' on the new dialog, then click the next group, then click the '?' again and then you can see it. It's a UX pain. Should be a quick fix please. -
2024-03-15 15:03:25.614 INFO TLC (Main): onEvent ENTERED 2024-03-15 15:03:25.614 INFO TLC (Main): ******* S_EVENT_PLAYER_LEAVE_UNIT ******* 2024-03-15 15:03:25.615 INFO TLC (Main): onEvent ENTERED 2024-03-15 15:03:25.615 INFO TLC (Main): ******* S_EVENT_PLAYER_LEAVE_UNIT ******* Can anyone else confirm this bug?
-
As title says. I'm still waiting on ED to say what new stuff is coming to the ME as they never address it in their 'beyond' propaganda or their blog posts... but additions like this are critical to being able to achieve much more dynamic missions on the fly and reduce repetitiveness.
-
Initially I thought it was changed to make it more realistic, but I don't think so anymore. When I go to mission editor to place new aircraft group for player, I can no longer select MiG-29 or Su-33 (modules I have got installed) when I choose to fly for the USA (which is my logbook pilot set to). The modules are obviously available for other countries, for example Su-33 for Russia (100% agree here) or MiG-29 for Poland (also agree), however, it is possible to select Ka-50 for USA or F\A-18C for Poland (which is less than realistic on both accounts). I remember from the past that all installed modules were available for both USA and Russia as I was using it that way before version 2.7. Was that intentional change and I need to suck it up or is this a bug now?
-
Github link to download: https://github.com/Fallen-Technologies/OutofmyZone The formatting of the post is better visualized over on the Github page, I recommend reading there! Out of my Zone! A simple DCS Script for creating No-Fly-Zones for each coalition. Rather than creating an individual trigger for each aircraft, checking if they're in enemy air space, and exploding just that one unit. This script will do it with just 1 trigger per zone! REQUIRES mist.lua! Can be found here: https://github.com/mrSkortch/MissionScriptingTools HOW TO SETUP: 1. Create a ONCE trigger with a TIME MORE (1) and DO SCRIPT FILE mist.lua 2. Create a ONCE trigger with a TIME MORE (2) and DO SCRIPT FILE outofmyzone.lua 3. Create a zone to cover the area you want to protect. HOW TO USE: 1. Create a REPETITIVE trigger 2. Conditions: PART OF COALITION IN ZONE [enemy coalition, zone name, ALL] 3. Actions: DO SCRIPT outofmyzone('coalition to protect', 'zone name') [Ex: outofmyzone('blue', 'Zone-1') ] 4. Repeat for as many zones as you want! WHAT WILL HAPPEN: When an enemy unit crosses over the border of the zone, the script will create a 100 size explosion to destroy it. Then it will have pop up text saying "(Unit-Name) (Player-Name) entered enemy territory and has been eliminated" for 15 seconds EXAMPLE:
-
Having these at ALL, Coalition or Group is too broad. As these are the only way to have a player directly interact with the mission / AI / story, then these really must, from a Mission / Campaign Designer's point of view, need adding as soon as humanly possible. So many interesting interactions are just impossible if a player Unit can't have their own menu commands to interact with the story/mission design. Even an event like this where the initiator is the player Unit: S_EVENT_RADIO_COMMAND That was mentioned in this amazing post last year: We desperately need these... please. missionCommands.addCommandForUnit() missionCommands.addSubMenuForUnit() missionCommands.removeItemForUnit()
-
For some strange reason, despite having COALITION and GROUP IN ZONE condition detectors, the only way to detect if someone from that side is above or below a certain altitude is at the UNIT level. This causes a significant problem in the ME when dealing with large MP flights of multiple large groups. Instead, it would be significantly easier, quicker, cleaner and more useful to specify at the COALITION level altitude limitations and be able to have an ACTION based on those being busted.
-
The lack of getters in the api means that we have to create additional look up tables for all scripting spawned units/groups etc... and have to keep going back to them. That's memory, processing overhead, just because of a lack of useful getters on Group/Unit objects. Please fix this glaring omission.
