historic_bruno

OK, if it helps at all, I can just pull directly from your Github repo. Since I found out how easy that is to do. That might help eliminate any yucky SVN<->Git interaction

Those tweaks are creating solutions to problems that need not exist in the first place (to cover up bad design choices), and I shudder to think at the uglification taking place in gamesetup,js Not to mention we're regressing and making the setup UI considerably less usable.

I noticed http://trac.wildfiregames.com/changeset/12074 - is this marking the target resource as globally, permanently inaccessible? What if a few gatherers are (temporarily) trapped but any other unit could reach it? And is this inaccessibility data updated/invalidated at some point?

I switched Git clients from Github for Windows to TortoiseGit. Now all is well and I'm quite happy with Git That would look amazing for building or destroying docks too

Hmm did you install the game in a different account than you're running it? I can't imagine why you'd need to use administrator permissions if you installed and run the game from a single account.

Just a reminder http://trac.wildfiregames.com/ticket/1223#comment:15 hopefully we can make a push on this over the next month.

What if we did both. Starting in the village phase they build round huts, then upon reaching another phase (city?) they can build blockhouses/tenements maybe with a pop bonus. Should be easy to do with technologies, assuming we want to have these different models.

I've also felt the Celtic buildings are somewhat disappointing compared to the others. Still, there's enough on the art department's plate without redoing another set of buildings

I'm ready to consider the original bug something we need to fix in actor editor, if you can't confirm it's fixed with wxGTK 2.9 (it seems like yucky logic and misuse of wxWidgets events anyway)

Would be so much easier keeping our current layout and just sticking the map preview on it...

Excellent, I was hoping we could get this working for non-GLSL hardware For those unaware of the difference, I found this page last night: http://www.opengl.org/wiki/Selecting_a_Shading_Language which gives an overview of the different choices for shaders, pros and cons.

Don't think so. The best thing is probably to design something that looks good at 1024x768 (easy to test with windowed mode, default.cfg or user.cfg can be set with yres/xres) and then just stretch things for higher resolution, distributing the extra space. It doesn't allow some fancy behavior but it mostly works

After you extracted it, does the file "%localappdata%\0 A.D. alpha\binaries\data\mods\public\gui\pregame\mainmenu.js" exist?

It's broken at 1024x768, all the controls overlap Also I hate having to move from one side of the screen to the other for related actions, in this case opening the map selection is on the right, choosing a map is on the left, then you have to move back to the right to OK it. (Especially annoying at 1920x1080)

How big is the map in the screenshot? It seems there's not much room to build and the scale of buildings to terrain is a bit off. The terrain shape itself looks good though.

Yes. It's mentioned in the Known Problems topic in this very forum

I think almost every texture we have is power of two I found one that isn't and should be fixed: art\textures\ui\session\portraits\emblems\emblem_athens.png (128x125) I agree that all we have to do is stretch them before and after. Atlas could do that automatically if we integrate the preview capturing with it.

We could easily, once we fix http://trac.wildfire...om/ticket/1514. The problem is pulling in possibly untrusted code from third party sources, compiling and distributing that EXE, especially if it's some kind of automated process. On a related note, I've pulled myconid's changes into my local git repo (didn't know it was so easy ) and successfully built it on Windows. I have no idea how this could be practically distributed without packaging the whole game, or at least changed EXEs/DLLs and a bunch of other assorted data files (it's probably cleaner to package the whole thing so people can use it independently of SVN). Plus I'd have to fix new files that have been added since the last time myconid' merged from upstream. And there's a few different branches, I'm not sure which one would be best for demonstration.

400x300 is not power of two The textures really need to be powers of two in each dimension or it causes problems with some drivers/GPUs.

I'd like to play around with it and see if I can break anything I'll try to test it tonight

They need to be power-of-two like all our other textures, correct?

AFAIK they all use horse.pmd. It can't be converted to a proper DAE because there's no skeleton data (it was exported directly from Max? to PMD/PSA). There's a bunch of horse .max files in art SVN though. I think Amish's new model is a big improvement though

There was some discussion along those lines here: http://www.wildfiregames.com/forum/index.php?showtopic=15640

We have one for generating a Trac page, but it doesn't look very flexible: http://trac.wildfiregames.com/wiki/Unit_Summary_Table_Generator Each template is hard coded in the script. Such a script should automatically scan for all templates in simulation emplates\* and sort them into buildings, units, etc. and extract relevant stats.

That's not 1024x768 It gives me an idea though. To help fill in the empty space on larger displays, we could expand the map preview and description -- the right side of that mockup, instead of only the player assignment area (as it is now). And if we resize the player assignment area, let's make sure it's not all aligned to the left, but the extra space is evenly distributed per column.