Jump to content


WFG Programming Team
  • Posts

  • Joined

  • Last visited

  • Days Won


Everything posted by s0600204

  1. Very nice. I really like the look of the Seleucid buildings. Incidentally, d'you maybe want to remove the Macedonian props from the `death` variant in the actor file? At the moment this happens when the market is destroyed in-game: Yep, the Macedonian barracks pops in for the ride into the ground! (Appears on the death of the Seleucid barracks as well, although that's not as obvious.)
  2. Ponies Ascendant has been updated on GitHub so that it works with the recent A20 release of 0AD. Download and enjoy!
  3. Prepping for christmas with family. And keeping an eye on IRC.

  4. If we treat your mod as a testing ground for "what-if"s, then, yes. Noted. Will look into it.Apologies for the delay. Fix submitted (http://trac.wildfiregames.com/ticket/3682), and committed to SVN (http://trac.wildfiregames.com/changeset/17384). Edit: Update to inform about fix having been committed.
  5. If I may put forward my two pence: I agree with the fact the phasing doesn't "feel" right. But I'm not sure that getting rid of phasing altogether is the right move, it just needs adjusting to fit the concept of the game. I also agree with the basic idea of these: On a slightly off-topic note, one thing that's bugged me for a while is the current appearances of the civil centres. My problem is that they look (particularly the Roman one) like city-phase structures. The first (or second if you're playing Nomad and build a dock first) structure you build upon deciding to settle in a completely new area is a large, stone clad building with fancy statues? Really? IMHO it would be better to have the civic centre starting off as a tent and a couple of flags stuck in the ground, and then developing as the game goes on to a more solid, permanent looking structure. On a slightly less off-topic note, in RoN, you placed a "Small City". Building enough buildings around said "Small City", it became a "Medium City" automatically. And again, more buildings and it became a "Large City" and eventually a "Metropolis". Each stage had a visual change for that city, and increases in health, defence and the radius width in which the player could place buildings and have them count towards that City's building count. Anyhow, getting back to the point - I think that "phases" need to reflect the status of your presence on the map, rather than be actually research-able. What I might suggest is that instead of keeping them as technologies that you have to research, they become automatic upon certain limits. Let me elaborate: My basic proposal is to have something similar to RoN, and to what Wraitii suggests. A player places a Civic Centre ("CC" for short), and it is built into its initial "Village" form. Place enough buildings around it, and the ability to upgrade that CC to its next state ("Town") is unlocked. This new state has better defence, higher garrison limits, greater influence on territory borders and a larger radius in which buildings can be placed to count as belonging to that CC. Same again to upgrade to a third, "City", state. Each CC upgrades separately to all the rest on the map. So where does phasing come in? Well, when a player places their first CC, the player is automatically transitioned from the "Nomad Phase" to the "Village Phase". When any one of a player's CCs on the map is upgraded to its "Town" state, then the player is automatically transitioned to the "Town Phase". And ditto, when any one of a player's CCs upgrades to its "City" state, the player is advanced to the "City Phase". Essentially, the player's 'current' phase is that of the most advanced CC the player controls at that point. And yes, this means that if a player loses their only "City"-state CC, they revert back to the Town Phase (or Village, if they have no Towns), which makes sense as they no longer have a "City" on the map. (CCs don't revert if they lose buildings.) So phases become conceptual and representational, rather than something manually researched, whilst remaining something that can be easily checked for in requirements of techs, buildings and units. (Essentially as a quick to check to see if a player has the necessary infrastructure to support more complex structures etc). We could even go slightly further and make it so only barracks near a City-level CC can train City-phase level units, Town-phase-level structures can only be built around town- or city-level CCs, etc. Checking what phase a player is in would be used for statistics, tech requirements, and to permit towers, walls and fortresses to be built away from CCs. (I like building towers on cliff edges. If I can only build stone (town-phase) towers near town-/city-level CCs, then my defensive options are curtailed somewhat.) By having CC-upgrades manually triggered by the player (rather than automatic upon a given number of buildings like in RoN), then (a.) CCs could be cheaper, with the CC upgrades being expensive, and (b.) there could be a pair-choice that could provide bonuses to nearby units/buildings in/of that settlement (ie. wgoyc's mercantilism vs agrarianism = bonus to nearby markets/traders vs bonus to nearby farms) thus permitting settlements to specialise. Anyway, long post, sorry. Thanks for reading. Oh, and I don't necessarily agree on being able to upgrade every building. Wooden palisade outpost -> wooden defence tower -> stone defence tower, maybe. Barracks Lv 1 -> Barracks Lv 2... I'm not convinced.
  6. Helping update various mods to work with A19

  7. A ticket was recently created on trac that proposes the creation of charts in the summary screen: http://trac.wildfiregames.com/ticket/3403 In the meantime, its been pointed out that the mod no longer works with the current development state of 0AD, so if you're running at the cutting edge of SVN and want to run the mod, here's an (unofficial) update: https://github.com/0ADMods/summary-charts (if you're still on A18, agentx's zip should work)
  8. The size of the "Footprint" is the size of the coloured box/circle around the base of a selected entity. It may have another use mind you, but... Wall piece templates (or at least the ones used in wallset_*s) all invoke the WallPiece component, which takes the form: <WallPiece> <Length>38.0</Length> </WallPiece>This is used by the wall placement code (see "simulation/helpers/Walls.js") used when a player places a wall in game.That said, I notice that the length given for the cart gate is shorter than the cart medium wall... which is evidently incorrect. Other given lengths may also be... off. While you're at it, would it be wrong if I asked if you would replace all the instances of 0*PI in the file with simply 0? And 2*PI/2 with PI? Edit: Added line about lengths possibly being wrong.
  9. Siege weapons are capturable, and they are units. Which files are you modifying and how? And some units (like heroes, or any units in the immediate vicinity of a friendly hero) shouldn't ever surrender. Probably ties in to the concept of a morale system. This would most likely require modification of the UnitAI component. And as the 'wandering' would require use of the pathfinder, it would more likely make performance worse. Either I'm not understanding what you mean, or this would cause confusion from players ("Why have my gatherers stopped gathering and are now wandering off?") To be "skittish" means they run away when being attacked or an enemy unit gets too close (rather than standing their ground or attacking). I do sort of like this idea, although as idle gatherers tend to collect around their last drop-off point, they'd have to wander a fair distance to provide useful LOS. That said, having idle gatherers move a short distance away from said drop-site so other gatherers still gathering can get to it would help prevent congestion. Just my two pence/cents/whatever.
  10. Oddly enough, that makes logical sense. To prevent 'resource quantity not set' errors, one of the base templates that most, if not all, the other templates inherit from will have food/wood/metal/stone costs all set to 0. So a structure that according to an in-game tooltip only requires 100 wood, will also require 0 food, 0 metal and 0 stone. I'd be tempted to suggest finding the template and changing the base values to neg inf, but that would probably cause other issues. Might be best to modify Cost.js to skip checking the current stockpiled quantity of a resource if the cost requirement for that resource is set to 0 (or less).
  11. It works perfectly over here. Check you've modified the line correctly.
  12. You can try it locally by changing the lines for food from "<element name='food' a:help='Food given to the player every interval'>" + "<ref name='nonNegativeDecimal'/>" +"</element>" +to "<element name='food' a:help='Food given to the player every interval'>" + "<data type='decimal'/>" +"</element>" +Be warned that there is nothing to prevent a player's resource count as marked at the top left of the screen from entering negative values. Feel free to come up with a solution to that problem. (ie. What should happen when a player runs out of food? Units start dying? Units desert to gaia? How should the game select which units should die/desert?)
  13. slenderbro, welcome to the community. To help us to help you, could you tell us a bit more about your computer and the install setup you have. You're clearly running Windows, but may we inquire as to the version? Also, what version of 0AD are you running? You appear to have a similar (if not the same) problem to that reported here: http://trac.wildfiregames.com/ticket/3267. There, the reporter appears to have at some point transferred his entire "Users" folder to a different hard-drive (but somehow managed to keep the C:\ prefix). Is this also true in your case? Or any other possible oddities in your filesystem?
  14. I'm sorry wgoyc, but I cannot reproduce the error. Like I said earlier, the variable mentioned in the error message is not used on that line. In fact none of the line numbers for civselect.js mentioned in the error match the actual location of the code they most likely refer to. Make sure your local copy of the mod is up-to-date. Or if you've copied the file to your own mod for some reason, please check you've copied it properly and in its entirety. Alternatively if you've modified it locally, then... well.
  15. 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.
  16. 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.
  17. 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)
  18. "integer" is an acceptable type, as is "decimal".
  19. 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.
  20. 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.
  21. 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.
  22. 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.
  23. 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)
  24. 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?
  • Create New...