historic_bruno

Now we're getting somewhere Thanks for looking into it. I wrote an early version of the pathplacer but haven't followed it's use in the game and I definitely didn't check its memory usage. Spahbod would be the maintainer of most random maps, FeXoR also contributes to parts of it.

I agree the tooltips are too long, but keep in mind that prior to adding that info, there was absolutely nowhere in the UI that allowed us to see attack and armor stats before training the unit. There is currently no mention of range anywhere, so I have no idea if my unit has a longer range than an enemy fortress or tower. This is really important info and should be shown somewhere. Also we have a lot of distinct units with difficult names, it's not always clear to me if a unit is ranged or melee - sometimes that's all I want to know! I propose the following: Add an info / help button in the corner of each training / construction button (or use a modifier/hotkey) Clicking the new info icon opens up a well-organized stats sheet with everything the player could possibly want to know about said entity and a large portrait Link to list of entities and stat sheets elsewhere in the menu The training/construction tooltip shows only: unit name, description and iconified costs Clarify in the description(?) whether a unit has ranged or melee attack - could be as simple as showing an arrow / sword icon after its name For already existing units and buildings, add attack type and range to the stats tooltip

I mentioned this in myconid's graphics topic, but I'll add it here as well. While most of the contents of source/ are authored by us and GPL licensed, there are a few exceptions not yet listed in LICENSE.txt: source/third_party/mongoose/ (MIT) source/graphics/mikktspace.* (zlib) source/graphics/weldmesh.* (zlib) Any others? The above are GPL compatible but we should explicitly list them so nobody incorrectly assumes they are GPL or the work of WFG (without reading the files themselves). I would suggest a) moving mikktspace.* and weldmesh.* to source/third_party/mikktspace and source/third_party/weldmesh for organization purposes, and mentioning the contents of source/third_party in LICENSE.txt. Edit: started update of LICENSE.txt by removing wxjs and adding Mongoose

I can probably get used to it. It's annoying that the icons aren't aligned with the text though, can they be padded with a few pixels at the top or something?

http://en.wikipedia.org/wiki/Substantial_similarity Hopefully not Wikipedia, but scholarly sources (books, journals, etc.) It would actually add a lot to our documents if citations were provided, for one thing it would remove doubt in the reader's mind that what we say is accurate (we rely on many obscure details that aren't common knowledge); it would make it much easier for someone to extend past research if, say, certain details were omitted; and it would clarify that we got the idea from e.g. Wikipedia and not they from us. It's not even hard assuming that when we write such documents we actually do use sources and aren't making this stuff up I wouldn't advise going through the design document retroactively to add citations, it's probably not possible anyway, but going forward it's a good practice. The simplest approach is to just stick a list of references at the end.

What's the motivation for this change? Other than it being possible

I disagree that it's a better solution, that sounds like only sweeping the problem under the rug (no pun intended) Since random maps should be deterministic given a seed and the map settings, we should be able to reproduce gameboy's OOM error and debug it. Is the random map script wasting memory, is it generating too many entities, or do we really need to increase the runtime size? It's not something the user needs to control, in fact I would argue they shouldn't, because it's not a user preference bug a flaw somewhere in the game. When debugging JS OOM errors, I would continue to advise against simply bumping the runtime size (as I did with Aegis Bot) and instead suggest testing with the GC run more frequently and investigating the scripts themselves. It's trivial to write a script that causes OOM errors, why couldn't it happen accidentally?

I too can't wan't to see what our artists come up with Just a taste: aqueducts, wells, pools, fountains. I do notice a water glitch on my system: Notice the dark patches on parts of the texture, they remain even after changing the sun angle and sky set. This is with or without GLSL. system_info.txt

Just want to remind people that even if we paraphrase information from an outside source (Wikipedia or wherever else), we still need to cite it. Taking someone else's idea and writing it in your own words doesn't make it your idea Of course that's much harder to prove than a blatant copy-paste, but it's the ethical thing to do. If we don't want to cite sources for e.g. random map descriptions, then they should just mention the characteristics of the random map instead of real-world descriptions based on someone else's research. The same goes for all the unit and civ descriptions, we'll need to go through them with a "fine toothed comb" and make sure none of it is violating copyright law.

There's a new build in SVN with a possible fix, so just update and test if you can

I like config options for everything too, but I'm a programmer Last time I suggested a config for something like this, it was shot down because the game should be smart enough to know how much memory is needed for whatever task, and I understand that argument. In other words, the user shouldn't have to decide how much memory needs to be allocated for a given JS runtime. We could make it variable: specify a minimum and gradually scale it up according to the user's system specs.

Hmm that's strange, what's your operating system? When you say it's slower what do you notice, is the mouse slow, the menus slow, what's your framerate like (Alt+F), do units move jerkily in the game? How would you define the slowness? It's hard to determine from only "slow" what could be happening Also check the in-game profiler (F11) to see what's taking the most time.

Which map size and how many AIs?

The retina display issue is a known problem, at this point we believe it's an SDL bug, it's hard to test without a retina display though Try running the game in windowed mode instead by setting windowed=true, that should work.

It would be really cool if some particles were used, like leaves falling, maybe some birds / butterflies fluttering around. Personally I love mechanical things, so seeing the "screws" or pumps that raised water from the Euphrates would be epic, if you could somehow work that in, or at least seeing animated water throughout the model (perhaps small waterfalls and aqueducts). As good as it looks as a static model, I can only imagine seeing it come to life!

I like that, it gives more personality to the ranks and somewhat reflects how their role changes with experience

If you follow the Trac timeline, you'll see ever so often someone will come by and fire off about a dozen new tickets. Often they are duplicates or feature suggestions better discussed on the forum, so we give a reason and close the ticket. I promise it's a painless process for the ticket creator, we don't make a spectacle out of them Our response time is pretty good, better than most open source projects, from what I've seen we get around to them the same day or next day at latest (there are many hidden eyes viewing every Trac update) I wouldn't assume that just because something is posted on the forum, IRC, or anywhere else, somebody else will create a ticket for it later. It's better to take the initiative, you might almost say it's the reporter's responsibility to do so, if they find a problem they want fixed, shouldn't they take the time to do it through the preferred channel? (You might wonder why I don't just create one myself, but I like to encourage others instead of only complaining about something that's wrong which happens constantly and is quickly forgotten, to create a Trac ticket instead, creating a document of the report and allowing much better control over task assignment, organization, attaching patches, cross referencing tickets, referencing in SVN commits, etc. It's a good habit to get into IMO)

I think people are confused about this, because the last Windows autobuild which became the game's binary was r11858 (this is what's seen in the game) but the data that was bundled included up to r11863 as labeled on the installer. The two will always differ slightly because for one thing the autobuild refers to the revision prior to its own commit, even if it's the last thing committed before a release, there will be a discrepancy of one revision. It would only pose a problem if the engine code changed between 11858 and 11863, which is why we have a commit freeze Similarly for Alpha 11, the game's menus will report r12634 on Windows but the actual package will be r12636.

That looks so beautiful, can't wait to have it in a scenario. The only problem is players might be distracted by how awesome it looks

Autorepair could be given a lower priority than responding to attackers. Not sure how easy that would be given the structure of UnitAI, but at least it's a possibility. The other concern would be if we implemented surprise attacks or gave working citizen soldiers a disadvantage when attacked (to simulate the need to put down shields/weapons when working and take the time to re-arm for combat), then it would definitely need to be an option.

It doesn't require formality, the default settings are almost perfect on Trac (you might only need to change component, but don't worry about owner/CC/keyword/milestone). So I'm not convinced it's harder to report a bug on Trac than it is here.

I still don't think the best solution would be assuming that if <texture> is found it's an old actor and if <textures> is found it's a new one - people could easily get the two confused by copy-pasting XML from different sources. We have a few possible solutions for preventing similar issues starting with A12: 1.) add the handling of old format actors back in, 2.) bump the actor version number from 1 to 2 (probably not bad from an organization standpoint) and either refuse to load version 1 or fall back to handling <texture>, and/or 3.) verify a model has valid textures defined for it before loading and rendering it. Really I can't believe there was no error, a model was apparently using garbage data for its texture

Please make a Trac ticket for this and other bugs you find, we very strongly prefer that I'm afraid when it comes time to look at what needs doing for A12, few are going to read these forum posts...

Healers could be moving or actively healing, in which case they shouldn't appear as idle Though they do autoheal, that case is not so different than autoattacking of soldiers.

Comments about the new UI in A11: If I have a unit selected, I can't tell what type of attack it has (ranged, melee, charge). Sometimes the tooltip description gives a hint, often it doesn't. The attack/armor stats tooltip should mention at least the primary attack type of the unit. The unit rank tooltip is not clear, it currently says e.g. "Basic Rank" which is not clear if the rank is "Basic" or if it's showing the basic rank, whatever that might be. This would be more consistent and clear: "Rank: Basic" Would be nice to see the AI name in-game. "Player 2" doesn't tell me anything about which AI I'm playing There may be value to seeing both username/AI name and the player name which are subtly different concepts.