s0600204

Hi wgoyc! Only when someone implements a scrollbar for scrolling objects within other objects. Which requires c++ modification, which is currently beyond my abilities. Not too sure what's causing that as that variable isn't used on that line, but I've pushed a newer version based on recent SVN changes to my repo, try that. I'm guessing you've modified your local copy of gui/gamesetup/gamesetup.js? Then find and copy the setCiv() function found in my repo's gamesetup/gamesetup.js (line 585) into your modifications.

Confirmed. units/rome_infantry_swordsman_b has other/palisades_rocks_fort explicitly disabled, while the other roman infantry do not. Curiously, on scythetwirler's master branch on GitHub, the commit where the above is implemented (https://github.com/scythetwirler/0ad/commit/451f87997233e674f47aa92acea9f07e0fdbf8ac) is the same commit in which all the other infantry units acquire the ability to build it. So it may be intentional.

Issues it solves: Gatherer-blocking - where one player deliberately sends units to gather at a resource close to an opponents base to prevent the opponent gathering from that resourceFore-knowledge of enemy gatherer movements - where a player can look at a resource and see how many units are currently gathering or have been assigned to gather there, regardless of whether said units are the player's or not, before any of them ever arrive.Issues it introduces:None. (That I'm aware of, no doubt someone will point something out.) The mentioned issue is one that is already present in 0AD.Edit: The example mod has been updated to be compatible with SVN (r16778)

"integer" is an acceptable type, as is "decimal".

My apologies for continuing/resurrecting an old thread... I have a counter proposal to the problem of counting currently gathering units on a given resource, when they are not actually at said resource: Specify units tasked to gather, but not actually at the resource, as "Enroute" gatherers, and make the object storing the entity-ids of these be player-specific.When a unit arrives at the resource, they are moved from the player-specific 'enroute-gatherers' object to the global 'gatherer' object for that resource.When a player selects a resource, the count they see in the UI is summed from the global 'gatherer' object and their particular part of the 'enroute-gatherer' object.To give an example:Player 1 and Player 2 can both see a tree they wish to gather from, a tree that has no current gatherersPlayer 1 sends four units to gather at the tree, and they are now considered 'enroute'Player 1 selects the tree in question, and sees from the UI that there are four gatherersPlayer 2 selects the tree, and according to her UI, there are no gatherers. (Which makes sense, as a Player shouldn't have advance notice of enemy unit movements)Player 1's units arrive and get to work. Player 2's UI updates, showing the four gatherers.Player 1 sends four more units, and upon reselecting the tree, his UI shows eight units.Player 2 also sends four units, and her UI updates to also show eight gatherers (Player 1's original four units who are still at the tree plus her four enroute units)Player 2's units get there first, and set to work. Player 1's units arrive shortly after, find the tree now full, and look for an alternative tree nearby.The plus is that it prevents gather-slot stealing by not allocating the global slots until the unit is actually at the resource, whilst also providing a way for a player to be able to assign units to a resource, and have the UI update to reflect that decision. To see if the above would work, I have created a mod to demonstrate: https://github.com/s0600204/gather-count (A18 only, sorry). Continuing, on a branch, I've also merged MattDoerksen/Deiz/historic_bruno's patch from #643, adjusting it to take into consideration enroute gatherers and also formations (which was a known issue with the patch). Known issues: Units coming out of a building (from being trained/garrisoned) following a rallypoint to a resource to gather are not counted. This is due to units being given the order to GatherNearPoint rather than Gather in these cases (causing units to use INDIVIDUAL.GATHER.WALKING rather than INDIVIDUAL.GATHER.APPROACHING). This is also true in the unmodified game.Edit: I created the mod so as to demonstrate and so people could try it easily. I can create a .diff patch if desired.

Thanks you, both of you. I still have a way to go, though. niektb has recently relocated the han.json civ file to its A19 location, so soon... soon... If some of the civs are not in the group they should be, or you feel a particular group is missing, then if you could please list them in this issue on GitHub. It would just give me a easily referrable point of reference for this particular problem. That goes for anyone. Thanks. The interface size is currently fixed at 976x720, which will fit on a 1024x768 screen, which is the suggested minimumum resolution for 0AD. I don't plan on changing those dimensions any time soon. It would be nice (and I'm mainly thinking of my structree here) if it was possible to define a minimum and maximum size for UI elements, so we could scale things, but I suppose that would require something of a rewrite of the GUI engine/parser/thing.

Work in progress: If you'd like to try it then the following should work: (A18) https://github.com/s0600204/0ad-civselection-mod(SVN) https://github.com/s0600204/0ad-civselection-mod/tree/SVN (Note: untested)Neither is compatible with han_china or millenniumad mods, due to relocated civ json files (aristeia works). Lion: if you'd like to help, I could do with a couple of small icons, about 16x16px, as indicated by the (terribly drawn, sorry) arrows below.

Okay, I've worked out what the problem is. It's because the norse civ uses phase_town_norse followed by phase_city_generic. phase_city_generic expects phase_town_generic to be researched, but because the norse civ uses its own variant, phase_town_generic never is researched and thus phase_city_generic remains unavailable. neiktb: I've come up with a solution. In fact, three possible solutions. They each work, but also each have a problem/drawback to that approach: (all links point to changesets on GitHub) Options 1 and 2 are variants on the same theme and both have the same issue - in that the icon for the city-phase tech appears besides the icon for the town-phase tech, rather than the preferred state of it only appearing once the town phase tech has been selected for research. Whilst this was happening anyway with the norse civ, this UI problem will now affect all civs that use phase_city_generic whilst this mod is loaded.Option 3 does not have this problem - with the icon for the city-phase icon only appearing once the town-phase has been or is in the process of being researched - however it is also incompatible with the aristeia mod, due to both of them modifying the same file (phase_city). This means that a norse vs egyptian match would not be fair with one of these two civs unable to properly reach the city phase.Like I said, any of the three options will fix the problem, but I'd like some feedback/discussion before one is chosen and merged into master.

Skuggor: Interesting. I'm getting the same issue. Thank you for reporting this. neiktb: I notice there is some confusion as to the phase the barracks and the blacksmith structures are supposed to belong to... Blacksmith: [0ad] template_structure_military_blacksmith.xmlRequiredTechnology: phase_townVisibleClasses: Town[millenniumad] norse_blacksmithRequiredTechnology: phase_villageClasses: Town VillageBarracks: [0ad] template_structure_military_barracks.xmlRequiredTechnology: phase_villageVisibleClasses: Village[millenniumad] norse_barracksRequiredTechnology: phase_townClasses: TownSo, the blacksmith and the barracks are being read by 0ad as belonging to both the Village and a Town phases. Also, the Classes list of the blacksmith in-game contains the Town token twice (I suppose it would be nice if the xml-parser would detect and remove duplicate tokens, but meh).I don't know if 0ad's confusion over the classes is the cause of Skuggor's problem, although I suspect it may be a contributing factor, but either way it probably should be cleared up. (Edit: Amended files to test, problem still exists)

Hello Skuggor, and welcome to 0AD! Do you have any other mods installed and active? And when you go to the mod-selection screen, is the millenniumad mod listed [a]after 0ad in the bottom most space? We're assuming you're trying to play as the norse civ, right? (You don't actually explicitly say...) And not that it should matter, but which OS (Windows, Linux, OSX) are you running the game on?

May I ask you to have another look at that?

I think the mesh needs rotating in blender (or whatever you use), Lion...

As I mentioned previously in http://wildfiregames.com/forum/index.php?showtopic=18505&page=10#entry305231, your stables mesh is off-centre (that blue/green/red axis marker is the 0,0,0 origin point for the mesh). I'm not an artist, but I would imagine you would need to centre the mesh in blender on the x,y axis and re-export or something.

In the Aristeia mod, the New Kingdom Egyptian civilisation currently presents the player with a choice when choosing the city-phase tech - to go with a Theban or a Ramesside city phase. Although not reflected fully in art yet, the two choices provide different heroes, champion units and selection of city-phase structures. My point being, the idea is not entirely lost.

My apologies for the delay in responding - work has gotten busy recently. If there's enough interest, I could look into experimentally putting an AOM-style interface together. But it would have to wait until I have some spare time. Ah, thank you.

Should now be fixed. Thank you for spotting. Why would it be, we're several centuries before vanilla Try changing formations/scatter to formations/null in civs/egyptian.json, line 206. Good.

Probably goes without saying, but the AOM-style civ-selection screen would need some thought put into it to permit the addition of further civs via mods. But like wraitii said, that's implementation. Remind me, was that a mockup, or something that was actually implemented by someone? The civ *.json files already have a "culture" attribute. I don't think it's used at the moment. For the most part it's just the same as the civ code of the civ. I suppose it should become an array (because for example, as I understand it, ptols are both egyptian and successors)

Lion: Could we have it so that it the x,y axis is central in the mesh, please. Because at the moment your mesh is being rendered off-centre. I'll update the obstruction values once the mesh sits in the middle of it. neiktb: We were previously using the macedonian ram and the persian stables as placeholders. The new ram is identical to the placeholder but with different shield props. (If you'd already worked this out, then my apologies for telling you something you already knew )

Lion: Should now be fixed in GitHub. Good catch.

What exactly is the problem, Lion? Could it be that you are trying to use units/egyptian/infantry_swordsman_b.xml, but the file you created is units/egyptian/infantry_swordman_b.xml?

Excellent . I'll push the fix to master shortly. Edit: Done.

No, I hadn't noticed that. Hmm. I'll amend them. Edit: He he, units were up to their shins in the floor... Pull request amended.

The files indicated by the errors do not exist in Aristeia. They do however exist in the the convert_attack mod. If you have the convert_attack mod enabled, disable it. Edit: get the name right, and what nietkb said.

I've created template xmls for the added structures. If someone would like to check them, the pull request is here.