st_dux

I can't test this right now, so I'm not sure if it will help, but try disableAI "FSM" on the driver.

You could do it that way. It's important that you change the leader first, though, before team switching. If you team switch first, locality of the group may shift to the server as the group would become AI-controlled, and then selectLeader might not work when executed from your machine. I haven't tested this, though, so I'm not 100% sure.

Ah, that's a shame. I'm afraid that using an extra dedicated variable is really going to be your only option, then.

Don't use the "FAILED TASK" module. Instead, in the activation field of your trigger (which doesn't need to be a switch type, by the way), use the setTaskState script command to change the state of the task.

Introducing the real-world process of looking up data in a table doesn't really add anything interesting to game. All you do in reality is look at the table for your weapon, find out how many clicks you need to make to be accurate at X meters, and then turn a dial that many times. You are still essentially just hitting a button (or turning a knob) until you're at the desired range setting, but now you need to look at a table first to find out what that setting is. There's no skill involved or anything like that. I think BrightCandle is referring to the normal red dot sights, not the backup ones. He's correct in saying that you couldn't adjust the zero with a simple sight like this in the field, which is why a battle sight zero of 300m makes sense. Such a zero will be reasonably accurate at all ranges less than 350m, even CQB ranges. This is because a bullet trajectory that crosses your line of sight at 300m on its way down will also cross it at around 25m (precise value will vary with weapon/ammo) on its way up. Between 25m and 300m, your shots will actually hit a bit high, but not by much: You'll hit reliably if you aim for center mass.

Also, in case you haven't read this already: Dialog Control You may be happy to learn that dialogs are one of the few aspects of ArmA scripting that actually uses a sort of object oriented paradigm.

selectLeader should still work. You just need to ensure that the command is executed on the machine where the group is local. If you are currently the leader of the group, then the group will be local to your machine. Use selectLeader to change the group leader to the AI you wish to switch to, then team switch to that AI.

Do you know where the control is in the config? You can get the raw string data (including strings used in the construction of structured text like "<br />") using getText. If your structured text was in your description.ext, for example, you could get its value using: _rawStringValue = getText(missionConfigFile >> "myDialog" >> "myStructuredTextControl" >> "text"); _structuredValue = parseText(_rawStringValue);

How would that be simpler than what we have now? "Mil turrets" would require the player to know what each angular adjustment translates to in terms of range, and this would vary widely from weapon to weapon and even from ammo type to ammo type. Right now all the player needs to do is select the appropriate range and go. Also, you're wrong about 100m zeroing not existing in real life. This is the standard zero for a rifle with adjustable sights.

What actually sets the task to FAILED? If it's a trigger of yours, then add the following condition to the trigger activation field: if (!taskCompleted myTask) then {myTask setTaskState "FAILED"} Even if the trigger fires in the above example, the task state will only be modified if it hasn't already been completed (meaning its state isn't CANCELED, FAILED or SUCCEEDED).

The value of the variable itself will be overwritten each time a client invokes the EH; receiving a broadcast new value is what fires the EH in the first place. Even if two clients were to attempt broadcasting a variable change simultaneously, though, I am 99% sure that the EH would fire twice, and each time it fires, you're going to be able to get the value uniquely set in each instance by using "_this select 1" within the EH code.

Kind of. You can think of call as introducing new code directly into the current thread. If that thread is scheduled (e.g., if call is used within a script that was executed via execVM or spawn), then the normal rules for a scheduled environment will apply, i.e., you can use sleeps. If that thread is unscheduled, though, then attempting to use sleep or waitUntil within code that is called will produce an error. Using spawn will create an entirely new thread that is always scheduled, so sleeps will never cause an error there. Here's an example to demonstrate what I mean: fn_waitFiveSeconds = { sleep 5; }; [] spawn { player sideChat "A new thread has begun!"; call fn_waitFiveSeconds; player sideChat "Five seconds have passed!"; }; Despite the fact that code containing a sleep is executed using call in the above code, this will never produce an error because call is being invoked in the scheduled environment of a thread that was spawned.

I seriously can't stand this entitled attitude that gamers often have nowadays. The DLC is extra, non-essential content that was released after the full game. In what way does this arrangement make you feel entitled to it just for having purchased the original title?

What constitutes "working suppressive fire"? Suppressive fire is just a high volume of fire in the direction of the enemy. Are you referring to the AI reaction (or lack thereof) to such fire? I'd say that while grass (and shadow!) concealment at distance is a very important missing feature, the most important feature missing from the series is the ability to create trenches and foxholes that are beneath the surface of the terrain. This is a critical component of infantry combat that has simply never been modeled in the series.

My thoughts exactly.

I appreciate the detailed review. I think some of the changes that you point out as negatives are just a matter of personal preference. For example: - I think the province system is a great improvement. - I like the recruiting-through-generals organization. It seems more immersive and realistic to me to have only cohesive forces led by generals on the map instead of random units all over the place. I also believe that the Imperium-based limit on armies and fleets reflects the political clout that would have been required at the time to raise so many troops. - I don't have an issue with armies "transforming" into transport ships. It basically takes an entire turn to do this, and transport ships are incredibly slow and easy to intercept. Since Patch 15, unescorted transports are also extremely easy to wreck even with small military fleets. Also, I don't agree that a 100-man unit isn't at a disadvantage against a 300-man unit. It's true that attacks only occur from one individual to another, but a 300-man unit is still going to be attacking more often because it will naturally envelop the smaller unit, and this also causes steep morale penalties. As for CA's marketing budget, I agree that it seems kind of obscene. Unfortunately, it also seems to work really well, because Rome II outsold all previous Total War games at release despite the fact that game was basically broken back then. That said, I do believe that CA have made good with the fans with all the support and free content the game has seen since that time.

I really don't think it's fair to say this anymore. Rome 2 is a complete game right now. It's not perfect, but no Total War game ever has been.

Well it's a Rome II Free Weekend on Steam (plus the entire Total War series is 75% off), so if you are kind of interested but not sure, now might be a good time to check it out.

Vastly improved from release. On my fairly modest machine (3.4Ghz i5, single GTX 770, 4GB RAM), I get solid performance with very high detail settings (not quite maxed out, but close) and huge unit sizes. In extremely large battles (e.g., full-stack vs. full-stack siege battle), tick rate will occasionally slow down noticeably, but the way they designed it this won't actually affect your framerate (simulation updates more slowly instead), so control is never hindered. The long turn times that made the campaign a drag at release are gone now, too; the AI processes its turns very efficiently.

The AI isn't perfect of course, but at this point I can safely say that it's best the series has seen, certainly much better than NTW. Even the siege AI has been improved to the point where it's really a challenge both on offense and defense. There are still hiccups here and there, but they are infrequent; the difference between the AI now and the AI at release is night and day.

It's been about a year since this game came out, and I must say, it has improved by leaps and bounds. Anyone who (reasonably) forewent this game when released may want to take another look now. The "Emperor Edition" (just a renaming of the game, not a special edition that costs more anything) doesn't just meet original expectations; it exceeds them (albeit a year late). Fifteen (!) major patches have been released over the last year, and it shows. Plus, there has been a substantial amount of free content, including several playable factions (Pontus, Selucid, Backtria, Getae), some new units, and even a free secondary campaign that focuses on the dissolution of the Second Triumvirate and the establishment of the Roman Empire under Augustus. The game has now officially surpassed Shogun 2 as my favorite Total War game.

I am trying to import a custom font that will allow me to use special characters required for Vietnamese text. I have successfully generated the TGA and FXY files necessary for my font using FontToTGA; however, I have no idea what to do with these files now. How are fonts installed? ---------- Post added at 12:22 PM ---------- Previous post was at 11:35 AM ---------- Figured it out. Fonts must go into an addon and added to the CfgFontFamilies config entry. Thanks to BlenderRus for making the Cyrillic Font Support addon, which is where I was able to learn this. An example config entry is shown below: class CfgFontFamilies { class ArialPlus { fonts[] = {"\myAddon\Fonts\ArialPlus\ArialPlus06","\myAddon\Fonts\ArialPlus\ArialPlus07","\myAddon\Fonts\ArialPlus\ArialPlus08","\myAddon\Fonts\ArialPlus\ArialPlus09","\myAddon\Fonts\ArialPlus\ArialPlus10","\myAddon\Fonts\ArialPlus\ArialPlus11"}; spaceWidth = 0.7; spacing = 0.065; }; };

Definitely not. Trust me: You will not saturate the system memory with simple script variables. A single texture probably contains more information than all of the script variables you will use combined.

That's fair enough, but it seems to me that the issue could be solved almost entirely by simply disabling the automatic switch to combat mode that was added in A2 (or perhaps keeping it but providing the player with an option to override it). To my knowledge, this never happened in ArmA titles before A2: Units could be kept in an "Aware" (and more responsive) state even when under fire. Why isn't it possible to revert this?

Could we please get an option to disable the automatic change to "Combat" behavior that the AI makes whenever it comes under fire? There is currently no way either through the command menu or through scripting to turn this off, and it makes the AI very unresponsive to basic commands. Getting the AI to make a proper assault, for example, is nigh impossible because the AI simply will not move at full speed when in "Combat" mode; they will insist on stopping every ten meters or so and going prone. This has been a problem since "micro AI" (which is otherwise pretty cool) was introduced in A2. AI in OFP was actually much better at assaulting because you could actually have it simply run forward.