-
Notifications
You must be signed in to change notification settings - Fork 116
add fleet missions queue #363 feature #817
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Changes from all commits
bd22799
44a6ac7
b3b044a
7d50fbc
b27601d
77b34cd
e33df7a
509b03d
b8093d1
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,111 @@ | ||
| <?php | ||
|
|
||
| namespace OGame\Console\Commands; | ||
|
|
||
| use Illuminate\Console\Command; | ||
| use OGame\Factories\PlanetServiceFactory; | ||
| use OGame\Factories\PlayerServiceFactory; | ||
| use OGame\GameMissions\AttackMission; | ||
| use OGame\GameObjects\Models\Units\UnitCollection; | ||
| use OGame\Models\Enums\PlanetType; | ||
| use OGame\Models\Planet; | ||
| use OGame\Models\Planet\Coordinate; | ||
| use OGame\Models\Resources; | ||
| use OGame\Services\ObjectService; | ||
|
|
||
| class TestFleetQueue extends Command | ||
| { | ||
| protected $signature = 'fleet:test-queue | ||
| {userId : User ID} | ||
| {galaxy : Target galaxy} | ||
| {system : Target system} | ||
| {position : Target position} | ||
| {--delay=5 : Arrival delay in seconds}'; | ||
|
|
||
| protected $description = 'Test fleet queue system by sending 3 attack missions to specified coordinates'; | ||
|
|
||
| public function handle(): int | ||
| { | ||
| // Get arguments | ||
| $user_id = (int) $this->argument('userId'); | ||
| $galaxy = (int) $this->argument('galaxy'); | ||
| $system = (int) $this->argument('system'); | ||
| $position = (int) $this->argument('position'); | ||
| $delay = (int) $this->option('delay'); | ||
|
|
||
| // Get planet | ||
| $planet_model = Planet::where('user_id', $user_id)->first(); | ||
| if (!$planet_model) { | ||
| return 1; | ||
| } | ||
|
|
||
| // Setup services | ||
| $planet_factory = app(PlanetServiceFactory::class); | ||
| $source_planet = $planet_factory->make($planet_model->id); | ||
| $player_factory = app(PlayerServiceFactory::class); | ||
| $player = $player_factory->make($user_id); | ||
|
|
||
| // Setup test data | ||
| $target_coordinate = new Coordinate($galaxy, $system, $position); | ||
| $player->setResearchLevel('computer_technology', 10); | ||
| $source_planet->addUnit('light_fighter', 6000000); | ||
| $source_planet->addResources(new Resources(1000000000, 1000000000, 1000000000, 0)); | ||
|
|
||
| $attack_mission = app(AttackMission::class); | ||
| $missions = []; | ||
|
|
||
| // Mission 1: 1M light fighters | ||
| $units1 = new UnitCollection(); | ||
| $units1->addUnit(ObjectService::getUnitObjectByMachineName('light_fighter'), 1000000); | ||
| try { | ||
| $mission1 = $attack_mission->start( | ||
| $source_planet, | ||
| $target_coordinate, | ||
| PlanetType::Planet, | ||
| $units1, | ||
| new Resources(0, 0, 0, 0), | ||
| $delay | ||
| ); | ||
| $missions[] = $mission1->id; | ||
| } catch (\Exception $e) { | ||
| } | ||
|
|
||
| // Mission 2: 2M light fighters | ||
| $units2 = new UnitCollection(); | ||
| $units2->addUnit(ObjectService::getUnitObjectByMachineName('light_fighter'), 2000000); | ||
| try { | ||
| $mission2 = $attack_mission->start( | ||
| $source_planet, | ||
| $target_coordinate, | ||
| PlanetType::Planet, | ||
| $units2, | ||
| new Resources(0, 0, 0, 0), | ||
| $delay | ||
| ); | ||
| $missions[] = $mission2->id; | ||
| } catch (\Exception $e) { | ||
| } | ||
|
|
||
| // Mission 3: 3M light fighters | ||
| $units3 = new UnitCollection(); | ||
| $units3->addUnit(ObjectService::getUnitObjectByMachineName('light_fighter'), 3000000); | ||
| try { | ||
| $mission3 = $attack_mission->start( | ||
| $source_planet, | ||
| $target_coordinate, | ||
| PlanetType::Planet, | ||
| $units3, | ||
| new Resources(0, 0, 0, 0), | ||
| $delay | ||
| ); | ||
| $missions[] = $mission3->id; | ||
| } catch (\Exception $e) { | ||
| } | ||
|
|
||
| if (empty($missions)) { | ||
| return 1; | ||
| } | ||
|
|
||
| return 0; | ||
| } | ||
| } |
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -45,7 +45,10 @@ public function handle(Request $request, Closure $next): mixed | |
| $player->planets->current()->update(); | ||
|
|
||
| // Update all fleet missions of player that are associated with any of the player's planets. | ||
| $player->updateFleetMissions(); | ||
|
|
||
| if (app()->environment('testing')) { | ||
|
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. How come we're only doing this during testing? Would we not expect this in prod?
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. We don't expect this in the production environment, because in production it runs through Laravel's queue system
Owner
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Is it possible to refactor the feature tests so they do use the Laravel's queue system, so we can assert that the queue processing etc. works using the existing test suite? I'm not very familiar with Laravel's queue system, but as the feature tests hit the actual database, the queue system should also be able to work normally, right?
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. It's possible to run assertions using Queue::fake(); So I'd expect to that that IMO. 👍
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. We use |
||
| $player->updateFleetMissions(); | ||
| } | ||
| } | ||
|
|
||
| return $next($request); | ||
|
|
||
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This change here means all existing deployments who want to upgrade also need to change their .env, correct?
I tested this PR locally without making this .env change, but as the
docker-compose.yml(dev) does expose a port it works via the old 127.0.0.1 connection. But on production deployments this won't work.I'm thinking we may want to add some sort of initialize script somewhere during docker container start to check for and update default .env values. Such an initialization script does not exist yet, but it would be helpful for future (default) changes too. Because right now without instructions, if someone follows the current upgrade instructions in the README.md, the fleet queue will break.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Using a script could overwrite the user's custom values. I think updating the README.md would be a better approach. Something like:
"If you are upgrading from version 0.13.0 or earlier, please add
REDIS_HOST=ogamex-redisto your.envfile."