historic_bruno

Updated to r12395. Some of the issues with the reference check script should be fixed now. It will still miss most of the UI textures. Missing files: Unused animations: Unused meshes: Unused textures: Unused audio: Unused templates:

Yes, and why isn't that possible? All you need to do is take a normal dude rig and add a bone that twirls around just so, then add a prop bone as a child of the twirling one - add the spear as prop in the actor, and it gets animated. Though you'd have to synchronize the twirling bone with the hand and rest of the body so it would look natural, that sounds difficult but not impossible.

Myconid was suggesting earlier in the topic that Blender has a way to automatically generate a non-overlapping second UV set, if you weren't aware. I don't know anything about it, but it seems likely to be a huge time saver for AO. Sounds like an UP_AXIS problem, that's a way for the modelling program to specify which axis it used as "up". I recall that one of them causes a problem with Blender's importer (probably the one Max exports), you'll likely have to adjust it manually after importing, or see if you can get the original .blend or .max from someone. Edit: there's a tool called COLLADA Refinery which claims to have an up axis converter, that might be worth a try.

By default it's fullscreen, see http://trac.wildfiregames.com/wiki/Manual_Settings - if you haven't altered the settings then it should still be fullscreen. In windowed mode you would see the title bar of the game window and the minimize/maximize/close buttons. You can also use the Alt+Enter hotkey to switch between windowed and fullscreen. Which version of the game are you using?

Philip's mysteriously referenced plan describes the actor system exactly as it is now The discussion in the staff forum is from 2004-5 and actually predates the terribly outdated info on Trac. By "conditional variants" I assume the author was referring to selecting a variant in response to game conditions, like chopping a tree, wielding a sword, etc., which is of course possible. The only thing proposed that isn't possible yet is "global variants" which would affect all actors in the game, there's a TODO about that in CUnit, but since seasons are the only given example and we don't want seasons, it's super low priority. Don't trust anything you read on Trac pages beginning with XML.* as they are hopelessly outdated and need replacing It's only a question of finding someone with time, energy, and knowledge to do so

The problem is there was no interaction between Mayans or any other American civ, and classical European/African/Asian civs that I'm aware of until the Vikings in Vinland around 1000 AD, but nothing on a significant scale or well-documented until the 1490s, which is long after even Part 2's time frame. So they would be like an isolated civ if we followed historical accuracy (which 0 A.D. aims to do). Sure we could add some placeholder American minifactions, and people could even play Celts vs Mayans for fun, but my least favorite part of AoK The Conquerors expansion pack was allowing those unrealistic and even ridiculous match-ups (and it completely ruined the civ balancing IMO).

I would rather have a technology or civ bonus that allows select units to scale steeper hills and mountains. We only need to find a historical basis for that For the Carthaginians at least it seems an obvious choice as Hannibal crossed the Pyrenees and Alps to reach Italy.

Hi, I assume you're running in fullscreen (not windowed) mode? What is your graphics card and which version of its drivers are you using (the game's system_info.txt might help, see this link for the log path)? What is your display's resolution set to? Do you have a single or multi-display setup? Are there any warnings or errors when you start the game?

Assuming we want to get the sound system in place for A11, and it seems we do, I would say a week after it gets committed at the earliest, as we'll need time to test that as well. All subject to change of course Hmm, can the GLSL version be tweaked to have identical looking particles? It's a shame if we have all these nice new effects but particles become ugly.

The usual problem on OS X is having the wrong version of wxWidgets or building it with the wrong options. So just make sure to use wxWidgets 2.9.x and that it was built with GL canvas enabled (--with-opengl was passed to ./configure). If you use something like MacPorts or Homebrew, the same advice applies. Luckily we already have a cross platform solution for threading, the game uses standard POSIX threads API and there's a Windows implementation included It's easy to use, for examples see CMapGeneratorWorker, CUserReporterWorker, CTextureConverter, CNetServerWorker. Thanks for the information, that clarifies things.

What process did you try? The key with texturing is UV mapping, which tells the game how a texture gets mapped onto a 3D shape. So if you import a head prop's DAE into Blender, you should be able to enter UV coordinate mode and view the mapping. I guess you have a few options: either try to alter your new head texture to match the UV map, or alter the UV map to match your new head texture. It's possible each head prop has a different UV mapping, so it's not guaranteed that a single texture will work for every head, but I'm not certain

Hopefully it allows you to install the Intel driver, I've never had a problem with it, but sometimes it shows a scary warning about using generic drivers on customized hardware

Apparently it uses the full local transform of the prop bone (meaning relative to its parent but unaffected by the rest of the hierarchy), so both the rotation and translation are used, this transform is calculated once during model import and then applied to the parent bone's transform during skinning. I don't know what the local transform equates to in Blender or Max, could it be the orientation of the prop bone in the bind pose? The existing system isn't perfect but it seems flexible enough for most animations. Which cooler animations would you want to see that are currently not possible?

It depends on the map, most of the handmade scenarios that I've seen look good at normal zooms because the designer had in mind to avoid tiling artifacts and when unavoidable, used textures that look good painted over large areas. Really the bigger problem I've noticed is ugly blending between textures rather than tiling. Random maps are a different matter and that tells me the random map scripts just need to use smarter terrain texture variation to avoid such obvious tiling.

That tool has crashed for me too, I think they broke something recently. It's handy and I've used it in the past with no issues.

Sounds like two problems, one is that hotloading is broken or unintuitive in Atlas which should be fixed, and also that having a separate tool is annoying which I agree with. I think eventually Atlas will be expanded to have a number of editors including entity, actor, and mod editors. Basically everything about modding the game should be done in Atlas and instantly previewed. There is a partial mockup for a new layout somewhere, which Michael created years ago.

Personally I think the easiest solution is to stretch the existing images from 400x300 up to 512x512, if we can live with the loss of quality. This is easy to automate in almost any decent image editor. Otherwise we can make all new images, or we can add padding to existing images up to 512x512 and use the GUI engine to crop them back to 400x300 (I've never actually tested that this works but others seem to think it would), or we could live with seeing the padding but it won't look good on all preview images.

Is this with the new experimental GLSL features enabled (AO, normal mapping, etc.) in the game's config file? Have you changed any Catalyst graphics settings (e.g. antialiasing or performance/quality) from their defaults? I suspect a driver reinstall would not reset those settings to defaults. I've had driver crashes in the past after altering those settings.

To expand on the above correct answer: For static models you can use empty nodes, although I think any node or object that is named starting with "prop-" or "prop_" would work (I suspect if you add a non-empty node, you will see its geometry in the game which is likely undesirable - not tested this). The engine adds a prop point with the transform of that node. They cannot be animated as it's a static model. For skeletal/rigged/animated models, you use bones named starting with "prop-" or "prop_". These prop bones will follow their parent bone's animation. Internally they are stored by the engine in the exact same format as static model prop points, except they have a parent bone ID used to compute their transformation at each step. The prop bones themselves cannot be animated, they simply follow their parent bone and are not part of the rig, as such they are not added to skeletons.xml.

I think the problem was that transparent tooltips look very ugly, possibly a bug in the UI engine. Tooltip alignment is slightly buggy as well, which exacerbates this problem.

Hmm I'm not sure we should disadvantage females too much. If all they can do is gather a few resources faster, but build slower, aren't able to place military or defensive building foundations, and on top of that have no attack, it seems too much disadvantage to even train them. It may be good for historical accuracy and realism but is it good for gameplay and balance? Actually as with gathering I would expect soldiers to become less proficient at building over time, despite strength, as they will be focusing on combat skills instead of carpentry

This needs to be fixed before release. What solution are we going with to resize the preview images to 512x512?

You might also look into actor variables, which are currently used only for construction dust particles via the "numbuilders" variable, but maybe could be extended to control other things.

Just add the image as an attachment to the page, the same way you would on a Trac ticket. Then reference it with [[image(filename.xyz)]]. There's a bunch of other options: http://trac.wildfiregames.com/wiki/WikiMacros#Image-macro

Just curious what you mean when you say ARB version? Are the AO/specular/normal/parallax stuff implemented in ARB that needs to be tested, or do you just mean the non-GLSL shader path? Sorry for the confusion