PTR Changelog 2016-11-01
-
This post describes changes on the Public Test Realm. The estimated launch date is November 7.
- When there is no free space in the target terminal while sending resources, it will not be dropped on the ground. Instead, only the amount that fits into the terminal will be sent. If the terminal has 0 capacity (i.e. it is in inactive state), then it won't be able to receive any resources.
Tell us what do you think about these upcoming changes in the comments below!
-
Cool! Does this also include sending to terminals we got no vision of? This way we can reliably send stuff to allies without it falling on the ground.
-
Yes, it doesn't depend on visibility.
-
Is there any way we'll be able to tell when this occurs, as well as how many resources actually were sent?
Presumably the fee calculation will be made with the new amount instead of the larger amount?
-
Is there any way we’ll be able to tell when this occurs, as well as how many resources actually were sent?
The only way to track actual transactions is to monitor them via
Game.market.incomingTransactions/outgoingTransactions. You can come up with your own layer on top of this system (probablydescription-based) in order to track their execution precisely.Presumably the fee calculation will be made with the new amount instead of the larger amount?
Yes, sure.
-
Would you mind sharing your rationale for this change? It seems like it might be a reaction to this discussion.
I explicitly asked about it before because I was planning to write some code based on this mechanic. I've not only done that, my room settlement choices have been partly based on this as well. I assume I'm not the only one using this mechanic. I'm sure you can understand how this would be frustrating.
If you (as the game designer) see this as the better decision for how terminals should work, I can get on board with that. But if you are going by the feedback in that discussion, it doesn't seem like there was anything close to a consensus. It seems like the bigger issue is whether there should be a GCL progress cap, terminal function just happens to be one of the more viable ways around that. Nerfing terminal function doesn't get at the main issue, it just breaks a lot of people's code. Even dissi wasn't complaining about terminal function itself, only that it seemed inconsistent with another mechanic.
I realize it must be tough to find a compromise between player feedback and your own vision for how the game ought to be. What absolutely shouldn't happen is decisions being made arbitrarily, and then arbitrarily being changed again down the road. This particular issue isn't that important in itself. The bigger problem is justifying putting effort into code that breaks when game mechanics are changed for such arbitrary reasons.
-
It is better in many ways. Actually, it should have been done from the start, but at that moment we didn't realize all the implications of this dropping mechanics. It spoils the purpose of a terminal as an easy-to-use resource sending mechanism. We have already disabled dropping for market transactions, and now it is just a logical step forward.
-
Can you change the return code? Right now you have all failure codes as negative, but maybe a positive code that represents "SUCCESS_PARAMETERS_MODIFIED" or something so we can easily tell when this mechanic comes into play?
-
It is not possible to know whether the transaction will be successful or not during the commands scheduling stage.
-
Bonzai, you can still, prior to unclaiming, ferry 900k energy into a storage to get the 1.8m CP required to reach RCL6. This is what I do.
-
+1 to this. It does slow down the process of switching to other rooms a bit (~2000 ticks to refill), but it seems like that's not a big increase in ticks compared to the time to get to RCL 6. Bonzai's energy sink rooms would still work with a slight variation.
Having said all that, I sympathize with the frustration in implementing code that uses specific mechanics to your advantage and then having to throw that out when the mechanics change.
-
This change doesn't address the unclaim/claim exploit, it's just an inconsistency that should be removed.
