noxious

Hi guys, my harpoon paper days are starting again, as illustrated by my purchasing saga. Going out to buy the 2003 review just after posting this. Last time I played was with H1 or H2 rules, back in the mid-80s, only played computer variants since then. No ground back then. So I've heard and read about ground rules existing for H4(.1), but not being up to date on what is what and where it is (much less its cost, hahaha), I'm asking for your help, dear pooners. Interested in "official" ground combat rules, be it in commercial or free, paper or online, supplements, as well as community mods, hopefully freely available. Or barring tailor made systems for H4.1, ground rules that work nicely with Harpoon would do. Thanks in advance, and poon on !

Man, oh man, I can't thank you enough !!! Just slit it open, and behold, 4.1 rulebook + annexes, + errata sheet from 2004 !!! I'm in business, heeeehaaaaaw !!! As a sidenote, I was fooled by the "ancient" looking plastic film around the box : brownish deposits in the corners and nooks... I guess they allowed smoking during their game club nights at the shop, hence the ancient look, hehe. God, I would have felt stupid... Well, guess I'll go grab a copy of the 2003 review there too (cheaper than at CoA) Cheers !

So, that's the story : bought the H4 boxed set, without realizing it was 4 not 4.1 from a local hobby shop. Paid a bit too much for it (66 Can + 15% taxes, around 75 iirc, they initialled wanted 80 Can, before taxes) to boot. Haven't opened it ( I had doubts after the time it took me to walk home, remembering about 4.1, less than 15 mins ) as I think they stamped it as a final sale due to the rebate, but that's irrelevant : no final sales in Quebec, any retail transaction is protected by a 30 day return in law So I want your input on this : return and order from CoA the high tide, or keep it, make scans of the quickstart rules in exchange for the appendix/compendium of 4.1 changes mentioned in the poll... Thanks in advance for your views, Cheers ! NOW IRRELEVANT !!! BUT LESSON FOR PROSPECTIVE BUYERS : 4.1 CAN HIDE IN A 4.0 BOX !!!!

Exactly : the desire to do it has been there on and off most if not all my life, and after examining my motives and reasserting it's not a delusion, wishful thinking, etc. I realized I had to follow suite, so that if it doesn't happen, I won't keep thinking of what may have been. I have enough of that to deal with (as we all do) from past mistakes, hehe. And if down the line, I come to the realization it's not for me, that I'm not suited for military life, well then, I'll have served and won't be wondering anymore either. Btw, I'm single, no children of my own, but a small niece thanks to my sister, and yes, my protective love for that little girl does enter the equation. So yes, in a way circumstances are making it possible now, instead of 10 years ago... You grasped the essence of it, I wonder why Thanks all for the support (and jealousy, that made my day T. 8p )

Well, well, as some might of you might have heard or read me mention, I've been considering serving in the armed forces of my home country, Canada. The decision has been made, after doing some research and talking to a couple recruiters. Not right away, as I have a few things to sort out, as well as get back into shape (not in bad shape, but not in the athletic form of my early tweens) Hopefully, late this or early next year, I'll be in, and even maybe on short track for a commission. If I was to be refused or cut during BT by the Canadian Armed Forces, which would be a huge letdown, I would then go to the Legion, since I can't enroll in the regular French Army (I'm also a French citizen, but no enrollment beyond 26 in the regular French Armed Forces, afaik ), as I've made up my mind, finally, about starting a military career. Why at 38 ? Well, it's always been somewhere in me that will to serve and fight for right, but my father's hate/love relationship with the military (he was after all a deserter..), and the strong anti-militaristic ambiance of my formative years led me away. And then I had trouble.... To sum it up, let's say I had substance abuse problems that led me astray. When I finally started to get my life back together, I flirted with the idea again, but I guess I chickened out So now is the time... I have no illusions I won't get my dream job, which is getting my wings and then getting phase IV training : fighter a/c, due to not having a natural 20/20 vision ( iirc, even corrective laser surgery would not make me eligible for any flying gig, even though I have close to 100 hours of flight time on single/dual props and gliders, albeit none of it totally solo since I do not have a license) If I can get enrolled for training as sonar operator, that's another favorite of mine, the avowed goal being to serve on a sub, as it's not a very popular posting. I even researched enlisting with the US Navy a bit more than 10 years ago to serve on subs, but not possible, even with letters of recommendation from a decorated american Korea and Vietnam vet. Otherwise, it's either recon or intelligence officer/enlisted man, armored or infantry I have a feeling I might end up in military intelligence due to my tech skills I'd like to serve on the field, see the bear and all that, but I'll settle for what is wanted of me. Really interesting how recruiting is done in Canada now, very scientific but also open ended : what you want also plays a part into your initial career path, as you do apply for a specific job(s). And changing tracks mid-career is possible, depending on circumstances (going from a more than adequately peopled posting to a one of their "hot jobs" comes as an easy example of possible career switches) Anyhow, that to say that albeit I might dream of getting my wings or working on a sub ( as I told Herman before, I don't have a problem with confined spaces.... Troubled past et al. ), I'm also very enthusiastic about ending up as a ground hugger I'm not enlisting for the initial 3 year gig to get money for school, good credit and status with the banks, etc. In fact not at all : money doesn't even enter the equation, the signing bonuses and other perks being just nice side effects, hehe. No, this is the first, and only time so far in my working stiff life, that I'm making a 'career' move, that I decide to have one in fact : even as a game dev, it wasn't a career, but just my job, even if one I have/had much passion for. I'm going for the long haul, hopefully 'til they kick me out because I'm too old in 20+ years(you can enroll at 55 in Canada : they want a possible 5 years from you before mandatory retirement at 60) Physically, even with the abuse in my past, I'm in better shape that sedentary men 10 or 15 years younger than me. Simply, I want to serve my home country (and if not, my second country through the Legion), and in a way, pay back my debt to society in a real, concrete and meaningful way. Sorry, I had to post this, as much to discuss it with other people who understand and can encourage such an endeavour as to make it more "real" to myself : I'm not getting much support and even less understanding in my immediate family and social circles... First, a desire to serve, to make some kind of difference, however how small in the global scheme of things.... A desire to payback for all I've taken from this society, which is the definition of true national service, be it military or not. Where else could have I had this kind of background and turmoiled life and still be able to find a place in society ? If I had lived in France, as might have happened (we nearly left Canada in the late 70s for overseas ICAO postings of my dad, with strong possibility of moving to France in the end), I would not be in a position to make any kind of choice, I would be ostracized for my past mistakes, etc. Not that things are perfect in that regard here either : people do have prejudices. Anyhow, here is to looking to Private/Trooper, Cadet Officer or Legionnaire Quijano posting around these parts P.S. : forced marches don't scare me, walking being my primary mode of transport, and at a fast pace to boot But running.... I was a sprinter kind of runner, never an endurance one, so I guess I have to take up running as part of my preparatory training for physical exams. That said, it'll be much easier to get back into a training regimen with the result being access to my chosen career.

Doesn't the original CIWS system works against air targets by crossing the line of fire from both guns ? e.g just like AA flak guns. If that is the case, I completely understand professionals being worried... Or each works on its half of the ship's circumference ?

It is usual for visiting aircraft to use "exercise mode" (to put it simply) with their sensors and avionics rather than "war mode", in order to avoid the danger (perceived or otherwise) that a host or participating air force might glean sensitive information from the frequencies used, etc. Yeah, I messed up, was thinking in French when I wrote that : I meant it to say I did think it was for that reason that the IAF would not light up completely and use everything, rather than incompatibilities. So when I read about the exercise a few weeks back, and the writer mentioned incompatibility for keeping the Soviet/Indian electronics in "exercise mode", I immediately thought that it was most probably because of not wanting to divulge sensitive information to the US and its NATO partners instead of the given reason. In retrospect, and now knowing slightly more about the intricacy of the relationship between India and Russia in asset production and maintenance for that platform, well, it's even more obvious... I realize that I've managed to convey the opposite of what I was trying to say

Thanks, incredible pics, I love the mig cockpit ones... Btw, I thought that it was for security reasons the IAF would fly blind when it was mentioned a few weeks back as due to "electronics being imcompatible with US and NATO systems...", and not because one of their numerous bed partners is Russia (kamasutra pun, too easy and obvious, so I had to do it 8p) Cheers !

Bonnes vacances le cousin d'outre la Grande Flaque !! Fales Portuges ?

Now, if such opinion pieces were part of the mass perception and opinions, we'd be getting somewhere... (maybe, I'm a rotten cynic) Alas, even in our enlightened country of Canuckistan, apolitical geopolitics don't get no airplay

Hmmm, isn't 20/20 hindsight nice 8p Excellent article nonetheless, but where was the open source intelligence community on this topic last week, before the onset of hostilities ? I'm not a "hardcore" afficionado of OSInt, but you guys do browse the gamut of sources to a certain extent, so was anyone talking along those lines before ? I mean, the bit about Russia and Poutine, etc. is common knowledge, even without being up to the minute in what's going on geopolitically, it's been painfully obvious since the attempted coup in 91 that Russia could not be ignored. But the specific developments in South Ossetia, did they take the OSInt community by surprise too, or a sizeable number of actors were already discussing that possibility ? I mean, not the geopolitics of the last few months, or 15 years, but actual warnings, dire or not, about the respective force buildups... If not, as good and enlightening to a point as that article is, it's still 20/20 hindsight and the good old "blame the Intelligence Pros" game Thanks for finding it Brad

My, erh, thanks for noticing. I think... Hehe, cheers, and thanks.

Who does ? I think you're mistaking wishful thinking with reality. As CV said, mostly everyone signed them (and some of the accompanying treaties often thought as being part of it), but no one follows them to the letter. And as he implies, you're most likely including all warfare international laws, treaties and agreements under the banner of the Geneva convention, which is wrong You do know that the Geneva convention really only deals with the treatment of wounded soldiers (and since 1929, POWs) and the respect of non-belligerents ? Weapons and their lawful usage is NOT covered by it. The first convention (1864) dealt with creating volunteer corps for the treatment of wounded soldiers on the battlefield, and the clear identification of medical army personnel and volunteers. The second extended the first (1906) (note, nothing about civilians as of yet) The third, in 1929, defined rules for POWs, it was revised in 1949, when the Fourth convention was signed, adding treatment of civilians to what is commonly referred to as the Geneva Convention (as you can see, there are four, plus many revisions). Mostly everyone does NOT follow the Geneva Conventions to the letter, which completely forbid civilian casualties, or the more PC term of "collateral damage", as a means of waging war. It also forbids any form of rough treatment of POW (aka interrogation techniques), which everyone partakes in, even the so nice Canadians It also calls for a certain protocol to warfare, which is never followed these days : declarations of war, when they're effected at all, are done after hostilities have well started... (note : this might be actually be part of Hague conventions...) Parts of the Geneva convention are sadly outdated in face of modern warfare : it was put in place at a time when the establishment still thought in terms of set battlefields, the 19th century. That's why it's been updated at late as 2006. Again, it deals with the issues pertaining to the consequences of war, more than the actual conduct of war, even if it includes guidelines (which no one follows in the Western world, we all bomb majorly civilian targets to get at the enemy) on its conduct. As for what weapons and practices are legal, signatories can't even agree on the limitations, and they have specialized lawyers who deal with that kind of militaro-diplomatico-legalese for a living. So, for the rest of us, it's even harder to make heads or tails of it http://en.wikipedia.org/wiki/Geneva_Conventions Note : I'm no expert or lawyer

Indeed, this could be a foretaste of things to come from the "new" Russian administration (sic) : the timing is very suspicious, as it's coincidental with the world media busy with the Olympics in Beijing... Nasty. I hope your friend escapes the worse.

Added points 13, 14, 15, 16 and 17

Overhauling the ID scheme : A proposal for a hashkey/hashmap resource ID scheme and accompanying database scheme note : I'm using the word addendum to mean the "mini-db" facilities discussed in this write-up, that is platform/weapon or other records contained in a scenario or battleset. Again, I apologize for any repetition or messed up sentences you might encounter due to my haste in finishing those write-ups... This is to make a case for a new scheme to at first supplement the old one, but eventually should completely replace it, at least ID wise, but possibly scrapping the old DB system for a brand new one that's more flexible. Discussion and writeup follows For those who might not know, let me give you a crash course in what a hashmap is. Basically, it's a way to generate a unique key from an object or datum (piece of data)'s properties, like it's name, size in bytes in RAM, etc. This key is generated by a formula akin to the ones used to generate (pseudo) random numbers on computers. It's a little mathematical construct that lowers the chance of two "objects" generating the same key, and in the cases you get "collisions", e.g. two identical keys, a simple mechanism deals with it by adding one to that ID, verifying that ID/Key is free and then assigning it to the new record who was giving us a duplicate key. Using 32 bits for the key, would give us over 4 billion unique keys, more than enough for the next couple of centuries of HCE development (yes, this a geek pun, referring to Gates saying about having 1 meg of RAM...) Btw, this is the technique used by many serious DB Management system nowadays to generate record keys. That's the hashkey. The hashmap is a structure that lets you tie the key to a record or piece of data in a meaningful way, a bit like an indexed array, except that instead of consecutive numbering starting from 0 or 1, here the indexes are determined by their accompanying data. The old ID scheme has to go, period. If for just one reason : hardcoded ID number significations. Or rather, that the engine expects certain numbers to mean something specific, and not just an ID to an arbitraty record. I don't know how far along the work to decouple IDs from engine code is, but obviously work has been done in that direction, at the very least for high ID images. As for the DB schema, I think it's clear why it has to go (managing more than a few DB in an installation quickly becomes a feat of juggling ) We need a new scheme, where the GE or SE won't expect picture IDs to be in this range or that, etc. Furthermore, the in-game (included editor) numbers should have no correlation to the ID record number in whatever db they are (just this will simplify DB management, import/export greatly, as tools won't have to replicate the DB internal ID scheme) So in your DB/PE, you just let Access (or possibly another DB system if you prefer) number the records as it wants, as the formula for an item's key (the ID actually used in GE/SE) would be universal and a matter of maths. An hashkey built on the record's name or a combination of the record's fields using a proper hash generator would give you over 4 billion unique IDs using 32 bit numbers. Enough. And you have a system to deal with collision. Of course, everyone must use the same map, I"ll talk about ways to manage this later on. That would be for the common DB, that I call the "global DB" in my wishlist and write-ups. It might be better to have temp IDs for addendum records that are generated when they're loaded into the game or editor from a scenario and battleset, so there is no need to manage user content, as it has no absolute ID across the community until it's part of the commondb (aka the global official DB, which is last in line for asset lookup, after the battleset and scenario addendii, e.g scenario lookup first, then battleset then global DB). The engine/editor just uses temp IDs generated at runtime as mentioned above for them. Then, the chances of conflicting IDs is much lessened. Of course, we'll need a community wide policy on incorporating new records to the global/commondb, or any other global DBs concentrating on a past or future era, geopolitical situation, etc. Thing is, in this scheme, specialized DBs, as well as the mini-dbs I call addendums, can always rely on the global DB to look up records they can't find first in the scenario addendum or the battleset addendum. Of course, records in addendums would also have IDs, but they would be "temp IDs" or "local IDs", in the sense that they mean nothing as far as the global DB is concerned. That means, and I know I'm most likely repeating myself to the reader, that for multiplayer, even if there isn't a central server, there must be a "host" or "arbiter", which is authoritative as far as IDs go (maybe whoever loads the scenario decides the in-game IDs. Anyhow, having hashed based IDs would help with networking, as you'd come up with a similar scheme to pass data around and to which object it applies, etc.) I think that in any case, one machine would have to be authoritative and be the law in a MP setup, even in P2P, to prevent some easy cheating. Personally, I favor server/client architecture, but that's another writeup coming up (or more in a distributed computing scheme, where the server is virtual and made up of all the machines participating in the online game, like SETI@Home, etc.). Sorry, but it's a very important point in bringing MP to HCE, if you want people to play, especially new players : the scent of easy cheating must not viciously coil itself around HCE MP In fact, in that scheme the hash based keys of the global DB would only be used to quickly retrieve records from it at load time, when preparing the data for the scenario. Ditto, for the platform display. It probably works that way in HCE's internals already : load stuff from commondb, copy it to memory record used in GE/SE operations, etc. So in all likelyhood, the major work would be revamping asset loading routines. I'd love to hear more on this, Tony or anyone else familiar with the internal workings ? The way I see it, existing records could even keep their current IDs, to maintain compatibility with old scenario and battlesets, and the new scheme would be applied to new entries to the global or commondb. It could be made to work under the current DB scheme, where everything is either in commondb, or in the Battleset DB, simply by prepending a unique ID to each DB, so that the engine would know where to look and could give meaningful error messages when it can't find it To finish, for now, my goal is to start or restart discussion on this topic, so that we can revamp resource management in HCE to simplify matters for the whole community, whether using a system based on the ideas exposed here, or something else altogether is not important to me. I will post another write-up on ways to manage the IDs, so that we don't have to deal with conflicts between user and official content on an annoyingly regular basis. Thanks to all for reading so far.

Case for more complexity in Ammo Points system : (note : I apologize in advance for the so so quality of the text and any misunderstandings stemming from it, as I had to edit/rewrite a lot of it in a very limited time frame, cutting down on my original drafts, which tended to be quite longer than the final result..) The proposed ammo system : First, it's first for a/c loadouts, but could easily be expanded to other ammo types (exercise for the reader ) It would still be a point pool for a/c ammo, but it would have additional constraints that would limit the amount of ammo of a certain type that could be bought through the point pool system of replenishment. Ideally, this should be an optional feature on the scenario/campaign level, features revamp allowing, . Meaning that by default, everything would have the default max value indicating no limits beyond having points to buy it. It remains to be seen whether it would be per loadout type (intercept, cap, cas, etc, iron bombs, precis, etc.) or by weapon type, as I think that you might as well do it per weapons so the system can be extended as is to other weaponry or assets/supplies if desired. Weapon limitations have the inherent side effect of limiting loadouts that use said weapon or equipment, achieving the loadout limit goal. For clarity's sake, in the text that follows I'm assuming per weapon type limits, as in missile/shell/etc. Either way, there would be a cap, that would be decremented by 1 everytime this type is purchased through the point system. So the record that keeps track of your aircraft ammo points would also keep track of maximums. A simple method like having unlimited weapons/loadouts have a max of -1 (so no decrementing, always available) while limited weapons would have their totals stocked in that field, and decremented appropriately when purchased. If this is not clear, please say, I'll try another tack Especially if any still think it's as much work as keeping track of exact weapon amounts : the whole point of this is not to have to do this, by having the default behaviour of no additional constraints beyond having the points to buy it. Why ? many have asked. Well, to be able to model specific ammo stock shortages, just like can happen in real warfare, rather than just limit them in a general way through just the point system. eg. not just saying you can't have any of this kind of cruise missiles or asm, but that you only have 1 or 12, or whatever of them. This is very interesting from an operational perspective, as it's relatively simple (especially in view that it would be built on the by then existing point system) but opens up a new world of complexity in the kind of situation we can model and represent, as you would have to make difficult choices on when and how to use your aces. For starters, this is really not that hard to do, and would even be easier to do with Lua integrated (plus, authors could mod the system for their scenarios and battlesets) I say this, because once it's a given that a major overhaul is being considered and worked on, it's not much more work to add to it at that point. If not, it's important to do the overhaul with view of ongoing modifications down the line, especially if it's to be tested iteratively by the community. But I digress : that's more to do with development strategies than the ammo points system. Akula proposed and elaborated the point system that will be the basis for replenishment mechanisms in HCE. As I posted early on in his thread, I found it to be a very simple and elegant solution to a complex problem. We don't want to switch the focus to micro management of supplies and ammo, so you can't give us too many details to deal with as the work necessary to manage it grows with the number of units to do it for. Not forgetting that using a very simple system to start with limits the number of bug sources, and simplifies building on it. So what I'm pushing for would be built on the underlying point system, after we've collectively verified that it's working to our expectations and is not taking away from the game's "fun factor" (hehe) As I've mentioned somewhere else, I think the first iteration should be just the point system as outlined by Akula and Tony. An alternative : One important point that's been raised by others : point value should model both volume and weight in that a missile or any other replacement system that takes up a lot of volume in cargo space should cost more than a similarly weighed cargo that takes up less volume. Reading the point about the Phoenix missiles posted earlier today in the replenishment thread (iirc) brought this to mind. I think that even if we stick with a pure point systems with no caps per item (well, a/c weapons being my first concern, but the system I present, again, can be easily expanded to cover anything that can be replenished), we should be able to modify costs and point pools on a scenario/campaign basis as to be able to model the situation as a designer sees fit. In fact, if having maximum caps for certain kind of ammo is not possible, I really think that we should be able to edit the point pool for replenishment vessels and onboard stores for other assets, as well as cost values for replenishment items, including but not limited to ammo, as to reflect potential limitations : if I can raise the cost for a certain kind of missile to the point that buying a couple (or a couple loadouts including it) will severely impair one's ability to earn victory in that scenario by stripping his points pool bare to buy those missiles. So that's one other possible solution to being able to limit particular ammo/etc in a scenario or campaign. Both could even coexist. My point being mostly that we should implement simple, additional constraints to the points system.

Case for Lua Scripting : note : This article goes a bit further in terms of technical details regarding implementation, to help Tony in his exploration of that possibility. I'm of course, ready to answer anyone's questions on the topic. It's also a work in progress Lua is very simple, and easy to embed into an application, as that's what it was designed for. It's ANSI C, hence can be "glued" to any set of programming language/runtime environment. It has a fast garbage collector, meaning the end users, aka gamer, who wants to mod, or add nifty features to his scenarios and battlesets can more than dabble with the scripting, without having to know much about programming fundamentals, and in particular, memory management. To boot, Lua can also be used as just a configuration language, which is what probably how most end users in HCE would view and use it. Implementing it in the way I envision (and Tony, if you want to do it, I'd be more than happy to help) would give the instancing feature I've mentioned for free : exposing the various structures that hold game-time information to Lua, would allow us to do something like this : Carrier1 = new Ship("Nimitz"); Carrier1.damagepoints = 700; -- original value being whatever (more realistic and extensive examples to come) It opens us a whole world of community interaction with the game, without having to make it open source, or even share the C source at all, hence not running into licensing issues. Some serious modding can be done through Lua, including the possibility of writing new external code in C (or other languages, as long as it's wrapped with Lua C API) to override existing behaviour, be it through a callback mechanism, or by setting up the game loop in a script file at game load time. World of Warcraft uses Lua for the UI : they implemented a set of UI widgets that can be created and configured from user scripts, as well as a library of functions calls and data variables that can be manipulated in user scripts. The possibilities are quite exhaustive, one might say endless, and also very powerful, while allowing your normal user to leverage it. Of course, this is not magical, you have to do some work in the game engine, etc. to expose stuff to Lua, but then, even Tony can code without having to rebuild the whole thing. The same executable could be used for scenario editing simply by changing its set of initialization scripts. Extending the application without rebuilding it, aka modding it, becomes possible through user written scripts. Configuration wise, it could have lists in script form that the GE/SE loads at initialization, describing images, sounds, videos, etc. that the UI uses. . Other internal parameters that don't use external (outside the program itself) resources could be exposed for configuration, like colors used for untextured land and sea, fonts for text, etc. Like .ini files, or batch files (to a certain extent, don't let that scare you off, hehe) Of course, scripts can be generated from user choices in tools, etc. So that manual editing is not the only possibility, but guarantees that anything meant to be exposed for modding/editing/etc. can be so at least in text form. That Lua is a complete programming language, and really, really fast at what it does is a bonus. It could render possible writing AI/PO for individual ship or ship classes, since at the simplest level, being able to do simple if then constructs, loops, variable assignments, and the like are the basic tools of progrmaming, hence of AI programming. Lua does not enforce Object Oriented programming, just like C, so don't think of Java or Python, or C# when you think scripting. Or basic, visual or not. It's very simple and powerful, and through its table construct (a sort of associative array if you will) allows the developer to build his own object system if needed. This is one of the reasons its performance is so good : simplicity of the innards, not including a complex object system and object hierarchy, etc. This simplicity also allows you to build your own object or whatever system with it, for your own particular needs. In that simplicity lies its true power and flexibility : you can keep things procedural or modular if you want, or build an object hierarchy with multiple inheritances (you'll have to implement it, and well, multiple inheritance is crazy, since you can do most of it with single inheritance and composite patterns), etc. Exposing HCE's innards to Lua doesn't have to be all done manually : there are a few tools out there that can generate bindings for Lua from sourcecode. Of course, you have to prepare the source for that, but that's beyond the topic of this writeup. Again, I reiterate my offer to help with this endeavour : it would open up such a world of possibilities, as well as allowing long term community maintenance of HCE without having the C source code, since a well planned scripting implementation coupled to a lightweight C API would expose everything needed to keep the game alive for years to come. It's really not very complex work, and is not very intrusive on an existing codebase : after all, you can pick and choose where the Lua virtual machine interacts with the game engine. Again, this work is what Tony would do, not the end user, who would only reap the benefits, and wouldn't have to touch it if he doesn't want to, albeit probably everyone would at least use it insofar as nearly everyone would tweak config files if there are any As Lua is a real programming language, with no expensive development tools needed to use it (it's open source in a very liberal way (not GPL)), it's very simple to use : you only need a text editor, as the virtual machine compiles the scripts from text form to its internal representation when they're loaded. A few debuggers exists for it, and it includes a debugging api, for the more involved script programming. Also, you can extend it with dll like modules written in C that you can load from scripts with a dedicated command (require iirc), that could call HCE's external C API on top of adding capability to Lua inside HCE Communication between Lua and "native" code, is done through a C api, which has Lua calls for the Lua side and C calls for the C side. It's done through a memory stack, through the usual push/pop calls, as well as other utilities to manipulate the stack. Lua uses those same calls for internal use, as any application's scripts will. But this allows the modification of a variable in Lua to also modify its counterpart in C code, and vice versa, affecting script variables from inside the engine, be it in-game or in-editor. Where to get more information on Lua : Official website : http://www.lua.org/ About Lua @ above site, for a quick flyover : http://www.lua.org/about.html Lua-Users wiki home page (good for community built tools, like automated code binders, language bindings, etc.): http://lua-users.org/wiki/ A list of known projects using Lua : http://www.lua.org/uses.html Edit : added some content, corrections, as well as external references on Lua, for those who might be interested

Nic's HCE Wishlist In no particular order, so while numbering is used to follow existing guidelines in using wish number to refer to it, you shouldn't assume the earlier ones are the most important to me. Neither is the quantity of verbiage on a topic any indication : here the professional inclinations show themselves, it's all somewhat interlocked in a cohesive design in my mind, as I've been tackling those same decisions on personal and professional projects in the past, and still do So technical aspects sometimes have been expanded on, etc. Especially in the early items, but time marches on.... For whom the bell tolls... erh, Tony told me to hurry up So some of the little(st) items are very dear to the designer in me, like augmented viconds, campaign mode, etc. 1 - ID numbering scheme and DB scheme refactoring, ultimately legacy free (haha) (the two go hand in hand in my mind, see my more extensive write-up on this topic later in the thread). ID numbering scheme should be key based, the key being generated and managed with standard techniques like hash maps, etc. Most important, the ID used in game should have no dependency on whatever scheme Access (or any other DB system used for the PE with this new scheme) uses internally to manage individual records across many tables. New DB scheme would then be using existing data layout and migrating it, eventually even retaining old IDs for existing data (far from impossible) to that new ID scheme. Also, from a loading data perspective in the GE and SE (and any other future tools), the way data is loaded would change to something like this : first look into the scenario for instances or custom asset classes, then the battleset, then the global DB. 2 - Lua integration for scripting (both programming and config scripts/external data handling) and in a roundabout way, ANSI C (or any language that can be wrapped with C ) plug-in programming (Lua includes a way to load external binary code that follows its guidelines for binary modules). Dedicated write-up follows in this thread. 3 - Multiplayer, with authoritative server, whether this is done P2P or server/client from a network protocol and transaction level is implementation dependent. Conceptually, I strongly believe there should be one (or more machines working in distributed fashion, like seti@home) server, who has authority on the game world, and decides on the validity of data. Even more strongly, I believe that the less calculations one does on one's machine that affects one's assets, the better. Cheating is a reality, and when you make it easy.... Sadly, that can be a strike against integrating scripting, but not if you have an authority directing and arbitrating the validity of the data flowing between players, and coherence of the game world. More info farther along. 4 - Per Scenario Instancing of assets, to allow modelling of damaged ship, limited ammo and supplies, unique custom platforms, etc. More info in following write-ups in the thread 5 - Supply/Limited Ammo : Again, my vote goes for Akula's idea for the point system, which can then be used to build the system I describe later on in this thread, which models ammo limitations with slightly more detail. Basically, I would like to see specific ammo limitations to model situations where you have limited amount of a particular ammo. This would be implementing by maximum caps, with a default value for unlimited beyond the point system (meaning if you don't have enough points, well you can't have any of that), zero for not available at all and a numerical maximum value that's decremented every time you buy such ammo (or whatever else, it can be easily expanded) and expend the points for it. So to get a particular ammo, you need to have enough points to purchase when resupplying but there has to be some left. I'll come back to it. 6 - Realistic speed/depth changes : I don't mind so much the group window reflecting the orders status for a group, but individual subs, ships, a/c changing altitude and speed instantly because of a group change... Granted, at the unit level in a surface/sub formation, a group order doesn't always change speeds/depth immediately since those units could be on patrol, catching up with the group, etc. 7 - More functional unit window : I want to be able to give orders to individual platforms in the unit window, beyond the formation editor.. If what I do puts it out of the formation and I don't take it out of the group, then it'll try to catch up with it once I'm not giving it my attention, e.g micro managing it any more, or whatever realistic consequences to taking a unit out of formation without dividing it from the group first. Still, this is more about more functionality in the unit window... 8 - Slightly more complex modelling of aircraft ops : modelling individual a/c very simply but more complex than now. Maybe a happy medium between Flight Commander 2 and our present situation, e.g. data modelling of individual a/c without going into so much movement detail as FC2, something like that. And the AI for it, or means to implement doctrine/SOP like in many games do for their ground units (TacOps, hi pete ) 9- Ground combat Ops, operational, somewhat tactical using a TacOps like system of SOP, direct orders, and AI execution, but at a higher organisational level, possibly. (or scalable) But a simple system, as far as modelling weapons,etc. but allowing some tactics fun. 10 - Comms/Data links modelling, and contextual sitrep (right click unit and group menus is my 10.5 wishlist item) Comms/Data links modelling : something with basic ranges, that drives the contextual sitrep item. Contextual sitrep, is that when you select assets that don't have the global picture, you get some indication of what it is they can and can't see, maybe by shading contacts that are not contacts for that group/unit ? (been playing some FC2 again lately, and that's how you know if you can target a certain bogey/bandit : you might know it's in front of you but can't see it so it's shaded/grayed out) All this is again a cry for more Unit window functionality : I love the unit window vs multiple zoom/tracking windows in ANW. I just with it did more.... 10.5 - Right-click contextual menus for groups/units, bases, even empty spot on the map (you'd get latitude/longitude/depth/weather/sea state, etc in the menu, or an option to show them. Example, obviously ) 11 - Advanced Viconds, including taking (back) bases, juryrigging them for use, and ditto with platforms, even in a sufficiently long scenario or campaign. 12- Campaigns : possibility to really string along scenarios and use results from previous ones, including viconds, but also unit damage/destruction, Supply/Ammo pool points, etc. Again, scripting would simplify doing a lot of this, as well as allow other programmer to help without needing the source code to HCE 13- ECM/Jammer control : being able to control ECM/Jammer like other sensors. 14- Extended/Custom Range Rings for Formation & Bases : Ideally, user configurable for each formation or base. If not, and they have to be "hard coded" then, vastly extend each ring in the base case. Seconding existing requests for that feature 15- Extended A/C Patrol abilities : When I send an Orion on an ASW Patrol from a base outside its range rings, I'd like that the AI controlled patrol would search a zone at the end of the patrol path, which gets it to the zone. Similar to other feature requests. 16- Time Controls in SE : Ability to not only set a precise start time to a scenario, but also ability to move along the timeframe of a scenario inside the SE, quite like in the H2/H3/ANW SE. This would allow us to "spawn" units later on, etc. 17- Partial "viconds" and scenario events : Ability to set goals or viconds that are activated before the end of the scenario, which couple to point 16, gives scenario editors the ability to set conditional events/unit dispatch, etc. For example, need to destroy TF1 before the next day for a certain event to happen and reinforcements to appear at a landbase, etc. Possibly more to follow, write-ups are coming later on tonight and tomorrow at the very least as posts in this thread. Edit : corrections + added 13, 14 and 15 (Aug 4th 08, 19:36ish) Added 16, 17 (Aug 7th, 2008)

Better than that, you can strike two birds with one stone : by allowing us to have "modified" instances of platforms and anything else from a DB, you have both this feature and the smaller DB all in one. Let me explain : instead of making a complete new DB for your battleset or scenario, you just basically add a particular instance of a platform, etc into the scenario. So that allows, for example, to have a special Typhoon to emulate Red October just in that scenario, or damaged ships, etc. This should work with a revamp of the DB scheme, where HCDB is just the common database : when you load a scenario, it first looks for instances or custom platform classes in the scenario itself, then in the battleset addendum/embedded DB, and finally, in the HCDB/common DB. That would probably work easier with a revamp of the whole ID scheme ( I mean scrapping the old one once the new one works) which wouldn't be based on sequential IDs for game engine use, but hash based keys, that would use the record itself to calculate the hash key. Standard key conflict resolution would be used for duplicates, but that's an implementation detail (hashmap). If needed I can expound on this in another writeup (Yes, my writeups will be coming soonish, I'm a bit of an obsessive perfectionist, hehehe, or I totally improvise like for this write up) Sorry for intruding like that Akula But yeah, a new DB scheme that would allow instancing of platforms and custom platforms in scenarios/battlesets without having to embed a full DB would be nice.

I'm having trouble believing this hasn't been doctored at all : the missile itself in nearly all the sequences seems to have a different contrast/brigthness setting than the rest of the image, and it looks totally "unnatural", not something that could be explained by "albedo factor" reflection, or something of the like. Anyone think the same ? Anyhow, watching it a second and third time just now does help with lowering my cynic scepticism, but not completely, something seems off. So saved on my hard drive for some more serious inspection Cheers !! N.

Sorry. Me. Comments, ideas later (too many things to write, only so much carpal pain one can take, and well, so little time 8p)

Hey Now, with all due respect to the Legion, let's not go down that road. Hehe, I knew you'd take exception to that As would a member of SAS, or any of the elite forces around the world, of course. Each and everyone of them most probably thinking his outfit is the best, being de rigueur and par for the course I'd say As for myself, I wouldn't know But the whole Légion recruiting's site does have that super bad arse super soldier aura to it, underneath all the "rejuvenated" look of the Legion : with having to sign in under an assumed name, the explanations as to why historically this was the case, and why the tradition is still maintained, even though it's not Murderer on the lam central anymore, or so they say Still insisting that you can join whatever your life's situation is outside the Legion, really sounds same old same old to me. And they call it revisiting their image, hehehehe So I had to make the classic chauvinist Frenchman comment, otherwise the world ends (or so would "we" French would like to think;)) Or something like that. As TEPonta pointed out, a lot of myth in that mythical aura, no doubt Then again, all elite corps have it too, to various extents. When you start measuring things, blablablablablabla 8p

Bug in SE 2008.44 : Is this a known bug ? When unit window is at x1 zoom, distances are double what they are in group window. Seems to happen at other "ratios" between unit window zoom and group window zoom, eg. certain combinations of zooms seem to trigger that bug in other situations than the 1x unit window. Haven't been able to 100% reproduce a list of such zoom settings, but could give it a try, if it's needed.

Je me doutais bien que t'etais français, hehe As for the Legion, if you think the Marine Corps is tough, well, the Legion will give it a new meaning. Ask some SAS dudes That is all. Oh, lest you don't know before you sign up folks : 5 years means 5 years, active duty or doing time in the stockade. NO EARLY OUTS Again, no early outs, no dishonorable discharges... Yes, it's like the Roman Legion (well, back then it was a 20 year hitch), and yes you can't join under your real name. But you can re-assume it after a year, after a standardization of your identity and military status. After 3 years, eligible for French citizenship, if you don't have it already : think about it, that means a EU passport...