RequiresOre & ProhibitsOre

[Akuukis]

Here are few things I found out myself that weren't documented. It would be nice to put it somewhere

1. Doc: RequiresOre & ProhibitsOre

Example:

        <RequiresOreSerial>
          <Ore>Iron</Ore>
        </RequiresOreSerial>
        <ProhibitsOreSerial>
          <Ore>Ice</Ore>
          <Ore>Platinum</Ore>
          <Ore>Gold</Ore>
          <Ore>Uranium</Ore>
        </ProhibitsOreSerial>

Note that this will not always work - currently generator takes a random roid checks it and either goes with it or discards. If it has already discarded 10 roids then it will take next one anyway regardless it follows rules or not.

2. Feature request

It would be nice to expose that maxTries variable to XML so I can raise it, i.e. when I pre-generate expensive worlds, or use it on sparse asteroid fields

[Equinox-]

I'm hesitant to expose maxTries. Since these worlds are procedural it incurs a permanent performance hit.

[Akuukis]

Current maxTries behavior effectively overloads RequiredOreSerial and ProhibitsOreSerial into something like "MoreLikelyOreSerial" and "LessLikelyOreSerial" at unknown and unpredictable weights. That's unexpected and not very use-able. IMO what's required is either

• strictly "Required" and "Prohibited",
• "MoreLikely" and "LessLikely" with variable (or at least predictable) weights,
• or both of them at the same time,

I understand your concerns about performance. I gave it a bit more thoughts and here's some more ideas:

1. expose maxTries only with adequate warnings, perhaps only in offline worlds, so that worldmakers like me can pre-generate my world for scenarios/campaign and take as much time (and lag) I need for it. That's million times faster than doing by hand anyway. Obviously, with intention to remove ProceduralWorld once world is done (or leave it with more sane settings, i.e. for factions only).
2. when maxTries are exceeded, skip the asteroid. That would make density effectively lower, but that doesn't matter much as I always preview my asteroid fields with eyes anyway.
3. Every time asteroid is generated, put its seed into a table of "last 100 found asteroids according to criteria XYZ". Once maxTries are exceeded, just take random seed from the correct table. This would generate identical roids here and there, but perhaps noone would even notice
4. The same as above but pregenerate the tables and include that as asset in mod folder. Would be better for performance but won't handle custom ores, so for those cases could fallback to what's above.
5. Register all different asteroid fields ore settings, and then slowly in background fill the queue of valid unused seeds until queue is full. Once engineer jumps to new asteroid field, drain from the queue.
6. Combination of 1, 3, 4, and 5.

[Equinox-]

This mod won't work for pregenerating worlds as the asteroids aren't saved to disk until modified.

As for require and prohibits I won't change the naming since it will break existing saves. I may be able to do something to make it backwards compatible.

I'll look into using some sort of lookup table to generate asteroids in a more predictable manner, probably using the last 100 generated table. Other things add a lot of complication.

It will never be truly requires/prohibits or predictable weights though. Some ores you literally can't control (like anything that mines iron)

On Tue, May 1, 2018, 03:04 Akuukis notifications@github.com wrote:

Current maxTries behavior effectively overloads RequiredOreSerial and ProhibitsOreSerial into something like "MoreLikelyOreSerial" and "LessLikelyOreSerial" at unknown and unpredictable weights. That's unexpected and not very use-able. IMO what's required is either

• strictly "Required" and "Prohibited",
• "MoreLikely" and "LessLikely" with variable (or at least predictable) weights,
• or both of them at the same time,

I understand your concerns about performance. I gave it a bit more thoughts and here's some more ideas:

1. expose maxTries only with adequate warnings, perhaps only in offline worlds, so that worldmakers like me can pre-generate my world for scenarios/campaign and take as much time (and lag) I need for it. That's million times faster than doing by hand anyway. Obviously, with intention to remove ProceduralWorld once world is done (or leave it with more sane settings, i.e. for factions only).
2. when maxTries are exceeded, skip the asteroid. That would make density effectively lower, but that doesn't matter much as I always preview my roid fields with eyes anyway.
3. Everytime asteroid is generated, put its seed into a table of "last 100 found roids according to criteria XYZ". Once maxTries are exceeded, just take random seed from the correct table. This would generate identical roids here and there,
4. The same as above but pregenerate the tables and include that as asset in mod folder. Would be better for performance but won't handle custom ores, so for those cases could fallback to what's above.
5. Register all different asteroid fields ore settings, and then slowly in background fill the queue of valid unused seeds until queue is full. Once engineer jumps to new asteroid field, drain the queue. This should be the most performant option as you won't feel the lag when jumping into asteroid field.
6. Combination of 1, 3, 4, and 5.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/Equinox-/SEProceduralWorld/issues/5#issuecomment-385638623, or mute the thread https://github.com/notifications/unsubscribe-auth/AAs7OCRMAKQz4HAvrds8r2y1B1vDElXBks5tuDMXgaJpZM4TrbvL .

[Equinox-]

Consider also adding an option to not spawn asteroids that don't satisfy the conditions.

[Akuukis]

That would be useful

[Equinox-]

Added ExcludeInvalid tag to AsteroidLayer.

Can't use last generated table due to client/server sync issues, will have to figure out something else. I'm going to close this since I don't really see any reasonable way to solve this without significant overhead. Currently asteroids are just really hard to control the ore distribution of and this has always been a bit hacky.