Portal abstraction

[Treer]

This is ready for review/merging.

• Sound effects/ambiance, and more particle effects

• Nether can be used for fast-travel, like in Minecraft (configurable in mod settings). Creates a reason for players to tech to Nether and go there. Especially without sprint.

• Portals will normally spawn on the surface instead of underground (MT5 only)

• Reuses/reignites existing remote portals, allowing portals to be turned on and off or repositioned in a room with predictable results - old mod would link to entirely new locations each time a portal was ignited. I took predictable behaviour for granted in Minecraft, and have come to realise it was required for the emergent portal gameplay.

  • Portal positions are stored in mod storage, with obsolete locations being removed from mod storage if/when a connection to one is attempted.
  • Reuses an existing portal or portal frame if there's one at the remote destination, rather than that portal being griefed by a slightly offset portal schematic.
  • If an existing portal or frame is found, no "volume is natural" check is required.

• Internationalization

• Portal API created. A solid portal implementation that's forwards and backwards compatible with the earlier system.

  • Enables registration of other "realm portals", two extra example portals are provided. (see nether mod settings if you want to enable them).
    • A portal to the Floatlands
    • A surface-travelling portal
    • Another portal is also implemented by the cloudlands mod.
  • Add an Encyclopedia section if the Help-modpack is installed, otherwise creates a Book of Portals that appears in dungeon loot, so that if different portals are available then players can discover how to build them.
  • Separates portal shape logic from portal behaviour code. Dev and testing can focus on one or the other without needing to manage both.
  • Enables different portal shapes, though the shape of the portal to the Nether is unchanged. Two more portal shapes have been added, which the example portals demonstrate.
  • Enables different portal colours and effects.
  • Fixes many edge cases and bugs in the older system

• Add mesecons support - portals can be switched on and off with mesecons, and wormholes emit mesecon energy. From a tech-tree perspective, mese is still required for portal ignition.

• Replaces ABMs with a single node timer.

• Remote portals are created in a matching orientation to the local portal.

• Preserve player position & facing relative to portal when traveling through wormhole (even if portals are at 90°)

• Player is not teleported until after the portal at the other end is confirmed and built.

• Players no longer bounce several times after teleporting

A Nether portal beside the playable API example portals (which are disabled from the game by default):

The Book of Portals - a player guide that appears in dungeon loot if there are extra portals available:

---

You can ignore the older version of this message below:

When I said I was looking to make a lot of changes and sofar said "Just send PRs", the scope of changes wasn't obvious, so I'm raising this pull request early to be less of a shock/get earlier feedback.

These are "phase 1" changes that add nothing new or interesting to game, and should be forwards and backwards compatible with existing maps and nether mod, but are starting to abstract the portal physics and handle more edge cases. Unfortunately handling edge cases adds more code, so I don't know whether this PR will run against any "worse is better" beliefs.

Motivation

Hardening the portals feels like the first step: The Nether in Minecraft adds something epic to the game that captures imagination, and I feel this is missing in MT even after you install the nether mod - I want a nether mod to affect the game, inject itself as an important part of any world that has the mod installed. I think a lot of that can happen without breaking compatibility.

• Fast travel - one of the reasons to quickly "tech to Nether" in Minecraft, and needed even more in MT when sprint isn't installed on servers. This makes routes through the game take detours through the nether.
• Atmospheric
  • Add portal sounds and unsettling background ambiance (most of which won't need ambiance mod).
  • Ruins
  • Red weed
  • The caverns change from 2016 is excellent in this regard
• Dangerous - related to issue Burning-related notices #4, but there are many options that aren't flowing lava. The random fire suggestion could be used though, unless that's server heavy?
• Materials or items. There are some nice materials already, but currently nethersand is just another sand (it could be quicksand, like Ethereal - see "Dangerous", or make eerie noises when stepped on - see "Atmospheric"), and there is no ore in the Nether to make going there a useful accomplishment. Nether mod can add a menu option that moves a specialist ore to be only found in the nether, or adds its own (the portal api also creates a need for new obsidian-ish nodes).
• Realm portals - unlike Minecraft, MT isn't just limited to the Nether. Allow other mods to use nether mod portals, adding dwarven portal (caverealms?), floatlands portal, cloudlands etc :)
• primitive portal memory - check previous nearby portal locations before trying a full terrain search - faster and makes portals more predictable, allowing them to be repositioned etc without losing the link. Perhaps a player must break the portal frame and that of every portal linking to it to remove the portal memory. It will be a game mechanic question.

[sofar]

All in all the proposed changes all sound really good. I'd be a little conservative with introducing new elements and make them dependent on other mods (caverealms) but thumbs up on your approach.

[Treer]

The API adds a Book of Portals to treasure that can be found, so players can discover portal types they didn't know about.

That adds a soft dependency to loot and dungeon_loot mods. Support for the Treasurer mod could be added later without nether needing a dependency, via a separate "Treasure Registration Mod" in their modpack

A soft dependency to the help encyclopedia will also be added.

[Treer]

The API is at a point where complete custom portals to other realms can be created, and looks much like I expect it will when finished. What still remains is adding another example portal shape and making the example portals go somewhere other than the Nether etc.

I don't expect to anybody to check it or test or play with it, but if someone does then it's at a point where feedback would be more meaningful than earlier.

A point of interest may be storage of portal locations in mod_storage - used to avoid having to find new portal locations if there's already a portal in the area. The limitations of mod_storage lead to a system that feels suboptimal, but optimizing a list of portals would probably be like optimising an idle loop anyhow. The storage of portal locations is treated as unreliable, so I can also just disable it if mod_storage api isn't available.

[sofar]

Seems very promising just from the commit messages and all. Please TCP me when you want some testing - I see there's a merge conflict but if you resolve that I'd love to try it.

[Treer]

Merge conflict resolved.

I'm on holiday in Germany at the moment so updates will be a bit sporadic, but the main stuff is done and should be bug free, so testing would be great.

(not sure what "TCP me" meant, perhaps an @sofar mention?)

[Treer]

This is finished and ready to play with.

• Play with the updated Nether portal
• Enable the example portals from Minetest -> Settings -> All settings -> Mods -> nether
• Go dungeon spelunking for a Book of Portals (or just use the screenshot of one on this page which was taken while the example portals were enabled)
• Construct additional portals

On a tangent, I think the Surface-travel portal has unexpected promise of its own, the mechanism seems to lend itself to gameplay I didn't plan, like slap a mesecon switch on it and a hidden base can have a doorway where the base is only ever accessible for the duration the switch is kept on. Or use it for exploration with the catch that you can't go back, or as a fast way to and from the surface but at a distant location.

The PR should be pretty thoroughly tested already. More testing is appreciated, but don't feel you're being treated as guinea pigs. I've tested on MT v5.2 and v0.4.16/0.4.17, and switched between master branch and this API branch to check the portals keep forwards and backwards compatibility.

I've only tested using a local server.

[SmallJoker]

Uh.. This is a monstrosity of a PR, changing most of the code in nether.
To the general concept I don't have any objections, although I'd really prefer to use images rather than ASCII art based on fonts with varying width.

@sofar Do you have any further remarks?

EDIT: It might be a good idea to add you as a repository owner if you're interested to maintain this mod.

[Treer]

Yeah, these pull requests are not fair on you two. The original text of this PR was

When I said I was looking to make a lot of changes and sofar said "Just send PRs", the scope of changes wasn't obvious, so I'm raising this pull request early to be less of a shock/get earlier feedback.

And I raised the question of a dev branch in PR #13. On the bright side there's only a couple of feature I still want to add, and I have to slow down now.

I would be interested in being added to the nether repository owners list.

I'd really prefer to use images rather than ASCII art based on fonts with varying width.

The ascii art isn't good - I agree. I'm weak on formspec but I suspect implementing a markup language in the portal API so that you can include an image when calling register_portal() would not be simple.

The portal shape definitions could provide an image, but it would have to be without texture. Otherwise calls to register_portal() could be required to pass an image separately from the description string.

[Treer]

The Book of portals now uses images instead of ASCII art, and I think is much better for that criticism.

Because I don't know how much space text will take up, or where it will end, and I need coords to place an image and can't wrap text around it, I've spaced entries out as much as possible. With 4 entries this looks like quarter of a page each. Not the best typography but I'm sure you understand the limitations.

• Playing on a large screen with 3 portals enabled:

• Playing on a small screen with 3 portals enabled

• Version 0.4.17.1 doesn't provide the ability to scroll when text exceeds the textarea, but the important instructions are at the top of each portal description.

I don't know what it would look like on an android.

Normally there won't be 3 portals though. By default there's only one portal, which means the introduction is on the left page and the Nether Portal is on the right page.

if the Help modpack is installed then that is used instead:

[MoNTE48]

I can not wait for it to be merged.
It has been in the work for more than six months and looks finished for about month.

[SmallJoker]

I quickly checked the PR - looks good.

Before rebase & merging:

• Would you like to squash commits? "Last chance"
• Did the generated underground change in shape? Is it seamlessly compatible with old worlds?
  • It looks the same to me after some comparisons.

[Treer]

Thank you for looking at it.

I meant to mention when you said "changing most of the code in nether" that this PR should only be changing the portal code: the mapgen code is moved into mapgen.lua, and the nodes/crafting is moved into nodes.lua. I just did a diff on those files and the originals to make sure nothing important changed.

(PR #13 will make changes to the mapgen code, but still retains the original code in mapgen_nobiomes.lua for version 0.4 of MT and v6 mapgen worlds. Again PR #13 should be seamlessly compatible, with the exception of limiting the nether by user-adjustable default to 11000 deep. Can discuss that PR another time)

Take a tag or branch of the nether mod before the merge. Rolling back, or forward between the two branches shouldn't break anything.

I'm ok with a squash-commit, I think the history will be retained in my treer/nether fork. 70 commits for this change is too much.

I may have misunderstood "last chance", but have just pushed a minor change that was still sitting on my computer.

[SmallJoker]

@FaceDeer Okay, it's good to hear that the map will be compatible.

Would you like to squash commits? "Last chance"

With this I wondered whether you would like to squash some commits (git rebase -i HEAD~72) yourself before I'll push the entire PR as-is to master. For example trivial typo fixes or commits that kinda belong together. A single commit for this PR would not be justified - and barely usable to find the commit that introduced a problem.

[Treer]

ah, yes, I've squashed a bunch of commits.

The history is much tidier.

[SmallJoker]

It looks like the merge commit in your branch causes conflicts. I think it would be possible to merge by a merge commit, but the history will become non-linear this way (and more annoying to troubleshoot).

[Treer]

I've rebased it onto the current master. Should work now.

[SmallJoker]

Thanks for your efforts!