Pikey

I think he was agreeing with the general sentiment I made about the base game was important to him but people don't buy that. Which tends to be a common view, if I understood correctly.

Tippis has outlined the reason, the Mission Editor cockpit parameters are provided for single player tutorials and dont work in multiplayer as client. You will see this with the green gates too. Although they work, you dont see where they are as a client. There's quite a lot of this going on in the application - things that only work in SP as player, versus things that work in both. Its definitely caused by how the product organically grew. Over the years there were some opportunities for standardisation disregarded...shelling zone, scenery removal, carrier lights, warehouse api etc. The following limitations are not documented on a per function level (by the publishers) Which functions work only as a lua function API ( from https://wiki.hoggitworld.com/view/Category:Class_Functions there's overlap but even the new Warehouse API not added to Mission Editor) Which functions work only as a Mission Editor condition or action (LOAD MISSION (really? yes really we've been using flags in scripting and triggers in ME), Training Gates (why cant we have these for scripting?, SET_CARRIER_LIGHTING MODE, arghhhh) Which functions work only in Single Player (shelling in zone, cockpit parameters, green gates, set failure, etc) Which functions have an API, matching trigger or action and work in single player and multiplayer (e.g. Push task, set task, mark to group, message to group, sound to etc) (side note: we have had things break in single player and not Multiplayer but thats not the normal way) (second side note - the entire lua game event system has the same limitaitons and some events do not trigger and never did in multiplayer. Others have different behaviours.) There's very little appetite shown in the last 15 years for making a standardization sweep that unifies these. We can assume that its not happening along with a lot of other things we would like to have. If you read this far you are the tiny tiny minority of players at the top of a pyramid of contributors that expand the attractiveness of the game whom have elected to spend their time in the least developed and greatest lost opportunity of the simulation itself. API's dont sell modules. I've had since version 1.2 to figure things out. I have no idea how anyone begins to learn and understand these limitations because I dont think they would make sense to an average person. I feel for you guys.

No sure what you mean, but this is exactly what I said. A new IFF system coming to DCS. It's a big deal, its a co-announcement.

The meaning of this is not that the Mig-29A will come without any functioning automatic mode 4 that the multiplayer community rely on, but a system will be built. There's been some built by third parties already, but they only work in limited ways. DCS hasn't done anything in this area before. To date, ED hone new systems on a single module. So I think this line is under the radar for its significance, since its saying there will be an ED IFF system of transponders, codes and interogators and the implication is that its an actual system that will be in use across modules. What do you think? What do you wish for in that system? Would you like your own side engaging with you if your transponder is out? SAM's with or without interogators? Rules of engagement? It's a big topic.

Where did all the old Afghanistan posts go? Specifically looking for the ones that debated whether this map was "interesting" and what type of games we could come up with, as a community. What's the attraction of an Afganistan map as a location for a 'game'? For aircraft targetting infantry, the infantry we have are of mediocre animation for the best ones, the ground AI routines have much less detail than a plane AI. For aircraft targetting vehicles we have some good new additions, but we are talking only 2 shapes of three types - arty, technical and airdefence. Thats 6 units out of the entire catalogue of DCS. For aircraft vs aircraft - nothing to simulate. For sea or ships - nothing to simulate. No offensive radars of any type to avoid/destroy. If you just want a sandbox (no pun intended) and don't care what's simulated then there are still better places to do that, that aren't confined to a place with limited existing infastructure. If you actually want a 'game' then the Balkans conflict in the mid 90's ticks every box - Soviet era peer equipment Large US base Aviano Italy Varied and beautiful (green and mountainous) scenery Era allows DCS inventory modelled Historical depth and detail Air vs Air, ground vs ground, Carrier ops Balkans was my age groups Afghanistan, for a period of modelling warfare, its much moire suited to DCS strengths and offers something different.

When you say "Spawn" you don't mean dynamically creating it with addGroup() via scripting, you mean just appearing as normal when put down in the mission editor right?

Here's how I used to do - I remembered later. https://github.com/thebgpikester/MPSG/blob/main/mpsg.lua

Hmm, thats a tough one. I had a quesiton before how does the script know if it is running on a server or not. WIthout anything else, only in the mission environment im not sure it is possible without either the plugin environment or some other check. Basically seems like you need to know that so you can write the script to cope with the differences in MP or SP (or host/client). I don't know how to do that in only the mission scripting off the top of my head. Anyone have an idea? It might be easiest to put a client down for a TF-51 that no one will use to just get all the right birth and enter unit events.

If there's nothing else playable, Player enter unit wont fire at the same time as the mission starts. You can see this happen if you add anything else playable. In this circumstance player enter unit is the same as mission start. It fires whenever the player is in the game but hasn't taken a slot. Same as birth. There's several of these events that have never been implemented properly and/or have quirky interactions in SP/MP as host/MP as client. Is there something you are trying to achieve (rather than testing the events) let me know.

I tested it, its working.

I've verified S_EVENT_PLAYER_ENTER_UNIT and S_EVENT_PLAYER_LEAVE_UNIT on the current public build. From Mission Editor, as client or player slot, both work. From MP, both work as the host only. From MP as a client, both fail to fire, as already reported. S_EVENT_BIRTH was fine in all circumstances S_EVENT_TOOK_CONTROL, I have never seen work.Never used it an dnot sure how its supposed to work. We did see that you can additionally not get the S_EVENT_PLAYER_ENTER_UNIT to trigger if the script is launched in a single player mission with no other slots (true player experience) but this is due to a timing issue as the script and player begin running at the same time. It's expected. It would have saved a lot of time if the script or mission had been supplied in a working state.

OK, OK, you want realism and immersion and you are going to use saved games and time speedups to achieve it. That wouldn't work for me at least, but there might be a way to put the carrier off the map anyway because the coastlines might be drawn out like they are with some of the other maps. If you are playing offline I reckon i could mod/script that if it's going to be popular.

If the map is to be 'centered on Bagdad', just under 150NM away is Kermanshah and we can have a good old 80's disco over the Zagros mountain range with an ever-increasing 80's lineup of modules from the golden era of air combat. That's less distance to Mosul in the north, Basrah in the south and the border to the west which is just a big vacuum of nothingness. So basically, there's nothing around here but the Iranian border and the Tigris and Euphrates if you ignore the mountains in the northeast between Iran. The problem seems to be that everyone wants to simulate GW1, carrier ops and 900-1000 mile round trips. Why? There's no save game, I've read popular social media where seemingly no one has more than 15 minutes to fly. At the very least a 70 mile flight to the merge over some mountains has to be the most favorable 'game'. The Navy were guarding their own anyway and weren't playing that much due to technical reasons. It's always so weird what people say they want. I expect someone to make a new game-breaking original content video on this comment next week, how Afghanistan doesn't work for DCS, when I've said it for years.

Hi, If you wish to know when a non-US country first had access to a specific weapon, read on. You might want to pick a specific year for a country and Wikipedia doesn't tell you anything more than the native country's in-service date. E.g. AIM-9L in-service 1976, sold to Egypt in 1983-87 and Israel 1980. DCS Historic mode generally finds the in service date for the native producer of a weapon. However, a lot of third world (cold war non-aligned) countries made purchases and were provided with older weapons than the US deemed current. The period of the Cold war saw a lot of exporting of military equipment in order to satisfy political policy. So historical mode is often inaccurate for dates that apply to the importer. Not surprising, the details of this are painful to find. May I present, The Stockholm International Peace Research Institue (SIPRI) https://www.sipri.org/ Thanks to these folks, you can check the versions, arrival year and quantity. Sometimes there's bonus material in the comments like which airframe the missile was intended for. For example, Israel received 376 AIM-7E's from 1976-1982 but the comments say they were intended for their F-15 stock. So there's two simple steps for getting a list of exports sales from the Sipri database before you can nerd away with your scenarios. To download a list of exports from one country to another 1. Visit https://armstrade.sipri.org/armstrade/page/trade_register.php 2. Enter the Supplier, Recipient, year range and weapon system type 3. Check the radio box Print register of Suppliers 4. Download the rtf file. The rtf file is a load of unreadable garbage to any word processor built this century, so we need another set of steps to convert it to a readable PDF. To convert the rtf file to something readable 1. Visit https://products.groupdocs.app/viewer/total 2. Drag the rtf file from your browsers download folder onto the groupdocs app viewer where it says 'or drag it in this box'. 3. Once processed, In the top right of the screen will appear download PDF. You can now work out questions like, "Did Egypt have access to AIM-7E before 1979?" Or, "What version of Sidewinder did Iran have?" And use a source that, whether it's wrong or right, is not worth contesting without a lot of effort. Answer the nerd call! Know things! Sound like a CMO database in human form! Then wonder why the USAF say the AIM-9J in service was 1977^^ https://www.af.mil/About-Us/Fact-Sheets/Display/Article/104557/aim-9-sidewinder/ . Enjoy!

Not seen that addition thing. Wires are problematic anyway, we've tried everything, animation states, guessing distance... Check with @funkyfranky though or join Moose DIscord to see if he's around.

it's not a simple script, that's why you couldn't do it, suggest you ask for help on the Discord server, the old methods needed slot blocker to kick people. https://discord.com/channels/378590350614462464/983485413060640778 There's a demo mission that could be adjusted to put the speed warnings in. Docs https://flightcontrol-master.github.io/MOOSE_DOCS_DEVELOP/Documentation/OPS.FlightControl.html Specific function https://flightcontrol-master.github.io/MOOSE_DOCS_DEVELOP/Documentation/OPS.FlightControl.html##(FLIGHTCONTROL).SetSpeedLimitTaxi

Before 2.9. The net effect of making a large dot suddenly disappear is worse than making a tiny dot disappear, especially at a critical moment, one of my personal issues with it. The other issues are: It's a default. Allowing choice should always be the default, not forcing people to have something they didn't ask for whether it's negative or not. It's not server-side configurable or enforceable (yet) - So right now, its basically dot neutral labels for everyone, enforced in MP. Great. It looks very different, depending on hardware (low res, big dot, high res it's somewhat reasonable, I liked it on my 4K screen, hate it in VR) It's nasty looking in VR. In VR I can't begin to explain but its really nasty seeing fighter-sized planes at 20nm as big black dots, just breaks immersion. That's the summary of my findings at least. This is divisive because not many seem to understand that this manifests according to your screen settings, so its going to get a bunch of disharmony on the forums and that brings out the subjectivity, when in fact, it's an implementation based on differences to start with. Objectively there are huge issues with the implementation and its no different from the scrapped imposter sprites a few years back.

Here is the disappearance factor issue. 10nm, see dot fine (remmeber, there is compression on the recording and in VR this is magnified. watch the range count down and then...just disappears in close. This was never the case before.

The change affects targets viewed in low resolutions more than high resolutions. There's no account for screen resolution in the dot size, so pancake gets nicer dots (they are still dots and you can see them) but VR and 1080 gets big black holes of space stations. Again, its a setting implemented as a default, that enforces the setting before VR users can opt out and before server operators can enforce one way or another. It is absolutely back to front, objectively so. And more objectively, from a technical standpoint it has no effect inside 1.2 miles when you are in and out of that range in the circuit, and especially at the visual contact WVR when the dot flicks between on and off which makes it absolutely awful you can lose sight of a plane the CLOSER it gets. SO it affects you at the worst possible time, when you need to keep visual and has no benefit to anyone in the beyond 5miles range where you either a) can't shoot or B) have a radar - pick your 'either or'. So who does this actually benefit? Anyone thankful for this is obviously playing this sim in a completely different way that I cannot fathom.

This is what happens when vocal minorities are listened to. This was nothing I ever wanted or asked for and its only made VR exceptionally bad by default. Watching dogfights from 20 miles removes the point of a radar, WW2 is now like watching a beehive tipped out, in modern combat people are now fox2 ambushing with radar off even more. How is this a good idea for the game when it changes the entire nature of multiple groups of players? The only people who benefit are offline players who can do what they like with the sims settings anyway. Multiplayer online group is stuck with enforced settings. This has basically made the change without giving the option first, its classic EDSA kneejerk.

This might explain years of confused frustrations. Although the explanation will fall short of actually explaining it.

That function will fail (BattleCommander) now in this fix patch. Depending on which script it is in, depends on who to ask to update it. It's not part of Mist, it's either the ZoneCommander part belonging to Dzsekeb or the mission builder 'Obi' whoever that is, maybe they have a forum thread? Once they figure it out you can replace that line with what the author intended for it.

Foothold is a Mist based mission, I know that's still updated by Grimes, but I have no idea if that is impacted or how, I haven't tried it personally.

fwiw (this will get lost in about 2hrs) getCategory() was fixed after many years, maybe never worked since 1.2. This will break scritps because people will have learned how to use it over time and copy paste does the rest. If you have scripts with examples like: category = event.initiator:getCategory() if category == Object.Category.UNIT then This will fail because the return has changed to depend what the function was called on, for example it returns now; Unit.Category = { AIRPLANE = 0, HELICOPTER = 1, GROUND_UNIT = 2, SHIP = 3, STRUCTURE = 4 } Airbase.Category = { AIRDROME = 0, HELIPAD = 1, SHIP = 2, } Weapon.Category { SHELL = 0, MISSILE = 1, ROCKET = 2, BOMB = 3, } Beforehand it used to be fixed to this: {UNIT = 1, WEAPON = 2, STATIC = 3, BASE = 4, SCENERY = 5, CARGO = 6,} Moose is fine (if you immediately update) and SpecialK has updated a bunch of things but I expect here and there people will bump into this.

Can confirm pretense current version is not compatible, Pretense uses this and other warehouse scripting commands available with only 2.9. Good for Dzsekeb, the mission is cutting edge, and having tried it, very impressive work.