Anti-paradox?

[flatball]

Pharo in progen queue sepi and octo
Turn Pharo into an Arcticus build sepi1 and octo1 send them back as progenoraters
Back in time sepi2 and octo2 are made (with the help of sepi1a and octo1a) send them back to become progenoraters
Cancel Pharo becoming Arcticus

Will sepi2 and octo2 still be created or will it all unravel? It’s very impractical but I still want to know if it would be achievable.

Though an interesting approach to finding an entry point into an ontological loop, it won't work because at the time of attempted entry, the unit(s) in question must already 'pre-exist' outside the loop. In this case, as with the previous example, the issue is with the "entry step", as the Pharo must have originally been made by something beforehand, not even mentioning that to make more units it needs the other progen units to already exist as well. A unit cannot be it's own parent/grandparent because it already had a unique parent to begin with, outside the loop.

Maybe this can explain it:
A makes B. B makes C. C jumps back to the past.
----
C can't make B because it was made by A.
C can't make A because 'some other unit' made it before that, or A existed the entire time from the start of the level.

[Shadowfury333]

On an unrelated note do you think you could upload the replay of that match I would really like to see kingjonh’s side of the battle (maybe you could do a deconstruction of the match)

KingJohnVI hosted the game, so he will have the replay.

[davesoft]

Pharo in progen queue sepi and octo
Turn Pharo into an Arcticus build sepi1 and octo1 send them back as progenoraters
Back in time sepi2 and octo2 are made (with the help of sepi1a and octo1a) send them back to become progenoraters
Cancel Pharo becoming Arcticus

Will sepi2 and octo2 still be created or will it all unravel? It’s very impractical but I still want to know if it would be achievable.

Though an interesting approach to finding an entry point into an ontological loop, it won't work because at the time of attempted entry, the unit(s) in question must already 'pre-exist' outside the loop. In this case, as with the previous example, the issue is with the "entry step", as the Pharo must have originally been made by something beforehand, not even mentioning that to make more units it needs the other progen units to already exist as well. A unit cannot be it's own parent/grandparent because it already had a unique parent to begin with, outside the loop.

Maybe this can explain it:
A makes B. B makes C. C jumps back to the past.
----
C can't make B because it was made by A.
C can't make A because 'some other unit' made it before that, or A existed the entire time from the start of the level.

The only real way into a paradoxic outcome is to abuse the immutable past. Cancelling far future events as the earlier events slip beyond the timewaves.
Grekim are good for cumulative time attacks and pre-breeding. Having a sepi and octo pumping out units in the past still allows another from the future to sit down and pump out units you couldn't back in the meta-past. Handy for hitting someone with tier3 tech back in the tier1 era, have to focus on teching up though..

Cumulative attacks are risky but I imagine there's a whole art to them. Set your progens to point to the HQ, do this very early on.
Whenever you want to make a 'big push' on the enemy make a bookmark with the F keys then give the HQ the order to attack.
Later in you can create units, assign them to the HQ (should be default if the progens point to it) and when you're happy, move you're new guys in to position and tell the HQ to chronoport to before your bookmark.
They'll arrive in the past and hook up to the past-HQ and recieve the order to attack. Great for 3prong attacks when you havn't actually built the units yet

Has the drawback that each time the departure order happens it'll send every unit assigned to it.. which can make amazing clouds of units but thier temporary and if the battle goes 'too' well all of your Qplasma will be spent looping these units till the immutable past swallows the situation and the units chronoport out of existance.


Not the RTS I thought it was initially...

When you get the game, practice on Iced with grekim. 5 units can become 50 rapidly, but it's all temporary.. time will sort itself out and the best you'll get are 5 slightly damaged units.

[omegatron]

As long as the pharo has an independent non paradoxial origin that should work. As long as the unit that received the order is still there the other progenerators don't matter.

[UsOurselvesAndWe]

I think you may have misunderstood, the pharo was the preexisting unit It had no hand In creating itself it merely survived up to this point.
The backdrop for all my examples was that it (the Pharo) was the sole survivor of a large battle (like the one from shadowfury’s video)

Here is an unabridged version of the scenario after the battle:
(Tn represents the iteration of events (T1 T2 T3 etc.), Sa Sb Sc will denote the iteration of sepi, and Oa Ob Oc for octo, there is only ever one iteration of the Pharo it does not travel in time though it does do different things given T)

T1
Pharo after battle goes into progen mode after an amount of time it leaves progen and moves to morph into an Arcticus.
The Arcticus then makes Sa and Oa
Sa and Oa chronoport to the time after the battle (that having been researched before the battle)

T2
Pharo is joined in progen by Sa and Oa of T1, they create Sb and Ob (Pharo being the one the orders are given to0
Pharo Sa and Oa stay in progen
Arcticus is never made as with Sa and Oa
Sb and Ob chornoport to after the battle (but before their creation)

T3
Sb and Ob join Pharo in progen (Sa and Oa do not arrive due to not being created in T2)
Pharo still has orders to create units
Sc and Oc are created
Sb and Ob stay in progen with Pharo

Will Sc and Oc have the order to chronoport (as in have the same ID’s as Sb and Ob) or will they be considered different units by the engine (making everything unravel in the UPP)?

Ultimate question: Is unit ID denoted from both parents or can one of them be swapped out for a different parent of the proper gender? If it is possible to change one parent and keep the child the same then this scenario will be perfectly acceptable, thus a grekim can become its own grandfather with not much problem at all, if not then my idea is a flop, no problem I’ll just move on to my next overly complicated plan, when I actually get the game I will probably post a few every month or so until I burnout.

[quote="omegatron"]As long as the pharo has an independent non paradoxial origin that should work. As long as the unit that received the order is still there the other progenerators don't matter.[/quote]

thinks omegatron i thought i read that somewhere a while back i didn't know if it was implemented or not though.

[Haiku]

Hmm, in my attempt to find a way to create an ontological paradox, I instead found what appears to be a way to permaclone... by using absurd amounts of chronoportation: (Also you may need several chronoporters).

send your unit back in time slightly more that the rechronoport delay, and give the same order to the resulting chronoclone when the re-chronoport delay wears off. You may need to observe the interval at double speed in order to get enough chronoports on the timeline before it hits the UPP depending on where in the timeline you are making it. Be careful about chronofragging your units. Just make sure the oldest chronoclone has no chronoport order.

Just after the arrival hits the UPP, undo the first chronoport order you gave, causing the mess to start to unravel, with each passing timewave erasing a unit. But just one unit per timewave. When the inconsistancy in the timeline reaches the past edge (if you did the right number of chronoports), there is still one arrival event remaining, which falls off the past edge becoming permanent. = clone.


Interestingly, you can use permacloned units to create what appears to be an ontological paradox to a hypothetical observer at the past edge (if it's an actual observer you may need another chronoport in the chain). Now lets say you permaclone a unit, and give the permaclone orders to build something then port back to its arrival time.

to an observer sitting on the past edge:
a unit arrives from the future, builds something and chronoports back to become its past self - ontological paradox.

[omegatron]

@UsOurselvesAndWe Yes, that will work. Sc and Oc will be the same as Sb and Ob so they will chronoport back to become they're own parents. I tested something like this a few versions back (I got a base class progen triangle and told the pharo to build a new pharo then told the pharo to become a spire, then I went back in time and replaced the octo and sepi and the pharo still got built and still became a spire).

[Shadowfury333]

The most important thing to making that work is to make sure that it was the pharo giving the progen orders, not the other two units.

[jseah]

The most important thing to making that work is to make sure that it was the pharo giving the progen orders, not the other two units.

That makes it not a "real" ontological paradox. You still need an input.

With a 'repeat orders' function, you can create a standalone ontological paradox. In the case of a tank looping through a chronoport cycle, you can cancel the production order for the tank at the factory and your tank still exists.

[omegatron]

The most important thing to making that work is to make sure that it was the pharo giving the progen orders, not the other two units.

That makes it not a "real" ontological paradox. You still need an input.

With a 'repeat orders' function, you can create a standalone ontological paradox. In the case of a tank looping through a chronoport cycle, you can cancel the production order for the tank at the factory and your tank still exists.

I don't see how it isn't a real ontological paradox, the octo and sepi are created by themselves and only becuase they exist. If you mean that the pharo has its own origin and the pharo has a part in making the octo and sepi then you could easily extend the whole thing for a pharo. After you have made the sepi and octo via the scenario already outlined you could use the octo and sepi to make a pharo and send that back in time to replace the original pharo. This way a whole grekim triad is able to make itself!