historic_bruno

I agree with this, the problem with keeping multiple AIs around is that it increases maintenance, every new feature that is added needs to be added to each AI separately. For example: walls, gates, technologies, healers, trade, bartering, to name a few, are all "new" features in the sense that AI development has not kept up the pace, now who wants to add support for these features to each of at least 3 AIs? Since we are still in alpha, we can make these decisions. The only reason some AIs appear to be easier is because they are broken or incomplete, as far as I know JuBot was not intended to be an "easy" bot, nor was qBot intended to be medium, but both were supposed to be very challenging state-of-the-art AIs. I don't think trying to pass off a broken AI as "easy" is a good decision because players will notice the quality of the AI, not only how challenging it is to defeat the first time they play. What makes a quality AI? Challenge - yes, but also coherent and varied strategies, unpredictability, use of various gameplay features, minimal impact on performance, adaptability to different maps and situations. If it were up to me, these would be on the chopping block: testbot, JuBot and possibly original qBot if we have a replacement. No offense to the developers of these AIs, they served their purpose and have maybe led to better AIs, let's not be afraid to move on It's better to focus our resources on one great AI then spread it out over a handful of mediocre ones.

Which OS are you using? Do you have the latest graphics drivers for your system?

One thing that would help is splitting off-topic posts and discussions to a separate topic, since we are now talking about sap points in depth, instead of poor siege model variety (people will see the original topic name and not realize it had anything to do with sap points). I would do this except I have no mod powers

There's a bug with sound in Atlas simulation test, resetting the simulation doesn't stop the sounds, so music and ambient effects continue playing endlessly, even if a new map is loaded. Yeah that sounds less than ideal. It goes back to the need for a threaded music manager. Music should be independent of the engine/renderer thread (although both simulation and UI should be able to trigger music changes, the music manager should decide exactly how and when the transition occurs and what to do at the low-level). Not all sounds need this, just ones that play for long periods across multiple UI pages, e.g. music. As far as the repeating music goes, it will get very tiring as you can imagine over a 1-2 hour or longer game. A music manager system could have a playlist with built-in periods of silence, not to mention being able to randomly select and mix in different tracks, and I think it would be really cool if the user could even add their own music collection as an option. I'm satisfied with how it works now as an initial version, but these problems will need to be tackled next which is why I bring them up now, it can start the discussion What is the impact of a larger buffer size? Do all sounds use the same buffer size, is it in bytes? Is it per-sound or one for the whole sound system? A larger buffer might help as a workaround, I still think a multithreaded music manager is the best long term solution. My informal test results: increasing the buffer size to 96k eliminated the stoppage during initial loading of the game setup page (very slow because it parses and caches a bunch of XML data) and the music continued even during giant random map generation. I'm not exactly sure what should happen when multi-entity selection occurs. From an aesthetic point of view, it shouldn't play multiple selection sounds simultaneously I think we discussed in the past one possible solution for handling multiple sounds playing simultaneously by adjusting the volume of the first instance of the sound, rather than playing them all. It seems like there should also be a cooldown period which varies per sound, during which the same sound can't play again (in battles all I hear is "Ugggh!" "aggggh!" "hooogh!" "Ugggh!" "aggggh!" "agggh!" ...) It could also switch to a special "group" or "chorus" sound when specified for the sound type, maybe when a given threshold of requests to play the sound is hit. It's the same problem but even more important with battle sounds, we shouldn't hear dozens of arrows, sword blows or deaths at once, instead the sound engine can switch to "group battle" sounds. The sound engine seems the likeliest candidate to handle that stuff, otherwise lots of sound implementation concerns creep into the simulation and UI, not to mention it's such a fundamental part of the sound system. Again this isn't critical to get perfect in the first version and in fact the old sound system was no better, but as soon as it's committed it becomes a TODO. No doubt the art and sound teams will have lots of suggestions once they can test it. I agree, there should be a smooth faded transition.

I suspect for the art team it's based on reality and past experience, as the programming team has typically lagged in terms of progress However - I would say create a Trac ticket for these ideas anyway (with the correct priority), so the idea is not totally forgotten or buried in forum posts and IRC logs. You might be surprised that someone digs it up, finds it interesting and works on it. I definitely would suggest avoiding a "can't do" attitude because the odds are someone can do it, but at the same time we do need to maintain priorities.

but this seems unrelated. I will try older revisions (but probably not today). Anyway pyrogenesis itself looks working. There are two known test failures in VS2008 Express, but they don't occur in standard VS2008 or VS2010 so it was decided to not fix them: http://trac.wildfiregames.com/ticket/884#comment:2

I'm saying there should be only one mesh in the model before exporting. That is not the case in Gen.Kenobi's DAE which is why our importer complains. It's easy to verify this, open the DAE in notepad++ or similar, and search for library_geometries, how many geometry entries are there? And if you looked in the original .blend I'm sure you would see there are multiple meshes there, too.

Removing random parts of the DAE doesn't sound like a good idea because that's still going to leave references to those parts elsewhere, and even if it didn't, it won't be the complete model so I don't see the point The best thing is to not export DAEs with multiple objects in the first place. Is it possible to combine them into one object after modelling but before exporting? It seems to be a problem the artists solve because all the DAEs import correctly...

There are multiple geometries/meshes in library_geometries. AFAIK the engine only supports one per model.

http://trac.wildfiregames.com/changeset/11995 It's automatically modified now by update-workspaces.sh, which creates problems because that makefile is SVN versioned.

What do you mean it complained? Errors or warnings would be helpful. For my part it built just fine in VS2008. Make sure you run update-workspaces.bat since there have been source files added.

You're not linking with any of the SDL libraries so the linker (ld) tells you they are undefined symbols. Including the headers in the source code only provides the definitions so that particular file can compile, but when it comes time for linking and creating the executable, you need to link with the required libraries - in this case SDL. You'll want to do something like this: g++ sdltest.c -o sdltest `sdl-config --libs --cflags` This will add the correct include and library paths, and the libraries needed to build an SDL application (e.g. SDL and SDLmain). I suggest you read up on using the GNU toolchain

One little thing I forgot to mention when reviewing, I think the following files should go in a separate directory, mostly because they have different licensing and aren't written by us (nor copyright Wildfire Games): source/graphics/mikktspace.cpp source/graphics/mikktspace.h source/graphics/weldmesh.cpp source/graphics/weldmesh.h Anyone else feel similarly?

You could add a bone just for the prop and animate that bone, then it would have to be a part of the dude's skeleton.

Testing this branch on the following system: system_info.txt With unchanged default.cfg, I get this error starting a game: which is no big deal since the hardware doesn't support GLSL, though it would be nice if it didn't crash. But then I set preferglsl, gentangents, and smoothlos to false, and I get this error (with renderpath defaulting to "shader"): and I get the same crash after forcing renderpath to "fixed".

I expect we use Latin quotes so far because they are the most plentiful and easy to find. Perhaps the community would like to build a list of quotes or interesting terminology in the other languages?

In a skeletal model, the prop points are just child bones with names that start with "prop-" or "prop_" and they follow their parent bone which is part of the skeleton. So yes, you can indirectly animate the prop points in skeletal models.

We use OpenSUSE Build Service, but the maintainer is missing in action, maybe it will work for Alpha 11.

If you built SDL yourself, use the sdl-config that resulted (usually in [prefix]/bin) to get the cflags and ldflags you need to compile. Although you'd probably need to do a "make install" for that. Or you can use the sdl-config that came with libsdl-dev from your distro's package manager.

It could be keyword based, the map data already supports keywords which are simply an array of strings. Not a bad idea, but because map loading might be too fast on some systems, if we want tips and loading screens to be more practical we should also implement this: http://trac.wildfiregames.com/ticket/689 I also like how in other games you can view tips and instructions specific to a map, even after the game has started. That's most useful for campaigns but really any map could benefit from a list of tips and guidelines.

Couldn't they just be propped? A trained siege units pops out with a few actors to push it, when idle they stand around, when moving they go into walking animation, etc. For firing and if they need to walk around relative to the siege engine itself, that might get more complicated for the animators, but since props are attached to animated bones it seems technically feasible. They shouldn't add much lag, other than having a few more animated actors in the game, and a few more bones per model for the siege engines.

Tested more on the laptop, here's the system info: system_info.txt Music bugs: I also notice the music starting loud, then tapering off a few times to normal volume. Did something change in the implementation since the last patch I tested (patch12.diff)? Often the music stops abruptly in the middle of a track. This appears to occur when the game window stops responding temporarily. There are no errors in the log so it's a silent failure somewhere. Let me know if there's any debugging data I can provide as this might not be easily reproducible on newer systems: One way I was able to reproduce it was clearing the cache and then going to the match setup menu and while the map data was loading, the music stopped (this is a very slow process on my system). I don't know what happens technically but the music doesn't continue. In one test it occurred about 30 seconds into the main theme. Music did start with a new match. I've found it also occurs in-game so it's not specific to the main menu. Once the game window was minimized and the music stopped abruptly. I can force music to start over by toggling Menu > Settings > Enable Music so the sound system is still working in that sense. We need to find out why it stops. [*]I just noticed the ambient sounds seem to be gone too, so it must be more than music that breaks. [*]The music is choppy and stutters, of course if you look at the system specs it's a low-end system, but maybe we can find a way to reduce the choppiness. Music comments/suggestions: What should we do when the game is minimized/unfocused or paused? Currently when the game is paused regardless of being minimized, I hear ambient sounds and music. I would say when minimized and paused, either we should taper off all sound or only play music. The ambient sounds get quickly annoying in the background. Is music intended to loop immediately? I thought there would be periods of silence and it seems like we shouldn't loop the same track over and over, it takes away from the impact of the music. It's OK to have silence and hear the other sounds of the game The main menu theme in particular is one that should play only once per game IMO. I like AoK's use of soft ambient sounds in the background after the main theme ends, maybe we could do something like that: sounds of riders, preparations for battle, or town noises - construction, gathering, etc. Unit voice response: Seems to work much better now, I even hear off screen units responding and camera seems to have no impact One thing that annoys me: when double clicking units, I hear a voice response for each click. It creates a repetitive sound for double and triple clicks. I think the better behavior would be to either not interrupt the sound from the first click or wait to play a response until the UI determines if it's a single or double click (but that seems trickier and prone to error).

A few things are needed first, here's a list: http://trac.wildfiregames.com/ticket/1520

A ship-mounted siege engine might be interesting, to clear away coastal defenses where it's too difficult to land. But this doesn't sound too promising:

Applied the patch, minor issues: * main.cpp: lib/res/sound/snd_mgr.h file is not found, this shouldn't be included * JSoundPlayer.cpp: warning that cx is an unused parameter, it's never referenced in the JS_SET_RVAL macro (should be safe to wrap it with UNUSED()) I'm stuck on an old cruddy laptop so I'll do some more testing. Those must be leftovers from using sed on that makefile. This is why I would rather we used a separate gmake.osx rather than trying to use one makefile for every *nix It definitely shouldn't be included in the patch.