I think you said something like this a couple months ago. I've had this new global define laying around for a while. It allows someone to set a starting era for the water animal spawns.
I've got another that does the spawning part of Raxo's No Limits mod.
I think you said something like this a couple months ago. I've had this new global define laying around for a while. It allows someone to set a starting era for the water animal spawns.
I've got another that does the spawning part of Raxo's No Limits mod.
@SO In the Hunting Review I posted what I wanted to do with Sea Critters. Basically it makes it so ships and sea critters can't interact with each other and more and more as time goes on the sea critters become invisible to the player. This is done by introducing some promotions and a line of ships that can see and be affected by sea critters. When that happens the spawn rates could be reduced by using the density parameters better.
Small sea critters (cod, tuna) become "invisible" (ie can't be seen and can't interact with ships) at the tech that provides trireme or galley.
Medium sea critters become "invisible" at Galleon
Large sea critters become invisible at Oil based ships.
The Kraken is always visible.
@everyone There are a number of places where we have in place a working feature which is basically awaiting a use review before more work on it can be done. Two important ones are
Unit Spawning.
The queue function I always forget the name of which allows you to queue things you have not even had the chance to discover yet.
The second has always mystified me and I have never managed to get it to work. It turns out, from watching a Let's Play, that I have never waited long enough.
A simple fix to this may be to default to showing only things from the era you are in but allow the player to set what they want to be the default in future games. Also what their preferences are for the rest of this game. Which, naturally, are different things.
Based on discussions here and elsewhere there are a number of problems with the Unit Spawn XML.
The first and biggest is that it is based on dates and it is next to impossible to get dates to match a C2C game play state.Yes we still need dates but it would be useful to have "game era" or "someone gets tech x" as well.
The details of how often a unit is spawned can be finely tuned but this can be a problem as well. Yes we still need to be able to specify how many (density) should spawn in an area - once that number is reached no more spawn until some move out or are killed. The other chance factors may be too fine for our use. Perhaps the old Dungeons&Dragons values of Common, Uncommon, Rare etc would be better. A "Unique" may also be better.
Where a unit spawns - region of the map. Currently most animals are assigned one or two regions on the historic Earth and assigned there with a few special animals limited to special co-ordinates. The problem with that is that what we did is we split the world into 6 regions by co-ordinates and used that. This does not work if the map is not just the whole world.
Where a unit spawns - environment. We do use this but on random maps these may not match up with the regions specified. This is only a minor issue as it provides a good bit of variation between games.
Terrain and its features don't affect spawn rates. There is a Natural Wonder that is supposed to increase the spawn rate (density) in its neighbour hood but there is no mechanism that works, I have tried.
Based on discussions here and elsewhere there are a number of problems with the Unit Spawn XML.
The first and biggest is that it is based on dates and it is next to impossible to get dates to match a C2C game play state.Yes we still need dates but it would be useful to have "game era" or "someone gets tech x" as well.
The details of how often a unit is spawned can be finely tuned but this can be a problem as well. Yes we still need to be able to specify how many (density) should spawn in an area - once that number is reached no more spawn until some move out or are killed. The other chance factors may be too fine for our use. Perhaps the old Dungeons&Dragons values of Common, Uncommon, Rare etc would be better. A "Unique" may also be better.
Where a unit spawns - region of the map. Currently most animals are assigned one or two regions on the historic Earth and assigned there with a few special animals limited to special co-ordinates. The problem with that is that what we did is we split the world into 6 regions by co-ordinates and used that. This does not work if the map is not just the whole world.
Where a unit spawns - environment. We do use this but on random maps these may not match up with the regions specified. This is only a minor issue as it provides a good bit of variation between games.
Terrain and its features don't affect spawn rates. There is a Natural Wonder that is supposed to increase the spawn rate (density) in its neighbour hood but there is no mechanism that works, I have tried.
1. FWIW I strongly disagree with spawn rates being based on dates or eras. But I do think the game would benefit from knowing what era it's in. This is simply the era of the tech leader, therefore if the runaway tech leader (think Rome) is eliminated, the game era may go 'backwards'.
2. Very good point. Spawn rates should very much be affected by how many of the critter have already spawned in the area and are still there. If there are any real problems with spawn rates, this alone will probably fix them.
3. Such maps are currently scenarios, so that makes this issue one for scenario creators to deal with.
4. Strongly agree. I have grown to love this variation.
5. Nice to have, but I'm confident if point 2. above is implemented, the failure to get this working will look like much less of a problem.
Based on discussions here and elsewhere there are a number of problems with the Unit Spawn XML.
1. The first and biggest is that it is based on dates and it is next to impossible to get dates to match a C2C game play state.Yes we still need dates but it would be useful to have "game era" or "someone gets tech x" as well.
2. The details of how often a unit is spawned can be finely tuned but this can be a problem as well. Yes we still need to be able to specify how many (density) should spawn in an area - once that number is reached no more spawn until some move out or are killed. The other chance factors may be too fine for our use. Perhaps the old Dungeons&Dragons values of Common, Uncommon, Rare etc would be better. A "Unique" may also be better.
We could use <iMaxAreaTotalDensity>X</iMaxAreaTotalDensity> more.
How it works in code:
if ( "number of plots in area" / "number of units of any kind owned by this player in area" < iMaxAreaTotalDensity ) {
Do not spawn any more units of this kind for this player this turn.
}
We also have <iMaxAreaUnitDensity>X</iMaxAreaUnitDensity> which almost does the same, but it only counts units of the same type as it is going to spawn, and it doesn't care which player owns the units in question.
We also have <iMaxLocalDensity>X</iMaxLocalDensity> which only check the density within the 49 closest plots belonging to the landmass instead of the entire landmass average density.
This does not consider which player owns the units in question either.
These three tags can all be used harmoniously together for each specific spawn entry to limit unit density through the spawn system.
The first and biggest is that it is based on dates and it is next to impossible to get dates to match a C2C game play state.Yes we still need dates but it would be useful to have "game era" or "someone gets tech x" as well.
1. FWIW I strongly disagree with spawn rates being based on dates or eras. But I do think the game would benefit from knowing what era it's in. This is simply the era of the tech leader, therefore if the runaway tech leader (think Rome) is eliminated, the game era may go 'backwards'.
We could use <iMaxAreaTotalDensity>X</iMaxAreaTotalDensity> more.
How it works in code:
if ( "number of plots in area" / "number of units of any kind owned by this player in area" < iMaxAreaTotalDensity ) {
Do not spawn any more units of this kind for this player this turn.
}
We also have <iMaxAreaUnitDensity>X</iMaxAreaUnitDensity> which almost does the same, but it only counts units of the same type as it is going to spawn, and it doesn't care which player owns the units in question.
We also have <iMaxLocalDensity>X</iMaxLocalDensity> which only check the density within the 49 closest plots belonging to the landmass instead of the entire landmass average density.
This does not consider which player owns the units in question either.
These three tags can all be used harmoniously together for each specific spawn entry to limit unit density through the spawn system.
Hmm... someone was using them quite a bit. I don't fully grasp the density numerics myself but figured whoever was employing them must've had a handle on it.
The original plan was not to define the map for spawning by coordinates but to assign spawns into biome collections instead, and at map generation, each 'area' (continent) would get its own random biome group from which spawns would be defined. We never did set this up so I'm not sure what you thought I was referring to when I used the term biome.
We even began considering a new way to define the biome so it's not just based on the 'area' definition which includes all land in any given landmass, and respectively all water in a given water mass. That way regions could take on more localized properties, split by mountain ranges and other natural barriers rather than purely water divisions alone, thus Africa could differ from North Asia and South Asia and Europe. A concept of choosing some biome origin spots then flooding the map with biome id points and having certain features like peaks require more spillover points from the flooding process to claim the tile and once all tiles were claimed, then affix the biome definition on the plot and get rid of the flood information afterward.
It could be done through a % modifier tag that specifies the spawn category and the era and the % adjustment at the entry to that era, that way wider categories like land animals, neanderthals, barbarians, etc... could be more easily sweepingly adjusted. It would just take a tag like this on erainfos.
1. Added a member to CvGame for current era.
2. Copied off of the AdvancedCiv Mod (or w/e it's called) and removed some of the DllExports. read Anq post somewhere for info.
3. Tiny bit of incomplete junk for DH's idea. Does nothing atm. Is the plan to make a new wonder for that mammoth thing?
1. There is already the wonder ie the Mammoth Trainer. It is a world wonder so there is only one.
2. The valid improvements for stopping the extinction are the hunting camp/preserve line of improvements.
3. Wild Mammoths (and Woolly Rhinos) units, if not on a resource, and the the resource herds get replaced with a "xx graveyard" which is visible and used at Paleontology or when the building becomes available.
4. City herds and map herds inside a nation's border may be saved at great cost reduced by the number of healers in the nation especially healers of animals. Perhaps at this point if a nation without the wonder saves a number of herds (city or map) then they should get a new building that allows them to also have Mammoth units.
It is intended to extend this to other animals as well eg Moa, Elephant Bird, Giant Penguin, Demon Duck of Doom and so on.
Thank you! Very accurate! (I almost forgot to check against pitboss exe, so I once thought there were some misses in your submit, but honestly none.)
I think this dllexport was not dealt with due to no real performance improvement and possibility of modding the exe in the (far?) future. Otherwise I've also merged changes from AdvCiv on my part and checked with Dependency Walker to undo more dllexport's here and there. Not 100% though, a few of them still puzzle me.
1. Added a member to CvGame for current era.
2. Copied off of the AdvancedCiv Mod (or w/e it's called) and removed some of the DllExports. read Anq post somewhere for info.
3. Tiny bit of incomplete junk for DH's idea. Does nothing atm. Is the plan to make a new wonder for that mammoth thing?
Thank you! Very accurate! (I almost forgot to check against pitboss exe, so I once thought there were some misses in your submit, but honestly none.)
I think this dllexport was not dealt with due to no real performance improvement and possibility of modding the exe in the (far?) future. Otherwise I've also merged changes from AdvCiv on my part and checked with Dependency Walker to undo more dllexport's here and there. Not 100% though, a few of them still puzzle me.
Since I don't have a lot of time to review this kind of thing and you seem to know what it is he's talking about, can I finally get you full SVN access so you can update his work on this for us?
Since I don't have a lot of time to review this kind of thing and you seem to know what it is he's talking about, can I finally get you full SVN access so you can update his work on this for us?
Wait a while, I'm going to review once again and make a sourceforge account finally. I'll need to review the diffs once more once I get to the stage to publish my change.
Wait a while, I'm going to review once again and make a sourceforge account finally. I'll need to review the diffs once more once I get to the stage to publish my change.
Hi, I write C++ and Python. I am willing to (attempt to) help with optimization for both of these, and maybe other coding tasks as required. I actually already did submit a tiny optimization patch that I think Thunderbird is testing. I work in the games industry and have been writing C++ for >20 years and Python for a couple. I'm not sure what the experience level of other C++ coders on this project is, but if useful I can help with code review, design advice, debugging etc.
Hi, I write C++ and Python. I am willing to (attempt to) help with optimization for both of these, and maybe other coding tasks as required. I actually already did submit a tiny optimization patch that I think Thunderbird is testing. I work in the games industry and have been writing C++ for >20 years and Python for a couple. I'm not sure what the experience level of other C++ coders on this project is, but if useful I can help with code review, design advice, debugging etc.
Your help would be tremendously appreciated. Some of us have been getting to know you better on Discord and I'm very happy you'd like to join us. Anyone have any objections? (He's really freakin' knowledgeable about the code y'all)
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.