Jump to content


WFG Programming Team
  • Posts

  • Joined

  • Last visited

  • Days Won


Everything posted by s0600204

  1. At a guess: when the foundation is placed, 0ad chooses a variant from each group based on their frequency, and the end result is a combination of these choices (the mesh is chosen from the first group, texture from the third, and so on). If there is no frequency defined for a variant, then that variant won't ever be chosen. When the units in-game reach the foundation and start building, 0ad switches to the specifically named "scaffold" variant in all the groups that have a variant by that name (if a given group doesn't have a variant by that name, then the output from that group doesn't change). In the unedited 6x6 foundation file wgoyc pasted above, we can see that the second group has both both an "Idle" and a "scaffold" variant. The first has the eyecandy bricks and piles of wood etc, but the latter does not. So when 0ad switches to the "scaffold" variant, all the eyecandy disappears. The edited 6x6 file works because the eyecandy is in a different group which happens to not have a variant with the name "scaffold" and so is not affected by the switch. Essentially, his suggested change based on the 2x2 actor is correct. So just make a patch based on that, and make similar changes to the 8x8 foundation actor.
  2. @wowgetoffyourcellphone The Chinese Imperial Court depicted in your video uses the 8x8 foundation template (which is also bugged in the same way). Looking at your mod's files it appears that all the fortresses, except those built by Carthaginian, Briton or Scythian units, use 6x6. For which, the changes you suggest should work (at least they do for me). (As a further note, I notice you have copies of several foundation actor files in your mod which seem identical to those in 0ad-vanilla.) @stanislas69 Do you feel like creating a patch against 0ad to fix this? (And perhaps sort out the inconsistent indenting in the affected files at the same time?)
  3. Most likely too late to get into A22, but this should solve your problem (I know you already have a copy of this file in your mod): diff --git a/gui/structree/load.js b/gui/structree/load.js index 1559722..a1710a4 100644 --- a/gui/structree/load.js +++ b/gui/structree/load.js @@ -212,6 +212,10 @@ function unravelPhases(techs) phaseList.splice(reqPhasePos+1, 0, myPhase); phaseList.splice(myPhasePos, 1); } + else if (reqPhasePos < 0 && myPhasePos < 0) + // If neither phase is in the list, then add them both to the end + // and hope that later iterations will relocate them if incorrect. + phaseList.push(reqPhase, myPhase); } return phaseList;
  4. The (vanilla 0ad) special/player_gaia template is not set up to inherit from special/player, and thus does not inherit the glory resource's barter multiplier when run in the Delenda Est mod. The template should probably be rewritten so it inherits what it needs. Patch: https://code.wildfiregames.com/D591
  5. Replied to your comment. (In case you hadn't noticed/been otherwise notified.)
  6. D295 (currently waiting on the review and acceptance of D517 (so as to minimise merge conflicts)), splits the Structure Tree code to make it easier to reuse the more generic parts of the Structure Tree code in other gui pages such as (as mentioned as an example in D295's description) adapting the "Civilisation Info" page to load civ/team bonuses, special technologies, heroes, etc. directly from templates which could thus lead to a purging of unnecessary information from {civ}.json files. Or, to put it another way, there are already revisions ready to be reviewed on phabricator that lead (in some way) to the proposed outcome, they just need to be reviewed. Now, admittedly we will very shortly be in feature freeze in preparation for the next alpha release, so merging of D295 will no doubt have to wait until after. But D517, being a bug fix, could make it in, so long as it is reviewed and accepted in time. @wowgetoffyourcellphone: As D517 was created in response to your remarks here, perhaps you would like to review it? Or at least confirm (on phabricator) that it fixes/remedies your problem?
  7. The problem you're having is with code added for D92 (which was literally just committed yesterday evening), that evidently wasn't tested fully. So, y'know, patch.
  8. At least it was a fairly recent old release (Debian (stable) users get A17 (released Oct 2014) unless they explicitly include the backports repo...)
  9. Congratulations. There are a couple dozen people playing online in the A21 lobby currently. Try some of the mods? Argue on the forums about game balancing? Share your secrets for success against the AI? Explore any maps you haven't played on? Up to you. And welcome to the community.
  10. Applicable ticket: http://trac.wildfiregames.com/ticket/643 And some previous discussion on the matter: https://wildfiregames.com/forum/index.php?/topic/17461-gatherer-counts-of-limiting-and-displaying/
  11. Yay! Okay, fair enough. If I may suggest then that you make that clear in the description of the unit in question, as otherwise players might wonder - if they've built everything they can build during the space of a game but never captured a merc camp - where the "Iphicratean Reforms" tech is. While I'm on the subject of clearly marking technology requirements in the gui, are you aware of ticket #3670? I mention it because after playing a little of your mod, I think it may impact you to a greater extent than it would core 0ad, and I'd like to get it right. Anyhow, back on topic (slightly), although the structree can be coded to work around every unit having a ProductionQueue component (but no actual entities listed within), I would think that there'd be a (admittedly tiny) performance hit in-game from such an approach. YMMV.
  12. Okay, been looking into this. The below is based on the code currently on the HEAD of the master branch of your GitHub repo. I've assumed you've modified all the relevant requirements' to take into account the modified entity requirement. I've also only looked at the structree (for now). Anyhow: The biggest problem is that your repo's copy of the globalscripts/Templates.js file is out of date. Don't remove it, instead replace with a copy from 0AD core, as... In your new copy, replace line 370 with ret.cost[type] = template.cost && template.cost[type] ? +template.cost[type] : 0; so as to prevent errors about your glory resource not being mentioned in your techs' cost requirement Other problems that cause errors: The `athen_champion_marine` unit requires a technology (`mercenaries/athen_reforms`) that can only be researched by the `merc_camp_egyptian` structure, which cannot be built by any Athenian unit. The structree doesn't like this. The mauryan (indian) shipyard (not dock) has the ability to research the `celts/health_warship_oceanic_transports` tech. Or, it would, except that this tech requires the `celt/unlock_warships` tech which cannot be researched at or by any entity trainable/buildable by the Indians. Again, the structree doesn't like this. There are a couple of things that you do, that core doesn't, namely: Instead of putting requirements of a pair tech in the `pair_{foo}.json` file of that pair, you put them inside the techs of that pair, which is a little repetitive. You've added the production component to every unit, causing the structree to think that every unit can either train a unit or research a technology. Right. Now to have look around in-game. Edit: After playing around a bit in-game, yeah it seems like it was most likely the out-of-date globalscript file as I didn't get any error messages. That said, the structree makes a few assumptions it shouldn't, so ticket.
  13. First draft: http://trac.wildfiregames.com/wiki/ModdingResources Try
  14. Unless things have changed recently, the creation of wiki pages on trac is still restricted to trac admins. If one of them would like to create a page (perhaps linking to it somewhere on the "Modding Guide" page) the "scripting notes" in the readme of the original resource_agnostic mod (https://github.com/0ADMods/resource_agnostic#scripting-notes) could be used as a starting point, albeit with a few alterations (the "To Remove a Resource" instructions are wrong). I'm busy with work for the next week or so, but if no-one else has done it by then I'll look into amending the instructions to match the current implementation. But I'll need the page created first... Edit: feneur has very generously granted me the permissions on trac to create wiki pages. So unless someone beats me to it, I'll get a wiki page written and up within the next week or two.
  15. Some time ago I wrote a patch that altered the ResourceTrickle component to allow the option of limiting the trickle rate by the percentage of territory controlled by the player. Essentially, the more territory lay within a player's territory borders, the faster the trickle rate. I'm not suggesting that a territory-limited-trickle should be added to houses, but perhaps on a CC, market or palace... It was never committed, but for those interested, it can be found on trac: http://trac.wildfiregames.com/ticket/3321 (it's the second attachment, and might need rebasing)
  16. Waiting for A21. And zophim to reveal more about his plans for Aristeia.

  17. I've pushed a couple of commits to the repo on GitHub. As long as you're comfortable acquiring the mod from there, Aristeia should (heh) work with the current A20 release without any problems. That's alright. I'm a terrible artist. We all have things we struggle with. I don't mind doing the scripting so long as I have a clear idea of what the end result should be. The list of proposed civs for the mod, along with the current design documents, can be found here. Sometime ago I implemented the scripting side of the New Kingdom Egyptian civ as close to the design documentation as I could (at the time). All that's left to do there IMO is the art/texturing/etc. I was considering starting to implement the scripting for... uh... the Assyrians, I think... but then @Zophim (author of the design docs) posted this so I elected to wait. And that was a year ago. He does say that he encourages the research into and collection of information regarding the civs. So if there's a civ on the above list that you wish to research... go for it.
  18. 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.)
  19. Ponies Ascendant has been updated on GitHub so that it works with the recent A20 release of 0AD. Download and enjoy!
  20. Prepping for christmas with family. And keeping an eye on IRC.

  21. 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.
  22. 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.
  23. Helping update various mods to work with A19

  24. 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)
  • Create New...