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!

Yeah, wondered what that was about. Should we be excited? Or scared?

+1 Well said. I'd rather have a couple of well researched and quality tested additions, rather than a flood of stuff that's been put together over a weekend. As Kuky said, if you really want to see something in LockOn, put the work up front.

You're not kidding EscCtrl... I've nearly chewed my own arm off.

All the shaders I've seen in the installation are PS1.1 and VS1.1 I've been meaning to take a proper look at those for a while - especially the explosion geometry shaders. Trouble is I'm a HLSL bod myself and have been meaning to learn assembly for ages...

This could be completely wrong, and dammit I'm not going to go on wikipedia or anything to check the facts - so if it's wrong, it's wrong. As I remember though, Li+ and NiMh batteries have some odd properties when their charging regimes are a little off. Different charge and discharge rates can cause permanent physical changes within the battery, effectively forming a non-reactive chemical barrier to further charge/discharge above or below that point in the battery. While the potential across the cell will still be high the 'charged' status of the battery will read ok, but you won't actually be able to draw that much current. Or something like that. I need a mars bar. Or just a really big slab of chocolate.

Anisotropic filtering is inexpensive in terms of GPU load, so nail that all the way up as far as she'll take it. As for AA, I had the Sparkle 6600GT and I was limited to 1024x768 by my monitor. At that resolution I actually found the best performance in most applications (not including lockon, which went at 2xAA) was at 4xAA rather than none - something I've found in common with my 7600GS.

If there's a sudden rush of info in July it's quite possible I will wet myself. (Do you think ED will cover my cleaning bill?)

That image looks like a z-test failure - as you probably know, whenever a pixel is passed to the render stage of the card it is checked against the z-buffer to ensure that it isn't occluded by any geometry that has already been rendered. It's unlikely that you'd have damaged such a specific area of the card's function, even with an overclock. A quick scout shows that your card uses a hardware accelerated z-buffer featuring "Early Z-Test" and "Lossless 48:1 Z-buffer compression". It's possible that these are interfering with your render with parallel surfaces at high viewing angles. There does seem to be some data on the ATI websites for developers about forcing the Z-test in order to diagnose rendering issues with the buffer optimisations - worth looking to see if there's a registry value you can change to set this as a consumer. Hope this helps.

I have two DVD units in my PC for this very reason - my main (and far newer and faster) DVD drive won't even spin up anything protected by securom.. so I have to keep the old drive in just for them!

Boolean's like a cookie cutter, you just make a second shape that equates to the volume you want to 'cut out' from your 'working' mesh - position it, apply the boolean operator and grin happily. Or, more often in my modeling fumblings, frown as the mesh breaks up in unexpected areas and resists attempts to reweld the wandering vertices.