Autopelago 1.1.1 (APWorld)

https://autopelago.app

Any 1.x version of the game client will be able to successfully connect to and complete games generated for any 1.x version of the APWorld.

Changes since 1.1.0

1. The victory location can no longer have an item from someone else's world.
   • This was always the case when the victory location was Snakes on a Planet for historical reasons - and now it's true for the other two.
   • This was a problem because when other worlds collect their outstanding items, the Autopelago client can mark the goal complete even if the victory location is out of logic.

Other Changes since 0.11.17

1. APWorld and Client version numbers are no longer coupled together. This used to be the case a while ago, then I changed it because it was a bit inconvenient, but with all the support tooling I see in the ecosystem, I think it won't be nearly as much of an annoying/confusing burden as it used to be.
2. The definitions of Useful/Trap/Filler ("bulk") items are now fully determined by the APWorld, instead of both the APWorld and client needing to agree in advance what all the possible items would be.
   • As part of this, these items are now defined in a format that should tend to be much more accessible to people who might want to propose changes / additions.
3. We now use a formula to figure out how to classify a bulk item according to the approximate strength of the auras that it grants.
   • This makes it easier to maintain the "bulk" list of items since we no longer need to manually classify each one.
   • It also ensures that we don't label an item as a trap if all of the traps have actually been disabled.
4. Bulk items are now defined in game-specific files under their own dedicated folder in the APWorld.
   • "Autopelago" must be present, and between everything, there must be at least "enough" unique items for us to place one bulk item per filler location.
   • Items with flavor from other games in the multiworld are placed in files named after those other games. The name must match the name of the other game EXACTLY in order to count.
5. Because of how many more variables there are now when determining which items to use to populate the world, we now use several layers of fallback to minimize (probably eliminate) the risk of new generation errors.
   • For example, if we're supposed to generate 100 traps but your list of enabled traps and list of other games in the multiworld only leave 40 items still classified as traps in the end, then that's when the new stuff kicks in. The legacy routine would have just failed generation (but this never would have happened in practice because of how restrictive we made the rules for items).
   • So when trying to place, e.g. traps, instead of only picking from the list of things that are traps by default, we pick from the ENTIRE list of ALL possible items, but in this priority order so that it still feels right:
     1. If there are available trap items from non-Autopelago worlds present in the same multiworld, then we use those first.
     2. If there are available trap items from Autopelago, then we use those next.
     3. If there are available trap items from non-Autopelago worlds NOT present in the same multiworld, then we use those next.
     4. Then draw from available filler items that WOULD have been traps if all of their disabled buffs/traps had been enabled, in the same 3 priority groups as above.
     5. Then go through the list of all other fillers, again in the same 3 priority groups.
     6. If for some reason we run out of filler items (I don't think this is possible, but I REALLY don't want to see people getting generation errors if I'm wrong), then we start placing buff items, starting with the least powerful and going up from there.
   • Same story for buff items.
   • For non-trap / non-buff filler items, essentially step 4 moves to step 3: for items that WOULD have been buffs/traps but where everything's disabled, we'll pick those only after we run out of "true" fillers, and we'll only move onto items from foreign non-Autopelago worlds once we've run out of "true" fillers elsewhere.
6. Switched to using the new "rule builder" system introduced in Archipelago 0.6.7. This means that Archipelago 0.6.7 or above is now REQUIRED to generate Autopelago worlds.
7. The rat can now "die". There are special options that control if, when, how, and how often this can happen.
   • When the rat "dies", it's returned to the starting location with all its meters set back to 0. Any "Smart" or "Conspiratorial" modifiers are unaffected.
   • If Death Link is enabled, then the rat will "die" instantly upon receiving the bounce from the server.
   • If the "Poison" trap is disabled (it's enabled by default), then that's the end of it. Otherwise...
   • Whenever the rat receives an item with a "Poison" trap on it (and it doesn't fizzle due to a very well-timed Confidence buff), then this sequence will play out:
     1. The rat will send a configured message to chat unless chat messages are (or this chat message specifically is) disabled on the connect screen
     2. An animation will play for some configured length of time.
     3. When the animation finishes, the rat will "die". If Death Link is enabled, the moment AFTER that animation is finished playing is when the bounce is sent.
   • At any time while the animation is playing, you can pause the game or close the tab to delay / postpone sending a Death Link to your other players. However, if Death Link is configured and the animation has started, there's no cheating death. If you disconnect while the animation is still playing, then the Death Link bounce will get sent as soon as you start again.

The legacy native client (0.10.x and below) will no longer work with newly generated multiworlds as of this version of the APWorld and going forward into the future.

No 1.0.0?

1.0.0 was the version that I had originally submitted for inclusion in Core, and it included the first five changes in the above list. I didn't bother releasing an APWorld for this version, since those changes are all just about pivoting to a reality where I won't be in charge of deciding when to release both sides of the app. They're HELPFUL even on a solo-only project, don't get me wrong, but I didn't want to push something with these incompatibilities until it could come with something positive to make up for it.

Since then, the other two features actually DID add enough value to justify a new release, so there you have it. 1.1.0.