Page 1 of 2

Bugs? Yes? No? Maybe? ;)

PostPosted: 12 Jan 2013, 01:02
by The Dark Lord
Today I finally played a game again and I enjoyed it despite getting 'raped by sado' ( :mrgreen: ), but there are two things I would like to discuss with you. I uploaded the replay so you can take a look: http://dc194.2shared.com/download/d08g- ... 3-639c7753

(I couldn't attach it to this post, because 'the board attachment quota has been reached'.)


1. Mining

Please look at my iron mines (I'm playing as black in the top right corner) and the iron mountain at the very top, around 37-38 minutes. You will see the tiles changing in that mountain. What's happening? One of the iron mines at the mountain below this one has extended its boundaries. The poor miner is mining all the way in the mountain at the top! Now, should this be possible?
I knew it worked this way in original TPR, but I'm not sure if that was the right way.

2. Deliveries

We already discussed this on TeamSpeak, and yes, maybe I didn't have enough serfs, maybe I shouldn't build too much at the same time... But please look at my gold smelters from minute 47 and onwards. You will notice serfs passing by with coal. And they're bringing it all the way to the iron production. That would make sense, because I didn't have enough coal mines in production yet... But they just ignore the metallurgists' while they are way closer. And later on they even bring coal from the left side to the metallurgists'. Adjusting the distribution of wares barely helped.
Now of course this was also my mistake, but I thought there was some sort of 'maximum number of tiles' in which serfs shouldn't have preferences in deliveries, but I would think the distance between the coal mines in the east and my iron production would exceed that number.

3. (I just added this one when I closed the replay) The statistics seem messed up, the number of recruited soldiers does not correspond with the graph.

Re: Bugs? Yes? No? Maybe? ;)

PostPosted: 12 Jan 2013, 02:20
by Lewin
1. Mining:
That's how it worked in TPR too. Iron/gold mining works similarly to coal mining, they take a small amount from a large radius and take everything from a small radius. We could possibly change this to only mine within a connected hill, but this could effect the balance of maps that use this (if there are any) plus it would be complicated to implement efficiently. I don't really think it's a big issue.

2. Deliveries:
Well I saw a few coal going past your smelters, but not that much and soon after they seemed to be taking all the coal there from the closest coal field. It was probably due the delay between the serf deciding what job to do and him finishing the job. For example at the time he chose to take the coal somewhere else, the smelter might have had a lot of coal in his input already (serfs prefer to deliver to houses with less of the resource in the input already). This is probably also why adjusting the distribution of wares didn't seem to have an effect, because it will take a few minutes before you really start to notice the effect of it. Remember that a serf decides what he will do when he first takes the job (after finishing the last one) so he then has to walk to the source house and then deliver the resource, that adds up to quite a delay. I guess we could make the serf recalculate the best destination for the resource after he collects it, but that has its own complications because multiple serfs could try to do the same job (that's solved at the moment by the serf deciding on the job at the start and "locking it" so others don't take it)
There isn't actually a maximum number of tiles that the serfs won't care about distances, they always care about distances, but distance can be prioritized lower than other things. For example, if your gold smelter had 3 coal and your iron smelter had 0 coal, then a serf would take the coal to the iron smelter IF the distance between them was <~60 tiles (each extra resource = 20 tiles). So basically:
Weighting = DistanceBetweenHouses + 20*NumberOfResourceInInputAlready
The delivery with the lowest weighting wins (NOTE: This is not the complete formula, there are lots of other factors too) Maybe 20 is a bit too high, we could reduce it to 15 or so because walking an extra 20 tiles is quite a lot just because of 1 extra resource in a house. What do you think?

3. Statistics:
I'm not sure what you mean. The Army graph shows the number of soldiers alive at that moment in time. The "soldiers equipped" stat shows the total number of soldiers equipped over the entire game. If you didn't lose any soldiers then the graph at the end would equal the "soldiers equipped" but because you lost soldiers (and trained new ones) the graph and stat will never match up.

On another note:
Do you think the "citizens" graph should ignore recruits? Currently it's quite misleading since everybody "loses" a lot of citizens after PT when they are converted into soldiers. But maybe we'd also need to change the "citizens trained/lost" stats to ignore recruits too, since otherwise the graph and stats would be very different. What do you think?

Re: Bugs? Yes? No? Maybe? ;)

PostPosted: 12 Jan 2013, 10:22
by The Dark Lord
1. Mining:
That's how it worked in TPR too. Iron/gold mining works similarly to coal mining, they take a small amount from a large radius and take everything from a small radius. We could possibly change this to only mine within a connected hill, but this could effect the balance of maps that use this (if there are any) plus it would be complicated to implement efficiently. I don't really think it's a big issue.
I don't think it's a big issue either, but the editor in Remake suggests you can only mine from a mountain the iron mine is connected to because it is showing the amount of iron in a mountain. Maybe it should show how much can be mined at a certain spot (although that would cause difficulties if you havel ike 4-5-6 tiles next to each other where you can build an iron mine...).
2. Deliveries:
Well I saw a few coal going past your smelters, but not that much and soon after they seemed to be taking all the coal there from the closest coal field. It was probably due the delay between the serf deciding what job to do and him finishing the job. For example at the time he chose to take the coal somewhere else, the smelter might have had a lot of coal in his input already (serfs prefer to deliver to houses with less of the resource in the input already). This is probably also why adjusting the distribution of wares didn't seem to have an effect, because it will take a few minutes before you really start to notice the effect of it. Remember that a serf decides what he will do when he first takes the job (after finishing the last one) so he then has to walk to the source house and then deliver the resource, that adds up to quite a delay. I guess we could make the serf recalculate the best destination for the resource after he collects it, but that has its own complications because multiple serfs could try to do the same job (that's solved at the moment by the serf deciding on the job at the start and "locking it" so others don't take it)
There isn't actually a maximum number of tiles that the serfs won't care about distances, they always care about distances, but distance can be prioritized lower than other things. For example, if your gold smelter had 3 coal and your iron smelter had 0 coal, then a serf would take the coal to the iron smelter IF the distance between them was <~60 tiles (each extra resource = 20 tiles). So basically:
Weighting = DistanceBetweenHouses + 20*NumberOfResourceInInputAlready
The delivery with the lowest weighting wins (NOTE: This is not the complete formula, there are lots of other factors too) Maybe 20 is a bit too high, we could reduce it to 15 or so because walking an extra 20 tiles is quite a lot just because of 1 extra resource in a house. What do you think?
Well the distance between the houses was actually really large so it is still a mystery to me, especially since the number of resources in input was 0 or 1 at the metallurgists'. And I even had more coal mines than smelters on that side. Can you show me the complete formula?
3. Statistics:
I'm not sure what you mean. The Army graph shows the number of soldiers alive at that moment in time. The "soldiers equipped" stat shows the total number of soldiers equipped over the entire game. If you didn't lose any soldiers then the graph at the end would equal the "soldiers equipped" but because you lost soldiers (and trained new ones) the graph and stat will never match up.
I'm aware what the graph shows, but I thought... Oh well, I checked it again and I guess I saw ghosts... :P
On another note:
Do you think the "citizens" graph should ignore recruits? Currently it's quite misleading since everybody "loses" a lot of citizens after PT when they are converted into soldiers. But maybe we'd also need to change the "citizens trained/lost" stats to ignore recruits too, since otherwise the graph and stats would be very different. What do you think?
Yes I think recruits should be ignored. Otherwise they are counted twice (because recruit --> soldier obviously). I think I already suggested something like this when the 'new' statistics were added. ;)

Re: Bugs? Yes? No? Maybe? ;)

PostPosted: 12 Jan 2013, 10:24
by pawel95
To 1.) and 3.) I think Lewin has said everything :P

So I want only say to point 2.) something. I think this is a problem,too.
I had some games, that NO serf came to my metallurgist for about 25 minutes. I know that i had less serfs, but i hadn´t gold to make more. This problem can be splitted up in two things:

1.) Its still a small (it was bigger in older releases) problem that when you build your metallurgist near your goldore and your coal is far away...

AND

2.)....you have too less of serfs, they will bring "often" coal only to the iron buildings.

However for example in my game, the only solution was to set the coal setting up to "0" for all buildings expected the metallurgist. So it is for me 100% depending on the distance from the buildings.


To that:

Maybe this problem with "too less serfs" would be fixed,when the serfs work otherwise. You know, I have seen it some times that in TPR the serfs are working like: "Ok, I am going to bring my timber to the sawmill and there will be finished a wood and this wood i will take, when I am there"

In the Remake it works little bit different: "Ok, I am going to bring my timber to the sawmill but there isnt any wood finished, so I will go to bring bread from storehouse to the inn" :D

Maybe it´s only my feeling, but i think that it is really so. I have seen it 100 times in the Remake,that one serf is going from 2 kilometers to take the wood,but there was a serfs bringing timber 2 sec ago and he hasnt tak the wood :rolleyes:


And when it should be like in TPR(maybe not the same,because it isn´t that good,too) : Than you wouldnt need that many serfs?!



What do you think about this all?

Re: Bugs? Yes? No? Maybe? ;)

PostPosted: 12 Jan 2013, 11:41
by T*AnTi-V!RuZz
(I couldn't attach it to this post, because 'the board attachment quota has been reached'.)
My bad, sorry :P

Fixed it, so you can now attach it if you want to.

Re: Bugs? Yes? No? Maybe? ;)

PostPosted: 20 Jan 2013, 00:12
by Lewin
I don't think it's a big issue either, but the editor in Remake suggests you can only mine from a mountain the iron mine is connected to because it is showing the amount of iron in a mountain. Maybe it should show how much can be mined at a certain spot (although that would cause difficulties if you havel ike 4-5-6 tiles next to each other where you can build an iron mine...).
I don't think that's important really.
Well the distance between the houses was actually really large so it is still a mystery to me, especially since the number of resources in input was 0 or 1 at the metallurgists'. And I even had more coal mines than smelters on that side. Can you show me the complete formula?
Yeah I agree that the metallurgist did look like the better option, so I think they choose the iron smithy because of the delay (at the time they decided on the delivery the iron smithy was the better choice). Remember that the the house will only request as many resources as you allow it in the distribution of wares, so if it is set on 3 and has 1 coal already, it will request 2 extra coal. Once two serfs have claimed those two coal deliveries, and more coal will be taken the iron smithies until the metallurgist can request more coal. It becomes complex and unpredictable because of the delay in serfs choosing the job and arriving at the source house. And changing the distribution of wares won't always have a noticeable impact until a few minutes later. You can view the "formula" here: (the result of the function CalculateBid is the weight, the lowest weighted delivery is taken)
http://code.google.com/p/castlesand/sou ... ue.pas#625
Yes I think recruits should be ignored. Otherwise they are counted twice (because recruit --> soldier obviously). I think I already suggested something like this when the 'new' statistics were added. ;)
I agree. What about "citizens trained" and "citizens lost"? Should they ignore recruits or not? In KaM they were counted I believe. Which is more interested to look at and compare to other results?
Maybe this problem with "too less serfs" would be fixed,when the serfs work otherwise. You know, I have seen it some times that in TPR the serfs are working like: "Ok, I am going to bring my timber to the sawmill and there will be finished a wood and this wood i will take, when I am there"

In the Remake it works little bit different: "Ok, I am going to bring my timber to the sawmill but there isnt any wood finished, so I will go to bring bread from storehouse to the inn" :D

Maybe it´s only my feeling, but i think that it is really so. I have seen it 100 times in the Remake,that one serf is going from 2 kilometers to take the wood,but there was a serfs bringing timber 2 sec ago and he hasnt tak the wood :rolleyes:


And when it should be like in TPR(maybe not the same,because it isn´t that good,too) : Than you wouldnt need that many serfs?!
The serfs WILL take a resource out when they go in, but they will only do so if another serf has not claimed that job. A good change to make would be for the serf to claim/lock the wood before arriving at the sawmill so no other serf takes that job. In most cases that would be far more efficient than some other serf doing it. I've added it to the todo list.

Re: Bugs? Yes? No? Maybe? ;)

PostPosted: 20 Jan 2013, 22:37
by H.A.H.
Perhaps it can be solved by an easier algorithm: allow serfs to swap jobs if the overal efficiency is higher.

For instance, serf A goes from the Woodcutters to the Sawmill, and serf B goes to the Sawmill to pick up wood to bring to the Weaponmaker.
After serf A has exited the Woodcutters, he will go to the farm to pick up corn to deliver in the storehouse.

However, serf B at that time is more near the farm and, as stated, serf A is very close to the sawmill. It is therefore more efficient to swap the two tasks, and let serf A perform the task of serf B and vice versa.

So instead of:

1. Finish job
2. Look for most efficient job
3. Perform most efficient job
4. Go to 1.

Do:

1. Finish job
2. Look for most efficient job
3. Look for most efficient job performed by other serfs
4. If we swap jobs with most efficient job performed by other serfs, will it be more efficient overal than we picking our most efficient job and other serf continue his?
5. Perform the now most efficient job.
6. Go to 1.

Re: Bugs? Yes? No? Maybe? ;)

PostPosted: 21 Jan 2013, 05:45
by Krom
Everything sounds good, but our main reason to not implement it was something else. We did not wanted to make serfs stopping on their way, or even worse - reversing if they pick another job.

Re: Bugs? Yes? No? Maybe? ;)

PostPosted: 21 Jan 2013, 06:10
by Lewin
Everything sounds good, but our main reason to not implement it was something else. We did not wanted to make serfs stopping on their way, or even worse - reversing if they pick another job.
Yeah, it would look odd to the player if the serf suddenly stops walking for no obvious reason, or if they start walking the other way. I can already see the flood of emails: "The new release is buggy, serfs forget what they are doing all the time!" :P

Re: Bugs? Yes? No? Maybe? ;)

PostPosted: 21 Jan 2013, 16:46
by pawel95
Everything sounds good, but our main reason to not implement it was something else. We did not wanted to make serfs stopping on their way, or even worse - reversing if they pick another job.
Yeah, it would look odd to the player if the serf suddenly stops walking for no obvious reason, or if they start walking the other way. I can already see the flood of emails: "The new release is buggy, serfs forget what they are doing all the time!" :P

Well yeah, that is a good point against my Idea. I have seen this often in TPR i think,that they walked like through the whole city and stopping than 10 meters before their finish :D

Re: Bugs? Yes? No? Maybe? ;)

PostPosted: 18 Feb 2013, 03:17
by H.A.H.
Include a constraint that serfs may not change direction in 180 degrees. Or include a think-cloud of the question mark, to show the player that the serf is confused. (I could enjoy seeing confused serfs turning 180 degrees. It reminds me of myself walking on street, when I make such same turn, and think that I must look retarded.)
The serfs WILL take a resource out when they go in, but they will only do so if another serf has not claimed that job. A good change to make would be for the serf to claim/lock the wood before arriving at the sawmill so no other serf takes that job. In most cases that would be far more efficient than some other serf doing it. I've added it to the todo list.
What will happen in the few odd cases in which it is more efficient when the other serf does it?

Another idea (off-topic) is that builders or other citizens near enemy towers could display a think-cloud with the same icon as very-hungry troops, when they are not allowed to enter the "danger"-zone of the enemies tower. This helps the player understand that the civilian is scared.

Re: Bugs? Yes? No? Maybe? ;)

PostPosted: 18 Feb 2013, 09:14
by FeyBart
(...)
Another idea (off-topic) is that builders or other citizens near enemy towers could display a think-cloud with the same icon as very-hungry troops, when they are not allowed to enter the "danger"-zone of the enemies tower. This helps the player understand that the civilian is scared.
As in "oh noes! I'll be tower food!"? :p

Anyway, I think we already had that idea in another topic about builder rushes.

Re: Bugs? Yes? No? Maybe? ;)

PostPosted: 18 Feb 2013, 11:33
by dicsoupcan
Or instead of the i am going to starve skull someone can try to make a ''being scared'' smiley to prevent confusion :P

Re: Bugs? Yes? No? Maybe? ;)

PostPosted: 18 Feb 2013, 11:47
by FeyBart
Or instead of the i am going to starve skull someone can try to make a ''being scared'' smiley to prevent confusion :P
I'm not sure what you mean?

Re: Bugs? Yes? No? Maybe? ;)

PostPosted: 18 Feb 2013, 12:06
by Lewin
Include a constraint that serfs may not change direction in 180 degrees.
That's pretty complicated to implement (since there can be 100s of serfs and 1000s of potential jobs calculating the route is done last because it's slow), and won't result in much improvement because only a few serfs could actually exchange jobs with a few other serfs. I don't think it's that important.
What will happen in the few odd cases in which it is more efficient when the other serf does it?
The only case where that is true is when you have too many serfs so there are always enough idle ones around. IMO it doesn't matter because it would only mean the delivery is slightly delayed until the serf arrives to drop something off. And if there's more than one item all the others can be taken, they should just reserve one for the serf dropping something off.
Another idea (off-topic) is that builders or other citizens near enemy towers could display a think-cloud with the same icon as very-hungry troops, when they are not allowed to enter the "danger"-zone of the enemies tower. This helps the player understand that the civilian is scared.
But why does the player need to understand that the civilian is scared?
This could be potentially useful for stopping player's using labourers to empty towers, they refuse to walk into range of the tower and show a thought bubble. But if none of your labourers will walk there which one should show the bubble? It's kind of odd if one random labourers shows a scared thought bubble because you ordered something to be built in range of a tower, that doesn't really help the player understand because the laborer could be miles away.