It would be great to be able to customize stargate address, mostly to prevent incoherent addresses such ass the ones with same glyph several times.

It would also be nice to have the 39th symbol (origin symbol), even if this one is fixed and non customizable (for obvious reasons) for each gate.

This way, combined with an option in global config to setup how many glyphs for what type of gate-travel (By that, I mean being able to choose to, for example, use 7 glyphs addresses to change dimension) would allow to use dimensions as planets and use real gate addresses from the show.

Just to add my own relevant wants to this issue:

How about an option for 1 stargate address per dimension? Default false. This would have two major benefits:

1. It'd be more like the show. Stargates are meant to be interstellar transportation systems. The Earth and Beta gates have the same address because they're on the same planet.
2. You could move a stargate without having to update the address lists on your offworld computers.
   In the event you have more than one stargate in a dimension, for outgoing, the receiving gate sees the same address regardless of which gate, because they're in the same dimension. For incoming, it could to the gate that's closer to 0,0. You could also de-power gates to keep them from being counted, replicating what the Russians did with the Beta gate but in a more intuitive method than detaching the DHD.

Alternatively:
How about an option for stargate addresses to be tied to the base block? Also default false. A piece of NBT data attached to the base block. It would also achieve point 2 in the above request.

What do you mean? Like, several chunks, like a 16x16 grid of chunks, all sharing a single gate address?

Precisely, yes.

What about a happy medium: address by region address? would allow wider sections to share an address, but still multiple addresses per dimension. If that's even possible?

This is an impossible suggestion. The gate address is calculated based on its chunk location and the dimension ID. Changing it so it can be custom would break every single stargate already placed in the world AND would be nothing short of against the entire cannon of Stargate itself.

From @madgician-vd
It would not be an impossible suggestion nor break anything.

1. Using a custom address would not necessarely mean, unlike your statement suggest, to remove the internal/original address...
   You just need to use the current existing address as an internal address and use a "custom_address" variable/property, which would default to internal address (and of course, if updated from old version, make existing gates having this field defaulting to internal field if empty).
   Doing so would, as said previously, not break anything existing, and would not be that hard to implement.

Interesting concept honestly though I see a couple issues, which are not impossible to fix.

Currently when the gate system does its chunk lookup for locating the other gate, it decodes the gate address upon dialing to load the tileEntity on the other end. In the above concept I would need to store a create a database that each gate would use during dialing to determine if it was a custom address, then re-route the chunk loading to the appropriate place.

I foresee one issue and that is duplicate gate addresses, or custom addresses that match chunk locations for gates that don't currently exist. It could be overcome.

This would also change the dialing sequence a bit since suddenly a gate wouldn't require 7 or 9 chevrons.

I fixed that chunk loading issue (dim wasn't loaded) a long time ago, apparently you've not even tried the 2.0.x versions.

I'm on 2.0.2, downloaded on curseforge.
md5 sum of the file: 2f2a2f07c0904b71fccd5c0c9dc5020a
If you fixed it a long time ago, it may be related to something with jed if I had this issue, or the way I generated my test dim. I'll make some tests later.

That's true, you would have to add a "matching index/table" (I don't like to use the word "database" for something so small, even if it's correct technically) if you need to decode coords + dim to preload chunks.
Rewriting dialing so it would give priority to "real address" in the case of both exists to avoid ingame exploits with using a custom address pointing to a real gate, and/or do duplicate check when entering the custom address when configuring the gate. Btw, I had some issues with multi-dim stargates in the past, if the dim wasn't loaded before, on first dial attempt, it returns an error, so rewriting dialing could be an opportunity to make that when an gate in an unloaded dimension is loaded, it loads it a bit sooner during the dialing sequence, so the first dial would work. (I worked around that with jed by loading dimensions on startup, had to since if the player logged out in a dim that is unloaded, he was teleported to dim0 when logging in back (if the dim was unloaded before or the serv restarted)).

So yes, it would not break anything since real addresses would still be usable if wanted, but it would definitely need some code-adjustments for most gate-related tools to support custom addresses. And imply a dupe-check that isn't required when addresses are determined only by the gate chunk's location.
This may not be a critical addition which would need high priority, but I still think it's worthy and would be appreciated by community, and to keep in mind for a later version.

This issue is pretty old, but using the same addresses than the show is a nice feature...

As i read through this issue - i think, a address alias is the best solution. Yes, you could probably use a address as alias which would probably result in a real address which would disable a certain gate, but the chance is pretty low, that you create a alias for a gate with a address which is already "in use".

The lookup could accomplish it like this:

• Address was entered
• Alias-Lookup to "real" address which translates to the chunk/dim address
• If no alias was found, try to dial like its doing it now
• If a alias was found, dial the alias but with the real address in mind

A alias could be set by a chat command by an admin, which would probably be sufficient.

/sgcraft alias <real-address> <new-address>

The new address needs at least 7 symbols and max 9 symbols obviously. This would allow an admin to create the "show"-stargates :)
In combination with the #121, this would create some well-known stargates you could probably just look up by googling ;)

Regards