

Gronank
Members-
Posts
55 -
Joined
-
Last visited
Content Type
Profiles
Forums
Events
Everything posted by Gronank
-
There are some secret stuff related to embarking and disembarking units from helicopters, but I haven't investigated further so I don't know if one could actually use these in scripts. They're used by the RadioCommandDialogsPanel.lua file though.
-
Not documented anywhere as fas I can tell. I found it searching for hidden stuff by iterating through the different objects and outputting the results.
-
You can view the start state of warehouses with env.warehouses (you get the table from the warehouses file when you open the mission as a zip). Yes, it is not particularly useful in any practical sense.
-
I got an _OK_ from the LSO, even though I spent a fair bit of the approach above the glide path. So yeah, seems lenient.
-
Does anyone get the sensation that this is caused by the mission editor? It feels like after you bash the computer around (delete folders, install drivers, et.c) reloading missions works fine as long as you stay out of the editor. Then you go into the editor and do *something* and then some corrupt state get cached and will crash on reload until you delete folders et.c. again. Does anyone else get the same feeling? Does anyone get the crashes without ever touching the editor? (I do get the uneasy feeling of being a confused villager trying to appease a capricious crash god)
-
Having a smart-ass cracking jokes in the back seat isn't unrealistic, the inability to tell him to shut up is. Jester could respond with hurt feelings about you not appreciating his colorful personality and then be quiet.
-
Yes, eclipse is another IDE with intellisense, but is it aware of the dcs types? If you write "Unit.", does it show the methods of the unit type?
-
Over the last few weeks, I've gotten more and more into scripting, but I feel productivity suffers from constantly checking references for spelling and fixing syntax errors. These are problems that are solved with a good IDE. That is not to say that there aren't good IDEs for Lua: I think Visual Studio Code does a fairly good job of the important bits, intellisense and syntax highlighting and validation. There are others too, but VSC is the the one I tried. However, in order to work properly, an IDE needs to be aware of the scripting environment. For us, this means all the scripting types (Group, Unit, env, et.c). I haven't found them defined anywhere in the game folder and I suspect that this is because they're defined in a dll somewhere (Scripting.dll perhaps). My plan for the near future is to create a mockup of the Lua types in the DCS script environment. It would let me do things like this: This, as you might imagine, would come in quite handy and make scripting life far kinder to my hair line. The limited type system in lua will mean it wont be perfect, but I think it will at least be useful. Before I begin, I have three questions: * Am I mistaken, and all these definitions already exist somewhere? * Alternatively, has someone already done this? * Does anyone know of a IDE/plugin/syntax/whatever that lets me provide hints for argument and return value types?
-
In the Syria version, quite often landing on hillsides and in sparse woods is the best option with a bit of gumption.
-
Pilots have normal human fields of vision, I have an office swivel chair. Swings and roundabouts, really.
-
I took the liberty of looking through the log. I think the actual culprit line is: 2021-04-23 09:31:19.669 WARNING EDOBJECTS: RegMapStorage::ForceID() - id is busy 2021-04-23 09:31:19.669 ERROR EDOBJECTS: Failed assert `success` at Projects\edObjects\Source\Registry\RegMapStorage.cpp:178 Unfortunately, I can't help you with what it means. The line you posted occurs dozens of times in the log, hours before the crash: it looks like a unit:isExist() is missing from some event callback somewhere, but you obviously know better than me if that is your problem or ED's. It's probably not a big deal, the error terminates the function call which is probably ok if the unit does not exist anyway, but it does pollute the log a bit. I also noticed other errors in there too, one of which you probably can fix: 2021-04-23 00:01:31.202 ERROR SCRIPTING: EWRS displayMessageToAll Error: [string "C:\DCSscripts\SoW_EWRS.lua"]:238: attempt to index local '_self' (a nil value)
-
Well, that's the point: we don't know what it can and can't do, we only know what tasks it has available. A F-15 could concievably strafe a truck, but it can't due to the missing AI task. It could be that the logic for F-15 attacking ground targets is absent from the game, but it is equally plausible that the basic strafing logic is shared between all aircraft and the only reason F-15 can't attack ground is because someone decided that a F-15 isn't supposed to do that.
-
+1 to the idea of the multi-role role -1 to the notion that it should be limited. Nothing is gained by imposing limitations based on someone's imagination of how a system might be used and a great deal is potentially lost.
-
It does fit, lots of space as long as you keep the body of the helicopter over the yellow circle... and the tail off to the side. Unfortunately, the game isn't so optimistic and it is not possible to spawn a mi-24 on the pad
-
Yes, that's the joke. Although... You take the role as part of a ragtag pirate crew, flying a surplus Hind off a derelict freighter cruising paradise. Performing audacious raids and slyly evaiding your persuers, will you be able to pull off the greatest heist in maritime history? I kind of want this now.
-
Shock twist and the Mi-24 campaign takes place in the Marianas No? Nobody? Ok then.
-
This thread is in my estimation completely off the rails. I am sympathetic towards anyone who struggles with AAR and become excluded because of it, but asking for convoluted helper mechanics is the wrong way to go. A far more practical solution would be to simply add a method in the script API to set fuel state on aircraft. Then mission designers get to choose how to deal with players who struggle. Maybe prompt "You've been loitering around this tanker for 5 minutes and are still running on fumes, do you wish to have your tanks filled so you get on with things", or something else, depending on preference. There are only upsides Empowers mission designers to create the experiences they want for all kinds of players There's still a point in learning AAR Easy to implement (There are likely reasons it is not trivial, but it is most certainly simpler than building "automagically fly the plane" functionality for every module with AAR capability) Yeah, if you can't refuel, you won't see your plane refuel. But really, that experience isn't worth much when it isn't earned and you still get to participate.
-
I was thinking of the X: Start Listen Command trigger action. I managed to get it to work in sp, but I have no idea of how it would work in mp. You're right that there isn't any published script API for doing the same. A bit unfortunate.
-
It's a good scenario. But it it's a little tedious to go into the radio menu to drop water. It would be better if water dropping could be initiated by trigger or cargo unhook buttons instead. It's probably different for each of the helicopters but I think it should be possible.
-
The issue of aircraft taxiing forward colliding with parked aircraft is illustrated in the attached track cvCongestion.trk
-
Currently, when you use the "Run Script" and "Script File" tasks you get a self object referencing the group executing the task. This is not the case for LUA predicate as start or stop condition. It would be useful to have the self reference here to. It is not uncommon that the group evaluating the condition is necessary context for the condition, such as checking fuel state to end a patrol pattern. If one want to do this today, one must remember to insert the correct group name everywhere the logic is used which is tedious and prone to error.
-
- 1
-
-
reported Misleading documentation describing MAV FOV button use
Gronank replied to Gronank's topic in Bugs and Problems
A similar issue: On page 211-212 we have: This does not match how it works in game. With no TGT, holding down the tdc button (I have realistic tdc enabled) makes the the crosshairs enter uncaged mode. Pressing the cage/uncage button enters caged mode and returns the crosshairs to boresight. With a TGT active, the crosshairs are locked on the target in uncaged mode. Pressing the cage/uncage button enters caged mode and returns the crosshairs to boresight. Pressing cage/uncage again returns the crosshairs to the target. Slewing is not possible in either caged mode. The documentation gives the impression that TGT replaces boresight when one is selected, i.e locked to target is caged mode and pressing the uncage button goes to uncage and grants the ability to slew, pressing the uncage button again returns to the target point. -
In the F/A-18C manual on page 209, the following can be read: This strongly implies that the Mav fov will not be changed by the fov button if the TDC is not assigned to the maverick display. Worse, the described behaviour would make perfect sense. But according to this post The fov button binds to the mav display as long as mavs are selected. Not only should the manual say so, there should be a big red box and flashing warning signs around it because it is quite unintuitive behaviour.