Re: crash during hosting, in a battle
 

turn off itunes before you start the game. turn off sound.

Re: crash during hosting, in a battle
 

no other way? i keep the ingame music turned off, but i kinda like hearing the battle sound effects.

Re: crash during hosting, in a battle
 

That depends on your system. I have no idea about Windows. It should either work magically, or not at all like you want.

I guess you are on a Mac. I have no personal experience with them, but AFAIK the system is structured somewhat like Linux. I can only speak about that: You have to look what sound daemon your system is using. Under Linux, Dom3 can use the aRts sound daemon (and it's the default) or the OSS sound daemon ("for better quality"). I think the OSS sound daemon is not capable of handling two sound sources at the same time, it locks the sound device for one source, at least on my system. The aRtsd however can handle two sound sources at the same time and has no problem to mix the sounds from the sources. So you can play something in the background and still hear the sound effects from the game.

Just make sure that all your programs are using the same sound daemon as output device. Check what audio options your Dom3 executable is offering with the "-h" switch, the audio options should be at the bottom.

Re: Bug Commentary
 

If my army is in province 1, and I select province 1 then press y, then it works yes.

If I order my army to move from province #1 to #2, then select #2 and press y, shift+click doesn't work in 3.06.

Re: Bug Commentary
 

The problem here is GrobRim failing to report the bug properly. I'll check this when I get home, then add it to the shortlist.

This should highlight why it is important to report bugs properly like mivayan here did. If a bug report is so vague that it is impossible to divine what the person reporting it meant, then it's likely to get dismissed out of hand.

I am no mind reader and neither are the devs, so when reporting a bug, it's better to go into detailed descriptions and step by step instructions on how to reproduce the bug (as mivayan did) rather than assuming that everyone knows what you meant. That will save everyone a lot of headache.

As an aside, I should mention that some of the bug reports gleaned from earlier readings of the thread only made sense when combined with other reports. In some cases things were so badly formulated that neither post (sometimes separated by several pages) by its lonesome made much sense or gave enough useful information to get anywhere, but together there was enough to produce a bug report. If ANYONE here thinks such reports are going to pass in the future, they had better think again, because in such events I WILL give them a piece of my mind. VERY firmly.

Edi

Re: Bug Commentary
 

Another post dealing with issues that were reported as bugs despite the bug status being questionable. We also get a new acronym: DAU = Dismissed As Useless. It will be applied to bug reports that are too vague or incoherent to give any useful information.

The next batch:

DAU. Report is too vague. ***** Queen is available for Midgård.

WAD. Shuten-doji has 2 hand slots and neither life drain or claw are bonus weapons. When shield is added, the second weapon is eliminated. If the order of the weapons were reversed, claw would disappear. Making life drain bonus would mean giving it as a bonus attack for every creature with life drain, which has deeper and more direct consequences than just switching the order of Shuten-doji's weapons. This is a matter of personal preferences related to game features, not a bug.

Probably WAD. Description may need an update to refer to him as a demon prince of the Underworld, but this is more a matter of personal preferences than even much of a description error. Leaving that up for the devs.

This needs a more detailed report and more independent confirmation. I have never seen this behavior and seems to be WAD. Are you sure you hadn't mistakenly given your missile squad attack orders?

WAD. This is nothing but pointless whining. The various slave trooper and slave guardian units and several of the slave commanders are used by EVERY SINGLE ERA OF R'LYEH. It is quite unreasonable to expect there to be a separate set of completely identical units except for the description, but no functional OR thematic difference.

For an example where there are functionally identical units with different descriptions, see Kailasa/Lanka/Bandar Log/Patala. Those nations have several units that are the same, but e.g. the Lanka and Kailasa Bandar Commanders are different units because the nations are thematically very different from each other despite superficial similarities. Such large scale thematic differences do not exist between EA and MA R'lyeh, which is the point that matters.

Re: Bug Commentary
 

Same thing happened for me once for the first and last time: I had cast Flaming arrows for my lot of ~100-150 archers. They fired their flaming arrows once, in turn 1. In turn 2, some enemy cavalry came close and into melee distance to some(!) archers. As soon as one of them was in melee, all the others stopped firing their much more useful flaming arrows, too, and switched to melee, even though they had no chance to hit anything in close range, yet, and most of them were surrounded by other archers.

Solution: Set them to Fire, then they will always use their ranged weapons if they can, and only use melee weapons if necessary. I was expecting that was the default that the AI would do, but I had to learn the hard way that this is not the case.

Re: Bug Commentary
 

It might be that one of the units suffered an affliction such as blindness. Since it couldnt fire it attacked, since it attacked they all attacked.

Breaking up the archers into many units helps

Re: Bug Commentary
 

I've seen the archers closing instead of firing into melee behavior, usually by AI/indy archers, but sometimes with my own. Hadn't thought that it might be connected to Fire orders vs unscripted.

The original bug (Any member of squad unable to shoot, whole squad charges) I remember seeing with Marveni. There was some discussion of it early on.

Re: Bug Commentary
 

Unscripted archers or archers set to fire archers sometimes advance far too close to the enemy front ranks in order to get in range to fire at their assigned target. Scripted ones are easy, set to fire closest and they'll stay back. Unscripted ones will pick their initial target stack at random, so either they close or they don't, it's rather hit and miss.

Edi