Jezuro

I think it's time to introduce something to prevent the asset destruction by teammates. I must admit that the behavior of some players has taken me by surprise. I should have expected the worst.

@EDcase @HellhoundF There are multiple spawn-kill preventing methods and punishments implemented (as mentioned in the recent update changelog). If these are not working properly we'll do our best to identify the issue and fix it. @Hostilian

While I agree with most points, there are still smaller scenarios hosted for those who prefer them.

The list you create is added to the group classes loaded from the faction config. If you don't want certain groups to be spawned at all, you will have to change the faction name in the Init module to some non-existing one and list all groups you do want to use in CfgWLFactionAssets. Keep in mind that individual Independent vehicles are never spawned on their own, only as a part of a group. Unless of course you use preset vehicles in the editor as described on the wiki.

64 player version has AI slots disabled on purpose as that many AI commaners would be too much of a performance hit for the server. You will also notice that the maximum number of subordinates you can request is lower, for the same reason.

1.90 update with quite an extensive Warlords changelog: https://dev.arma3.com/post/spotrep-00085

The mode has very specific respawn rules (namely redistributing respawn locations when your base is under attack), so I would not recommend using respawn templates.

@Oray65 this feature will become available in the next update.

Can't give you a specific date at the moment but as soon as we're sure everything's working as it should.

We'll be addressing another particular method to inject scripts in multiplayer in the next update, so hopefully that will help the situation. @Pryminko it sounds like something is wrong with one or more custom ammoboxes. Make sure the classnames are correct or try removing some or all of them to check if the error is indeed there.

As many of you have noticed, Arma II introduced a new conversation system (I'll be referring to it as "conversations" further on) which replaced the old say/...Radio description.ext-based approach. There have been many questions regarding this subject, so I decided to write a short overview of the possibilities and usage of this system. Main advantages The system itself waits for the sound sample to finish. No more sample time measuring and countless sleeps! Conversation always flows through the appropriate channel (direct for face to face, team radio for distant team members etc.) Possibility to create fully dynamic conversations. Transparent syntax (FSM branches allow fast and efficient edits). Theory In order to run a conversation, all of the participants need to have the proper topic added to them. The conversation then starts with the first sentence which one of the participants says to another. After that, the conversation flow is usually controlled by scripts - FSM's and event handlers assigned to the participants. After a participant receives a sentence, his script reacts to its ID and reacts with the proper answer. It may sound a bit complicated, but it's really not. Let's start with adding the topic. The scripting command to do this is kbAddTopic: person kbAddTopic [topicName, fileName.bikb, (fileName.fsm, (eventHandler))] topicName: (string) Can be anything. fileName.bikb: (string) Name of the .bikb file - will be described later. fileName.fsm: (string) Name of the .fsm file - will be described later. Optional. eventHandler: (string or code) Will be described later. Optional. Here is an example of what the code usually looks like: unit2 kbAddTopic ["baseDefended", "baseDefended.bikb", "baseDefended_unit2.fsm", {call compile preprocessFileLineNumbers "baseDefended_unit2.sqf"}] .bikb files Stand for "Bohemia Interactive Knowledge Base" as it was originally used only for storing an AI unit's memory of what it has seen. Not important to you. You will use these files to store all the speech samples (referred to as "Sentences" further on) used for the topic. This is in fact quite similar to the good old cfgSounds and cfgRadio classes in description.ext. Here is a short .bikb file: class Sentences { class example_01 { text = "Hello Bret."; speech[] = {"\Sound\jemaine01.ogg"}; class Arguments {}; }; class example_02 { text = "Oh, hello Jemaine."; speech[] = {"\Sound\bret01.ogg"}; class Arguments {}; } }; class Arguments{}; class Special{}; startWithVocal[] = {hour}; startWithConsonant[] = {europe, university} text: Subtitles used to caption the sample. If you're using stringtable, use $stringName (has to start with "STR_"!) speech: Sound sample. arguments, special, startWithVocal, startWithConsonant: Don't worry about these. The scripts In both FSM's and event handlers, there are some default variables which you'll be using quite often: _this: Receiver of the sentence. The unit that had this particular script assigned via kbAddTopic. _from: Self-explanatory. Basically the unit that told me the sentence. _sentenceId: The sentence this unit is reacting to. Defined in .bikb in class Sentences. _topic: Self-explanatory. Topic name used in kbAddTopic. FSM's FSM stands for Finite-state machine. We have released the FSM Editor some time ago. I will not describe its functionality here, I'm sure there are plenty tutorials out there. You can open one of the conversation FSMs used in the example mission (you need to have the FSM Editor installed to open it). As you can see, the FSM parameter is optional in kbAddTopic. That is because a) you don't want to use scripts at all and rather manage the conversation manually (about that later) or b) the unit is always controlled by a player. The engine recognizes who's controlling the unit by the time it receives a sentence. If it's controlled by AI, the assigned FSM is executed. If it's player-controlled, it fires the event handler. If you're making an MP mission and the unit is playable, you will want to use both the FSM and the event handler. Event Handlers Nothing to do with our standard event handlers. This is a code used only if the unit is controlled by a player and is executed not only if it receives a sentence, but also if the player points at someone and is close enough to start a conversation ("Talk to" action appears). This is very important to understand. FSM's are executed only once after each received sentence, event handlers are fired constantly (usually every frame) as long as you're pointing at somebody. Here is an example showing all you might want to use (you should get familiar with kbTell and kbWasSaid first): // here we'll be storing all the sentences from which the player will choose (the menu on the left side of the screen) // if there's only one option in the array, you will have the sentence as the "Talk to" action BIS_convMenu = []; // we want the player to be able to approach his buddy and talk to him via the action menu // we need to check: // if I'm pointing at my buddy // if I'm not answering any of his sentences // if I haven't told him hello already // then we add that array to BIS_convMenu - the parameters are mostly self-explanatory if (_from == buddy1 && _sentenceId == "" && !(_this kbWasSaid [_from, _topic, "hello1", 999999])) then { BIS_convMenu = BIS_convMenu + [["Say hello.", _topic, "hello1", []]] }; // here we make the unit say the proper sentence based on the one he just received // I use switch-case-do, it's completely up to you how to evaluate it (if-then etc.) switch (_sentenceId) do { case "hello1": { _this kbTell [_from, _topic, "hi_how_are_you"] }; case "good_you": { _this kbTell [_from, _topic, "fine_thanks"] }; case "what_do_we_do_today": { // here the player will have 3 answers to choose from BIS_convMenu = BIS_convMenu + [["Football.", _topic, "choose_footbal", []]]; BIS_convMenu = BIS_convMenu + [["Bike.", _topic, "choose_bike", []]]; BIS_convMenu = BIS_convMenu + [["Arma II.", _topic, "choose_arma2", []]] }; }; // return the sentence list pool BIS_convMenu There. Everything should be explained in the comments inside the code. As you can see, it's nothing more than a compiled sqf function. "Interrupted" event The left-side menu on the HUD with the list of possible sentences can be closed via backspace at all times. If you want to handle this event as well, you just have to add new sentence class called Interrupted into you .bikb file. It can be then used as a standard _sentenceId in the script. Example mission And finally, here it is. The example mission contains everything that has been explained here and shows you mainly how to manage the files. It contains voice samples from the Harvest Red campaign, please don't be surprised that the conversation is a bit out of context :) Get it here. "Manual" conversation flow For some reasons, you may not want to use FSMs and event handlers to control a conversation. For this, you will want to use kbWasSaid. An example will suffice I think. miles kbAddTopic ["briefing", "kb\briefing.bikb", ""]; shaftoe kbAddTopic ["briefing", "kb\briefing.bikb", ""]; shaftoe kbTell [miles, "briefing", "shaftoe_briefing_H_1"]; waitUntil {shaftoe kbWasSaid [miles, "briefing", "shaftoe_briefing_H_1", 3]}; miles kbTell [shaftoe, "briefing", "shaftoe_briefing_M_1"]; waitUntil {miles kbWasSaid [shaftoe, "briefing", "shaftoe_briefing_M_1", 3]}; hint "Conversation ended." Mission accomplished Well, I think that's everything for now. It's quite possible I forgot to mention something or made a typo in the scripts, please let me know if you're confused about something and I'll edit it out.

It's hardcoded to EAST vs WEST. With the next update, you will be able to sort of hack your way through this though.

Yeah that will be fixed in the update too.

It's available in Parameters in the lobby, look for Sector voting reset. It's disabled by default though.

Are you talking about the Altis scenario in particular? Have you had this experience with other maps as well?

@thirith Pretty straightforward. Check Parameters in the lobby. Also, I would go for Stratis or Malden. Altis can take the whole day.

This should already be possible via standard Action menu.

Yeah that turned out to be a real problem in the code to pull out without issues so I scrapped that feature.

@hydrobigbang Not sure which version is currently on the dev branch, but please check the status when the stable update comes out. @Shoppy Basically all of these things are customizable via scenario parameters in the lobby. Official server use default settings for pretty much everything though.

Community wiki page will be updated when the update comes out.

ANOTHER BATCH OF PRELIMIARY PATCHNOTES (1.90) Please keep in mind that not all of these might make it in the update. Tweaked: Asset requesting routines for AI Tweaked: Path planning routines for AI Fixed: Some modded planes would crash upon landing Fixed: Ejection seats and canvases from fighter jests no longer block runways Fixed: Some planes would need to double-take a landing Added: Unless their base is under attack, all playable units are now invulnerable after respawn until they leave the base (60 seconds maximum) Added: Individual asset lists Fixed: The mode would not work properly in singleplayer environment Changed: Arming mines in your own base is not allowed unless the base is under attack Fixed: It is now possible to get rid of vehicles (via Action menu) purchased by AI before player took control over that AI Fixed: Static defences are now properly calculated for the maximum amount of assets Changed: The team killing penalty duration is now increased progressively up to 5 minutes for each 3 player kills or 6 AI kills Added: Sector zone restriction border width is now customizable for each sector in the module window Fixed: Sector voting is now handled properly even if the only player who voted disconnects before the voting is finished Added: Maximum group size is now defined in the Warlords Init module Fixed: Fast travel to contested sector no longer lands you in water if there is land somewhere around the sector Added: You can now further customize various classes for dynamically spawned assets Added: 64 players version of Whole Altis scenario Added: 32 players version of Malden scenario Added: 32 players version of Stratis scenario Fixed: Helicopters would land on inconvenient locations when ordered from the airstrip in Tanoa (South) scenario Tweaked: Various sector and zone border sizes to avoid pointless zone restriction triggering Fixed: Various script errors Fixed: "Starting CP" parameter in the Warlords Init module would set up incorrect values for some settings

Periodic cleanup of all weapon holders is incoming.

These are things that are easily customizable as it is. You want to have vehicles as part of garrison? Place them in the editor. Not everything can be done automatically and if it can, it very rarely has as good results as scenarios hand-crafted by someone. Similarly, you want to have garrison in buildings? Feel free. It's not in vanilla because spending half an hour clearing a single sector in a small town from AI is not what Warlords is about. I'm sure there are plenty of great scenarios offering that kind of gameplay out there.

I did briefly consider having garrison in buildings way back when I started working on the mode, but due to AI not being the best at clearing buildings and the amount of time required to clear out larger towns, particularly on Altis, this was not implemented.

Would you say tanks popping up from the ground are more immersive? I mean there always will need to be some sort of compromise between realism and playability. All things considered I think the airdrop approach is the most feasible.