Jump to content

Pikey

ED Beta Testers
  • Posts

    5683
  • Joined

  • Last visited

  • Days Won

    4

About Pikey

  • Birthday 03/18/1973

Personal Information

  • Location
    Cumbria, UK (GMT)

Recent Profile Visitors

64840 profile views
  1. If you say so I believe you, It's not something I remember or ever needed. The thing with scripting is that people use it in unique ways and the game does change over the years. The fastest way to success here is to find an alternative for whatever it is you need to achieve at a higher level. Workarounds are a necessary evil in DCS, because we can't control some things. It's really common for people to focus on the thing under their nose but if you want to "track" units and build a database (what do you want to do by the way?) then have a look at the way mist and moose do that. For example, to get a list of all units in a variable called AllGroups in MOOSE, add moose.lua at the start of your script and add just one line: AllUnits = SET_UNIT:New():FilterOnce() If you want to maybe target all ground groups that are alive, then: AllGroups = SET_GROUP:New():FilterCategories("ground"):FilterActive(true):FilterStart() If you want to access them and instantly delete everything on the map: AllGroups:ForEachGroup(function (grp) grp:Destroy() end) It's cool that you want to do this yourself, but its a path to frustration to try to change DCS to fit what you wrote. As for knowing if the birth event ever fired in SP at the start, it's not worth your effort to find out, since it won't change how it is. Please don't feel frustrated at asking for one thing and getting a different answer than you expected. I can't help change DCS code, I can probably help with solutions though and the MOOSE Discord has over two thousand people using this specific class for over 8 years now https://discord.gg/v9uncFnP
  2. 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?
  3. Here's how I used to do - I remembered later. https://github.com/thebgpikester/MPSG/blob/main/mpsg.lua
  4. 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.
  5. 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.
  6. 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.
  7. 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.
  8. 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.
  9. 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!
  10. 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.
  11. 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
  12. 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.
  13. 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.
  14. 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.
×
×
  • Create New...