Moa

Generally the TacView scripts can be left where they are. What matters (or at least, used to matter) is you have: EnableExportScript = false in the file: Config\Export\Config.lua If you have EnableExportScript = true then the Integrity Check will fail on many servers (eg. 51st, 104th, etc). So, you can try changing this value without having to un-install TacView. For example you may wish to leave TacView installed so you can generate TacView logs when reviewing tracks - the lottu tool has a checkbox to ease turning that EnableExportScript property on and off when reviewing tracks.

Superb! One of the VNAO guys (VFA143_X-Man) flies the US Navy T-45 version of the Hawk for real (although he's been selected to transition the Hornet in the next couple of months). Will be completely awesome when this model is completed! Please keep up the great work.

A dynamic campaign is not difficult. It is a lot of work. I know as I've done the analysis for my plan to complete a FC2/DCS mission generator this year that can base missions on the results of previous missions (where the results are analyzed as part of the 'dynamicscore' pilot scoring/statistics software suite as running on the 104th server).

Since you asked, the IL-2 campaign system is by Paul Lowengrin: http://www.lowengrin.com/news.php Doing something like this for LockOn/DCS cannot be done overnight, so I'll be plodding away for months on it. Meanwhile, the new DCS mission generator looks handy in the mean time.

The License for FC2 states: "4.1This Program may contain certain design, programming and processing utilities, tools, assets and other resources ("Program Utilities") for use with this Program that allow you to create customized new missions, campaigns, skins, terrain and other related materials for personal use in connection with the Program ("New Game Materials"). The use of any Program Utilities is subject to the following additional licence restrictions:" and "(f)all New Game Materials created by you shall be exclusively owned by TFC and/or its licensors as a derivative work (as such term is described under U.S. copyright law) of the Program and TFC and its licensors may use any New Game Materials made publicly available by you for any purpose whatsoever, including but not limited to, for purpose of advertising and promoting the Program." In the case of using ED tools to create missions and skins it looks like there is a case for enforcement (enforcement meaning the TFC owns *all* content produced by those "Program Utilities"). If missions and skins are created from scratch without using ED tools then they are not subject to those license conditions (they don't become owned by TFC). Using independent third-party tools for interoperability is explicitly allowed (Section 3.1 f of the EULA) and even if there wasn't there seems to be plenty of precedents in US case law (for example), even to the point of reverse-engineering (but again, no breaches of copyright allowed). This is good as my next LockOn project is a mission generator (both a standalone version and a version which will be hooked into the my stats system => true dynamic campaign).

While I'm at it, please let me clarify that IANAL (lol, love this abbreviation, it means: "I am not a lawyer"), but here are tidbits I've picked up from discussion around the Web (these aren't legal advice, get a real lawyer if you ever need one). There was a post about community made stuff being the property of ED. It is a little tricky here. Stuff that "extends" LockOn/DCS, eg. LUA scripts directly embedded into LockOn and using the lowest-level interfaces provided by LockOn could be considered "derivative works" and may be subject to conditions imposed by ED (if they ever chose to). It would be a very long stretch to say that stuff that "uses" LockOn but it not derivative (eg. my lottu and stats programs, which are Java, not LUA/C++ as DCS/LockOn are) would probably fall under ED's purview. Missions use LockOn/DCS but such created content are probably non-derivative (just as Sony doesn't own or have direct control over the LockOn videos that get produced with Vegas). Just pointing out to that poster that sometimes community created stuff could be subject to control by ED, and sometimes it is very unlikely to be (not that ED have ever enforced such control, but we should be aware it is possible and we may either need to acquiesce to EDs rights, or intentionally build non-derivative works [as I do]).

Just so you know, in most modern countries if someone creates a work they automatically have copyright over it, even if it does not have a notice. The fact they put it on the web for you to enjoy does not mean that the copyright is relinquished, it just means there is an implicit 'license' grant for you to use whatever they produced. Legally (in most countries, although the Internet fuzzes it a bit) someone who then reproduces or distributes that thing is infringing copyright ('stealing' as you put it) despite having the implicit 'license for use'. I'm not saying this to be 'heavy' nor pedantic. I hope to be informative so that you know how the international community (WTO etc) would see such similar situations, and so that you can understand the discussion with a proper mental framework (such issues are well understood and discussed to death on the InterTubes already). Since copyrights are pretty much ignored on the Web (which has both good and bad aspects) it means the only way for the creator to retain control is to restrict its spread. It is not the creator who harms the community but those who take the work without authorization. Even liberal outfits such as the Free Software Foundation (FSF) and others retain copyrights and require licensing under terms they choose. This is the only way that creative people (eg. Tyger) will remain 'incentivized' to create more good stuff for us to enjoy, which is why the principle of (limited-term) copyright is recognized universally as good (even if not always followed) and morally just. You will note that those who have taken the work in this case don't even acknowledge the creator or have the common courtesy to ask permission to distribute (which would have given Tyger a chance to find mutually satisfactory terms - since he likes people enjoying the fruits of his labor). In the Internet Age this is the direct moral equivalent of 'stealing' physical goods - no one has any right to help themselves to the copyrighted work of others (not only is it immoral, it is also illegal, not that anyone is threatening legal action - so please don't panic anyone). If you don't like Tyger's terms (use TS and fit in with others on his server) then you have perfect freedom to create a mission and publish yourself (note: reverse engineering is perfectly permissible, copying the bits directly is not). We all have large constraints on our time - but that is no excuse for those that 'steal'/infringing copyright especially in such a tiny community as ours. Tyger is a busy man- he has a family and children and a (more than) full time job as a Regimental Sergeant Major in the British Army (including recent combat in Afghanistan). He gave up his free time (it takes several dozen hours to create a great mission, then even more to test and tweak) to create and share his mission, on terms he would like to choose. Anyone else is free to also give up their limited free time and create a mission themselves. Sorry for getting on the soapbox here - but it is annoying that people think it is their 'right' to make demands about the labor (missions, mods) and resources (servers) of others. Sure, state you would like more open servers - but that is different from essentially demanding that control of a resource ought to essentially serve the 'will of the community' rather than the creator/owner. Community created resources are a privilege the creators grant you, since they wish you to also have fun, but it is no 'right' of users. Once you create your own missions (if you stop making excuses and give up your own time, if sounds like you are very able) then you will have the 'right' (copyright) and be able to extend the privileges to others as you see fit.

My spelling may be 'British' (it is the 'English' language after all), but my philosophy is this regard is American - following the ethos of Richard Stallman and the Free Software Foundation for the most part.

Tyger is right. He made the mission and it is his right to do with it what he wants, including locking it (he doesn't need a good reason to do so, but he does have good reasons, some of which he took the time to explain). If you don't like it then I suggest you create your own mission and test it until it is of multi-player quality. Then you are free to share your talents with the community. Far too often people on these forums act as if they have some kind of right to the hard work of others (ED or modders) and have the right to complain loudly about the decisions made by the creators - despite the fact that they themselves have never contributed anything of such significance (and therefore do not appreciate the colossal amount of work such things take to create, test, and make easier for others to share). Commenting and criticism is fine, and even serves a necessary function, on the understanding that the creators *owe you nothing*. No matter if you disagree with the creators they are contributing to the community far more than those who contribute (and it is a contribution, albeit small) nothing other than criticsm. While creators (myself included) would very much like you to enjoy our work, and appreciate the feedback you give please don't mistake that anyone other than the creators has the right to dictate on how we decided to share our software (my personal preference to be more open, but others are perfectly within their rights to be more closed when sharing their stuff, or on whatever other terms they choose). Yes, please state your wish that there be more un-passworded servers that are out there, but you must also respect the rights of the server owners that provide them (and they do cost money and effort to run and maintain) out of the goodness of their hearts. If you don't like closed mods then create ones yourself and share them (this is what I do, I have licensed the source of my lottu utility under GNU GPL v3, and will soon share my statistics source code). If you don't like passworded servers then please create one and manage it yourself (as I do with the VNAO 'stallturn' server). It is this that will grow the community (which you profess to want, as do I).

Well, OpenGL 3 and later have changed (more shaders and less fixed-function pipeline stuff, finally eliminated in OpenGL 4) so it follows that JoGL also had to change. I don't think LEAVU needs customized shaders for its 3D stuff so OpenGL 2 or lower should be perfectly fine.

VNAO mod has GBU for the 'F/A-18s'. Don't forget to use also use terrain masking where you can.

http://jogamp.org/ is where the action has migrated to. You could also try JMonkey Engine ot LWJGL (or one of the other number of libraries for Java over OpenGL), although they're more scenegraph oriented. One benefit of JoGL is that it is close to the C API, which means there is a large number of © tutorials, samples and documentation and are straightforward to get working.

Hi Yoda, good to see you're around again. Users don't have to mess around with DLLs if you bundle a 'fatjar'. The DLLs are still there, but bundled inside the single executable program. While I didn't need DLLs, I did use a fatjar for lottu (http://stallturn.com/wiki/en/lottu). I then used JSmooth (http://jsmooth.sourceforge.net/) to create a single exe for Windows users (Linux/Mac users [eg. me] that alter the tracks [even if they can't play them] can cope with a jar). I also used JSmooth to create the 'dynamicscore2' collector program that can be installed on LockOn game servers (used on stallturn for VNAO stats and the 104th Phoenix server stats, http://stallturn.com/104th/) as the single file is easy to install (known as 'xcopy installation' in the Windows world as you can simply do a file copy to install it). For an example of a JAR that bundles DLLs for different operating systems within it see the JNA (Java Native Access) library. ps. If it was me I'd be using Swing and doing optimizations (eg. caching rendered text that changes far more slowly than 60 fps, and then using the dozens of hardware accelerated texture compositing units built into modern GPUs) rather than using awful AWT (although good for brute-force rendering at 60 fps) that has a lot of cross-platform issues. pps. I have some altered LEAVU2 LUA export scripts and modded LEAVU code that allows access to flaps, hook, gear, canopy and speedbrake status. I used this to make a little Angle-of-Attack control and mechanical status panel for when I do US-style carrier landings with VNAO. The controls are ugly as I never got around to skinning it, but I should commit the code as it might be handy for pit-builder. Finally, Integrity Checking has pretty much been standardized on most of the more popular LockOn servers. Due to a potential exploit in LockOn exports and fact that new users could not connect using a default installation of LockOn if they have the LEAVU export scripts you'll find that most servers effectively prohibit the use of LEAVU (naturally, for my purposes my stallturn server does allow its use, but instead requires the VNAO mod).

I think ED are well aware of users wanting a dedicated server. It is a bit of effort to create one though and I think they've had other priorities so far (like creating DCS:BlackShark and then expanding it with Warthog with its advanced weather, bump mapping, avionics and other goodies). I'm sure it is on their big TODO list. These days, if you choose carefully you can get a motherboard with onboard support for DirectX 9. If you limit the number of frames rendered on the server per second then it is reasonably close to 'headless' operation in that you can use a rackmount system without dedicated video card (although it's true you also could say that "nearly a virgin" is not the same as "a virgin", :) ).

TacView ACMI export can cause micro-stuttering for sure. I'm confused though, I thought we were talking about LockOn tracks? LockOn tracks don't cause a stuttering problem. Although, there is the problem that generating ACMI from a track is a hassle, slow, and inaccurate compared to the ACMI generated directly, since track replay has imperfect replay). Changing the location of LockOn log files Changes some of the log files. Some appear to be generated by LockOn itself and not controllable by LUA (although they don't cause stuttering). In the file scripts\net\server.lua in the function on_net_start() creates the server network log: function on_net_start() log = io.open("Temp/net-server.log", "w") for local games I think the on_start() function is used instead (at least, that is what ServMan uses). where you could change the path to that file. Changing the location that TacView ACMI files get written to: If you want to change the location of the ACMI files that are written (ignoring the logs and tracks, as they don't seem to be the problem) then modify: Config\Export\TacviewExportBlackShark.lua find the function BeginLog=function(self), and change the line that starts with: self.AcmiFile=io.open("./Temp/Tacview-" .... so that it is something like: self.AcmiFile=io.open("E:/acmi/Tacview-" .... If that doesn't make a performance difference (since you are still doing I/O operations) then perhaps it's worth thinking of getting an SSD for LockOn.

Hi Breakshot, My suggestion was to remove the tracks rather than disable them. On last weekend's OPFOR event the 60 players on (including youself) didn't notice any significant lag while recording the server track, yes?. I'd be surprised if streaming a track out (at the relatively slow rate of 40 MB/hour => around a measly 10 kB/s on drives/busses that can stream around 2000 to 10000 times this rate) makes a difference for a modern drive with write-behind caching enabled (which can buffer in RAM & disk buffers until the system is able to do I/O). Possibly more significant for server performance is limiting the frame rate using graphics.cfg. Stallturn is deliberately limited to 15 fps (because I watch VNAO carrier traps from time to time) but could be lower, say 10 fps with only a little noticeable effect. This drops the CPU load enormously and improves the latency in responding to client (network) requests.

Have a look at scripts\net\cleanup Add an item to remove tracks if need be. Personally, the tracks aren't that big compared to modern (cheap!) hard disks. I never throw any of the files away since it is hard to get back if you decide to look at them later (you'll learn a lot from watching tracks and TacViews).

To get scientific about it. 1) If you start at the IP (RTN point) at the indicated altitude (1016 m) and near the approach speed (270 km/h), the following will work. 2) Correct angle-of-attack is +7 nose pitch. Trim for this. If you vary the nose too far from this the hook will not catch. 3) Correct descent rate is 5 m/s down (there is a white marker on the VVI at this rate). You can touch the deck up to 7 m/s without exploding. Come down faster and *B00M*! There is a 'sink rate' light near your engine dials. If that is lit and you are about to touch the desk then 'wave off' at max power (leave your gear, hook, and *especially* flaps down, in case you do touch the deck). 4) Adjust throttle to maintain glideslope. In FC1 the correct throttle setting was 82% fan. With more powerful engines in FC2 the setting is around 78%. Make small changes to the throttle. Instruments: * When far from the carrier use the HSI needle to line up. This will get you localized (but not precise enough to be on the deck centerline - you need the following instrument for that). * When approximately on line and slope use the little white needles on the ADI for more precise adjustment (can only be used when near the correct position, but more precise than the HSI). * When the white needles are centered use the AoA indexer on the HUD to make small throttle changes that will keep those white ADI needles from budging. Do this and you will be able to land on the Kuzntsov *without even looking at the carrier*. You can use this technique in the dead of light (with carrier lights off) or in max fog conditions where the carrier is visible only for the last 1000 feet of approach. Note: real pilots train to do IFR in a 'heads down' manner like this (not visually looking for their destination outside the aircraft). I find 'following the circle' adequate during the day but not precise enough for zero visibility traps. Several big things for carrier traps on the Kuznetsov (for a 'heads down' approach that can be used in both IFR conditions, and VFR- follow these and you can be a landing 'Jedi' [blast shield down]): 1) Start at the correct height, distance and close to the required airspeed. 2) When your flaps come out there can be 'ballooning' and nose pitch up. Anticipate and counter it with a little nose down. This is worse at higher speeds so try to start close to the correct speed. 3) After your flaps, gear and hook are out then pitch up to +7 degrees and trim. Re-trim again if your speed changes. If you need to move the stick on the approach thenre-trim to keep that magic +7 nose pitch. Trim, trim, trim that aircraft! 4) Don't get fixated on solving one thing (pitch, speed, altitude, descent rate, throttle). Make an adjustment. Check another instrument. Check the result of the first adjustment and correct if necessary. Check another instrument, keep you 'insttument' scanning going the whole way down the slope. 5) Anticipate. If you were high and have lowered the throttle to descend slightly then put the throttle up again *before* you reach the correct glideslope. It takes time for engine changes to take effect (inertia in both the aircraft and rotataing engine turbines have to be changed by small accelerations over a finite time). If you don't anticipate you'll end up 'chasing the needles', which is not good. 6) There is a line running down the center of the landing deck (imagine the line starts at the farthest point at the deck and runs to the stern, and then on to you). If the line is pointing to the left then you must turn left. If the line is to the right then you must turn right. If the line appears vertical then you are good, worry about whether you are too high (use ADI white needle) or too fast (HUD Angle-of-Attack indexer). 7) When landing (carriers or airfields), your nose pitch (mostly) controls speed. Don't vary it. Use the throttle to change your rate of descent (and a slight effect on speed). Don't dip your nose to speed up, use your throttle instead. 8) Do not flare before touchdown as you would for an airfield. You descent onto the carrier without flaring (it's a 'controlled crash' really, don't worry though, carrier aircraft have landing gear specially reinforced for just this). 9) With practice you won't have to use your speedbrakes once you are on approach after the IFR. If you have your spedbrake out when you are close to the carrier then you've done something wrong earlier on. You don't want your speedbrake out if you need to go around (called a 'wave off' in Navy terms) or the arrestor cable breaks or you miss it (called a 'bolter'). This covers 'straight-in' landings on the Kuznetsov under all visibility conditions. US Navy style landings are considerably different. To find out about those you can google virtualnavalairops (VNAO) who do these in LockOn (disclaimer: that includes me). Don't worry if you find it tough, it takes a lot of practice to master carrier landings (they are a great test of pilot skill and many online squadrons use them as part of testing candidate pilots). Keep practicing and 'fly the numbers' as I have given them. In time you won't need the 'numbers' and your own visual judgement will be sufficient - but until then, use the numbers as they are a good substitute for an experienced eye. Note: mission designers, carriers never have cross-winds (unless their steering is damaged). They can always turn into the wind for takeoff and recovery, and steam at full speed while they are doing so.

Immmer, this thread contains the hosting server track, TacView generated from that track (caveat emptor), and post-battle analysis and commentary. http://www.104thphoenix.com/modules.php?name=Forums&file=viewtopic&t=2867 Scores will be out as soon as we've checked everything for accuracy. It was a great battle!

Thanks todd022.

Please take the necessary time ED (ignore the impatient n00bs) - she's a complex beast and most of us are prepared to wait until the next set of functionality is ready for testing.

The 104th stats system (dynamicscore2) has all the infrastructure to manage stats from other servers. The only thing missing is the dropdown listbox on the user-visible applet - and extra testing to make sure it all works as expected (there are many automated 'unit tests' and 'integration tests' for the back end, but none for the GUI). dynamicscore2 also exports a SOAP webservice interface that allows any client program to get access to the stats - so it is open for merging. The intent is to also give the software and source code to the community (licensed under Gnu GPL v3 or later). Then anyone can host and it is up to them whether they would like to merge statistics or not. I can't speak for Case but considering he did the global stats way back for FC1, and I'd be very surprised if his FC2 system also wasn't fully able also to handle data from multiple servers. At the moment there are no short-term plans to merge the data (for me, too many things to look at/fix up since my software is still in beta). It is a natural evolution though so will be looked how to get the nuts and bolts going in the future.

Some pilots have requested that the 104th Dedicated Server pilot statistics be reset as they were experimenting with how the server works and their battle efficiency does ot reflect regular operations. We are allowing our server guests to choose whether to reset the statistics on 2011-01-01 00:00:00 UTC or to keep the 2010 statistics as part of each pilot's career statistics. You can cast your vote to keep the 104th statistics for 2010 or to start with a clean slate in the New Year. As Burger King says, "Have it your way": http://www.104thphoenix.com/modules.php?name=Forums&file=viewtopic&t=2815

Very clever Bob. Just be careful that you get the latest version from time to time. Soon I'll try and load the Java 'WebStart' JNLP file that allows you to run the program locally, but checks the network to see if there is a new version you could download (best of both worlds).

Thanks for quantifying the timing information Distiller. The information is coming from my server in New Zealand to you in Spain. It's probably not a fast route there (shared with a lot of other traffic from NZ to Europe and vice versa) and you're probably not the only gettting data from the server (which only has 2 MB/s up). traceroute would be interesting. Of course, latency is not the same as bandwidh. Once the stats have been sorted out (they're still in a bug-fix beta stage) they could get hosted somewhere with a higher upload speed. That may help a little. Like I said to another poster though, I can't do too much about the World's network speeds in software. There are just a huge amount of statistics to get across the wire.