Carriers should always DROP first


#1

This is something that has been bugging me for a while and hopefully Jay will consider fixing.

It’s very, very common in the game to have a re-supply junctions where often two (or more) carriers arrive at the same time. Compared to NP1, the carrier actions are NP2 are just awesome (great implementation Jay) so it’s pretty easy to set one carrier to do a “Collect All” and the others to do a “Drop All” … and then they continue on their merry paths.

However, while the ships are always dropped, they aren’t always picked up … per the Codex:

“Carrier actions are not sorted in a particular order, so if two fleets arrive at a star in the same tick, there is no guarantee that one will drop ships off before the other tries to pick them up. To ensure this happens as expected you should make sure the pick up happens a tick after the drop off.”

Now, I realize it may be difficult to sort out the “right” thing to do if multiple carriers arrive at the same time with conflicting orders (collect all, garrison, etc.) so I’m not asking for an “N-Complete” solution to handle all cases. However, I would respectfully suggest that the FIRST thing that should be done is any carriers with “Drop” orders should do that … after that, then let the existing code sort things out.

I think one of the intents of the greatly enhanced/automated carrier orders was so people didn’t have to wake up at O-dark-30 to check their fleets … so it’s very frustrating to check in the morning and see half your ships left behind.

I.e. the current approach rewards the “night owl” who can login every hour to “fix” this problem in real-time and defeats the purpose of setting waypoints and checking the game periodically.

Sure, I know I can wait one tick … but should this really be necessary?

And if you are meeting re-supply ships at several stars en-route to the front, it’s even more in-efficient since you may need to pause that hour at each junction along the way to be sure you got the ships.


Carrier Collection Optimisation
He who controls the spice controls the universe
What is the order of actions when ticks happen?
#2

Yep. Agree 100%.


#3

I’ve only played a handful of games but I’ve never noticed any ships being left behind in a supply route in which I’ve configured a looping carrier between every star.


#4

I agree - I’ve always used that one extra tick to make sure (especially in a TBG) but you shouldn’t have to.


#5

I kind of like it. It rewards who has more attention to the details and punishes the sloppy.


#6

I’m not sure if you meant you like the current approach or my proposal … but I’d argue my suggestion to have it behave as it “should” does reward those who have attention to details who set well timed waypoints.

The current approach punishes those people who don’t login every tick to make sure the carriers did what they were supposed to do.


#7

No sane fleet commander with a Collect All order would depart a star on their way to war without waiting for the reinforcement fleet that they knew had a Drop All order for the same star on the same tick.

Such a commander would be better off working in the kitchen or as a member of the janitorial staff on a hospital ship. Therefore, I support HULK’s proposal.


#8

Thinking about the code logic,
Currently

If Carriers at Star
For each Carrier
Process Orders (Drop…Collect)
Next Carrier
End

Needs changing to

If Carriers at Star
Process Orders (Drop…Collect)
For each Carrier
Next Order
End


What is the order of actions when ticks happen?
#9

You are supposing they are supposed to do that way. For me, they are supposed to make a mess if you don’t wait one more tick.

I understand your complaint, but I think the concept of “well timed waypoints” is relative here. If you are careless, you will have to login every tick just to make sure you did not forget to put the right commands, or you did not forget to transfer the ships, or you did not accidentally command the carrier to go away one tick before it should - and this last one may be exactly what is going on!

I’m just arguing that there is not so much difference if you can synchronize the carriers to the same tick or if you have to synchronize them with one tick of delay.


#10

In my recent games the “delay” order has not always worked as it should, and is in fact worthless if it can’t be counted on.


#11

Frank: I tried using the delay, but found it simpler to simply click on a star the number of ticks I want it to delay there.

eDave: Yep … there ideally should be an order of action processing done first … and actually, I think “Garrison” would probably be the last action. Regardless, that’s a more complicated situation (the N-Complete solution I alluded too - i.e. what if one carrier says Garrison 10 and the other Garrison 20) … so at least for now, I’m just advocating that Jay have the Carriers all do their Drop’s first … and then process as normal.

Arth: I may not be explaining it well … but I often have multiple fleets setup through multiple waypoints … once I set it up, I should be able to forget it. Waiting that extra hour can often make a HUGE difference if you beat the other player there … and whether or not you get the defensive bonus.

So right now, there is an “advantage” conferred to the player who is willing to NOT wait that hour, but instead, login every tick to transfer the ships if the game does not. Markwkidd is correct that any fleet commander who has a “Collect All” order and leaves ships on the star should be assigned KP duty! :wink:


#12

Oh, now I got it. Thanks for the clarification!

I think that the best way to address this “complex situation” is by allowing players to set the priority of the carrier.

But anyway, I feel that benefits to people that logs in every hour to check the game are only natural to real-time matches. If we are going to change this, we should also allow players to pre-define investments to be done on production and notify them by e-mail as soon as is detected a new carrier movement from other empire.


#13

Bumping this thread with the hope that others will chime in and we can “persuade” Jay to make this change! :wink:


#14

I think this would be a great fix (until perhaps some more complicated albeit predictable order of operations is implemented). The problem I always have is that this is ALWAYS the behavior that I want when loops interact with each other. In turn-based games you may be able to manually fix the drop-off/pick-up when two carriers are at the same star, but you can’t do anything between the turns. It’s incredibly complicated to plan interacting routes, and making sure the right thing happens just guarantees you must waste an hour by delaying the pick-up carrier, and that’s assuming you can get the timing right. The more carriers there are, the worse it gets.

In fact, I’d argue that this is an even worse problem in turn-based games, since you don’t even have the opportunity to manually transfer ships every tick.

For the time being, why not try:

  1. Combat rules
  2. Drop-off
  3. Everything else

Bulk waypoint changes
#15

Agreed!!!


#16

Yes I agree too. Drop off should be a priority for ship transferring. A ship should wait for all its passengers to arrive and have a few minutes delay until it departs. On a cruise ship, if a passenger is missing they must wait for the passenger to arrive before they depart. They wouldn’t leave the passenger in another country. The same thing should happen with a carrier in space. All passengers should arrive before the carrier departs. It makes more sense than all the ships arriving and departing at the same time.


#17

I’ll put it on the top of the list but it might be a week or so till I get to it. I will try and look at whatever the problem is that makes the delays unreliable. (its in the same code. )


#18

Bumping this thread - the reasons were best said here!


#19

I do agree with @Hulk… It is hard to schedule the carriers properly and a pain when you look at them and they are not with the ships they were supposed to be.


#20

Bumping this thread as Jay might be doing some work on the combat rules to make them more computationally efficient so this might be addressable at the same time.