Ships_In_Range :: Enemy Health
59 views
Skip to first unread message
MassConfusion
Jan 20, 2012, 11:07:43 AM1/20/12
to Schemaverse
I may be missing something altogether, so please forgive me if I'm off
base.
After finally running across another active player I've been trying to
refine the combat bit of my little fleet script and I happen to notice
that the Ships_in_range view always seems to return a 1 or 0 for enemy
health. I took a quick look at the setup script and it seems to be
generated from this :
enemies.current_health/enemies.max_health as health,
which would be fine if it were returning the percentage value, but the
view itself seems to be only returning an integer type instead of a
float.
This is just being kinda problematic since my script stops engaging an
enemy when their health is at zero, and it appears the view is always
returning a zero unless the enemy's health is at maximum (or perhaps
better than 50%, problem still applies) the ship simply wont be
destroyed unless it has zero health.
I'm going to try and find some other option for the moment since this
particular view is already painfully slow to resolve sometimes, even
when specifying an ship_in_range_of.
Has anyone else that's created a combat section have any tips?
base.
After finally running across another active player I've been trying to
refine the combat bit of my little fleet script and I happen to notice
that the Ships_in_range view always seems to return a 1 or 0 for enemy
health. I took a quick look at the setup script and it seems to be
generated from this :
enemies.current_health/enemies.max_health as health,
which would be fine if it were returning the percentage value, but the
view itself seems to be only returning an integer type instead of a
float.
This is just being kinda problematic since my script stops engaging an
enemy when their health is at zero, and it appears the view is always
returning a zero unless the enemy's health is at maximum (or perhaps
better than 50%, problem still applies) the ship simply wont be
destroyed unless it has zero health.
I'm going to try and find some other option for the moment since this
particular view is already painfully slow to resolve sometimes, even
when specifying an ship_in_range_of.
Has anyone else that's created a combat section have any tips?
Abstrct
Jan 20, 2012, 9:27:58 PM1/20/12
to Schemaverse
Hi MC,
Looks like I must have forgot the cast making that view pretty damn
useless. Sorry about that, I will fix that for you shortly!
As for ships_in_range being slow, I do have good news regarding that
too. Once I upgrade to Postgres 9.1, there is new "K-Nearest-Neighbor
Indexing" which will allow me to index on distance. That should
substantially speed up ships_in_range and pretty much every other
aspect of the game (i.e.: all the action functions). I am pretty
excited about this feature to be honest, I just haven't had a moment
to perform the upgrades.
Anyways, thanks again for the bug report. How are your scripts coming
along? I notice there is actually a bit of a battle heating up :D
-Absrtct
Looks like I must have forgot the cast making that view pretty damn
useless. Sorry about that, I will fix that for you shortly!
As for ships_in_range being slow, I do have good news regarding that
too. Once I upgrade to Postgres 9.1, there is new "K-Nearest-Neighbor
Indexing" which will allow me to index on distance. That should
substantially speed up ships_in_range and pretty much every other
aspect of the game (i.e.: all the action functions). I am pretty
excited about this feature to be honest, I just haven't had a moment
to perform the upgrades.
Anyways, thanks again for the bug report. How are your scripts coming
along? I notice there is actually a bit of a battle heating up :D
-Absrtct
MassConfusion
Jan 20, 2012, 11:46:04 PM1/20/12
to Schemaverse
I thought something was a little funny there :) thanks for looking
into it
the upgrade sounds.. well awesome.. I was hoping to incorporate a
routine for planetary defense, but once your total ship count gets
over a thousand or two running through each ship with ships_in_range
is almost impossible. I'm sticking to picking one ship per owned
planet and pulling those, but still, with 122 planets so far I'm
worried it'll bomb the entire script out.
scripts are good :) although i may have been slightly overzealous
setting my upper limit variables. I have the majority of the basics
now automated, and some of the combat.
Speaking of which, hopefully the float from ships_in_range will make
things a little easier to cope with, but it still seems to drag on for
quite a while. 60 tics seems like an eternity to wait for an enemy
vessel to blow up, especially when the tics get longer and longer the
more ships and calculations the server is doing. I've noticed on
Thursday mornings tics come almost instantaneously, whereas already
earlier this afternoon it was taking a minute to a minute and a half
to get the tic counter to advance (and yes this is probably my fault
for attempting to conquer the entire map) but by next Thursday I'll be
lucky to see a tic every 5minutes, stretching those 60 tics into hours
and hours
.
Or instead of shortening the minimum tics for exploding, would it be
possible to set a max negative value for ship health? perhaps a ship
is able to repair regardless of it's point value for the 60 tics
UNLESS it reaches -200 health at which point it automatically explodes
that same tic?.. come to think of it.. a self_destruct() routine that
executes the same tic wouldn't be a terrible idea for unwanted ships,
maybe even get 1/2 the cost of the ship back.
I don't know, the combats going to take a bit, I realize not everyone
has a script managing everything, and even though I do I love hitting
the refresh button occasionally to see where everyone is going and
what the totals are. I feel like at this point, unless confronted with
overwhelming odds, I should be able to hold off an invasion fleet for
some time just with the repair() calls built into the current script.
I took your advice by the way, compartmentalized most everything
behind a single control script, only calling those sections that need
to be run. It's really become surprisingly self-regulatory and speedy
for what amounts to just a single script.
I digress, and I apologize again for being the handful that I am to
deal with :) for what it's worth, I think you have done, and are
doing, a down right amazing job, and I really envy your project.
into it
the upgrade sounds.. well awesome.. I was hoping to incorporate a
routine for planetary defense, but once your total ship count gets
over a thousand or two running through each ship with ships_in_range
is almost impossible. I'm sticking to picking one ship per owned
planet and pulling those, but still, with 122 planets so far I'm
worried it'll bomb the entire script out.
scripts are good :) although i may have been slightly overzealous
setting my upper limit variables. I have the majority of the basics
now automated, and some of the combat.
Speaking of which, hopefully the float from ships_in_range will make
things a little easier to cope with, but it still seems to drag on for
quite a while. 60 tics seems like an eternity to wait for an enemy
vessel to blow up, especially when the tics get longer and longer the
more ships and calculations the server is doing. I've noticed on
Thursday mornings tics come almost instantaneously, whereas already
earlier this afternoon it was taking a minute to a minute and a half
to get the tic counter to advance (and yes this is probably my fault
for attempting to conquer the entire map) but by next Thursday I'll be
lucky to see a tic every 5minutes, stretching those 60 tics into hours
and hours
.
Or instead of shortening the minimum tics for exploding, would it be
possible to set a max negative value for ship health? perhaps a ship
is able to repair regardless of it's point value for the 60 tics
UNLESS it reaches -200 health at which point it automatically explodes
that same tic?.. come to think of it.. a self_destruct() routine that
executes the same tic wouldn't be a terrible idea for unwanted ships,
maybe even get 1/2 the cost of the ship back.
I don't know, the combats going to take a bit, I realize not everyone
has a script managing everything, and even though I do I love hitting
the refresh button occasionally to see where everyone is going and
what the totals are. I feel like at this point, unless confronted with
overwhelming odds, I should be able to hold off an invasion fleet for
some time just with the repair() calls built into the current script.
I took your advice by the way, compartmentalized most everything
behind a single control script, only calling those sections that need
to be run. It's really become surprisingly self-regulatory and speedy
for what amounts to just a single script.
I digress, and I apologize again for being the handful that I am to
deal with :) for what it's worth, I think you have done, and are
doing, a down right amazing job, and I really envy your project.
Abstrct
Jan 23, 2012, 8:04:50 PM1/23/12
to Schemaverse
Alright the health column is now numeric rather than integer. That
should help :P
The view is still slow as hell but, ya, working on it. You may want to
try querying the my_events view for details on what to attack as well.
This is a bit more reactionary but at least it's another option. This
table is also a tad slow due to it's size but if you specify the
previous tics you are looking for it should actually return things
pretty quickly since the tic is one of the indexes.
Right now the main thing that slows down the game seems to be
boatloads of ships since they also mean lots of movement, lots of
actions, lots of logging of actions, etc. I am working out some new
potential solutions via gameplay changes to combat this problem but I
will start up a new thread to discuss that a little later. This would
be something after version 1.0 is finally released anyways but it is a
problem I would like to sort out before the next Schemaverse
Tournaments (pgCon 2012 and hopefully DEFCON 20).
Hopefully the gameplay changes will help keep the tic from growing out
of hand. About a year ago when the game was accidentally discovered by
others, they quickly overloaded the system with ships and
intentionally long scripts making a tic about an hour. Definitely a
tad boring at that rate! I think keeping the tic time down will be an
ongoing battle but at least it's a fun challenge to work on.
I am definitely open to ideas on how to deal with a ships destruction.
At one point, when your ship exploded you got the full amount of a new
ship back into your account as we were worried that players would find
themselves in a situation where they have basically lost and had no
resources to continue. Then we realized that it's a game and sometimes
you lose games so the destruction credit was removed. One hour does
seem like a long time when you have automated everything and it has 60
different tics to realize the ships in danger but it's also not that
long if you think of it happening to someone playing without scripts.
Hopefully now that the ships_in_range.health works, the time it takes
to be destroyed won't be as big of a deal but let me know if you still
think we should tone it down to 30 or even 10 before explosion.
I really appreciate the kind words. To be honest, I am just @#$%ing
stoked that people are actually interested in it! Every new user
totally makes my day. Don't worry about hassling me about problems you
come across, I know it's far from perfect and it is through the
questions, complaints and suggestions that I figure out how I can
improve it.
Cheers
-Abstrct
should help :P
The view is still slow as hell but, ya, working on it. You may want to
try querying the my_events view for details on what to attack as well.
This is a bit more reactionary but at least it's another option. This
table is also a tad slow due to it's size but if you specify the
previous tics you are looking for it should actually return things
pretty quickly since the tic is one of the indexes.
Right now the main thing that slows down the game seems to be
boatloads of ships since they also mean lots of movement, lots of
actions, lots of logging of actions, etc. I am working out some new
potential solutions via gameplay changes to combat this problem but I
will start up a new thread to discuss that a little later. This would
be something after version 1.0 is finally released anyways but it is a
problem I would like to sort out before the next Schemaverse
Tournaments (pgCon 2012 and hopefully DEFCON 20).
Hopefully the gameplay changes will help keep the tic from growing out
of hand. About a year ago when the game was accidentally discovered by
others, they quickly overloaded the system with ships and
intentionally long scripts making a tic about an hour. Definitely a
tad boring at that rate! I think keeping the tic time down will be an
ongoing battle but at least it's a fun challenge to work on.
I am definitely open to ideas on how to deal with a ships destruction.
At one point, when your ship exploded you got the full amount of a new
ship back into your account as we were worried that players would find
themselves in a situation where they have basically lost and had no
resources to continue. Then we realized that it's a game and sometimes
you lose games so the destruction credit was removed. One hour does
seem like a long time when you have automated everything and it has 60
different tics to realize the ships in danger but it's also not that
long if you think of it happening to someone playing without scripts.
Hopefully now that the ships_in_range.health works, the time it takes
to be destroyed won't be as big of a deal but let me know if you still
think we should tone it down to 30 or even 10 before explosion.
I really appreciate the kind words. To be honest, I am just @#$%ing
stoked that people are actually interested in it! Every new user
totally makes my day. Don't worry about hassling me about problems you
come across, I know it's far from perfect and it is through the
questions, complaints and suggestions that I figure out how I can
improve it.
Cheers
-Abstrct
MassConfusion
Jan 23, 2012, 9:16:42 PM1/23/12
to Schemaverse
Thanks for the fix! Hopefully I'll have time tomorrow to sit down and
adjust the scripts etc.
The destruction tic count is probably fine for now, I'm thinking up
ways to reinforce scout ships that run across enemy fleets.
Thought of something else btw, not terribly important, it occurred to
me that there isn't any way for players to converse in-game, maybe a
Communication_log table that everyone can see and post messages to?
Perhaps we should have a separate threads for new ideas..
I babble again, looking forward to the updates, thanks again for the
tons of hard work you put in :)
adjust the scripts etc.
The destruction tic count is probably fine for now, I'm thinking up
ways to reinforce scout ships that run across enemy fleets.
Thought of something else btw, not terribly important, it occurred to
me that there isn't any way for players to converse in-game, maybe a
Communication_log table that everyone can see and post messages to?
Perhaps we should have a separate threads for new ideas..
I babble again, looking forward to the updates, thanks again for the
tons of hard work you put in :)
Abstrct
Jan 24, 2012, 8:14:27 PM1/24/12
to Schemaverse
Haha, don't tempt me. I have considered writing a SQL only forum now
for a while but it seems a bit silly. Another possibility is to
somehow dirty hack in an XMPP service so people can communication
inside and outside the game.
There is always the LISTEN/NOTIFY system too which could be used like
so:
LISTEN public;
NOTIFY public, 'Hello world!'
I still need to try to get LISTEN working nicely in the PHP world
(more specifically, schemaverse.com/tw/). If I can pull that off then
it would make a pretty hilarious chat system although somewhat
unreliable (message is lost if nobody is listening).
With all that said, feel free to stop by our IRC channel on freenode
#Schemaverse. Not as fun as it happening within Postgres but there is
still some nice people around.
for a while but it seems a bit silly. Another possibility is to
somehow dirty hack in an XMPP service so people can communication
inside and outside the game.
There is always the LISTEN/NOTIFY system too which could be used like
so:
LISTEN public;
NOTIFY public, 'Hello world!'
I still need to try to get LISTEN working nicely in the PHP world
(more specifically, schemaverse.com/tw/). If I can pull that off then
it would make a pretty hilarious chat system although somewhat
unreliable (message is lost if nobody is listening).
With all that said, feel free to stop by our IRC channel on freenode
#Schemaverse. Not as fun as it happening within Postgres but there is
still some nice people around.
Christopher Browne
Mar 22, 2012, 3:47:42 PM3/22/12
to schem...@googlegroups.com
On Monday, 23 January 2012 20:04:50 UTC-5, Abstrct wrote:
The view is still slow as hell but, ya, working on it.
I have a suggested patch out there to improve this view...
Basic idea being that if you add the player ID to the ships_near_ships table, it becomes way more efficient to filter it down to just *my* ships.
I added columns for both players (player + opponent), which may be overkill. Perhaps it suffices to specify the one player.
MassConfusion
Mar 30, 2012, 2:38:57 PM3/30/12
to Schemaverse
Well, I just noticed a fun fact!
Somewhere in the last iteration or so the Ships_In_Range view now
shows friendly ships as well as enemy ones, consequently, my script
has literally whacked every single one of my own ships.
Somewhere in the last iteration or so the Ships_In_Range view now
shows friendly ships as well as enemy ones, consequently, my script
has literally whacked every single one of my own ships.
Abstrct
Mar 30, 2012, 3:19:44 PM3/30/12
to schem...@googlegroups.com
ahahahaha sorry about that! Totally all my fault. I thought I was being helpful D:
I will revive any ships in the system that were killed by friendly fire.
Is this feature helpful at all or should the view be changed back to excluding all of your own ships?
MassConfusion
Mar 30, 2012, 3:33:08 PM3/30/12
to Schemaverse
hehehe, it's totally fine, I probably should have written the attack
portion to exclude my own user_id in the first place, but since it
never showed them before I guess it just slipped my mind. I've
rewritten that little bit and it's already rebuilding itself so I'm
not worried about it :) and yes, I can see where it'd be beneficial in
the right circumstances.
it took forever to figure out what happened, when I took a look at it
today all my ships were just gone except for one on each planet and
the issue didn't immediately present itself because instead of going
from 100 to zip real quick so I could see that something was
happening, they were nibbling away at each other and slowly dying one
by one.
On the upside, rewritting the way it counts enemy ships has improved
the speed again, before when it was seeing friendlies as bad guys it
was running the entire attack section on every single planet, I guess
that's why the runtime had quadrupled yesterday.
portion to exclude my own user_id in the first place, but since it
never showed them before I guess it just slipped my mind. I've
rewritten that little bit and it's already rebuilding itself so I'm
not worried about it :) and yes, I can see where it'd be beneficial in
the right circumstances.
it took forever to figure out what happened, when I took a look at it
today all my ships were just gone except for one on each planet and
the issue didn't immediately present itself because instead of going
from 100 to zip real quick so I could see that something was
happening, they were nibbling away at each other and slowly dying one
by one.
On the upside, rewritting the way it counts enemy ships has improved
the speed again, before when it was seeing friendlies as bad guys it
was running the entire attack section on every single planet, I guess
that's why the runtime had quadrupled yesterday.
Reply all
Reply to author
Forward
0 new messages