Jump to content

TEMPEST.114

Members
 View Profile  See their activity

  • Posts

    1724

  • Joined

  • Last visited

  • Days Won

    1

 Content Type 

Everything posted by TEMPEST.114

  1. TEMPEST.114
    You have to have the 'a' flag on the file set for APPEND. io.open (filename [, mode]) This function opens a file, in the mode specified in the string mode. It returns a new file handle, or, in case of errors, nil plus an error message. The mode string can be any of the following: "r": read mode (the default); "w": write mode; "a": append mode; "r+": update mode, all previous data is preserved; "w+": update mode, all previous data is erased; "a+": append update mode, previous data is preserved, writing is only allowed at the end of file. The mode string can also have a 'b' at the end, which is needed in some systems to open the file in binary mode. This string is exactly what is used in the standard C function fopen. Lua 5.1 Reference Manual Programming in Lua : 9.1
  2. TEMPEST.114
    Sigh. It's impossible WITHOUT SIGNIFICANT REWRITING. That's the point. Sure, they can add it, but it's not quick or easy. Everything in the ME needs rearchitecting. It needs data moved away from the actual boxes and abstracted. This isn't easy or quick. If they're going to that amount of effort then it's basically common sense to just write a whole new M.E. That's what I meant. I thought that was obvious. ? That's not even the issue. The issue is there is no abstraction on the M.E. Everything is tightly coupled and locked in. Hell, in the damn panel for the wind it does the scaling for the back end 33 - 1600ft winds IN THE UI LAYER!!! It wasn't 'designed' to handle group selections - and what i'm talking about here aren't multiple objects of the same type, I'm talking about group selecting different objects - i.e. helos, statics, ships and aircraft, and the UI pairing back to show the common editable elements that are CORRECT for the selection and the selected TYPES. Saying it can do group selection now, because you can hold down shift and click, isn't the same thing. If you're going to add a marquee and not limit the user on what they can select, then you have a much larger problem and the way the M.E. is built, it just can't handle that without so much refactoring and rewriting, it's not worth doing - they're better off writing a whole new one using proper tools architecture and abstracting everything so there is no coupling.
  3. TEMPEST.114
    From looking at the code for the the ME dialogs and panels and input fields, the suggestion that keeping the same variable in the input box in the ME dialog will break something in the back end is nonsense. We're just talking about a UI facing box. This is the problem with the 'architecture' of the ME. Everything is so tightly coupled, that there is little to no separation of the data model, from the UI logic to the View (software engineering terms). This is what I meant about the architecture of the M.E. and game engine. Either way, what we are shown in the M.E. when we change FLAG ON to FLAG OFF, should keep the name of the flag variable. If they need to do something else in the background to not break the back end when changing from one to the other - then that's their issue to deal with in the data model. It shouldn't affect the actual model logic, because we can just change the variable name again and everything is fine. There is no reason why the VIEW/VIEW MODEL can't do that for us. I wonder how much of this is tech debt and spaghettification and no-one wants to touch anything for fear of unknown consequences? There shouldn't and I really can't believe there are ANY consequences for this. Otherwise when we change the name back, things should break right?
  4. TEMPEST.114
    It's changing an ACTION for a specific TRIGGER... there is nothing I can think of that would affect ANYTHING else in the back end. They know something we don't or something is lost in the Chinese whispers, 'cause that doesn't make any sense... but if it's the former, then the 'architecture' is f***ed.
  5. TEMPEST.114
    As I keep explaining, in multiple threads. The way the mission editor is written, these are IMPOSSIBLE. There is no ability to understand a subset of acceptable parameters that can be modified when group selecting, and there is no way an 'undo manager' can be shoe-horned in because there is no standard construct of what a 'parameter change' is, so it can't be rolled back. EVERY TEXT BOX, FIELD, PARAMETER is it's own thing and is handled by it's own code and does it's thing by itself. To put an undo manager in would require AN ENTIRE REWRITE of every dialog, every panel, every button, every field. It's not going to happen without a rewrite! I've looked at this. I've posted threads on this. People need to be better at searching and start asking the better request - give us a proper, modern mission editor and dump this archaic, broken, poorly 'designed' thing we currently have. But as many, many have said - it's just about functional and there is no money in it for ED to make a better one. And this was in the first page of this forum... You're not exactly looking for already asked things are you @Mig Fulcrum?
  6. TEMPEST.114
    When you add more than one PERFORM COMMAND -> TRANSMIT MESSAGE to a unit i.e. AI F18, with the 2nd one to start ONLY when a specific flag is true, as soon as you click on of the two Transmit Message statements in the UI, it changes the Transmit Message sound file to the sound file of the one you didn't click. This bug is preventing the ability for a unit to transmit different things depending on flag states - which I believe was the entire point of having a START condition. Attached is a Caucasus mission with two F18's one player, one AI. The AI has two transmit messages, the first is playing on a loop, the second - which I assumed would replace the first, will only start when the player has done an F10 Radio Command to 'Check In'. This sets a flag 'PlayerCheckedIn' to true, which should start the 2nd audio file. The two audio files are as the image above states. However, as soon as you click, touch, change any of the UI, then the audio file for BOTH transmit message statements changes to the SAME audio file. TransmitMessageBug.miz
  7. TEMPEST.114
    /smh...
  8. TEMPEST.114
    There is no option to STOP the currently transmitting message via a STOP CONDITION for the PERFORM COMMAND -> TRANSMIT MESSAGE function inside the Mission Editor or Scripting. If you had both a START and a STOP condition, then interactive and dynamic communications could happen between players and AI aircraft, by having multiple TRANSMIT MESSAGES stacked up, each with their own START and STOP conditions.
  9. TEMPEST.114
    It should allow the creator to specify the freq and band etc, so that the triggers ACTIONS only work when a player aircraft has the correct frequency set on a suitable radio.
  10. TEMPEST.114
    Interactive mission creation is crippled by the inability in Multiplayer missions to know when a player aircraft has tuned to a specific radio frequency correctly (or at all). A world.event generated whenever ANY player in the mission tunes a radio, or switches to a radio that provides not only the unitName, but also the radio unit AND the freq it's tuned to would be tremendously helpful. Yes, if they were tuning from say 120.0 to 127.50 then it would fire an event for every frequency in between, but it's not hard to capture the last one and compare to the next event. Or, perhaps this can only fire when the tuning has stopped (i.e. waiting for a time > 'a specified delay' = final freq). Either way, knowing when a MP aircraft has tuned to the correct frequency allows the mission creator to be able to play specific audio/send specific text to that unit and update that Group's (better if it was UNIT level) F10 Radio Menu with options based upon what they're now hearing/reading.
  11. TEMPEST.114
    Thank you, though I would make an argument that it IS a bug, because two SOUND TO XXXX ACTIONS generate noise because two sound files are playing at the same time. That doesn't seem right.
  12. TEMPEST.114
    This affects all SOUND TO xxxxx ACTIONS, as well as all RADIO TRANSMITTER type ACTIONS - basically, any method in the M.E. or via scripting to get DCS to play a sound, this bug is present. 1. Sounds should be added to a PLAYBACK QUEUE and played back, one after the other, in the order by which they were added to the queue and NOT - as they currently are - all played at the same time! Currently this means if you wanted to send a custom morse code signal, you'd have to send each sound file for each character, note the duration, and delay the next by that duration + a 'gap' in time and repeat. This is a PITA and stupid for so many reasons. Otherwise you're forcing creators to make a magnitude of individual sound files to cover all eventualities. This makes the mission large, slow and puts a HUGE amount of work on the creator, fighting against the DCS game engine. 2. On top of that, this means you can't get all that to loop, as the 'loop' only understands looping an individual file, and not a sequence of files. This is another part of the bug report - you can't loop a sequence of sounds, only individual ones. You should be able to batch up a sequence of individual sound files and have them play sequentially and then be loopable. 3. Also, if a player performs an event that triggers a sound effect i.e. MOTHER talking to them with a custom audio file, or a custom AWACS speech audiofile, at the same time as another player triggers the same or another custom audio event then CURRENTLY, both play on top of each other, rather than sequentially. All of this should be available to scripters as well as in the M.E. Trigger system.
  13. TEMPEST.114
    Wot? Huh? Where am I? Too many hits I think...
  14. TEMPEST.114
    Nope. Or at least I couldn't get it to work.
  15. TEMPEST.114
    Hey. Remember, this line is working in the 'server' environment. Environments are a key concept in Lua that can keep grouped things together, but keep disparate things apart: https://www.lua.org/pil/14.html The 'server' environment is completely separate from the 'mission' environment that DCS Scripting Engine and the Mission Editor reside in. So they can't talk to each other unless there is a constructed bridge between them. You need to specifically either GET something from the other environment from within a different environment and you can only do that if you have some environment or table in common. This is the problem. The hackiest solution is your own TCP server sending out the 'server' stuff, and a 'mission' TCP client reading, but networking is a PITA.
  16. TEMPEST.114
    Have you tried placing it by script, giving it a specific Y value? Does that get around it?
  17. TEMPEST.114
    TBH I don't think this should be in the Mission Editor. I think it should be on the Multiplayer Screen where you pick your jet - there should be a tick box in that row, to start hot, otherwise it would be cold.
  18. TEMPEST.114
    @Flappie Just found out this exact same bug is happening for ALL ACTIONS within the same 'context. i.e. all RADIO MENU Add/Remove do this bug. All Picture To (Unit/Group/Coalition) do this bug. There seems to be a bug when changing ACTION from one option (within the same context) to another, it resets everything. Do you need this as a new bug or because it's related but now a LARGER issue, that is common to all ACTIONS it's okay here?
  19. TEMPEST.114
    Have you, on them reaching this trigger, set a TASK SET for them to go to their final (and it should be set as a LANDING) waypoint? That's how I've done this. The TASK SET removes all the other tasks that have been PUSHED to the back of the queue. Otherwise, once they get close to that final waypoint, then the tasks PUSHED previously will reassert themselves and hence, they fly back to where it all started...
  20. TEMPEST.114
    Here's the app: https://www.baremetalsoft.com/baretail/ I didn't write this app nor do I get any benefits from promoting it, just that I don't think many are aware of it and it's usefulness. What this app allows is a live, realtime view of the dcs.log as it's being appended to from DCS and your scripts. The killer feature however is that you can use the HIGHLIGHT system to give colours to key phrases or words so they stand out. Here's a screenshot of how I've set mine up. My Superscript (currently called 'DCSTLC') is broken down into atomic 'Modules' that have one singular function, and each module has it's own three letter name. For each of these names (which I log out to dcs.log with) BARETAIL can read the log entry and if it finds a pattern match it will highlight that line accordingly. This way, the bits you're interested in don't get lost in the sea of other log messages. Hope this helps!
  21. TEMPEST.114
    @arilm21 Did my posts solve your problem?
  22. TEMPEST.114
    Okay, you're going to need to view the DCS.log as it's running to see the output. I'd suggest the free app called 'BARETAIL' or you can just let this mission run for 5 seconds and then open dcs.log in your texteditor of choice. This is the results you get from the two function calls listen in my original post: 2024-05-07 10:26:37.427 INFO SCRIPTING (Main): { [1] = "1", [2] = 1, } Notice that the first result as double quotation marks around it? That denotes that the value is of type STRING. The seconds one has no quotes, this denotes that it is of type NUMBER. They BOTH should be numbers. typeBugDemo.lua typeBugDemo.miz
  23. TEMPEST.114
    Is this really a bug in the Mission Editor or Scripting Engine or a problem with your mission? If it's the latter, it shouldn't be in the bug section as this isn't the purpose of this channel. Perhaps recreate this in the general M.E. channel and if you can verify this is a bug, then report here? Otherwise this should be deleted until you know it's a bug that needs ED to fix.
  24. TEMPEST.114
    I would suggest then, that you change the title and original post to specify that this current behaviour is a bug. Your original post was that you couldn't create or save/load templates of static objects - but as I've shown you, you can. What you're highlighting is that they don't drop where you last clicked the map, but at the original or some other arbitrary point and then you have to manually move them. That's the 'bug' I think needs fixing. And if you keep one bug report to one thing, it's easier to track - for us and for ED. The 'wish list' item of 3d map can't happen the way this M.E. has been built. I'm in fully agreement with you, but it needs a dedicated, separate and modern Mission Editor for that to work. So it's best tagged onto the existing wish list item as a comment then a new one. Just my 2p.
  25. TEMPEST.114
    @Flappie Hi. Don't know if you missed this, but could you please test your end? I'm definitely getting strings back and not numbers.
×
×
  • Create New...