spugnut

:D the one thing I've learned through that brief foray is that DCS is made up of lots of interlocking code ayers, some dating right back to LockOn. I take it then that much of the lua code you start with when coding up a module is boilerplate from ED? I'll refrain from asking any more, despite fascination or we'll pull this OT.

I've just been poking around to see what radar specific code exists in the module, and my first impression is "not much". From what I can see so far (an extremely quick look), the radar is declared and set a max range - then it has two competing definitions for a value named "radar_can_see_ground". has_differential_stabilizer = false, radar_can_see_ground = false, stores_number = 9, ... and... --sensors detection_range_max = 120, radar_can_see_ground = true, -- this should be examined (what is this exactly?) CanopyGeometry = { azimuth ... Amusingly, the developer has also left in a note to confirm the functionality of the setting! :) We also don't have a great deal to compare to either - unlike most DCS modules, the FC3 modules appear to be compiled down into dlls preventing trivial examination. I'm guessing though that what we'd find is that the module loader just hooks values such as detection range out of the dll or lua as appropriate and passes it to the engine to handle. Having said all that, I've just realised that I've not seen any values relating to scan speed, max/min azimuth etc - but the module does set the radar type as "RDY", again pointing to this being defined and handled in ED code rather than RazBam's. I'd reckon that a module doesn't have sufficient access to the required underlying data representing other aircraft around it to for a 3rd party to independently develop a radar model. With that in mind, I don't think there's a huge amount any 3rd party can do about any perceived sensitivity to notching - it's defined and settled a long way up the chain from them!

I've had no problems having both installed - but I've only tested with 1.5 OpenBeta so far,

The instructions at https://github.com/jboecker/dcs-witchcraft are pretty much there, but you'll get a bomb-out when you try and light it up - the version of node packaged with the source is outdated and can't run the external code that's grabbed as part of the setup. My post here - https://forums.eagle.ru/showpost.php?p=3316398&postcount=91 (didn't this thread used to be sticky?) explains the remaining bit of magic. If you still have trouble, let me know where it falls over and I'll see if I can give you a hand. I'll look at forking jboeckers code too to see if we can make this smoother. ~S~

Since posting I have found that using the export functionality in WitchCraft seems to work quite well (certainly in my 1.5 Beta). Only gotcha was replacing the version of Node that the distribution was supplied with.

Hi all, If anyone else bumps into the problem LowLee mentions, updating the version of node that is shipped will fix it up. D/l from https://nodejs.org/en/download/ - grab the binary rather than the installer. Open it up your zip handler of choice, then copy the node.exe over the top of the one in your "windows/nodejs" folder under witchcraft. Hope this helps! ~S~

Hi all, I'd like to get a bit more involved with mission development, but for some of the effects I'd like to achieve I'd need to read from cockpit indications and switch positions. In a quick bit of mission building I managed to identify some of the things I needed by hacking apart the clickabledata.lua file, but I understand that there is a console available which I could use to query the running aircraft to help build my trigger list through simple lua prompts - but it is restricted to non-public builds. Is there any way that I could obtain access to a console enabled build, or is it for the chosen/proven few? Many thanks, Spugs ~S~

A workaround is to cycle the gear lever while on the ground - silences the warning after starting a new mission/respawn.

Thanks - feedback is always appreciated too. I know it's quite basic, in my defense it's been a long time since I cracked out the mission editor (probably about six months after the KA50 came out!). One thing that I'm sure I used to be able to access was the debug console - I just read in the manual however that it is removed from public builds. Does that mean that one needs to be an officially recognized content creator to activate it?

Hi all, First, thanks to RAZBAM for putting together such an interesting aircraft - early days of course, but there's a lot of interest around this bird. I've hacked together the start of a quick-and-dirty training mission (attached), but unfortunately I'm not going to have much more time to work on it for a bit. I know we're going to have training missions from some very skilled people once the EA phase completes, but in the meantime I hope the things I've welded together here will be useful to someone. Cheers all! ~S~ AV8NACold.miz

I am impressed to say the least - this is without doubt the most amazing free update I've ever had for any software ever. Prettier? Check. Faster? Wasn't expecting, but check. So impressed I purchased another module to support the devs? Check.

Wow - my fears about potentially poor download speeds are completely unfounded; I'm getting close to 10MB/s! IT will be mine, oh yes - it will be mine. A crisp salute to all at ED. Thank you all! ~S~!

Sat chewing my joystick... Well, I have an updated updater - so that's got to count as progress! :joystick:

Thanks for the pointer Ian - much appreciated!

Hi all, Been a long time since I last rolled by the forums - good to see the amount of buzz there's been since all the new modules started coming in! I have a simple question that may have been answered elsewhere, but if so a quick search doesn't turn it up. If I wanted to create a tutorial style mission (i.e. one which responds to user events such as switch hit, setting changed and with the "follow the rabbit" style guides), what is the tooling/workflow required? Cheers all!