Evil_Echo

There is no special character in a vanilla version stringtable.xml. The first line there would be just <?xml version="1.0" encoding="UTF-8"?> A counter suggestion to me making the FSM for you, which is quite easy once you are used to that editor. There are plenty of examples in the missions that come with ArmA - unpack the missions.pbo and look in Bootcamp\T02_Parachute_Jump_Training.utes\kb\ and open instructions_BIS_instructor.fsm with the FSM editor. Looking at one would be more effective than my posting a series of screen shots to detail every element's contents in the FSM.

When in doubt, test the situation without ACE ( or any other mod for that matter ).

The odd character in the leading line of the XML is due to my saving the file in UTF-8 format -I have some Cyrillic later on in that file for a Russian civilian. There is no recommended name schema really, though I tend to tag with a leading STR_DIALOG just because that seems common elsewhere. In regard to FSM files... You put your tests ( the cases in the switch ) in condition tests ( yellow diamonds ) and the responses in termination boxes ( the FSM is called, runs and quits until needed again ).

The script or fsm is passed several magic variables besides the well-known _this. In the context of the kb system. _this - who sent the message. _from - what character the message was send to. _topic - the topic at hand, the arbitrary label you assigned to the conversation as part of kbAddTopic. _sentenceId - the classname entry you defined in the bikb for a particular sentence. Your script/FSM takes this information and formulates whatever response you want. The flow comes from each character having files defining their reactions. A simple example based on your dialog - call it "chatter" chatter.bikb class Sentences { class J_0 { text = "Hey!"; speech[] = {}; class Arguments {}; }; class P_0 { text = Uhh, hi."; speech[] = {}; class Arguments {}; }; class J_1 { text = "So those bastards came after you too, eh?"; speech[] = {}; class Arguments {}; }; class P_1 { text = "I... I think so."; speech[] = {}; class Arguments {}; }; class J_2 { text = "You 'think so'?"; speech[] = {}; class Arguments {}; }; }; chatter_player.sqf BIS_convMenu = []; switch (_sentenceId) do { case "J_0": { _this kbTell [_from, _topic, "P_1"]; }; case "J_1": { _this kbTell [_from, _topic, "P_2"]; }; default { }; }; // return the sentence list pool BIS_convMenu chatter_JohnRaynor.sqf BIS_convMenu = []; switch (_sentenceId) do { case "P_0": { _this kbTell [_from, _topic, "J_1"]; }; case "P_1": { _this kbTell [_from, _topic, "J_2"]; }; default { }; }; // return the sentence list pool BIS_convMenu You would also have FSM files with the same logic flow as the scripts, but those are hard to post in this forum. To humor me, pretend they are out there as well. In your init you do a kbAddTopic of chatter.bikb for both your characters - using "chatter" as your topic. JohnRaynor kbAddtopic["chatter", "chatter.bikb", "chatter_JohnRaynor.fsm", {call compile preprocessFileLineNumbers "chatter_JohnRaynor.sqf"}]; player kbAddtopic["chatter", "chatter.bikb", "chatter_player.fsm", {call compile preprocessFileLineNumbers "chatter_player.sqf"}]; Then at the appropriate time in your mission scripts/triggers you have JohnRaynor start the conversation and the responses ping-pong back and forth. JohnRaynor kbTell [player, "chatter", "J_0"]; This example is linear in flow, but you certainly could code in branches to reactions to make the dialog go in differing directions.

Mando is not one to give up easily. Sanity is such a minor thing anyway. But thanks for the good words. Alway doing our best to make it even better.

Check the other thread on this subject - I have posted some samples inline there.

I use a switch vs a series of if-then-elses to make the code cleaner. I use tests at all because that is how you get a character to automatically respond to what another has said ( this is AI after all ). The advantage is - you don't have to write a long series of chat statements. Just the first one to trigger the conversation and the responses and counter-responses just flow. No need to time the sound samples and add sleeps to ensure that A is done talking before B starts up. Also the system picks the right channel for you, local if close by, radio if distant, vehicle if both in same ride.... Stringtables - just a handy way to package up phrases. And as already mentioned you can have phrases in different languages all keyed to one tag - game makes the substitutions for you auto-magically. The string table can be a file in one of two formats. The older way is a .csv file, comma separated values - a common format supported by spreadsheets like Excel. Kinda clunky and harder to edit. The new way is in XML, much cleaner and even viewable by most web browsers. Only downside at the moment is the BI wiki has not documented the XML version yet. It's not hard though. Block and tag in a manner similar to html... <?xml version="1.0" encoding="UTF-8"?> <Project name="Arma2"> <Package name="Mission"> <Container name="Red Dawn"> <Key ID="STR_DIALOG_BRIEFING_D1_0"> <English>Hammer 1 - attend the morning briefing.</English> </Key> <Key ID="STR_DIALOG_BRIEFING_D1_1"> <English>We'd appreciate you joining us at the briefing, soldier.</English> </Key> <Key ID="STR_DIALOG_BRIEFING_D1_2"> <English>Hammer 1 - get your butt in a chair at the briefing tent now!!!</English> </Key> ... </Container> </Package> </Project> The tags used for each "Key ID" are what are referenced in the bikb file.

The FSM editor is pretty much required for manipulating FSM files, plain text editor just does not cut it there. For conversations, you need a couple of files. The bikb file, contains the text phrases to utter or references to stringtables entries, and references to optional sound files if you want audio. You include all dialog for all parties of a conversation here. You can have multiple files for different topics and they can be used simultaneously if you want. For automated responses you need one or two files each character in the conversation. A FSM file drives the responses for AI and a sqf script for when that character is currently run by a player. The logic in those files is just simple action-response events ( if someone says this then I say/do that ), so if you look at the sqf version you can figure out what the FSM would be and vice-versa. For non-automated dialog, there is no need for entries in those files at all, so in some cases you may not even need more than the bikb file. All the files go in a kb\ folder in your mission... For evac conversations, here is the bikb... class Sentences { class M1_0 { text = $STR_DIALOG_EVAC_M1_0; speech[] = {}; class Arguments {}; }; class D1_0 { text = $STR_DIALOG_EVAC_D1_0; speech[] = {}; class Arguments {}; }; class M1_1 { text = $STR_DIALOG_EVAC_M1_1; speech[] = {}; class Arguments {}; }; class D1_1 { text = $STR_DIALOG_EVAC_D1_1; speech[] = {}; class Arguments {}; }; class M1_2 { text = $STR_DIALOG_EVAC_M1_2; speech[] = {}; class Arguments {}; }; class D1_2 { text = $STR_DIALOG_EVAC_D1_2; speech[] = {}; class Arguments {}; }; class D1_3 { text = $STR_DIALOG_EVAC_D1_3; speech[] = {}; class Arguments {}; }; class D1_4 { text = $STR_DIALOG_EVAC_D1_4; speech[] = {}; class Arguments {}; }; class D1_5 { text = $STR_DIALOG_EVAC_D1_5; speech[] = {}; class Arguments {}; }; class D1_6 { text = $STR_DIALOG_EVAC_D1_6; speech[] = {}; class Arguments {}; }; class M1_3 { text = $STR_DIALOG_EVAC_M1_3; speech[] = {}; class Arguments {}; }; class M1_4 { text = $STR_DIALOG_EVAC_M1_4; speech[] = {}; class Arguments {}; }; class H1_0 { text = $STR_DIALOG_EVAC_H1_0; speech[] = {}; class Arguments {}; }; class A1_0 { text = $STR_DIALOG_EVAC_A1_0; speech[] = {}; class Arguments {}; }; class H1_1 { text = $STR_DIALOG_EVAC_H1_1; speech[] = {}; class Arguments {}; }; class A1_1 { text = $STR_DIALOG_EVAC_A1_1; speech[] = {}; class Arguments {}; }; class H1_2 { text = $STR_DIALOG_EVAC_H1_2; speech[] = {}; class Arguments {}; }; class H1_3 { text = $STR_DIALOG_EVAC_H1_3; speech[] = {}; class Arguments {}; }; class H1_4 { text = $STR_DIALOG_EVAC_H1_4; speech[] = {}; class Arguments {}; }; class H1_5 { text = $STR_DIALOG_EVAC_H1_5; speech[] = {}; class Arguments {}; }; class H1_6 { text = $STR_DIALOG_EVAC_H1_6; speech[] = {}; class Arguments {}; }; class NukeCity { text = $STR_DIALOG_LAUNCH_HQW_City_Nuked; speech[]={}; class Arguments { class Burst_type {type = "simple";}; class Grid {type = "simple";}; class Location {type = "simple";}; }; }; class NukeLocation { text = $STR_DIALOG_LAUNCH_HQW_Location_Nuked; speech[]={}; class Arguments { class Burst_type {type = "simple";}; class Grid {type = "simple";}; }; }; class Interrupted { text = ""; speech[] = {""}; class Arguments {}; }; }; class Arguments{}; class Special{}; startWithVocal[] = {hour}; startWithConsonant[] = {europe, university}; and script file for Delta Team, the base commander.... BIS_convMenu = []; switch (_sentenceId) do { case "M1_0": { _this kbTell [_from, _topic, "D1_0"]; }; case "M1_2": { _this kbTell [HotShot, _topic, "D1_2"]; }; case "H1_3": { _this kbTell [_from, _topic, "D1_3"]; }; default { }; }; // return the sentence list pool BIS_convMenu

Now have the kb system working very well, it just takes a little practice to get your head fully wrapped around it. And using it with the MP support modules ( rKBTELL via the RE call ) works fine for simple phrases. But remote version does not appear to support complex phrases, ones with variable substitution. Looking at the 1.56 version of the MP module seems to support that finding. :confused: All is not lost, you just need to use a wrapper script and rEXECVM that instead.

EASA just replaces the launchers it can find with new ones. Basically swaps the hardpoints out. The amount of ordnance is just what the new launchers can carry. Guessing you'd need to specify some version of a rotary bomb rack to simulate the internal bomb bay capacity and some hardpoints on the wings for external stores. You'd definitely need to have the B-52 set up to work with EASA if you wanted to allow use of the ACE B-61 nukes because that is how those bombs are armed. Otherwise those bombs are just shiny rocks. The bombs can be loaded at start of mission without using the UI, but the EASA code has to be used in one way or another. Mando weapons have their own way to setup. No interconnect with ACE in this area.

Concider ArmaHolic as a host, they are good.

Could be just the sound you are using. I recorded my own PA announcement, put it through a band-pass filter to reduced the quality and added a touch of echo to increase the feeling it was coming from a real loudspeaker outdoors. A trigger fires off a stock alarm sound FX and also kicks off a script to say3d 3 sound files to make the announcement. Only slightly hard part was ensuring the alarm shut down later.

I see it too, annoying but harmless. Ditto for a number of other warning messages.

Don't use any mods when playing those missions, most likely one of them has upsurped the key binding for flashlights/lasers.

Seems non-spam content to me. And you are helping out a fellow Mando'er so why not?

FYI - the MM/EE nuke is not quite the same as the ACE version (the B-61). Using both in a mission could lead to some inconsistant effects. It's nothing that could not be overcome, mostly synching ACE's version to the improved weapons effects routines I wrote for Mando. Plus some better ties to ACE's individual and vehicle damage systems. Up to ACE if they want to do that.

Wut?? Sorry, not every artillery mod. Perhaps you mean those that use one-click actions on a map to target. But if precsion is an issue, a better mouse is the solution as already mentioned.

Would rather fight than play dress-up Barbie. :rolleyes: Like it or not, ArmA is a combat sim not some MMORG. The focus is on fighting, particularly infantry and armor. Any role-playing capability is largely up to mods adjusting individual soldier models, face, uniforms, etc. The game engine is not designed to support morphing the underlaying skeletal structure - so making a soldier more or less bulky/tall on the fly is not feasible. Don't think BIS should expend the resources to support adding that capability either. They have limited time and people, tasking them with such an off-topic feature would be a great waste when far more important things are needed.

If you are looking at AI-only solutions I already have that in the ECHO package. It allows for custom notification of artillery events and manages ammo internally ( well, BIS does reloads for ya when using just AI ). Packages like ACE and R3F are oriented for player use, but great stuff as well.

Do believe you need CO (A2+OA). I have used MM with just A2, but you get warning messages about some missing dependancies. Attempting the same with just OA would likely not work at all. Given the going price for A2, it's worth getting it for Christmas. There are some nice demo missions included that show how to launch a scud with the various warhead types. Basically you just add a line or so of code to your mission scripts to activate the magic for a scud launcher you've placed on your mission map. Something like the following, where scud1 is the launch vehicle and there is a target marker on the map called "mk_nuke".... [false] execVM "mando_missiles\mando_missileinit.sqf"; [] execVM "mando_missiles\mando_gun\mando_guninit.sqf"; // Wait for Mando Missile addon initialization waitUntil {!isNil "mando_missile_init_done"}; waitUntil {mando_missile_init_done}; [] execVM "mando_missiles\mando_setup_full.sqf"; ... // Nuke em - heheh [scud1, 2, getMarkerPos "mk_nuke"] execVM "mando_missiles\units\mando_ai_scud.sqf"; My MIRV bolt-on is not currently included in the release - see comments in a few postings back. We'll see about how to get that out if there is enough interest in it.

I posted a quick and dirty script wrapper to do just that some time ago. Since then have built an entire package for artillery. But for your case the old script would do fine, should be able to locate via searching this forum.

Cannot discuss certain things in public nor anything starting to come too close to those things. Just have to take what I have said as good enough without asking why. Sorry. I never assumed those warheads were local designs. More likely bought or stolen from a more advanced country because of the difficulties previously mentioned.

Given that damage is proportional to the cube root of yield, a properly spaced 3x5kt strike covers a bit more area than a 1x80kt and damages it more uniformly. Sound military technique as well as cheaper to compute game-wise, so win-win. There already was a MIRV ( a MARV really ) in one of the demo missions bundled with MMA. I used that as a template for my SS-20, making it fly faster, higher and release the warheads in a spread over the target with a reasonable bit of CEP tossed in as a true MIRV would do. I had also tuned a copy of the patriot to better approximate PAC-3 standards ( being a realism nut ). The improved patriot can almost always knock down a scud or my SS-20 when it's not using the MIRV option. But only seen my battery of 2 launchers kill the MIRV'ed variant once in the many times I've tested the mission, a very lucky shot that got it before all the warheads had spread out. It's up to Mando whether we should bundle up my versions in his release or they get offered separately - they're just simple stuff built on top of his wonderful toolkit. I'll trust him to make the correct call on that. Meanwhile, a couple pics... Patriots firing Incoming MIRV Airbursts The decay rate variable should probably go in init.sqf, since it's global and only needs to be set once. But see no real harm in putting it in the JIP init as long as the value never changes.

+5 to that.

Yes, a misfired HE or nuke warhead would destroy the missile. All I can say is that this is nonsense. The reasons why are not something to discuss in open forum.