Ykkrosh

What version of Windows are you running? 32-bit or 64-bit? If you click the "Continue" button, does the game continue and work properly?

Looking good . Is the default orientation a bit off? Maybe the <up_axis> should be changed to Y_UP or something.

Hmm, I looked at the example you posted in Blender (2.53) and found a few issues: You don't have to actually define any materials, you can say <triangles count="4" material=""> and it seems to load and render correctly. (If you don't specify any material then it crashes.) I think you need to have a <technique_common><accessor>... thing in each <source>. In the <triangles> you are saying that each vertex has three inputs at separate offsets, which means the <p> needs 3 numbers per vertex (and 3 vertexes per triangle and 4 triangles in total) but you only have one per vertex. You should either repeat each number three times (for the position index, normal index, and texcoord index); or change all the <input>s to say offset="0" so they share the same number. You say <vertices id="hex_b-Vertex"> but then refer to source="#hex_b-Geometry-Vertex" instead. You don't need the translate/rotate/scale in the <node>.

Options mean twice as much to design and implement and test and maintain and understand, so there's a fairly significant long-term cost, and they should only be added if they're going to be sufficiently valuable. (I have no idea if this is one of the cases where the value outweighs the cost, but I'd probably prefer to err on the side of simplicity.)

Maybe the unit icons could be sorted by their type, so all the units of type X are next to each other followed by all of Y etc? That might make it easier to visually determine the set of units you've selected - currently it seems random (or probably based on entity ID) and you have to search through every single icon to count how many there are of a given type.

The only things I can think to try are older drivers, or changing from Win7 to something that has better driver support for your hardware. (Maybe an Ubuntu LiveCD could work ). Otherwise it seems like your drivers just don't handle OpenGL properly, and I don't believe there's anything we can do about that.

Hmm, it looks like the latest drivers for that are found here, intended for Vista but apparently they install on Win7 too. They say "AMD’s DirectX 9 ATI Radeon graphics accelerators are not officially supported under Windows 7", so it's not too surprising if they fail - I don't think there's anything we can do in the game to help when you're using obsolete drivers on an unsupported OS

That looks like the drivers haven't been updated successfully - it still says "2.0.6347 Release" and the driver DLLs are dated 2007.

If it's still crashing, could you attach the new crashlog.txt/crashlog.dmp?

Stack trace: 0a640c40() kernel32.dll!_HeapFree@12() + 0x14 bytes > 08dba880() pyrogenesis.exe!upload_level(unsigned int level=0, unsigned int level_w=64, unsigned int level_h=64, const unsigned char * __restrict level_data=0x0b150000, unsigned int __formal=12288, void * __restrict cbData=0x0028f1d4) Line 793 C++ pyrogenesis.exe!tex_util_foreach_mipmap(unsigned int w=185925632, unsigned int h=64, unsigned int bpp=24, const unsigned char * pixels=0x0b150000, int levels_to_skip=-1, unsigned int data_padding=1, void (unsigned int, unsigned int, unsigned int, const unsigned char *, unsigned int, void *)* cb=0x00c1f8f0, void * __restrict cbData=0x0028f1d4) Line 147 + 0x12 bytes C++ pyrogenesis.exe!upload_impl(Tex * t=0x00000000, unsigned int fmt=32992, int int_fmt=32849, int levels_to_skip=-1) Line 816 + 0x11 bytes C++ pyrogenesis.exe!ogl_tex_upload(const __int64 ht=68719476760, unsigned int fmt_ovr=0, int q_flags_ovr=0, int int_fmt_ovr=0) Line 878 C++ pyrogenesis.exe!CRenderer::LoadTexture(CTexture * texture=0x0028f26c, int wrapflags=0) Line 1483 + 0x15 bytes C++ pyrogenesis.exe!CParticleEngine::InitParticleSystem() Line 82 + 0x3f bytes C++ pyrogenesis.exe!CRenderer::Open(int width=1280, int height=800) Line 539 C++ pyrogenesis.exe!InitRenderer() Line 527 C++ pyrogenesis.exe!Init(const CmdLineArgs & args={...}, int flags=0) Line 820 C++ pyrogenesis.exe!RunGameOrAtlas(int argc=1, const char * * argv=0x022a1140) Line 439 C++ pyrogenesis.exe!main(int argc=1, char * * argv=0x022a1140) Line 460 + 0xf bytes C++ pyrogenesis.exe!wmain(int argc=1, wchar_t * * argv=0x022a17a0) Line 371 + 0x7 bytes C++ pyrogenesis.exe!__tmainCRTStartup() Line 583 + 0x17 bytes C pyrogenesis.exe!CallStartupWithinTryBlock() Line 385 C++ kernel32.dll!@BaseThreadInitThunk@12() + 0x12 bytes ntdll.dll!___RtlUserThreadStart@8() + 0x27 bytes ntdll.dll!__RtlUserThreadStart@8() + 0x1b bytes Looks like it's crashing inside the graphics drivers. You should update to the latest drivers and see if that helps.

There should be an OpenLogsFolder.bat file where you installed the game - if you run that then it should show a folder with crashlog.txt and crashlog.dmp. Can you add both of those files as an attachment here?

What parts do you think it should be used for? There are technical reasons why it's quite difficult to have complex physics that affects gameplay (our multiplayer system relies on deterministic computation but physics libraries usually rely on floating-point). In AoE3 it was purely a graphical effect; I think CoH may have been the same but can't remember it well. So we could probably do some kind of ragdoll death animations, with a bit of effort to set up the skeleton data files to support that. AoE3 also had destructible buildings, which are hard because they require a load of artist effort to split the building into dozens of tiny fragments, and I don't think we have the resources to spend on that, and we don't have lots of cannons that would make buildings frequently break apart like that. Are there other things we could use physics for?

If it doesn't work with no material information, have you tried adding some material information? Perhaps something simple like <library_materials> <material id="default-material"> <instance_effect url="#default-effect"/> </material> </library_materials> <library_effects> <effect id="default-effect"/> </library_effects> ... <triangles material="default-material" count="4"> ... <bind_material> <technique_common> <instance_material symbol="default-material" target="#default-material"/> </technique_common> </bind_material> ... would be sufficient?

As mentioned a bit on IRC: It looks like this is the old problem with the pathfinder, though I'm not sure why it's quite so terribly slow for you (maybe I just didn't test with enough units?). The situation to avoid when playing the game is lots of units all moving and getting in each other's way, because that makes each of them do a not-very-fast path recomputation every time they move. I think the real solution is to redesign how unit movement works (again) so that it works better in these situations. (The current pathfinder should probably be kept for navigating around static obstacles, since I think it works well for that - we just need an extra layer for dynamic obstacles.)

Hmm, seems a bit odd. Did the SVN checkout definitely complete? Sometimes it stops before it's finished - if you run "svn up" (from the checkout directory) then it should just say "At revision 7983." (or similar) if it's okay. If that doesn't help: Does the file libraries/spidermonkey-tip/src/build/autoconf/acoutput-fast.pl exist?

Yes. (That should be fixed eventually, but it needs knowledge and time and access to varied Macs to test it.)

Turns out that I changed my mind and set up the PPA after all. I think I've got all the packages updated now and documented here, and I've tested most of them at some point so I think they should probably work. Bug reports / fixes would be good from anyone who uses these distros

Looks largely reasonable to me . Have you tried successfully importing into a 3d modelling program (like Blender)? If you have xmllint, have you tried validating the file? It's possible you need a <library_visual_scenes> (probably with no translate or scale or bind_material) and <scene> to say the mesh exists. (I'm not certain, though.) It looks like the created/modified dates are wrong - I think they need "-" instead of "/". The <float_array count="6" id="hex_b-Geometry-Position-array> seems to be missing a " character. To save disk space, the floats should be shorter - six decimal places should be sufficient.

Added reset (the H key). Rotating upwards when zooming seems tricky to do properly with this camera system. The camera doesn't automatically move up/down to follow the terrain, except when it's exceeding the min/max zoom distance settings, so the zoom distance can vary within those limits. If the rotation was linked to the distance then it'd wobble annoyingly when you scroll over small hills. If it wasn't linked to the distance then they'd get out of sync and you'd often be stuck at weird angles. I can't think of a way to implement it so it would work nicely. (I think in those other games the camera does move to follow the terrain height (so the distance from the camera to the terrain is constant and can be tied to the rotation), but I'm not sure I like that since the movement feels a bit artificial and it masks the visual effect of slopes.)

The .pmd just has the mesh and UV texture mapping coordinates, then it gets referenced by an actor XML file like binaries/data/mods/public/art/actors/props/units/shields/hex_a_back.xml which also says what texture to apply to the mesh (as well as animations, and props (other actors that get attached to the mesh)). (The same mesh can be reused with many different textures, e.g. we have lots of different shield patterns if you look at the hele_round_spartiate_sp.xml actor.) The material data in the .dae file just gets ignored. It's included because that's what the standard Collada exporter does, but it's never required - you could omit all of it (library_images, library_materials, library_effects, and the bind_material) when constructing a new .dae file.

I changed them quite a bit. Any opinions on how it feels? Pan: move mouse to edge of screen; or arrow keys; or WASD; or middle-button-and-move-mouse; or "/"-and-move-mouse; or click on minimap. Rotate: shift + mouse-wheel; or ctrl + arrows; or ctrl + WASD; or Q, E. Zoom: mouse wheel; or "+" and "-". If you open the developer overlay (via the menu, or press shift+D) then you can disable the camera constraints to get more control (for e.g. taking nice screenshots). See binaries/data/config/default.cfg's "view." section for tweakable parameters. Are the speed and range and smoothness settings sensible, or are there changes that make it nicer?

Have you seen the PMD documentation on the wiki? That might clarify a few things If you run the game then look in your cache directory (~/.cache/0ad/ on Linux, %appdata%\0ad\cache\ on Windows), it'll have .pmd files corresponding to the .dae files that are in binaries/data/..., so you could compare them that way. The 2 is indeed the version number there, and 352 the data length (the file is 364 bytes, with 12 byte header). The '00 ff ff ff' (your hex dump seems to be reversing the byte order) is usually the 'u8 bones[4];' array (each vertex can be influenced by up to 4 bones and this one is influenced by bone 0x00 and the other three slots are unused). Looks like there's 6 vertices but each is 52 bytes (when you include the VertexBlend). Most of the values are floats, so you need something like Python's struct module to unpack them into numbers.

Just remove the "<float/>" from the ship actor XML files - the ship entities will still float, but non-entity ship actors won't.

This can be changed in simulation2/components/CCmpSelectable.cpp ("m_Overlay.m_Thickness = 2;") - could you try experimenting with that to see what you think works best? Yeah, I think it probably is . We don't want to require fragment shaders for this, and any textures can just be generated offline.

Don't give their actor the "float" property, then . Objects will be rendered as floating if either their actor or their entity specifies floating, so for normal unit actors (e.g. ships) that are used by floating entities there's no need to mark the actor as floating too. It's only needed for actors that do not have an entity template file (e.g. all the little decorative objects).