Is it possible that the home planet a player starts with begins the
game with no fuel on it at all? I think I've run across that instance,
either that or some glitch that is preventing me from mining a
starting planet, it's something I hadn't previously thought to include
in previous fleet scripts.
Sorry, just to clarify, I've made sure that it's not a range problem,
unfortunately due to the firewall restrictions at the new job I don't
have access through pgAdmin to the error channel. Unfortunately the
fleet script started creating and upgrading mining ships, but they're
just getting a 'failed to mine' message everytime, they have
prospecting up to 65 or so but have yet to pull a single resource from
the starting planet.
Also, as long as I'm thinking about it, thanks for adding the ability
to create public variables :) are these going to get reset and
disappear at the start of new rounds on thursday? or will they persist
between rounds?
On Jan 13, 9:13 am, MassConfusion <fors...@gmail.com> wrote:
> Is it possible that the home planet a player starts with begins the
> game with no fuel on it at all? I think I've run across that instance,
> either that or some glitch that is preventing me from mining a
> starting planet, it's something I hadn't previously thought to include
> in previous fleet scripts.
The problem wasn't fuel after all, it was actually that the planet had
a mining difficulty of 0. This is a multiplier used during the actual
mining phase and, well, I'm sure you can see the problem with this if
you difficulty is zero. It is funny that you called it a dead planet
because it was actually more of a dead planet then one simply with no
fuel (fuel does eventually regenerate).
ROUND_CONTROL() has now been fixed to have a minimum of 2 difficulty
during the planet creation so this issue shouldn't happen again. I
will commit the small change a little later tonight.
Glad you like the public_variables. Right now I don't touch them at
all at any time. You can set your own and they simply won't update/
delete unless your user does so (this includes persisting across
rounds). This may actually be annoying in some cases where you would
rather variables are deleted after a round ends but that could easily
be handled with a new flag you can set on the table. Keep me posted
how you end up using the variables for your own scripts and if the
system should be altered at all.
-Abstrct
On Jan 13, 2:07 pm, MassConfusion <fors...@gmail.com> wrote:
> Sorry, just to clarify, I've made sure that it's not a range problem,
> unfortunately due to the firewall restrictions at the new job I don't
> have access through pgAdmin to the error channel. Unfortunately the
> fleet script started creating and upgrading mining ships, but they're
> just getting a 'failed to mine' message everytime, they have
> prospecting up to 65 or so but have yet to pull a single resource from
> the starting planet.
> Also, as long as I'm thinking about it, thanks for adding the ability
> to create public variables :) are these going to get reset and
> disappear at the start of new rounds on thursday? or will they persist
> between rounds?
> On Jan 13, 9:13 am, MassConfusion <fors...@gmail.com> wrote:
> > Is it possible that the home planet a player starts with begins the
> > game with no fuel on it at all? I think I've run across that instance,
> > either that or some glitch that is preventing me from mining a
> > starting planet, it's something I hadn't previously thought to include
> > in previous fleet scripts.
Aah! Im glad you figured that one out, I thought there might have been
a snag after it ran for 24 hours with no results. I took a peek at the
creation script at one point but without being able to install postgre
myself there was just no way of knowing what values it was throwing
around. I'm feeling a little helpless without the error channel but
I've already been making some script changes in preparation for next
weeks round on a secondary account. I seem to be bumping up against
the size/character limit already but haven't quite nailed down just
where its at yet, hopefully the new variables will make it easier to
shorten up the longer queries.
On Jan 13, 7:59 pm, Abstrct <j...@saucetel.com> wrote:
> The problem wasn't fuel after all, it was actually that the planet had
> a mining difficulty of 0. This is a multiplier used durng the actual
> mining phase and, well, I'm sure you can see the problem with this if
> you difficulty is zero. It is funny that you called it a dead planet
> because it was actually more of a dead planet then one simply with no
> fuel (fuel does eventually regenerate).
> ROUND_CONTROL() has now been fixed to have a minimum of 2 difficulty
> during the planet creation so this issue shouldn't happen again. I
> will commit the small change a little later tonight.
> Glad you like the public_variables. Right now I don't touch them at
> all at any time. You can set your own and they simply won't update/
> delete unless your user does so (this includes persisting across
> rounds). This may actually be annoying in some cases where you would
> rather variables are deleted after a round ends but that could easily
> be handled with a new flag you can set on the table. Keep me posted
> how you end up using the variables for your own scripts and if the
> system should be altered at all.
> -Abstrct
> On Jan 13, 2:07 pm, MassConfusion <fors...@gmail.com> wrote:
> > Sorry, just to clarify, I've made sure that it's not a range problem,
> > unfortunately due to the firewall restrictions at the new job I don't
> > have access through pgAdmin to the error channel. Unfortunately the
> > fleet script started creating and upgrading mining ships, but they're
> > just getting a 'failed to mine' message everytime, they have
> > prospecting up to 65 or so but have yet to pull a single resource from
> > the starting planet.
> > Also, as long as I'm thinking about it, thanks for adding the ability
> > to create public variables :) are these going to get reset and
> > disappear at the start of new rounds on thursday? or will they persist
> > between rounds?
> > On Jan 13, 9:13 am, MassConfusion <fors...@gmail.com> wrote:
> > > Is it possible that the home planet a player starts with begins the
> > > game with no fuel on it at all? I think I've run across that instance,
> > > either that or some glitch that is preventing me from mining a
> > > starting planet, it's something I hadn't previously thought to include
> > > in previous fleet scripts.
That's unfortunate about the error channel being blocked by your
firewall. I can see that making dev a little tricky but don't forget
you can run your fleet scripts directly by getting it's fleet id and
then executing something like: SELECT FLEET_SCRIPT_<id>();
This won't help you see all issues but it will at least show you if
your script is working at all and if it's being killed due to a
timeout. I will see what I can do about somehow getting the error
channel into the games web interface. No promises but I will certainly
add it to the list.
Also, if you are running into character limits I have a couple
suggestions on how to help with that. First off, be sure you are
casting the actual block of code as text with the syntax 'this is my
long script'::TEXT. If you don't, postgres may assume it's something
like a character varying type and you will lose all but the first bit
of your string. Furthering that, if you are still running into issues,
don't forget that your fleet scripts can call other fleet scripts!
Using the same function call as above, you can create a modular design
with one main calling script like this:
UPDATE my_fleets
SET
script_declarations= ' scripts RECORD;',
script='
FOR scripts IN SELECT id, name FROM my_fleets WHERE enabled=''t'' and
name!=''Controller'' ORDER BY id ASC LOOP
EXECUTE ''SELECT fleet_script_''||scripts.id||''();'';
END LOOP;
',
enabled='t'
WHERE name='Controller';
The added benefit with this is that you are still only buying
execution time for one fleet script.
-Abstrct
On Jan 14, 11:16 am, MassConfusion <fors...@gmail.com> wrote:
> Aah! Im glad you figured that one out, I thought there might have been
> a snag after it ran for 24 hours with no results. I took a peek at the
> creation script at one point but without being able to install postgre
> myself there was just no way of knowing what values it was throwing
> around. I'm feeling a little helpless without the error channel but
> I've already been making some script changes in preparation for next
> weeks round on a secondary account. I seem to be bumping up against
> the size/character limit already but haven't quite nailed down just
> where its at yet, hopefully the new variables will make it easier to
> shorten up the longer queries.
> On Jan 13, 7:59 pm, Abstrct <j...@saucetel.com> wrote:
> > Thanks for the bug report!
> > The problem wasn't fuel after all, it was actually that the planet had
> > a mining difficulty of 0. This is a multiplier used durng the actual
> > mining phase and, well, I'm sure you can see the problem with this if
> > you difficulty is zero. It is funny that you called it a dead planet
> > because it was actually more of a dead planet then one simply with no
> > fuel (fuel does eventually regenerate).
> > ROUND_CONTROL() has now been fixed to have a minimum of 2 difficulty
> > during the planet creation so this issue shouldn't happen again. I
> > will commit the small change a little later tonight.
> > Glad you like the public_variables. Right now I don't touch them at
> > all at any time. You can set your own and they simply won't update/
> > delete unless your user does so (this includes persisting across
> > rounds). This may actually be annoying in some cases where you would
> > rather variables are deleted after a round ends but that could easily
> > be handled with a new flag you can set on the table. Keep me posted
> > how you end up using the variables for your own scripts and if the
> > system should be altered at all.
> > -Abstrct
> > On Jan 13, 2:07 pm, MassConfusion <fors...@gmail.com> wrote:
> > > Sorry, just to clarify, I've made sure that it's not a range problem,
> > > unfortunately due to the firewall restrictions at the new job I don't
> > > have access through pgAdmin to the error channel. Unfortunately the
> > > fleet script started creating and upgrading mining ships, but they're
> > > just getting a 'failed to mine' message everytime, they have
> > > prospecting up to 65 or so but have yet to pull a single resource from
> > > the starting planet.
> > > Also, as long as I'm thinking about it, thanks for adding the ability
> > > to create public variables :) are these going to get reset and
> > > disappear at the start of new rounds on thursday? or will they persist
> > > between rounds?
> > > On Jan 13, 9:13 am, MassConfusion <fors...@gmail.com> wrote:
> > > > Is it possible that the home planet a player starts with begins the
> > > > game with no fuel on it at all? I think I've run across that instance,
> > > > either that or some glitch that is preventing me from mining a
> > > > starting planet, it's something I hadn't previously thought to include
> > > > in previous fleet scripts.
Awesome again! Ill definately try classing everything to see if that's
the issue. I had tthough previously about nesting the scripts but
figured the runtime limit would probably apply to each one regardless,
now that I know they don't I may compartmentalize each section like
that even if the casting works, I'm interested to see just how
automatic I can make everything. Thanks!
On Jan 14, 11:17 am, Abstrct <j...@saucetel.com> wrote:
> That's unfortunate about the error channel being blocked by your
> firewall. I can see that making dev a little tricky but don't forget
> you can run your fleet scripts directly by getting it's fleet id and
> then executing something like: SELECT FLEET_SCRIPT_<id>();
> This won't help you see all issues but it will at least show you if
> your script is working at all and if it's being killed due to a
> timeout. I will see what I can do about somehow getting the error
> channel into the games web interface. No promises but I will certainly
> add it to the list.
> Also, if you are running into character limits I have a couple
> suggestions on how to help with that. First off, be sure you are
> casting the actual block of code as text with the syntax 'this is my
> long script'::TEXT. If you don't, postgres may assume it's something
> like a character varying type and you will lose all but the first bit
> of your string. Furthering that, if you are still running into issues,
> don't forget that your fleet scripts can call other fleet scripts!
> Using the same function call as above, you can create a modular design
> with one main calling script like this:
> UPDATE my_fleets
> SET
> script_declarations= ' scripts RECORD;',
> script='
> FOR scripts IN SELECT id, name FROM my_fleets WHERE enabled=''t'' and
> name!=''Controller'' ORDER BY id ASC LOOP
> EXECUTE ''SELECT fleet_script_''||scripts.id||''();'';
> END LOOP;
> ',
> enabled='t'
> WHERE name='Controller';
> The added benefit with this is that you are still only buying
> execution time for one fleet script.
> -Abstrct
> On Jan 14, 11:16 am, MassConfusion <fors...@gmail.com> wrote:
> > Aah! Im glad you figured that one out, I thought there might have been
> > a snag after it ran for 24 hours with no results. I took a peek at the
> > creation script at one point but without being able to install postgre
> > myself there was just no way of knowing what values it was throwing
> > around. I'm feeling a little helpless without the error channel but
> > I've already been making some script changes in preparation for next
> > weeks round on a secondary account. I seem to be bumping up against
> > the size/character limit already but haven't quite nailed down just
> > where its at yet, hopefully the new variables will make it easier to
> > shorten up the longer queries.
> > On Jan 13, 7:59 pm, Abstrct <j...@saucetel.com> wrote:
> > > Thanks for the bug report!
> > > The problem wasn't fuel after all, it was actually that the planet had
> > > a mining difficulty of 0. This is a multiplier used durng the actual
> > > mining phase and, well, I'm sure you can see the problem with this if
> > > you difficulty is zero. It is funny that you called it a dead planet
> > > because it was actually more of a dead planet then one simply with no
> > > fuel (fuel does eventually regenerate).
> > > ROUND_CONTROL() has now been fixed to have a minimum of 2 difficulty
> > > during the planet creation so this issue shouldn't happen again. I
> > > will commit the small change a little later tonight.
> > > Glad you like the public_variables. Right now I don't touch them at
> > > all at any time. You can set your own and they simply won't update/
> > > delete unless your user does so (this includes persisting across
> > > rounds). This may actually be annoying in some cases where you would
> > > rather variables are deleted after a round ends but that could easily
> > > be handled with a new flag you can set on the table. Keep me posted
> > > how you end up using the variables for your own scripts and if the
> > > system should be altered at all.
> > > -Abstrct
> > > On Jan 13, 2:07 pm, MassConfusion <fors...@gmail.com> wrote:
> > > > Sorry, just to clarify, I've made sure that it's not a range problem,
> > > > unfortunately due to the firewall restrictions at the new job I don't
> > > > have access through pgAdmin to the error channel. Unfortunately the
> > > > fleet script started creating and upgrading mining ships, but they're
> > > > just getting a 'failed to mine' message everytime, they have
> > > > prospecting up to 65 or so but have yet to pull a single resource from
> > > > the starting planet.
> > > > Also, as long as I'm thinking about it, thanks for adding the ability
> > > > to create public variables :) are these going to get reset and
> > > > disappear at the start of new rounds on thursday? or will they persist
> > > > between rounds?
> > > > On Jan 13, 9:13 am, MassConfusion <fors...@gmail.com> wrote:
> > > > > Is it possible that the home planet a player starts with begins the
> > > > > game with no fuel on it at all? I think I've run across that instance,
> > > > > either that or some glitch that is preventing me from mining a
> > > > > starting planet, it's something I hadn't previously thought to include
> > > > > in previous fleet scripts.
