Jump to content

s0600204

WFG Programming Team
 View Profile  See their activity

  • Posts

    264

  • Joined

  • Last visited

  • Days Won

    6

 Content Type 

Posts posted by s0600204

  1. Gatherer counts: of limiting and displaying.

    in Game Development & Technical Discussion

    Posted · Edited by s0600204

    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 resource
    • Fore-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)

  2. Some modding questions

    in Game Modification

    Posted

    Oh yeah, and I looked at the datatypes available for schemas. So there's only positiveInteger and nonNegativeInteger. So is there no way to use a value of -1 anyway, or would I need to use ''text''?

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

  3. Gatherer counts: of limiting and displaying.

    in Game Development & Technical Discussion

    Posted · Edited by s0600204

    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 gatherers
    • Player 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 gatherers
    • Player 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.
    • Like 1

  4. Design: Civillization Name

    in General Discussion

    Posted

    Very nice!

    BTW, s0600204, your progress look awesome! I tried it (with some of my meddling :) ).

    Thanks you, both of you. I still have a way to go, though. :moil:

    It will be a delight to see Han in the Asia category and Kushites in Africa category.

    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.

    Also, does that menu scale downwards? I have a... rather small monitor (vive le no money)

    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.

  5. Design: Civillization Name

    in General Discussion

    Posted

    Work in progress:

    KQFfIhf.pngaVTPEuv.png

    If you'd like to try it then the following should work:

    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.

    Mj02Lij.png
    • This is a button that opens the civ selection dialog for the given player
    • These are buttons that select the group of civs under their respective headings
    • Like 7

  6. Need help, II Phase Broken!

    in 1,000 A.D.

    Posted

    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.
    • Like 1

  7. Need help, II Phase Broken!

    in 1,000 A.D.

    Posted · Edited by s0600204

    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 Village
    Barracks:

    [0ad] template_structure_military_barracks.xmlRequiredTechnology: phase_villageVisibleClasses: Village[millenniumad] norse_barracksRequiredTechnology: phase_townClasses: Town
    So, 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)

  8. Need help, II Phase Broken!

    in 1,000 A.D.

    Posted

    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?

  12. Design: Civillization Name

    in General Discussion

    Posted · Edited by s0600204

    The choice would have shown itself during one of the town/city upgrade phases, and would have affected the hero choices, special structures, and late game technologies.

    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.

    • Like 2

  13. Design: Civillization Name

    in General Discussion

    Posted

    @s0600204 can you work in this proposal?

    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.

    I believe it's just a mockup (originally posted here).

    Ah, thank you.

  14. (Aristeia) Playtest: Egyptians

    in Aristeia

    Posted

    ERROR: CCacheLoader failed to find archived or source file for: "simulation/templates/units/egyptian_champion_swordsman_ramesside.xml"

    ERROR: Failed to load entity template 'units/egyptian_champion_swordsman_ramesside

    Should now be fixed. Thank you for spotting.

    Why the tech tree is not the same as vanilla version?

    Why would it be, we're several centuries before vanilla ;)

    Why is missing the icon toggle off formations?

    Try changing formations/scatter to formations/null in civs/egyptian.json, line 206.

    I make new Icons

    Good.
    • Like 1

  15. Design: Civillization Name

    in General Discussion

    Posted

    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)

  16. (Aristeia) Playtest: Egyptians

    in Aristeia

    Posted · Edited by s0600204

    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.

    xdwXy82.jpg
    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 ;))

    • Like 1

  23. Solved - Trying to make playable Aristeia

    in Aristeia

    Posted

    Lion, could you try changing the contents of simulation/templates/special/player_egyptian.xml to this, please:

    <?xml version="1.0" encoding="utf-8"?><Entity parent="special/player">  <EntityLimits>    <Limits>      <Monument>2</Monument>      <Obelisk>5</Obelisk>      <Sphinx>3</Sphinx>    </Limits>    <LimitChangers>      <Monument>        <RamessesII>2</RamessesII>      </Monument>    </LimitChangers>  </EntityLimits></Entity>
    • Like 1

  24. Whats the real information center about the factions?

    in General Discussion

    Posted · Edited by s0600204

    Actually, the most up to date of the two would be the information available via the civinfo dialog in-game, but neither is particularly accurate. Consider them as an indicator of what will be, rather than what is.

    Ardiosmanae is, as far as I can tell, a concept rather than a technology, and may eventually be seen as higher food gather/production rates for the celt and brit civs from game start. Possibly. But it hasn't been implemented yet.

    Oh, and it has never been implemented as a technology: that was something that was intended as an aura (in r13766) before auras were implemented (in r13998) and has since been corrected.

    Edit: found revisions

    • Like 1
×
×
  • Create New...