Possible MINE() range bug
51 views
Skip to first unread message
MassConfusion
Mar 6, 2012, 1:44:23 PM3/6/12
to Schemaverse
Ab,
I've seen something a little strange roll across my events history
recently, but I haven't had the time to look through the source to try
and track down the problem.
Derpfish and I are mixing it up a bit and on several tics (including
the last one that just went by 872) he's conquered one of my
previously owned planets (745), here's the strange bit though:
I realize that whomever MINE()s more from the planet on the last tic
takes over ownership, but he doesn't seem to have any ships near it.
Also, I've got a dozen ships there, and I've made sure that their X, Y
is exactly the same as the planet, and that their RANGE is maxed out
at 2000, and I'm not showing anyone in ships_in_range either.
As I said, I haven't had the time to go through this, I'm a little
swamped today and can only keep half an eye on my fleet at the moment,
but I seem to remember a tweet about the 'old coordinates' system and
it being mirrored on the new fields. Is it possible these have become
out of sync somehow and that's the issue?
Let me know if I'm having another full retard moment, maybe I've just
not thought it through enough again :)
I've seen something a little strange roll across my events history
recently, but I haven't had the time to look through the source to try
and track down the problem.
Derpfish and I are mixing it up a bit and on several tics (including
the last one that just went by 872) he's conquered one of my
previously owned planets (745), here's the strange bit though:
I realize that whomever MINE()s more from the planet on the last tic
takes over ownership, but he doesn't seem to have any ships near it.
Also, I've got a dozen ships there, and I've made sure that their X, Y
is exactly the same as the planet, and that their RANGE is maxed out
at 2000, and I'm not showing anyone in ships_in_range either.
As I said, I haven't had the time to go through this, I'm a little
swamped today and can only keep half an eye on my fleet at the moment,
but I seem to remember a tweet about the 'old coordinates' system and
it being mirrored on the new fields. Is it possible these have become
out of sync somehow and that's the issue?
Let me know if I'm having another full retard moment, maybe I've just
not thought it through enough again :)
Tigereye .
Mar 6, 2012, 1:49:24 PM3/6/12
to schem...@googlegroups.com
Ships_in_range is now cached which MAY explain this behavior?
(consider this a stealth hack? :P)
(consider this a stealth hack? :P)
Abs would be far better to comment though!
Sent from my mobile device
MassConfusion
Mar 6, 2012, 2:34:47 PM3/6/12
to Schemaverse
A stealth hack! Where does he get those wonderful toys..
Maybe caching that view wasn't the best idea after all :(
I wonder how often that gets updated.. this little skirmish has been
going on for a good 30 tics now.
I like the speed up from it, but not being able to see the bad guys
feels a little like Mike Tyson punching a one armed baby..
On Mar 6, 12:49 pm, "Tigereye ." <tiger...@tigereye.ca> wrote:
> Ships_in_range is now cached which MAY explain this behavior?
> (consider this a stealth hack? :P)
>
> Abs would be far better to comment though!
>
> Sent from my mobile device
>
Maybe caching that view wasn't the best idea after all :(
I wonder how often that gets updated.. this little skirmish has been
going on for a good 30 tics now.
I like the speed up from it, but not being able to see the bad guys
feels a little like Mike Tyson punching a one armed baby..
On Mar 6, 12:49 pm, "Tigereye ." <tiger...@tigereye.ca> wrote:
> Ships_in_range is now cached which MAY explain this behavior?
> (consider this a stealth hack? :P)
>
> Abs would be far better to comment though!
>
> Sent from my mobile device
>
Abstrct
Mar 6, 2012, 2:55:34 PM3/6/12
to schem...@googlegroups.com
Hi MC,
Now, with all that being said, it is also possible that the ship is in range and it is actually just not being shown in the ships_near_ships instead of being stuck in the ships_near_planets cache as originally thought. This code is all of about 4 days old so some bugs are not completely unexpected.
I am taking a look into this now. I don't think it is the cache system as MINE() calls in_range_planet() which looks directly at the ship and planet table to calculate distance.
As far as how often does the cache system update, any ship that moves in the tic has all entries in ships_near_ships and ships_near_planets that reference that ship removed and the cache for that ship is rebuilt. The only time the system should be out of sync is if there was a failure in tic after a successful move_ships() call and during the update cache functions that build ships_near_planets and ships_near_ships. So far I have not seen any recent failures in TIC that would suggest this happening.
Now, with all that being said, it is also possible that the ship is in range and it is actually just not being shown in the ships_near_ships instead of being stuck in the ships_near_planets cache as originally thought. This code is all of about 4 days old so some bugs are not completely unexpected.
Let me poke around and hopefully figure out the actual reasoning. Thanks as always for slightly being forced into the beta tester job
-Abstrct
Abstrct
Mar 6, 2012, 4:01:15 PM3/6/12
to schem...@googlegroups.com
Well it looks like Stealth Hack is pretty close to the truth although I am not sure if this one was intentional.
Because the update takes place on any ship that moves, any stationery ship was pleasantly ignored. Like say, a ship that was just built. I am fixing the create_ship function so that it creates the initial record in ships_near_ships/ships_near_planets to resolve this issue, then I will regenerate the full cache and start the tic back up.
Let me know if you still notice the issue once the tic is up and running again. If there is any riches I can bestow upon you in the game as a thank you for the bug report just say the word.
-Abstrct
MassConfusion
Mar 6, 2012, 4:06:09 PM3/6/12
to Schemaverse
well, at least that makes sense, glad it was an actual issue this time
instead of just me overlooking something obvious.
no riches necessary, fiddling with this thing when I get a spare
moment during the day is just plain fun for me :)
instead of just me overlooking something obvious.
no riches necessary, fiddling with this thing when I get a spare
moment during the day is just plain fun for me :)
derpfish
Mar 7, 2012, 2:45:35 AM3/7/12
to Schemaverse
Huh, interesting bug. So far I've pretty much only been tuning my
script for what I'd call industrial efficiency rather than aggressive
tactics, but I hadn't realized that the latest patch would make my
miners invisible. Good catch.
script for what I'd call industrial efficiency rather than aggressive
tactics, but I hadn't realized that the latest patch would make my
miners invisible. Good catch.
MassConfusion
Mar 7, 2012, 9:22:56 AM3/7/12
to Schemaverse
I realized I had to do something about the combat aspect a few rounds
ago when I saw that you had conquered far more of the realm than my
previous fleet AI had :) so now I'm adopting the slow and sustainable
approach. Once I get the bugs out of this one though I had thought of
starting a third, more viral type, script.
I think we effectively brought the entire system to a crawl after the
tic restarted yesterday, suddenly there was several hundred enemy
ships to do battle with. It was glorious.
ago when I saw that you had conquered far more of the realm than my
previous fleet AI had :) so now I'm adopting the slow and sustainable
approach. Once I get the bugs out of this one though I had thought of
starting a third, more viral type, script.
I think we effectively brought the entire system to a crawl after the
tic restarted yesterday, suddenly there was several hundred enemy
ships to do battle with. It was glorious.
MassConfusion
Apr 3, 2012, 2:31:21 PM4/3/12
to Schemaverse
I hate to say it, but this may need to be revisited, seeing another
similar set of circumstances.
Have a ship (3204) sitting directly on a planet (252) and although
there are no ships (enemy or friendly) showing up on ships_in_range
(have max range too), it simply won't capture, the event log shows
that it's successfully mining every turn as well.
I got to looking through the code in perform_mining() that handles the
change of conqueror_id and it appears that it's calculating the new
conqueror based on how many ships mined the planet instead of how much
fuel was mined as I originally thought. Plus, it's hammering the
already overworked events table.
I won't profess to know enough about this to think I have a solution,
so maybe cbrowne can offer some insight, but would it be more
efficient to have the planet/player/totals tossed into a temporary
table, or a table that gets truncated every tic at the same time the
Mine_success/Fail events are added, and then total up that table? I'm
sure by now you're looking at a couple million event entries, this
might help to get the total number of entries into something
manageable, plus you could base it on the total extracted from the
planet instead of just how many ships showed up to the party.
I dunno, I'm probably completely off my rocker again, sorry in
advance!
similar set of circumstances.
Have a ship (3204) sitting directly on a planet (252) and although
there are no ships (enemy or friendly) showing up on ships_in_range
(have max range too), it simply won't capture, the event log shows
that it's successfully mining every turn as well.
I got to looking through the code in perform_mining() that handles the
change of conqueror_id and it appears that it's calculating the new
conqueror based on how many ships mined the planet instead of how much
fuel was mined as I originally thought. Plus, it's hammering the
already overworked events table.
I won't profess to know enough about this to think I have a solution,
so maybe cbrowne can offer some insight, but would it be more
efficient to have the planet/player/totals tossed into a temporary
table, or a table that gets truncated every tic at the same time the
Mine_success/Fail events are added, and then total up that table? I'm
sure by now you're looking at a couple million event entries, this
might help to get the total number of entries into something
manageable, plus you could base it on the total extracted from the
planet instead of just how many ships showed up to the party.
I dunno, I'm probably completely off my rocker again, sorry in
advance!
Abstrct
Apr 3, 2012, 4:32:55 PM4/3/12
to schem...@googlegroups.com
Have a ship (3204) sitting directly on a planet (252) and although
there are no ships (enemy or friendly) showing up on ships_in_range
(have max range too), it simply won't capture, the event log shows
that it's successfully mining every turn as well.
I can't exactly figure out what is up right now regarding this but I am looking into it. IN_RANGE_PLANET seems fine. Your ships are showing up as within range of the other ships around that planet, but for some reason they are not showing up as in range to you. I will keep debugging for a bit and hopefully figure it out shortly.
I got to looking through the code in perform_mining() that handles the
change of conqueror_id and it appears that it's calculating the new
conqueror based on how many ships mined the planet instead of how much
fuel was mined as I originally thought. Plus, it's hammering the
already overworked events table.
Thanks to all the great code and ideas lately, perform_mining() is one of the last really slow parts of the game. Even the particular event calls it make seem to happen pretty fast, it is a combination of all the other sql calls it needs to repeatedly make. There is definitely room for improvement in this function, we just need to figure out exactly how/where.
I won't profess to know enough about this to think I have a solution,
so maybe cbrowne can offer some insight, but would it be more
efficient to have the planet/player/totals tossed into a temporary
table, or a table that gets truncated every tic at the same time the
Mine_success/Fail events are added, and then total up that table? I'm
sure by now you're looking at a couple million event entries, this
might help to get the total number of entries into something
manageable, plus you could base it on the total extracted from the
planet instead of just how many ships showed up to the party.
This is definitely something I have thought about too. Event is a beast so I am sure it would help speed things up. This just needs to be done in addition optimizing all the other calls it needs to make repeated.
-Abstrct
MassConfusion
Apr 3, 2012, 5:07:58 PM4/3/12
to Schemaverse
ahaha! that's fantastic, I'm out of range with myself.. maybe there
was really something to it when they told me I was losing touch..
I've started losing planets to phantom fleets now XD all the radar are
coming up blank, unless this is some new addition allowing planets to
rebel against their tyrant overlords (in which case there will be mass
whippings until moral improves).
No rush, I'll continue to improve the fleets running speed in the
meantime :)
was really something to it when they told me I was losing touch..
I've started losing planets to phantom fleets now XD all the radar are
coming up blank, unless this is some new addition allowing planets to
rebel against their tyrant overlords (in which case there will be mass
whippings until moral improves).
No rush, I'll continue to improve the fleets running speed in the
meantime :)
Christopher Browne
Apr 3, 2012, 10:05:10 PM4/3/12
to schem...@googlegroups.com
Grr. Thought I'd posted this earlier...
On Tuesday, 3 April 2012 16:32:55 UTC-4, Abstrct wrote:
It looks as though something happened recently; events and successful fleet action seem to be ticking along now, which is a fine thing!
It seems to me that mining should be taken out of the "main loop", and turned into something that gets requested and processed automagically. The mine() function winds up running logic on an individual tuple basis each time it's called, which can't be as quick as doing it on a mass basis.
It seems to me that there are two things to be done, both somewhat separate:
a) I'd like to see ship_control split into two tables, one for movement, and the other for actions.
The clever use of views thing would involve making 2 views:
a) my_ships_movement, where an ON UPDATE rule allows doing what we use move() for now.
b) my_ships_actions, where an ON INSERT rule allows one to indicate MINE/REPAIR/ATTACK, and where this simply inserts a tuple into the "ship_action" table. ON DELETE allows removing that, in case you screw up.
I imagine it would be good for ship_action to be persistent. That is, once I have told ship 2 to MINE planet 72, or ship 17 to REPAIR ship 58, or ship 3240 to ATTACK ship 3241, those actions will be repeated until I stop things. That's particularly good for mining, as an enormous amount of the present scheduling work relates to saying "yep, mine that planet again!" Make ship_action persist, and that work of scheduling the action disappears.
The tic process then should handle performing mining in a somewhat different way, and I think the use of temporary tables would be hugely good for this. It eliminates a *pile* of locking for the interim work.
1. Establish a temp table with the list of all ships that have MINE as their action, the planet id, and player. That'll be scanning ship_action. Make sure it has an index on (planet, player). That index will be useful later.
I'm not sure of ideal orderings of the next few bits; they might be mixed into one grand query, or be better as several UPDATEs or as subsequent INSERT INTO another temp table.
a) Need to know which ships are still alive, and prospecting capabilities; draw that from ship.
b) Need to know if the ship is near the planet. Draw from ship.range, ship.location, and planet.location. That probably means we fold a) and b) together into one query.
Eliminate ships that are dead; they don't matter.
c) Ships that are too far from the planet should log MINE_FAIL. We can probably do the logging immediately; no need for intermediaries.
d) Do a per-planet loop, and handle mining on each planet.
d.1) If planet is undisputed, that is, there are no miners for other than the planet's owner trying to mine it, then there's guaranteed success.
Select ships on that planet in random order (from temp table!) and update to indicate success and set random amount of mining, for the first 30 ships (or whatever is the planetary limit). Update all other ships on that planet (in temp table) to indicate failure.
d.2) Planet is disputed.
Go through logic to figger out who wins the planet, and which ships get successful mining. Do this to "the temp table." The successful ships get random amounts based on the prospecting data already in the temp table. Remember it's 0 if the planet has been emptied.
Notice that no balances have yet been touched by this.
d.3) Work out how much fuel they *actually* got.
All we have, at this point, is a temporary table that knows which ships successfully mined, and which didn't, and how much they mined. Now, for accounting...
Another temp table... Aggregate stuff computed in step d on a per-planet basis, to give us something like...
create temp table t_mining_per_planet (planet_id integer, player_id integer, total integer);
insert into t_mining_per_planet (planet_id, player_id, total)
select planet_id, player_id, sum(mined_fuel) from t_mining_results_by_ship
where mined_fuel > 0 group by planet_id, player_id;
But... Some planets run out
for c_planet_id in select planet_id from t_mining_per_planet where total > (select whatsleft from planet where id = planet_id) loop
-- Curtail mining; give 'em 1/2
update t_mining_results_by_ship set mined_fuel = mined_fuel / 2 where mined_fuel > 0 and planet_id = c_planet_id;
update t_mining_per_planet set total = (select sum(mined_fuel) from t_mining_results_by_ship where planet_id = c_planet_id and mined_fuel > 0);
end loop;
e) Update planets to remove mined material, setting to 0 if < 0.
f) t_mining_results_by_ship contains all the data needed to populate events. Insert the whack of data there.
g) Aggregate the per-planet data, and adjust player balances on that basis.
update player set fuel_reserve = fuel_reserve + (select sum(total) from t_mining_per_planet where player_id = id);
That wants an index on t_mining_per_planet(player_id).
The stuff that locks heavily will take place on the temp table(s) that are never visible outside the tic process.
I haven't looked at all at how movement takes place; I suspect similar might be true.
The HUGE value of using a temp table for the work process is that it gets rid of most of the locking. It is not infrequently the case that test runs of my fleet script struggle with the tic process when both of them are trying to mess with my player's balance. That slows both, to everyone's detriment.
If most of the work is taking place in a temp table, and you only update the "main" tables with finalized results, there's a lot of locking that doesn't need to take place.
Also, for mining, it'll be a HUGE win to not have 8000 iterations of "update player set fuel_reserve = fuel_reserve + 27 where id = 89", but rather do that once with the 2.5M total.
On Tuesday, 3 April 2012 16:32:55 UTC-4, Abstrct wrote:
Have a ship (3204) sitting directly on a planet (252) and although
there are no ships (enemy or friendly) showing up on ships_in_range
(have max range too), it simply won't capture, the event log shows
that it's successfully mining every turn as well.I can't exactly figure out what is up right now regarding this but I am looking into it. IN_RANGE_PLANET seems fine. Your ships are showing up as within range of the other ships around that planet, but for some reason they are not showing up as in range to you. I will keep debugging for a bit and hopefully figure it out shortly.
It looks as though something happened recently; events and successful fleet action seem to be ticking along now, which is a fine thing!
I got to looking through the code in perform_mining() that handles the
change of conqueror_id and it appears that it's calculating the new
conqueror based on how many ships mined the planet instead of how much
fuel was mined as I originally thought. Plus, it's hammering the
already overworked events table.Thanks to all the great code and ideas lately, perform_mining() is one of the last really slow parts of the game. Even the particular event calls it make seem to happen pretty fast, it is a combination of all the other sql calls it needs to repeatedly make. There is definitely room for improvement in this function, we just need to figure out exactly how/where.
It seems to me that mining should be taken out of the "main loop", and turned into something that gets requested and processed automagically. The mine() function winds up running logic on an individual tuple basis each time it's called, which can't be as quick as doing it on a mass basis.
It seems to me that there are two things to be done, both somewhat separate:
a) I'd like to see ship_control split into two tables, one for movement, and the other for actions.
The clever use of views thing would involve making 2 views:
a) my_ships_movement, where an ON UPDATE rule allows doing what we use move() for now.
b) my_ships_actions, where an ON INSERT rule allows one to indicate MINE/REPAIR/ATTACK, and where this simply inserts a tuple into the "ship_action" table. ON DELETE allows removing that, in case you screw up.
I imagine it would be good for ship_action to be persistent. That is, once I have told ship 2 to MINE planet 72, or ship 17 to REPAIR ship 58, or ship 3240 to ATTACK ship 3241, those actions will be repeated until I stop things. That's particularly good for mining, as an enormous amount of the present scheduling work relates to saying "yep, mine that planet again!" Make ship_action persist, and that work of scheduling the action disappears.
The tic process then should handle performing mining in a somewhat different way, and I think the use of temporary tables would be hugely good for this. It eliminates a *pile* of locking for the interim work.
1. Establish a temp table with the list of all ships that have MINE as their action, the planet id, and player. That'll be scanning ship_action. Make sure it has an index on (planet, player). That index will be useful later.
I'm not sure of ideal orderings of the next few bits; they might be mixed into one grand query, or be better as several UPDATEs or as subsequent INSERT INTO another temp table.
a) Need to know which ships are still alive, and prospecting capabilities; draw that from ship.
b) Need to know if the ship is near the planet. Draw from ship.range, ship.location, and planet.location. That probably means we fold a) and b) together into one query.
Eliminate ships that are dead; they don't matter.
c) Ships that are too far from the planet should log MINE_FAIL. We can probably do the logging immediately; no need for intermediaries.
d) Do a per-planet loop, and handle mining on each planet.
d.1) If planet is undisputed, that is, there are no miners for other than the planet's owner trying to mine it, then there's guaranteed success.
Select ships on that planet in random order (from temp table!) and update to indicate success and set random amount of mining, for the first 30 ships (or whatever is the planetary limit). Update all other ships on that planet (in temp table) to indicate failure.
d.2) Planet is disputed.
Go through logic to figger out who wins the planet, and which ships get successful mining. Do this to "the temp table." The successful ships get random amounts based on the prospecting data already in the temp table. Remember it's 0 if the planet has been emptied.
Notice that no balances have yet been touched by this.
d.3) Work out how much fuel they *actually* got.
All we have, at this point, is a temporary table that knows which ships successfully mined, and which didn't, and how much they mined. Now, for accounting...
Another temp table... Aggregate stuff computed in step d on a per-planet basis, to give us something like...
create temp table t_mining_per_planet (planet_id integer, player_id integer, total integer);
insert into t_mining_per_planet (planet_id, player_id, total)
select planet_id, player_id, sum(mined_fuel) from t_mining_results_by_ship
where mined_fuel > 0 group by planet_id, player_id;
But... Some planets run out
for c_planet_id in select planet_id from t_mining_per_planet where total > (select whatsleft from planet where id = planet_id) loop
-- Curtail mining; give 'em 1/2
update t_mining_results_by_ship set mined_fuel = mined_fuel / 2 where mined_fuel > 0 and planet_id = c_planet_id;
update t_mining_per_planet set total = (select sum(mined_fuel) from t_mining_results_by_ship where planet_id = c_planet_id and mined_fuel > 0);
end loop;
e) Update planets to remove mined material, setting to 0 if < 0.
f) t_mining_results_by_ship contains all the data needed to populate events. Insert the whack of data there.
g) Aggregate the per-planet data, and adjust player balances on that basis.
update player set fuel_reserve = fuel_reserve + (select sum(total) from t_mining_per_planet where player_id = id);
That wants an index on t_mining_per_planet(player_id).
The stuff that locks heavily will take place on the temp table(s) that are never visible outside the tic process.
I haven't looked at all at how movement takes place; I suspect similar might be true.
I won't profess to know enough about this to think I have a solution,
so maybe cbrowne can offer some insight, but would it be more
efficient to have the planet/player/totals tossed into a temporary
table, or a table that gets truncated every tic at the same time the
Mine_success/Fail events are added, and then total up that table? I'm
sure by now you're looking at a couple million event entries, this
might help to get the total number of entries into something
manageable, plus you could base it on the total extracted from the
planet instead of just how many ships showed up to the party.
This is definitely something I have thought about too. Event is a beast so I am sure it would help speed things up. This just needs to be done in addition optimizing all the other calls it needs to make repeated.
The HUGE value of using a temp table for the work process is that it gets rid of most of the locking. It is not infrequently the case that test runs of my fleet script struggle with the tic process when both of them are trying to mess with my player's balance. That slows both, to everyone's detriment.
If most of the work is taking place in a temp table, and you only update the "main" tables with finalized results, there's a lot of locking that doesn't need to take place.
Also, for mining, it'll be a HUGE win to not have 8000 iterations of "update player set fuel_reserve = fuel_reserve + 27 where id = 89", but rather do that once with the 2.5M total.
Abstrct
Apr 4, 2012, 10:55:41 AM4/4/12
to schem...@googlegroups.com
I think I fixed ships_in_range. Please play around with it and let me know if it seems to be making more sense now. Hopefully it is even a bit faster now
-Abstrct
MassConfusion
Apr 4, 2012, 11:22:25 AM4/4/12
to Schemaverse
Yep, definitely fixed, finding tons of enemies now.
Sadly, this much action on this many planets is probably going to slow
the tic to a crawl for some hours, fleet runtime has already
quadroupled hehe
Glorious
Sadly, this much action on this many planets is probably going to slow
the tic to a crawl for some hours, fleet runtime has already
quadroupled hehe
Glorious
Abstrct
Apr 4, 2012, 11:52:53 AM4/4/12
to schem...@googlegroups.com
I have created ships_in_range_ (note the trailing _) as a second attempt (for science). It seems like it is actually faster than the cached results that ships_in_range uses but I confirm with more testing.
Do you mind playing around to see if the ships_in_range_ view is actually faster?
MassConfusion
Apr 5, 2012, 9:52:56 AM4/5/12
to Schemaverse
Wups, missed this post yesterday somehow.
I'll definitely mess around with it when the site comes back up, at
the moment it's just kicking me back out to the login screen
everytime.
I knew I could count on cbrowne to expound on the temp table idea :) I
have to agree with him too, I realize it'd probably mean a good bit of
rewrite and restructure, having a temporary table and then doing the
commits based on a rollup of that table has just GOT to be better than
modifying the data in the main tables thousands and thousands of times
per tic.
It kinda sounds like a larger long term project, so I'm not going to
hold my breathe at the moment :)
On Apr 4, 10:52 am, Abstrct <j...@saucetel.com> wrote:
> I have created ships_in_range*_* (note the trailing _) as a second attempt
I'll definitely mess around with it when the site comes back up, at
the moment it's just kicking me back out to the login screen
everytime.
I knew I could count on cbrowne to expound on the temp table idea :) I
have to agree with him too, I realize it'd probably mean a good bit of
rewrite and restructure, having a temporary table and then doing the
commits based on a rollup of that table has just GOT to be better than
modifying the data in the main tables thousands and thousands of times
per tic.
It kinda sounds like a larger long term project, so I'm not going to
hold my breathe at the moment :)
On Apr 4, 10:52 am, Abstrct <j...@saucetel.com> wrote:
> I have created ships_in_range*_* (note the trailing _) as a second attempt
Reply all
Reply to author
Forward
0 new messages