historic_bruno

By the way, it wasn't clear in the release announcement, but IME input should work on both OS X and Windows It will work on Linus, too, but there it requires SDL2 built with IBus support, and at least on my Ubuntu test system, the SDL2 package did not support this.

Please don't make multiple topics for the same problem, you have already mentioned issues with saved games in several posts and submitted a Trac ticket as well.

Can you see which texture #28 is? It may be obvious from looking at it, or you may have to look at a call stack for it. The "Graphic and Compute memory analysis viewer" should let you view the individual textures.

Ah, yeah, there have been a lot of changes to support newer hardware since then. But you might be able to Continue in spite of that.

Ah I see you got it working Thanks for providing the data! It's only textures? ~274 MB which is a lot but still much less than the 1GB you have, you might look at the other objects I mentioned (framebuffers, vertex buffers, shaders, etc) Maybe it doesn't break on out of memory errors :/

Is the cursor missing from the start of the game? Are you running fullscreen or windowed mode? Does toggling that (Alt+Enter) help? Can you attach your system_info.txt from the log directory? (see also GameDataPaths)

Assuming you're on Windows: Download and install it, create a new project with the wizard, point it to wherever your pyrogenesis.exe is, and accept all the defaults until it's finished. You can set a breakpoint with Breakpoints > Break on Detected Error. Then press F5 or clicking the green arrow will start the game as usual. Now at any time you can press F6 or use Debug > Break inside gDebugger to break into the debugger, or wait until there is an error and it will break automatically. I would recommend testing in windowed mode, not fullscreen. Once you've broken into the debugger, View > Viewers > Graphic and Compute memory analysis viewer or Ctrl+Shift+M will open up a window that shows the GPU memory usage.

You could use a tool like gDEbugger to run the game, and set it to break on detected GL errors. Then when you get the 1285 error, you can take a look at the GPU memory usage and see if anything sticks out (it will show everything in GPU memory: textures, shaders, FBOs, VBOs, etc).

I'm only asking for testing purposes

I think we'll have some form of trigger editor, now that we have triggers, but did it actually work pre-Alpha? A lot of things were implemented pre-OS, then were removed when the simulation was reimplemented by Philip, etc. Did you try loading maps from anywhere in Atlas? That was broken for years until A16(?), because maps are loaded through the VFS, which is mapped to only a few real directories on your computer. The old file dialog was misleading that way, you couldn't really open or save anywhere. http://releases.wildfiregames.com/

When you try to save, are you playing with an AI? Does it always fail to save, or only sometimes? Does it make a difference if you play without an AI? When it fails to save like that, please attach the crashlogs, as you did for failing to load a saved game.

Seems like your saved games are getting corrupted somehow. Can you attach one of those you can't load here? You might try moving all of them out of the saved game folder except one, and keep doing that until you find one that is broken (if any). They are simply zip files, we can test if they are valid.

Here's an A17 release candidate bundle for OS X: https://drive.google.com/file/d/0B-qlXhiirMW3U1E3T0ROZlhhSTA/view?usp=sharing It should run on 10.5+ 64-bit Intel Macs. Hopefully some of you get a chance to test it before A17 release and report any problems here Fullscreen/windowed toggling is still buggy, that's the biggest issue I've noticed so far.

If we have a plane as a demonstration, we could have a tank, but you're right, it's too late for A17.

Use Shift+Mousewheel to rotate the camera, you can find more hotkeys in the in-game manual or here. Mouse tilt may or may not work, we need more people testing it: #2848

Surely you want to use the "install" command for apt-get, your line is missing that where you have "0ad". Also none of those lines from sources.list mention squeeze-backports, and also you should do a sudo apt-get update after fixing that. I think this tells you everything you need to know: http://backports.debian.org/Instructions/

I believe they get turned into CSimulationMessages which are serialized and sent over the network to the server, which then broadcasts them back to the clients, which deserialize them back to CSimulationMessages. The process really starts with posting network commands via Engine.PostNetworkCommand().

As far as I know, it has all been laid out by hand. At least I have never used a tool for it. In fact, I would be reluctant to use one other than for quick prototyping, as the produced code would likely be much less readable.

A brief update: the OS X build now defaults to using SDL2, build-osx-libs.sh should be run to pull in the latest dependencies. This offers several improvements, notably the ability to toggle fullscreen and windowed mode, and (untested) better support for Retina displays. There were some updates to build-osx-bundle,sh, including a new --release option that will do an SVN export and remove incomplete translations, etc. the same as build.sh does for the Linux release packages. Also, I have successfully built 10.6 and 10.7 compatible bundles on 10.9 with only a one line change in build-osx-bundle.sh, so I think we can go back to supporting them for A17

I'm a little curious as to how the game builds on the iPhone SDK.

To clarify, one of you can host a game in the lobby, but the other player can't join? Not even get into the host's match setup?

That sounds like health status bars, if it's above the units in-game, and that is completely normal

Should be fixed in r15761 thanks to a patch by mimo. If you find other problems, please create new tickets for them.

That kind of makes sense though, if you place a foundation in FoW and it gets destroyed, that tells you enemies are there, but you wouldn't this know otherwise. I think it's a different case than deleting your own foundation, that is like canceling a plan, and it doesn't give you any more information to exploit. I'm sure there are other opinions about it. #2710 mentions some of these problems.

Issues I've noticed which may or may not be bugs: * Construction progress not shown on fogged foundations. * Can't delete foundations placed in fog of war unless they are visible, but why? * ...unless you place a foundation in a visible area, then open the delete confirmation window, and the foundation becomes fogged, then you can delete it, but it will reappear until the area becomes visible again. If there's a gameplay reason for not deleting foundations in FOW, I guess it should be verified in Commands.js. In that case, the kill button in the UI should also be hidden. * Got this warning once, not sure how to reproduce it yet: WARNING: JavaScript warning: __internal(32) press line 0 reference to undefined property g_Selection.toList(...)[0]* Hovering status bars (for health, etc.) aren't visible on fogged entities, not sure if this is intentional since it worked in previous releases. Note that it's not really accomplishing anything, because I can still see the health of the entity by clicking on it.