EVERGLADES: bugs and suggestions
- Egbert
- Commander
- Posts: 658
- Joined: Tue Sep 03, 2002 7:00 am
- Location: The Scholars' Library (dusty section)
- Contact:
Well, that was interesting. I already had about 20 orders set in advance. Then I put in another order to spy a player "before order #2." It put it there, but then it took some of my other orders, and jumbled them up!!!! Uhhh, I think that's a bug.
Also, here's a suggestion: We now have 1 order that will take up 5 turns and give you 5% Instinct. That's nice, since you are using only 1 order to give commands for 5 turns (for example, you could have had 1 order saying that for 1 turn you get 1% Instinct, but it would have been much less efficient, since you would need 5 orders to get 5% Instinct). Why not have the same order for Hunt? 1 order which would say that you hunt 5x for 5 turns (you can still keep the 1 hunt/ 1 turn order). It would be very efficient, and you can use the 4 extra orders which you are saving for something else.
Also, here's a suggestion: We now have 1 order that will take up 5 turns and give you 5% Instinct. That's nice, since you are using only 1 order to give commands for 5 turns (for example, you could have had 1 order saying that for 1 turn you get 1% Instinct, but it would have been much less efficient, since you would need 5 orders to get 5% Instinct). Why not have the same order for Hunt? 1 order which would say that you hunt 5x for 5 turns (you can still keep the 1 hunt/ 1 turn order). It would be very efficient, and you can use the 4 extra orders which you are saving for something else.
"Fairy tales can come true,
They can happen to you,
If you're young at heart."
They can happen to you,
If you're young at heart."
- Undertaker
- Commander
- Posts: 574
- Joined: Tue Sep 03, 2002 7:00 am
- Location: The Back Room (behind Sharky's place)
- Contact:
5%? I'm only getting 4%, just checked the event log.Egbert wrote:Also, here's a suggestion: We now have 1 order that will take up 5 turns and give you 5% Instinct.
"That's a good question. Let me see...In my case, you know, I hate to advocate drugs or liquor, violence, insanity to anyone. But in my case it's worked." Hunter S. Thompson
- korexus
- Moderator
- Posts: 2832
- Joined: Tue Nov 12, 2002 8:00 am
- Location: Reading
- Contact:
- Egbert
- Commander
- Posts: 658
- Joined: Tue Sep 03, 2002 7:00 am
- Location: The Scholars' Library (dusty section)
- Contact:
Hey, do I have a saturation limit? My turn result says that I got to 3543 (burp), and consumed 42. But the top of my page says I have a saturation of 3500. Is 3500 the max?
Edit: never mind, I am now at 3621 (must have been a rounding error). Gracious, I need to lose weight!
Edit: never mind, I am now at 3621 (must have been a rounding error). Gracious, I need to lose weight!
"Fairy tales can come true,
They can happen to you,
If you're young at heart."
They can happen to you,
If you're young at heart."
- Strider
- Trooper
- Posts: 172
- Joined: Tue Sep 17, 2002 7:00 am
- Location: West Side!
Not sure if this is really a bug at all, just something I noticed today and thought I'd ask:
My turtles have been grazing away in the forest on some very abundant green plants. Those plants just increased in body size over the last cycle! Is this part of evil Al's plan to starve my innocent turtles?
Thank God they've grown some legs to hunt for some more food...
My turtles have been grazing away in the forest on some very abundant green plants. Those plants just increased in body size over the last cycle! Is this part of evil Al's plan to starve my innocent turtles?
Thank God they've grown some legs to hunt for some more food...
Never laugh at live dragons...
- Dameon
- Moderator
- Posts: 1056
- Joined: Tue Sep 03, 2002 7:00 am
- Location: Valn Ohtar Chapterhouse
The plan to change green plants from BS1 to BS2 has been in the works for a bit now, it seems like it was implemented last cycle. It's really necessary to be able to support BS3+, so yeah for that. It does suck you were eating all those green plants before they mutated, but that's part of being in a beta I guess. BTW, what square were those in exactly?
"A Knight is sworn to valor, his heart knows only virtue, his blade defends the helpless, his might upholds the weak, his word speaks only truth, his wrath outdoes the wicked."
- Mullog
- Veteran
- Posts: 330
- Joined: Mon Sep 29, 2003 7:00 am
- Location: Aalesund, Norway (freezing!). Member of the Vulkings
I was afraid that would happen. We increased the body size of green plants so that there would be more food in the map. I am sorry that you had to suffer, but that is the price of advancement I am afraid.Strider wrote:Not sure if this is really a bug at all, just something I noticed today and thought I'd ask:
My turtles have been grazing away in the forest on some very abundant green plants. Those plants just increased in body size over the last cycle! Is this part of evil Al's plan to starve my innocent turtles?
Thank God they've grown some legs to hunt for some more food...
Mullog
Quidquid latine dictum sit, altum sonatur.
- Whatever is said in Latin sounds profound.
- Whatever is said in Latin sounds profound.
- Hamster
- Recruit
- Posts: 60
- Joined: Tue Mar 23, 2004 8:00 am
- Location: Osijek, Croatia
After deleting some orders I got the remaining orders in a strange sort. Seems some stuff inside the queue is messed up when deleting. I'm not sure what is the shortest way to reproduce the BUG, especially because I also tried to insert an order while the queue was full (so maybe it causes the BUG).Egbert wrote:Well, that was interesting. I already had about 20 orders set in advance. Then I put in another order to spy a player "before order #2." It put it there, but then it took some of my other orders, and jumbled them up!!!! Uhhh, I think that's a bug.
Hope you're not messing with the ID field when inserting/arranging orders in the queue and because of this the MAX_ID error in sp_orders appear sometimes. Or is this error also because of the same BUG mentioned above?
There are 10 types of people in this world.
Those who understand binary numbers and those who don't.
Those who understand binary numbers and those who don't.
- Undertaker
- Commander
- Posts: 574
- Joined: Tue Sep 03, 2002 7:00 am
- Location: The Back Room (behind Sharky's place)
- Contact:
Next time please notify us before you make that change. I will starve shortly. I had 2600 plants at my disposal, now I have none.Mullog wrote: I was afraid that would happen. We increased the body size of green plants so that there would be more food in the map. I am sorry that you had to suffer, but that is the price of advancement I am afraid.
Mullog
"That's a good question. Let me see...In my case, you know, I hate to advocate drugs or liquor, violence, insanity to anyone. But in my case it's worked." Hunter S. Thompson
- korexus
- Moderator
- Posts: 2832
- Joined: Tue Nov 12, 2002 8:00 am
- Location: Reading
- Contact:
- Undertaker
- Commander
- Posts: 574
- Joined: Tue Sep 03, 2002 7:00 am
- Location: The Back Room (behind Sharky's place)
- Contact:
It would be nice if spying told you the plant size, not just color. If you can "see" what color it is you should be able to see the size as well.
Or I could be off target and color determines size.
Or I could be off target and color determines size.
"That's a good question. Let me see...In my case, you know, I hate to advocate drugs or liquor, violence, insanity to anyone. But in my case it's worked." Hunter S. Thompson
- Dameon
- Moderator
- Posts: 1056
- Joined: Tue Sep 03, 2002 7:00 am
- Location: Valn Ohtar Chapterhouse
Color does determine size. White, yellow, and red are size 1. Green and blue are size 2. Grey is 3, and black is 4. These, and other things are all covered in a player's manual I have written with help from Kor and Mullog that is currently pending final review by Al- I imagine it will be out shortly. Oh, and if you want to message to me in game where those green plants are, I am sitting on a square of 4000+ red plants that I wouldn't mind exchanging with you if you are at all reasonably close- that offer goes out to everybody who was on a green plant square, btw. Note I will only agree to move if the green square is CLOSE to me, so I can't promise anything.
"A Knight is sworn to valor, his heart knows only virtue, his blade defends the helpless, his might upholds the weak, his word speaks only truth, his wrath outdoes the wicked."
- Mullog
- Veteran
- Posts: 330
- Joined: Mon Sep 29, 2003 7:00 am
- Location: Aalesund, Norway (freezing!). Member of the Vulkings
WARNING! TECHNICAL DETAILS!Hamster wrote:After deleting some orders I got the remaining orders in a strange sort. Seems some stuff inside the queue is messed up when deleting. I'm not sure what is the shortest way to reproduce the BUG, especially because I also tried to insert an order while the queue was full (so maybe it causes the BUG).Egbert wrote:Well, that was interesting. I already had about 20 orders set in advance. Then I put in another order to spy a player "before order #2." It put it there, but then it took some of my other orders, and jumbled them up!!!! Uhhh, I think that's a bug.
Hope you're not messing with the ID field when inserting/arranging orders in the queue and because of this the MAX_ID error in sp_orders appear sometimes. Or is this error also because of the same BUG mentioned above?
The last version of the Order Queue did this. I changed the ID's of the orders to make room for the newly inserted orders, but this made the auto_increment field to go mad.
So I had to change my strategy. Now if an order is to be inserted in the middle of the OQ, the order is first placed at the end of the OQ, then the existing orders are copied so that they are behind the new orders, and finally the old copies of the existing orders are deleted. This way I can use the auto_increment all the time, and the database operation is actually much faster. The rearranged orders were a result of me forgetting to tell the database to copy the orders in the same order they were inserted... In most cases that would be the normal behaviour, but there is no guarantee for that.
What I would like to do is to have the OQ to be a linked list, with each order knowing which order is the next one in the queue. That way it would be trivial to update the queue. Unfortunately, linked lists are not easy to implement in a database. Hamster, do you have any suggestions to how I could do that?
END OF TECHNICAL DETAILS
The bug should be fixed now.
Mullog
Quidquid latine dictum sit, altum sonatur.
- Whatever is said in Latin sounds profound.
- Whatever is said in Latin sounds profound.
- Hamster
- Recruit
- Posts: 60
- Joined: Tue Mar 23, 2004 8:00 am
- Location: Osijek, Croatia
There are many techniques. I'll explain 2 easy ones that fell on my mind for now:
1) Linked list
Add 1 field that contains ID of next order (next_order_ID). When inserting an order you should have "insert after order X" and then update the next_order_ID of the order X to the new one and the old value copy in the new order. This transaction should be as follows:
- insert of new order (all data except next_order_ID) and remember it's ID
- select of order X (read its next_order_ID)
- update next_order_ID of order X
- update next_order_ID of new order
A little problem arises when displaying the OQ. OQ should be selected for a specific user and then it should be reconstructed from the resultset (faster than 30 or more single record selects).
2) Order# field (seems easier to implement)
Add 1 field that contains the order # (order_num). When you insert an order, increase this data by 1 in the orders that follow. This transaction should be as follows (X is the arder before you try to insert the new one):
- update order_num with order_num + 1 where order_num >= X
- insert the new order woth it's order_num = X
OQ should be selected with ORDER BY order_num. When an order is deleted from the queue, all values could be decreased by 1 (not necessary).
Both techniques should be faster than the new one. 1st has less rows affected, but a little complicated.
1) Linked list
Add 1 field that contains ID of next order (next_order_ID). When inserting an order you should have "insert after order X" and then update the next_order_ID of the order X to the new one and the old value copy in the new order. This transaction should be as follows:
- insert of new order (all data except next_order_ID) and remember it's ID
- select of order X (read its next_order_ID)
- update next_order_ID of order X
- update next_order_ID of new order
A little problem arises when displaying the OQ. OQ should be selected for a specific user and then it should be reconstructed from the resultset (faster than 30 or more single record selects).
2) Order# field (seems easier to implement)
Add 1 field that contains the order # (order_num). When you insert an order, increase this data by 1 in the orders that follow. This transaction should be as follows (X is the arder before you try to insert the new one):
- update order_num with order_num + 1 where order_num >= X
- insert the new order woth it's order_num = X
OQ should be selected with ORDER BY order_num. When an order is deleted from the queue, all values could be decreased by 1 (not necessary).
Both techniques should be faster than the new one. 1st has less rows affected, but a little complicated.
There are 10 types of people in this world.
Those who understand binary numbers and those who don't.
Those who understand binary numbers and those who don't.
- Mullog
- Veteran
- Posts: 330
- Joined: Mon Sep 29, 2003 7:00 am
- Location: Aalesund, Norway (freezing!). Member of the Vulkings
Thanks for your suggestions!Hamster wrote:There are many techniques. I'll explain 2 easy ones that fell on my mind for now:
1) Linked list
Add 1 field that contains ID of next order (next_order_ID). When inserting an order you should have "insert after order X" and then update the next_order_ID of the order X to the new one and the old value copy in the new order. This transaction should be as follows:
- insert of new order (all data except next_order_ID) and remember it's ID
- select of order X (read its next_order_ID)
- update next_order_ID of order X
- update next_order_ID of new order
A little problem arises when displaying the OQ. OQ should be selected for a specific user and then it should be reconstructed from the resultset (faster than 30 or more single record selects).
2) Order# field (seems easier to implement)
Add 1 field that contains the order # (order_num). When you insert an order, increase this data by 1 in the orders that follow. This transaction should be as follows (X is the arder before you try to insert the new one):
- update order_num with order_num + 1 where order_num >= X
- insert the new order woth it's order_num = X
OQ should be selected with ORDER BY order_num. When an order is deleted from the queue, all values could be decreased by 1 (not necessary).
Both techniques should be faster than the new one. 1st has less rows affected, but a little complicated.
#2 is what I did for my first attempt. More or less. All players and all games share the same order table so there may be orders after the ones we want to move, so adding 1 is not enough, I must add the difference between the first order id and the max order id. By setting the order id manually, the auto_increment got confused and stopped working properly, making the order id's grow too fast.
The new version is essentially the same, only that I use the auto_increment to get the new order id's as well. I really want to use the auto_increment instead of running a MAX() query each time an order is inserted, so that is why I choose this apporach.
#1 is what I really want. The problem with it is that it must be sorted manually after fetching the orders. I think. Is there a good way to sort the list without doing it manually? By sorting the list manually we will introduse a quite large extra load on the server, and we are already pushing it too hard I think...
But thanks for your suggestions! It is obvious that you know what you are talking about
Mullog
Quidquid latine dictum sit, altum sonatur.
- Whatever is said in Latin sounds profound.
- Whatever is said in Latin sounds profound.
- Hamster
- Recruit
- Posts: 60
- Joined: Tue Mar 23, 2004 8:00 am
- Location: Osijek, Croatia
As you can see, both my sugestions are based on a separate field. This way you don't have to mess up with the PK ID and it's autoincrement routine.
If you look on the performance you get this:
- my #1 - 1 insert row + 1 select row + 2 update rows + problem of displaying which uses some time
- my #2 - 1 insert row + statistically aprox. O/2 (where O = max queue depth and in the case all users use it always full, but we can halve it once more) + a simple select for displaying
- your new solution - 1 insert + aprox O/2 deletes + aprox O/2 inserts (may be used O/4 as in previous example) + a simple select for displaying
insert cost most, update a little, delete depends on DB system (but you can use a mid value), so calc yourself
P.S. Software optimization (both code and DB) is something I'm most interested in programming
If you look on the performance you get this:
- my #1 - 1 insert row + 1 select row + 2 update rows + problem of displaying which uses some time
- my #2 - 1 insert row + statistically aprox. O/2 (where O = max queue depth and in the case all users use it always full, but we can halve it once more) + a simple select for displaying
- your new solution - 1 insert + aprox O/2 deletes + aprox O/2 inserts (may be used O/4 as in previous example) + a simple select for displaying
insert cost most, update a little, delete depends on DB system (but you can use a mid value), so calc yourself
P.S. Software optimization (both code and DB) is something I'm most interested in programming
There are 10 types of people in this world.
Those who understand binary numbers and those who don't.
Those who understand binary numbers and those who don't.
- Undertaker
- Commander
- Posts: 574
- Joined: Tue Sep 03, 2002 7:00 am
- Location: The Back Room (behind Sharky's place)
- Contact:
Check you event log for a message from meDameon wrote:Color does determine size. White, yellow, and red are size 1. Green and blue are size 2. Grey is 3, and black is 4. These, and other things are all covered in a player's manual I have written with help from Kor and Mullog that is currently pending final review by Al- I imagine it will be out shortly. Oh, and if you want to message to me in game where those green plants are, I am sitting on a square of 4000+ red plants that I wouldn't mind exchanging with you if you are at all reasonably close- that offer goes out to everybody who was on a green plant square, btw. Note I will only agree to move if the green square is CLOSE to me, so I can't promise anything.
"That's a good question. Let me see...In my case, you know, I hate to advocate drugs or liquor, violence, insanity to anyone. But in my case it's worked." Hunter S. Thompson
- Strider
- Trooper
- Posts: 172
- Joined: Tue Sep 17, 2002 7:00 am
- Location: West Side!
I got a suggestion. I just logged in to find that my species is extinct, although I have no idea why. Since I had plenty of sat lvl last time I logged in, I'm pretty sure someone came along and ate me, but it would still be nice to know how it happened.
Can you add a blurb on to the extinction notice on how it occurred? Or allow the player to look at his event log?
The turtles will be avenged....
Can you add a blurb on to the extinction notice on how it occurred? Or allow the player to look at his event log?
The turtles will be avenged....
Never laugh at live dragons...
- Egbert
- Commander
- Posts: 658
- Joined: Tue Sep 03, 2002 7:00 am
- Location: The Scholars' Library (dusty section)
- Contact:
- Saladin
- Moderator
- Posts: 1652
- Joined: Tue Sep 03, 2002 7:00 am
- Location: The Netherlands