Borders

User avatar
Dunam
Posts: 113
Joined: Tue Apr 30, 2013 11:55 pm

Re: Borders

Post by Dunam » Sat May 25, 2013 4:28 pm

Are you sure it doesn't mean that expansion is slowed by different type land than the village, but never by forest.

I don't think this code has any of its constants explained, it's just the mechanics.

I don't know C# though so I'm doing educated guesses.

User avatar
VDZ
Posts: 31
Joined: Wed May 22, 2013 8:27 am

Re: Borders

Post by VDZ » Sat May 25, 2013 4:41 pm

Dunam wrote:Are you sure it doesn't mean that expansion is slowed by different type land than the village, but never by forest.

I don't think this code has any of its constants explained, it's just the mechanics.

I don't know C# though so I'm doing educated guesses.
Nope, though it's understandable why you'd think that.
if (patch.Type != this.Civilization.CivilizationType)
{
[code to raise num depending on terrain type, excluding forest]
}
else
{
[give discount]
}
This code means two things:
1. If the terrain type is the same as the village's base type, it gets the growth discount. (The else clause.)
2. If not, raise its expansion cost dependent on the terrain type. (The switch block.)

If a desert village would expand onto forest terrain, it would not get the different terrain penalty; however, it would miss the same type growth discount. It will expand onto forest more easily than onto swamp, but not as easily as expanding onto desert.

I did make a slight mistake in my previous post, though; forest expanding faster applies only to non-Forest villages expanding over Forest terrain; a Forest village grows as quickly over Forest terrain as a Desert village grows over Desert terrain.

coanda
Posts: 54
Joined: Wed May 22, 2013 3:46 am

Re: Borders

Post by coanda » Sat May 25, 2013 4:52 pm

Glancing over that code indicates to me that villages are really danger-averse in growing - unless there's a lot of unnecessary 0-valued parameters in there, villages don't grow when threatened and they tend to avoid dangerous tiles when deciding whether to expand left or right.

They also prefer to expand steadily on each side, but will expand on just one side at a time if the terrain on the other side is too expensive. Swamp, desert, mountain, and ocean all have specific additional costs associated with expansion onto them if not of the correct village type, and expansion onto your village-type's terrain has a discount.

This might be an argument for removing the danger from your villages if they're basically done growing for a while - then they can expand borders a bit more easily before you start growing them again.

The big parameter of interest, of course, is in this.parameters.ReachPointsPerSecond. No idea what, if anything, might impact how that is set... but it is the base multiplier by which all this expansion is growing.

Kalil
Posts: 45
Joined: Wed May 22, 2013 6:22 am

Re: Borders

Post by Kalil » Sun May 26, 2013 12:47 am

VDZ wrote:The code for growth is very complicated (and uses a lot of local variables, making it really difficult to read if you don't have the real source code). Here's the relevant decompiled code for people who can read C#, though you'll find it hard to read even if you use C# frequently.

The growth algorithm checks the tile right next to the border (the one it's trying to expand to). Tiles of a different type than the village's base type (any type, including ocean and mountain) slow the city's growth (or rather, it grows easier on tiles of the village's base type).

Expansion over non-Forest terrain also seems slower than other terrains.

Other than that, the algorithm seems to be including everything but the kitchen sink in a complicated calculation I can't bring myself to decipher.
Ooooh, thank you very much. I'll poke around that and see if I can decipher it.

ollj
Posts: 53
Joined: Fri May 24, 2013 12:38 am

Re: Borders

Post by ollj » Sun May 26, 2013 7:35 pm

This shows:

from the Tick() function wich influences a cities growdth but barely its border expansion via GrowReach():
- food wealth and tech grow (and theres a speed cap for all of these) but they dont seem to inflience border growth
- greed may grow but it doesnt seem to influence border growth.
- "toxitixy" influences a cities growdth but not its border growdth
- theres a limiting cap called "IrresponsibilityCap" that limits a cities growdth but not its border growdth

these are itnerestring, they are definitely related to city border growth, from the GrowReach() funtion (in combination with the Tick() functions values):
- while a city is in panic over dangeous animals its borders can cease to grow for a while.
- while a city is sucessfully destroying dangerous animals, its borders can increase faster.
- "disrupted" orand "struggling" cities will lose reach points, preventing border growdth for a while. may mean theres a hostile/dangerous city border touching the border of this city. may mean damaged cities stop growing.
- swamp desert ocean and mountain each have independent values for their cost to expand over. they seem to be the same for all city types.
- there is a discount for expanding cost if the groundtype is the same type as the city type (this never counts for oceand or mountains since theres no city of that type)
- there is a factor/discount for expanding cost if there is a plant on it and no danger on it.
- there is a factor/discount for expanding cost if there is a animal on it and no danger on it.
- the left border can exmapnd independently from the right border. the left border has priority, except if the right one can be bought cheaper while the left one is still too expensive.

---

And that soource code segment doesnt even say what the ComputeBuyValue() function does.

apparently a city computes the "buy value" of the tiles left and right outside its borders.
A city also has a given number of "reachpoints" that can be spend to expand to the tiles outside the border. it checks the "left" side first, but thats a relative direction.

---

oh nice i never thought of cecompiling it. yeah its seems to be created with a similar tool that Terraria was created with, theres tools to get to the assets and code of it.

User avatar
VDZ
Posts: 31
Joined: Wed May 22, 2013 8:27 am

Re: Borders

Post by VDZ » Sun May 26, 2013 9:52 pm

ollj wrote:oh nice i never thought of cecompiling it. yeah its seems to be created with a similar tool that Terraria was created with, theres tools to get to the assets and code of it.
Correct, both Reus and Terraria were made in C# using XNA. All C# code can be decompiled, usually into perfectly readable code that's relatively easy to recompile. Reus doesn't seem to decompile properly, though, with code like this appearing:
public string ᭇ�哈䘂೒墅ގ(string 쒮幢杘觨䱕깮둴胂)
{
return 䨳ⴵ栈Ȋክ驢냲.턴㛹唌ᴢ醣覐ἀ(this.㫦䵮鷭쪎䷕뜕, 등꺎쵪㘎嫘氒쥕䅖.䗰냕̓Ƴj璣(new object[]
{
齤ີ裹陋.ꃛ툵絼ﴨ퐥䣜<string>(2022006464u, 7183938448009086467uL),
깇l䕯ꓲ�䮝쬿.鵭䉹䗝ب폟௾輸潥().ToFileTime(),
쒮幢杘觨䱕깮둴胂,
꣪邞鴔魒ߒ⦽䦠�.㠮ﲁ冤ꈹ൜룬�<string>(1449865289u, 13471180854884973984uL)
}));
}
Not sure if it's because I'm using an outdated tool or because Reus just does some weird stuff internally. Terraria was a lot easier to mod. As it is now, I can't even compile Reus until I take the time to figure out what goes wrong. Reus also stores some actual data in XNB format (things like the ReachExpandSwampCost), which I'll never be able to access unless someone wrote a tool that can do it for me. I'm a programmer, not a cracker, so my reverse engineering skills are script kiddy-level.

yatima2975
Posts: 32
Joined: Mon May 20, 2013 11:18 pm

Re: Borders

Post by yatima2975 » Mon May 27, 2013 12:52 am

VDZ wrote:Reus doesn't seem to decompile properly, though, with code like this appearing:
public string ᭇ�哈䘂೒墅ގ(string 쒮幢杘觨䱕깮둴胂)
Not sure if it's because I'm using an outdated tool or because Reus just does some weird stuff internally.
Try using the De4Dot extension to Telerik's JustDecompile (it has a 'Clean Obfuscation function'), I've had reasonable results with that, especially if you use it together with dotPeek. The code becomes readable, but not yet compilable.
VDZ wrote: Terraria was a lot easier to mod. As it is now, I can't even compile Reus until I take the time to figure out what goes wrong. Reus also stores some actual data in XNB format (things like the ReachExpandSwampCost), which I'll never be able to access unless someone wrote a tool that can do it for me. I'm a programmer, not a cracker, so my reverse engineering skills are script kiddy-level.
I have written an elementary xnb dumper for Reus, which gives me the various parameters. You can see my raw code here (I'm sure you'll know what to do with it): http://pastebin.com/2jb8vqna. It doesn't recurse into the plants and such yet, but for determining growth it'll do. I'm writing a standalone village simulator, just to get to know the code :-)

Post Reply