Summary: AMP or Adaptive Metaroom Placement is a method of writing metaroom CAOS that eliminates the need to collision-check a metaroom against every other metaroom ever created. Instead of having to stay totally up to date on the placement of all those other rooms, developers can use this method to instead have their metaroom simply search a world for an empty spot to inject itself into.
Obviously though, this method comes with some challenges. Quoting a few from the previous thread:
...even though they play nicely with themselves and other adaptively placed metarooms, they risk clashing with the coordinates of most current/older statically placed metarooms if the static metaroom is injected later.
It's not just a matter of changing the coordinates of where the room is injected. You would also have to update the coordinates for every single plant/animal/foreground agent/possibly CA links/pretty much anything that is in the room.
Regardless, I can't seem to stop myself continuing to explore this concept anyway.Adaptively placed metarooms haven't really been stress-tested afaik. It's possible that there are some complications involved that just haven't surfaced yet. When I was working on the ant tunnels I was able to generate over 50 small-ish (about workshop size) empty rooms without any issue, but I didn't try injecting more, injecting lots of different shapes/sizes, or packing them all full of various agents, so it's possible there's limitations to them (I feel fairly confident the concept is at least stable enough for most normal playstyles, but again, testing will really tell).
While I personally am the most interested in using the AMP method for future metarooms (and making it as easy as possible for others to use the method as well), Gio has shown interest in converting the existing C3/DS metarooms to AMP-standards:
So here goes:Gio wrote:The painstaking, tedious process of converting the official C3/DS metarooms should be our first step, as it covers a lot of the bases and questions you've posed so far. The converted rooms can serve as a stability test (can it handle the default game?) which then serves as our baseline for further testing (agent injecting, new worlds with static rooms, turtles).
Here is the pastebin for an example AMP-enabled room - this one injects a simple clone of the DS Hub (map/rooms only, no agents). It's not thoroughly bugtested and needs a remove script but it is (or should be) functional. (Also I promise it's way more readable once copy-pasted into the CAOS tool)
Here is the python script I used to assisted in the tedious process of converting the selected hub room-placement code (from !map.cos in the DS bootstrap). It's probably really bad because I don't know python and basically just googled "how to do x" for every other line; it's very limited because I wrote it to parse only that particular format and it would need to be adapted for any other use, but it might get someone more knowledgeable than I started at least.
Ultimately I think I want to have a script that will merge an output cosfile from the Map Editor with the AMP script, so after mapping out the room, developers would only have to export the !Addon.cos-file, run the conversion script on that file, and immediately have an injectable cosfile of their AMP-enabled room with as little effort as possible. But I'm going to take a break and work on some other things for a while to avoid burning out.
In the meantime, let me know what happens if you try this out, and let me know if you think of any other problems this project might face that need overcoming. And of course, feel free to ask any questions.