Ecliptic: galaxies should be able to issue planets

[juped]

In the launch version of Ecliptic, the planets that directly belong to galaxies are inaccessible. This is a niche issue - I (~rolsut-rospub) may be the only person directly affected. However, it's also uncontroversial - no one thinks it should permanently stay like that, it was just a matter of development triage - and may be a good candidate for a first contract upgrade, assuming nothing needs to be fast-tracked past it.

Enabling their use makes the logic of some functions somewhat more complex, so it's not a simple matter of just not disallowing them. However, it's not a huge task, and it's one I am willing to take on. I plan to work with Tlon's Azimuth team on this so we get it right, then I (~rep) will propose it on-chain once it has their endorsement.

[philipcmonk]

As far as I'm aware, this is the only part of the code that explicitly disallows spawning them:

azimuth/contracts/Ecliptic.sol

Lines 358 to 359 in 1cd367e

	require( (uint8(azimuth.getPointSize(prefix)) + 1) ==
	uint8(azimuth.getPointSize(_point)) );

What I don't know is whether the rest of the flow assumes things like "a point's children count fits in a uint16" or "a point's sponsor is always one level up" and whether they could be worked around. I suspect it's possible, but that's the first thing to check.

Obviously, anything in Ecliptic is upgradable, anything in Azimuth isn't really, so keep that in mind.

[Fang-]

For previous discussion, see #2.

When making this change, spawn- and child-related logic needs to be re-checked in all contracts. I'm unsure off the top of my head whether it matters anywhere, but the assumption during development was always "galaxies can spawn max 255 child ships".

azimuth/contracts/Ecliptic.sol

Lines 622 to 624 in 1cd367e

	if ( size == Azimuth.Size.Galaxy )
	{
	return 255;

[juped]

I read over the contracts (lightly) a while back and the data store (Azimuth contract) has either a 2^32 max or 2^256 max on everything. I don't think that much in Ecliptic besides spawn limits is implicated - some things, like escape logic (can only escape to one class higher) are not actually problems in my view (it's okay if escaping from your nonstandard class of parent is one-way).

I anticipate a lot more effort rechecking all the logic than in actually adding new logic.

[philipcmonk]

That's probably true. Of course, for Urbit to support these there may be changes required in the %jael vane as well. That's easier, though.

[juped]

I predate %jael so it's not familiar to me, but I will at least look it over.

[joemfb]

I suspect %ames is more likely to have an issue with this than %jael. The :dns app also might need some adjustment for this case. Happy to take a look when things settle down a little.

[juped]

Historically, it worked fine pre-jaeling of ames; depends on how much has been gutted.