stwf

ugh I don't get that on Mac either, obviously or I wouldn't have released the code. oh well I'll try to figure out what is going on. Any good details? In windowed mode or pausing the action somehow else? Sound effects cutting out is strange.

ok, first pass at playlist functionality is in. Let me know if there are any problems.

So from a novice point of view the only real strategy they know is flanking someone or coming up from behind. I'm not sure to what degree it is historically accurate, but game wise you expect to really do a number on someone you manage to surround or hit from two sides, especially if they didn't have a 2 sided formation in place, etc.. I think we need to get that working, if only from a gaming aspect, that you get a noticeable advantage there beyond the regular numbers PS I guess this implies that 'unformed' troops get an overall penalty, since in the end its one unit firing at another, that would be the default case, and any sort of formation either helps him avoid damage or does nothing at the worst

Is there a design document on these modes? I must admit I'm not entirely sure what each one means, like Death Match vs Supremacy... My favorite mode was Rise of Nations Conquer the World, where it played like Risk but then you went in to fight each actual battle. It gives the game infinite playability, especially when you could make an ally who would provide you with a teammate in battle. There are infinite possibilities For real historic accuracy I think we would need a system where you travelled slower through a swamp or forest than down a road, but I agree fixing the lag is top priority, the game has to be fun to play above all else.

Any idea how to fix this? I guess its missing the fact that the variable is being passed in by address and can be changed? I tried declaring it volatile, but that conflicts with how OpenAL defines the function...

OK, I got rid of most of the warnings in the sound code. No real issues there but it is better to initialize all variables I guess. I left in the two issues with ogg.cpp. THe code there is fin if the macros are unrolled. I guess the analyzer isn't running through the preprocessor.

Since some discussions are taking place concerning formationsI thought I would chime in. I'm not especially knowledgeable about ancient war, or really experienced in RTS's so I think my expectations may match what a lot of new users might feel. The obvious to a casual user advantage of using formations in battle is to give a directionality to the attack or defense. A group of archers would get a more lethal attack to the front in exchange for weakened defense on the sides. Thus a group of archers in a straight formation would defeat the same number of ungrouped archers that were in front of them. So my interests are formations for defending a straight on attack, defending against a flank atttack, and maybe one that was pretty good at both. Conversely on attack I'd want to attack straight on, perform a flanking attack, maybe a balanced one too. In addition RIse of Nations has a seige formation that would concentrate on defending the catapults while bombarding a town, that was very useful. As far as movement, it should really just insure that everyone arrives at the same plac eat the same time. Instead of everyone getting somewhere as fast as they can. [Hijacking this to make it the discussion thread for Formations Review]

I just put in a fade in and out when the app switches focus. It also honors the pauseonfocusloss flag. Otherwise I left the behavior as is. It turns out I can differentiate between being minimized and losing focus. So what ever the consensus for the behavior is I will implement. I don't think that having a set of preferences for background behavior is overdoing it. You can turn the sound off using the static function CSoundManager::SetEnabled(false). You can turn it back on by passing true to that function. That completely closes it down and then reinitializes it. This snippet will pause and unpause it, I could put this into a static function if you like. if ( g_SoundManager ) g_SoundManager->Pause(g_Game->m_Paused); At some point I would like to get into the Atlas stuff but it seems like there is plenty to do game wise for the time being ;-)... I did wonder why the actor editor didn't play the units sounds. But otherwise I haven't spent much time in Atlas at all. If you could put this in at some point I'd appreciate it.

OK, I will play around with that. I agree that if the action doesn't pause the music shouldn't. I will also smooth out the abrupt cut offs. I can look into what kind of options we have here, as you said I'm not sure we can tell if we are minimized or not. SI this something the Design Committee might get involved in? This originally sprang out of http://trac.wildfiregames.com/ticket/1712 . But for some reason this bug still persists. It seems like the Atlas engine doesn't stop or pause through the same mechanism that the regular game does... But it does seem to start the music normally, odd My one option is to just make Atlas aware of the sound manager and pause the music when the simulation is paused. But that doesn't seem right. Any ideas in how I can best capture Atlas starts and stops?

OK, I think a quick fade out can be put in pretty easily. It just doesn't seem right that the game action pauses and the music doesn't. Certainly the ambient noises should shut down, so it only seemed logical that the music did too. To me pause means pause, including the music. But I'll adapt it to be anything thats decided upon. I just noticed it that trying to take a phone call during a game meant I had to quit to get the music to stop!

Perhaps some mild deterrent to using the CC as a dropsite? Figure the CC can process and distribute grain, but it can't do it as efficiently as a dedicated farmstead can, so units making full drop offs at a CC might take some time to unload, where it is instant at a dedicated drop zone. So the loss of worker time would prompt people to build farmsteads instead of farms close to the CC. Just a thought

I have been thinking about pathfinding. I know this may not jibe with the way other RTS' handle things, but we are aiming for more historical accuracy, right? I haven't given thought to how this would be implemented, but maybe it is worth investigating. So normally when someone sent out a large army for attacking, they wouldn't really take the direct route, through rivers and forests, but they would take the roads, right? So if we established roads in the game it wold make pathfinding much easier since most long trips would take the road across the map at least as far as they could. If someone did want to stage a surprise attack and come a different direction you would expect that to take more interaction from the player, specifically dragging them off of the road, and then directing them how to go. It seems another inaccuracy we have is how units seem to try and find the shortest path even through the fog of war. In the case where a unit was sent deep into unexplored territory wouldn't that unit only be able to take the best route a tile or two at a time? It would depend on its line of sight. Units in real life entering unexplored territory would be expected to hit dead ends and have to turn around. Maybe scout units could get some more distance due to a sense of knowing the best way to go. Then we could also make distinctions between fighting on land where the geography is already known (as well as roads and their paths) vs unexplored territory where everything starts as a mystery. Anyway more food for thought...

Thanks! That was the link I was looking for... You know we could trim quite a few items from there by moving all of the naval issues to version 1.1 (or 1.2)

I will spare no expense for my deathbot!

Wouldn't the best way to handle this adaptive AI be to make it a stand alone web service.? Then give it a chance to log in as a regular player and interface with the game the way other remote clients do. Then it could get better and better as people kept playing it. Replay wouldn't be a problem since the host game would just see it as another player. I know this would be a lot of work and not much help to the app, but it could be a cool thing to have.

Thanks!

lol I never said you wouldn't beat it, just not crush it. It always gives me an entertaining challenge. I guess I just suck though. Anyway my contention stands that its good enough for beta and we can focus on addressing some issues with it for 1.0

I know in the past I have seen a list in the wiki of the 'must have' items fro a release, but I can't find it now. Anyone have the link? I think the link should also go on the front page of the wiki. In large flashing red letters! OK, maybe not, but prominently. I also believe this game is much closer to release than most people think. 99% of the people you would get from a release would have a great experience paying the game as is and won't ever get to the point where they can crush the AI. I see no problem with limiting single player games to 1 vs 1 (to avoid lag) at least in the beta. And then concentrate on optimizing, balancing and bug fixing as we push to 1.0. It seems many of the complaints I hear could easily wait until a 1.1. BTW even in Rise of Nations (my favorite) I have watched armies of AI run back and forth on the map confused, and they make the AI tough by giving it a huge resource gathering advantage. So there is Its a shame that on a project this great anyone is downhearted at all! You are all too close to it to see how awesome it is!

hmm, I hadn't really gotten in to it too much. But currently the simulation finds all PEACE tracks in a civ's json file, picks a random one and loops that forever. So I'll add a way to upload the whole list and play each song in order, looping forever. Then I can add options for gaps between songs, or random play. This way the simulation can decide exactly what it wants a people can play around with it.. I did think that any changing of the music, say to battle music, would wipe out the playlist.

You can play sounds, but at the moment you can't play a sound at a position without a unit. I can put that in though, I was also going to add a playlist capability for the next alpha. Yes the numbers thing is a clear place to improve, having a separate sounds for multiples of the same unit in the same general vicinity. That would let the SoundManager play a lot more sounds too. Is there an easy way to get this info? I don't think having sounds based on formation or state would be too hard either. Although it might be best handled in the simulation. Thanks, this is just what we mean, although they don't seem to consider where to place the sounds, or if cavalry on the far right and far left should be considered the same unless I misunderstand it. The muffling for offscreen stuff is already in there but more more strict than this paper suggests although it can easily be changed.

Does anyone think the battles sound better? More full? The error messages are meant to be removed before alpha 13. I just put them in to test we were getting the expected behavior on all platforms. It sounds like we are so I don't think there is a need to keep them in there at all. For the record getting the message ERROR: Sound: Entering distress mode through shortage Is normal and expected during a moderately sized battle. At this point some sounds are not getting played. A good improvement would be a way to prioritize certain sounds and try and make sure they get played. Anyway when the battle is over you should exit distress mode with no error (on Win and Linux). It seems MacOS returns 'unknown internal error' at times when in a stressed state. People on the OpenAL mailing list think its some thread contention bug in Apples implementation. Either way it doesn't seem to have too much effect, but I will keep trying to isolate it. If only to report it to Apple.

ok, the problem with building in Windows should be fixed now... sorry about that.

OK, it is in! I'll be around on IRC in case anything goes wrong.... Hopefully this will improve the sound for people. There are still two log messages included for testing purposes. It will say it is going into distress mode over large battles. Then when the battle subsides it should come out of distress mode, hopefully reporting no errors. I haven't seen errors anywhere but on Mac, and I'm not sure they needed to be worried about.

Hello All,I'm back! Did anyone get a chance to try out the latest patch? Anyway either way I guess I should just commit it to trunk and see what happens, no?

OK the new SoundManager code is in a patch attached to its trac ticket (I'll also attach it here) http://trac.wildfire...com/ticket/1766 This is a diff against the latest svn trunk, so patching should not be a problem. I'll be AFK for a week (so I didn't want to check changes in), hopefully this will work fine and can be incorporated during my absence or when I get back. Battles should sound much fuller, and should work much better in low resource environments. Also there is some extra logging here, about going into and out of distress mode. Going into distress mode dues to shortage and coming out with a 0 error count is normal (during large battles) and good behavior. On MacOs there seem to be times the system returns an unknown error when it can't play a sound. So in that case you might go into distress mode on an error and emerge with a big error count. I think this is also not a big problem. It shouldn't happen on non-mac platforms (let me know if it does) and doesn't affect the sound noticeably (also let me know). I can try and track down the exact cause of the issue in the future. Enjoy! soundManagerEntity.patch