Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix Chronoshift-return and Iron Curtain being lost when a RA MCV (un)deploys. #15300

Merged
merged 5 commits into from Jul 22, 2018

Conversation

@pchote
Copy link
Member

pchote commented Jun 27, 2018

This PR fixes the long-standing inconsistency (and similarly long-standing balance complaint from parts of the community) where MCVs (but no other actors) can opt out of the chronoshift return by simply deploying (and then optionally undeploying) before the timeout expires.

The timeout is now remembered across deploy/undeploy cycles, and if the MCV is deployed when the timer runs out it will be returned to its origin in the undeployed form. take a 50% damage hit.

The ChronoshiftReturnTransformedActor trait, like the rest of the Chronoshift logic, lives in the Mods.Cnc dll and therefore is not considered a general purpose trait. There are a number of additional things that could be added to it as part of any future migration to Mods.Common, but for now these are out of scope.

Fixes #13473.

@pchote pchote added this to the Next release milestone Jun 27, 2018

@MustaphaTR

This comment has been minimized.

Copy link
Member

MustaphaTR commented Jun 27, 2018

I'm curious, what was the case in original?

@pchote

This comment has been minimized.

Copy link
Member Author

pchote commented Jun 27, 2018

I'm pretty sure that it wasn't.

@MunWolf

This comment has been minimized.

Copy link
Contributor

MunWolf commented Jun 28, 2018

I'm pretty sure the original didn't allow you to teleport the MCV at all.

@pchote pchote changed the title Chrono-return deployed MCVs in Red Alert. Fix Chronoshift-return and Iron Curtain being lost when a RA MCV (un)deploys. Jun 28, 2018

@pchote

This comment has been minimized.

Copy link
Member Author

pchote commented Jun 28, 2018

Added a commit to apply a similar fix for the Iron Curtain.

Suggested changelog: "Fixed Iron Curtain and Chronoshift status being lost when a MCV deploys."

@@ -158,6 +158,7 @@
<Compile Include="Traits\Attack\AttackTDGunboatTurreted.cs" />
<Compile Include="Traits\GpsDot.cs" />
<Compile Include="Traits\ChronoshiftReturnTransformedActor.cs" />
<Compile Include="Traits\TransferTimedExternalConditionOnTransform.cs" />

This comment has been minimized.

@MustaphaTR

MustaphaTR Jun 28, 2018

Member

Why put this on CnC dll? Sounds generic enough to me. Both Transforms and ExternalCondition traits are on Common dll.

This comment has been minimized.

@GraionDilach

GraionDilach Jun 28, 2018

Contributor

Because this is a hacktrait and we don't intend to extend it to general. See IRC log.

This comment has been minimized.

@pchote

pchote Jun 28, 2018

Author Member

Same as above: The implementation has fundamental limitations (listed in the [Desc]) that would make this trait a nightmare to support generally, and which can't be fixed. They are not a problem for our specific use case in RA, but i'm sure modders will soon run into them if we offered this for general use.

@ZxGanon

This comment has been minimized.

Copy link

ZxGanon commented Jul 1, 2018

I find this change very weird and odd.
But let me explain why:

  1. I´m sadly lacklustering about most traits of the original mechanics in Red Alert 1 but what I can tell is that in RA2 and RA3 it was a core mechanic to teleport your MCV and also being able to deploy it without it being teleported back (since obviously the reshifting of Chronosphere was removed in modern games since it was a huge flaw why the Chronospehe was so weak back than).

This change might weaken the Chronosphere even more than it already is. Also the Chronosphere in later CnC´s was even stronger and didnt had that downside.

  1. This change might affect the learning curve for new players in Ora aswell since they have learned that only Vehicles can teleported but not structures so why should the build up Conyard be teleported back?

  2. Even though it didnt happen in competitive 1v1 yet (but maybe in 2v2 and above) but it is such an interesting mechanic being able to chrono your MCV to try an invasion behind your opponents base.

I find it odd that people have complained about this change since it is nothing gamebreaking (at least in my point of view).

Can you guys send me the discussion of people complaining about this particular trait?

Edit:
I found the discussion spawned out of this: https://forum.openra.net/viewtopic.php?f=82&t=20569

I have to say this topic is far more constructed and well explained than I thought considering our community is...chaotic.

Im still not conviced about such a huge nerf to the RA1 Chronosphere since it still is way weaker than in Ra2 and above.

@WhoCaresora

This comment has been minimized.

Copy link

WhoCaresora commented Jul 1, 2018

I find that decision odd as well. I alwais saw the chrono basepush or "chrono hidden backline base" as a legit and valid strat in either 1V1 or teamgame. It is balanced as you know when its happen and like a simple basepush you have the same resources as your enemy to counter it if no more because you already have mmore structure than him and possibly your army around.

According to my memory to the old cnc, i never used the chrono in skirmish to attack but i remember it was my way to safely pull back in my base an ennemy's conyard after an enge cap and undeploying. So it was present in the original.

As a well establish mechanism and known by most players I don't see why it should be changed. It is not harder to counter than execute.

By making this change you will just make the strategy more costly, the work around is simple : prepare a war factory and an mcv on hold ready to exit : chronoshift, deploy : place WF : unhold the mcv and .... there you go same thing, 2000$ more costly and stronger because you have a vehicule production right on the spot instead of only cheap barrack and infantry. You can even use one of your expansion conyard as it will chrono-return safely after the operation.

As for IC, if it can be transfered on mcv -> conyard and vice versa, i fear (personal pov) it can become way stronger to start basepush or retreat an mcv safely for soviet. Right now it has a nice balance as you have to time your mcv movement deployement and IC application following what you want to protect; Standing basepushing conyard or retreating mcv. The transfert of IC would give too much flexibility for the soviet player to play with the mcv. But i would playtest it to make my mind.

@ZxGanon

This comment has been minimized.

Copy link

ZxGanon commented Jul 1, 2018

Also even though that might sound weird but teleporting MCV´s was a thing in multiple campaign missions and thats the first thing people see and recognize as "valid".

@HappyORA

This comment has been minimized.

Copy link

HappyORA commented Jul 1, 2018

Nerfing the already terrible Chronosphere. Which one of your balance gurus supported this? Obviously a soviet player.

@ZxGanon

This comment has been minimized.

@HappyORA

This comment has been minimized.

Copy link

HappyORA commented Jul 1, 2018

I see the strategic genius is onboard.

@pchote

This comment has been minimized.

Copy link
Member Author

pchote commented Jul 1, 2018

@ZxGanon Most of the complaints I have noted over the years have been from the wider community: comments in reddit posts, third party articles, our news post comments, etc. I can't reasonably go back and find these, so I will paraphrase what I felt was the key point behind these complaints: In team games you have two factors that combine to scale the effectiveness at an almost-quadratic rate. A 1v1 is fine because the build and repair rates have been tuned such that there doesn't seem to be a legitimate balance problem here. In a 2v2 you double not just the building rate, but also the repair rate. So you have more things to kill, and each thing is also harder to kill. This scaling increases super-linearly with larger teams.

You are welcome to dismiss my motivation here as hearsay because I can't provide sources, but I would like to think that most reasonable people in the community would trust that I am trying to act based on my 8 years of experience shepherding this community and monitoring feedback.

Ultimately, the thing that motivates me the most with this PR is consistency. You can argue all you want about balance one way or the other, but this is all hot air sitting on top of an inarguable technical bug. OpenRA's Iron Curtain and Chronoshift game mechanics are simple and very well defined: you use the power on a group of units, and they become invulnerable / teleport somewhere else for a fixed amount of time, before returning to their original state.

These behaviours apply to MCVs just as well as other vehicles. If you object to fixing this bug, then you need to justify why it is correct for a MCV that is left idle to remain invulnerable / return to origin like a normal unit, but for a MCV that is deployed and then immediately undeployed to lose its invulnerability / not return to the origin. From a gameplay perspective these cases should be identical, so how can we justify the difference?

Similarly, in all other aspects we try to make sure that there is no distinction between construction yards and MCVs: they are supposed (aside from a handful of bugs) to be seen as different states of the same unit – this is a well established fact across all of the games' lore. If you object to fixing this bug then you need to justify why it is correct for a unit to lose invulnerability / requirement to return when it changes state. What is special about MCVs? Why shouldn't this apply to MAD Tanks deploying, or to submarines when they submerge/surface, or to aircraft when they take off/land? The fact that this happens for MCVs only because of limitations in the transformation code is something that is irrelevant for players, and is what this PR solves.

Yes, this changes balance. Yes, this will break some long standing strategies, but also potentially opens new ones. This is how OpenRA has always worked: we fix bugs, and then adapt the balance to compensate for changes in the gameplay they introduce. It's absolutely fantastic that we have a dedicated 1v1 scene, but OpenRA is not PUBG or TF2 or some other "finished" game that is in maintenance mode. Core mechanics are still being worked on as contributors time allows, and this means that the gameplay will continue to evolve in the default mods. We expect players to either embrace this philosophy in good faith, or to find another game to play. It is unfortunate that OpenRA became much more popular at a time when development started to slow down, because many players became invested without realizing that this was part of what they were getting themselves into. I find myself having to explain this far too often to people who have already made up their mind that I must have a personal vendetta against them because I am trying to change things that they want to keep the same.

The moral of that story is not "you have no say in what is going to change so go away" it is "if your feedback is "I will not accept any change, so you go away" then you are not contributing to the discussion, and things will move forward without you". If we can start from the premise of "lets find a way to fix these bugs without ruining the balance" then we can find a compromise that more or less works for everybody.

@ZxGanon

This comment has been minimized.

Copy link

ZxGanon commented Jul 1, 2018

"lets find a way to fix these bugs without ruining the balance"
I planned to settle on this one right from the start.

@FRenzy-OpenRA

This comment has been minimized.

Copy link

FRenzy-OpenRA commented Jul 1, 2018

Thank you for your explanation , the change indeed follows a logical motive of bug correction and consistency, although might bring a balance problem indeed.

A copy-paste of an idea I posted on Discord, that might alleviate the balance change, and also go in the direction of consistency :

"" Also, I had an idea : if IC can affect buildings, why chrono can't ? That could be a fun idea to play with.

i.e. chronoing buildings temporarily somewhere else.

Example : chrono a WF to drop an MCV, a demo truck / defensive chrono to protect a building being attacked / chrono base defences near an ore patch / ... ""

Other ideas :
Happy : "i likee ganons idea of eveeryone getting german chrono"
Me : "there might be other ideas : play with timers / durations, chrono buildings, ...
maybe german chrono is 5x5, other 4x4
maybe all are 5x5, but german chrono lasts longer "

@CH4Code

This comment has been minimized.

Copy link
Contributor

CH4Code commented Jul 1, 2018

@pchote is it technically possible to have a lobby checkbox option (permanent chrono-mcv(y,n) ) for easing the transition period?

@pchote

This comment has been minimized.

Copy link
Member Author

pchote commented Jul 1, 2018

A simple option would be to scale the return delay based on the number of units being teleported. The standard Chronoshift footprint contains 5 cells, so we could maintain 20 seconds as the baseline if all cells are occupied. If the player chooses to shift only 3 units, then we could increase the delay to 20 * 5 / 3 = 33 seconds, or if they want to teleport a lone MCV then it could stay for 100 seconds – long enough to build a small supply base that could then produce its own MCV if the player wanted to.

Edit: Of course, the base 20 second delay was balanced based on old assumptions. The changes in game mechanic from this PR might be enough to justify revisiting that choice completely. The original game had this much longer, at something like two minutes IIRC. The original game also only allowed a single unit to be shifted, so this actually fits well with my suggestion above to scale the delay based on number of units.

@FRenzy-OpenRA

This comment has been minimized.

Copy link

FRenzy-OpenRA commented Jul 1, 2018

" or if they want to teleport a lone MCV then it could stay for 100 seconds – long enough to build a small supply base that could then produce its own MCV if the player wanted to. "

It is a very interesting idea, although it might be dangerous since IC should behave the same (for consistency) (or should it not ?)

Thus, a 100sec IC'ed unit / building might be too strong.

Could go for a linear interpolation between 1x 20sec for 5 units , to 2x 20sec for 1 unit, for instance, if we wanted to go that way.

@ZxGanon

This comment has been minimized.

Copy link

ZxGanon commented Jul 1, 2018

Exceptions are poison for an RTS game just saying since that kills of learning curve for new players and creates oddities later down the line (ala SC2 with inconsitency of units and drop behaviours that they had to fix later like Siege Tanks, Hellbats etc.).

@pchote

This comment has been minimized.

Copy link
Member Author

pchote commented Jul 1, 2018

I completely agree, hence this PR!

@ZxGanon

This comment has been minimized.

Copy link

ZxGanon commented Jul 1, 2018

@pchote After having an immense discussion with lots of my colleges from TS I´m pretty sure the answer behind this difficult task lies behind this question:

What was OpenRA´s goal again?

No matter now if balance or code related. Because this PR has a 4 sided medal now.
RA1 Chrono, modern RA2 Chrono, Bug and balance.

At this point the maker has to decide which way we go because if we go strict than the current IC isnt RA1 confirm either.

I answered the question for myself to go full RA2 way with the Chonrosphere because OpenRA modernizes old RTS titles that flawed by WW inconsistency and lack of experience we have now.

RA2 Chronosphere was a very good but simple idea to draw a straight line here BUG related or Balance.

@Smittytron

This comment has been minimized.

Copy link
Contributor

Smittytron commented Jul 1, 2018

Of course, the base 20 second delay was balanced based on old assumptions. The changes in game mechanic from this PR might be enough to justify revisiting that choice completely. The original game had this much longer, at something like two minutes IIRC.

One of the more positively received changes from Orb's Allied Overhaul went the other way, giving the chrono return a shorter time.

@pchote

This comment has been minimized.

Copy link
Member Author

pchote commented Jul 1, 2018

@ZxGanon that is a loaded question, and my experience with the community is that questions like that, when posed without context, are usually intended as a trap so that my words can be twisted in ways that I do not intend.

I feel that my comment above concisely presented the problem with treating MCVs as an exception, and why the changes in this PR are the most logical fix to them.

@ZxGanon

This comment has been minimized.

Copy link

ZxGanon commented Jul 1, 2018

Fair enough.

But you could also go after a specific line how ORA was intended and just do it.
In theory you do not have to be concerned with anyones opinion... but I´m happy that you are.

@avalach21

This comment has been minimized.

Copy link

avalach21 commented Jul 1, 2018

I strongly disagree with your perspective on this topic. Right off the bat.. the MCV is an absolutely unique unit in that it transforms into a structure.. No other unit does this in the game.. Units and Structures are separate. Once the MCV transforms.. it is a new entity.. it is a structure now and follows the rules of structures. Let us also remember that in the original RA1 this was permanent... the MCV literally goes through a metamorphosis, sheds all of its old traits. and becomes a new entity entirely - a structure.

Now let me make another critical point.. the chronoshift does NOT return everything to their original state at the time of chronoshift. Units that are destroyed during the chronoshift go through a "state change" - as in they used to be in a state of existence , but now after being destroyed, they are in a state of non-existence. The chronosphere does NOT return these units to their original state and respawn them "back in time" at their point of origin - They are permanently effected by their state change and are dead forever. In the same way, the MCV has had its state changed... the MCV has gone through a metamorphisis state change from a unit to a structure. From all perspectives of game logic/lore/common sense... structures CAN NOT, DO NOT and HAVE NEVER chronoshifted. It makes PERFECT SENSE from a game balance, game logic and game lore perspective for the Con Yard to not return after the chronoshift period is over. The current functionality of this is NOT A BUG. On top of this logical conclusion, it also matches the way it functions in the original game(s). I really think you need to reconsider your perspective on this issue.

If you want to tweak the code, I would say that yes, if the MCV is deployed, then undeploys and returns to the state of being an MCV at the end of the chronoshift period, then it should be returned (This would open up a plethora of new strats). The Chronosphere returns things back to their original teleport location but still in their current state. If the MCV is in a deployed state, then for "consistency" it needs to be returned to its point of origin in its current state. The Chronosphere literally can't handle returning it in it's current state "(Chronospheres can't teleport structures... never have they ever) so the structure stays there. Again, this is logically consistent, game-wise, lore-wise and balance-wise.

Thanks for your time if you read this.

@KOYK

This comment has been minimized.

Copy link
Contributor

KOYK commented Jul 1, 2018

How about fixing the more important stuff like path finding for example or the delay of passing commands to units like tanya when you smash the stop command and shes still going, doing the previews command and ending up dying. instead of doing this pr who as you can see no one who actually plays the game likes it.

Whats the point to all this any way @pchote? you are talking about a community some ware in the net. Don't you read your own forums? or github? Do me a favor and go check some games in ra and ask the players if they will like to see this pr or if they even agree to it in the first place. Do that and see with your own eyes and then talk about the opinion of the community if you manage to even get 20 out of 70 to agree with this it will be a unreal i tell you now.

Bottom line: this pr actually makes it worst than what you are trying to "fix" because I know that ill chrono 1 mcv and my team will be forced to spam war factories and then get out new mcv's with defenses, try to counter that. This my friend is not a "bug" or a problem. This is what Red alert is about if you want to make an other game be honest with as atleast, inform as about it and change the title to some thing else rather than red alert. We are here for red alert not something that resembles the name.

If this pr gets out ill go red alert unplugged and play there even if the servers are not that many. I might even pay for some servers in the end.

@pchote

This comment has been minimized.

Copy link
Member Author

pchote commented Jul 1, 2018

Once the MCV transforms.. it is a new entity.. it is a structure now and follows the rules of structures.

This may have been true in RA1 (where, like you say, it is a permanent one-way transformation), but IMO this certainly isn't the case in OpenRA's Red Alert. The MCV remains selected when it deploys and stays in the same control group. At some point in the future we hope to fix the bug where units lose their target when it transforms. Dynamic MCV play is a big part of the gameplay, with players deploying and undeploying at will.

RA1 was consistent in not returning the construction yard because like you said it was a permanent transformation to a building, and buildings can't be teleported. The inconsistency here comes from the change to encourage undeploying, which then leads to the issues that I explained in my comment above. I agree that teleporting the conyard back as the MCV isn't ideal, but it is a lot more consistent than what we have now, and i'm sure we can all agree that neither RA1's approach (removing undeploy) nor RA2's approach (removing the chrono-return) are viable for OpenRA.

Now let me make another critical point..

We may have to agree to disagree here. I don't think that this makes perfect sense, and the complaints i've noted and referred to above show that i'm far from the only person. Again, I don't think we can appeal to the original game here, because the root of the whole problem is that we changed the way that MCVs work to conflict with this logic.

if the MCV is deployed, then undeploys and returns to the state of being an MCV at the end of the chronoshift period, then it should be returned

This is definitely an option worth considering, but IMO this could be quite confusing as the return may then happen many minutes after the original chronoshift.

Thanks for your time if you read this.

Thank you for demonstrating how to contribute constructively to the discussion even while completely disagreeing with the premise.

@Smittytron

This comment has been minimized.

Copy link
Contributor

Smittytron commented Jul 1, 2018

I don't have a strong opinion on chrono mcv either way, and I've seen valid points on both sides. That said, it's hard to ignore that the discussion here and on discord about this has been strong and mostly one-sided against changing the current behavior.

I do like seeing the iron curtain transfer on deploy/undeploy, and would like to see that part of this PR go through.

@KOYK

This comment has been minimized.

Copy link
Contributor

KOYK commented Jul 1, 2018

Thank you for demonstrating how to contribute constructively to the discussion even while completely disagreeing with the premise.

If that is aiming at me then please tell me why the following I said was not constructive:

ill chrono 1 mcv and my team will be forced to spam war factories and then get out new mcv's with defenses, try to counter that.

And

Do me a favor and go check some games in ra and ask the players if they will like to see this pr or if they even agree to it in the first place

Also lets not turn this in to a thumb down contest please. At least say why you are disagreeing with my comment.

@pchote

This comment has been minimized.

Copy link
Member Author

pchote commented Jul 4, 2018

@Smittytron: Good catch. The .csproj entry got lost in the reworking/rebasing, but I didn't spot this because that file is only used for compilation on Windows. Fixed.

@Smittytron
Copy link
Contributor

Smittytron left a comment

Condition transfer works great. Only thing that looks out of place is that the Iron Curtain won't stop the damage of the chrono vortex. That said, a gameplay situation where an IC is used on a chrono'd MCV should be very rare.

The vortex went a little fast for my taste but I imagine things like speed and amount of damage can be decided later. (Or not at all if the plan is to eventually make the vortex a free-moving entity.)

@pchote pchote added the PR: Needs +2 label Jul 4, 2018

@pchote

This comment has been minimized.

Copy link
Member Author

pchote commented Jul 4, 2018

the Iron Curtain won't stop the damage of the chrono vortex.

This is actually deliberate. I wanted to shortcut any arguments about balancing for team games, and IMO it makes sense for a rip in space-time to damage the structure from the inside.


void INotifyCreated.Created(Actor self)
{
conditionManager = self.TraitOrDefault<ConditionManager>();

This comment has been minimized.

@abcdefg30

abcdefg30 Jul 5, 2018

Member

You are never checking for null, so this can become .Trait<ConditionManager>.

This comment has been minimized.

@abcdefg30

abcdefg30 Jul 5, 2018

Member

Same for positionable, I guess.


[GrantedConditionReference]
[Desc("Condition to grant while the vortex animation plays.")]
public readonly string Condition = null;

This comment has been minimized.

@abcdefg30

abcdefg30 Jul 5, 2018

Member

You are setting defaults for Sequence and Body that are pretty specific to this use case. Any reason you didn't include values for Condtion, Damage and OriginalActor as default values here?

This comment has been minimized.

@pchote

pchote Jul 5, 2018

Author Member

The condition and damage are to aid with self-documentation.


var max = chronosphere.World.Map.Grid.MaximumTileSearchRange;
foreach (var tile in self.World.Map.FindTilesInCircle(destination, max))
if (chronosphere.Owner.Shroud.IsExplored(tile) && positionable.CanEnterCell(tile))

This comment has been minimized.

@abcdefg30

abcdefg30 Jul 5, 2018

Member

Why are we checking IsExplored? (I.e. is there a technical reason, as this doesn't make sense to me otherwise.)

This comment has been minimized.

@pchote

pchote Jul 5, 2018

Author Member

This is copied from the Teleport activity. I agree that most of that code doesn't make sense, but changing that is out of scope of this PR.


void TriggerVortex()
{
if (!string.IsNullOrEmpty(info.Condition))

This comment has been minimized.

@abcdefg30

abcdefg30 Jul 5, 2018

Member

Do we want to check if conditionToken == ConditionManager.InvalidConditionToken here?

@@ -54,6 +54,7 @@ explosion:
TilesetOverrides:
DESERT: TEMPERAT
INTERIOR: TEMPERAT
paradox: factpdox

This comment has been minimized.

@GraionDilach

GraionDilach Jul 5, 2018

Contributor

You don't need this one anymore.

@pchote pchote force-pushed the pchote:chrono-return-deployed-mcv branch from 63b15c1 to cabf836 Jul 5, 2018

@pchote

This comment has been minimized.

Copy link
Member Author

pchote commented Jul 5, 2018

Updated.

@abcdefg30
Copy link
Member

abcdefg30 left a comment

00:32:49 (abcdefg30) pchote another thing: teleporting back doesn't keep the iron curtain
00:33:08 (abcdefg30) happens when you iron curtain an mcv, then deploy it shortly before the chrono timer runs out
00:33:15 (abcdefg30) so it deploys but gets teleported back as mcv
00:33:27 (abcdefg30) this mcv won't have an iron curtain
@abcdefg30

This comment has been minimized.

Copy link
Member

abcdefg30 commented Jul 6, 2018

Another thing I found which might be "wontfix" in this PR (see IRC):
noChrono.gif

Edit: Replay (and commit) can be found here https://github.com/abcdefg30/OpenRA/tree/noChrono

pchote added some commits Jun 27, 2018

Add ITransformActorInitModifier.
Remove hardcoded Cargo reference from Transform.
Add ChronoshiftDurationInit.
Fixes time remaining bar not displaying if selection
bars are enabled on killed actors.
Fix MCV deploy erasing Chronoshift history.
If the MCV is deployed as a Construction Yard when
the timer expires the structure will take a 50%
damage hit from a chrono-vortex.

If the MCV is in the process of (un)deploying it
will be returned in MCV form.

@pchote pchote force-pushed the pchote:chrono-return-deployed-mcv branch from cabf836 to 6d9e279 Jul 7, 2018

@pchote

This comment has been minimized.

Copy link
Member Author

pchote commented Jul 7, 2018

Fixed the chrono-curtain timing issue by calling the INotifyTransform and ITransformActorInitModifier interfaces (missing these was an oversight).

might be "wontfix" in this PR

Yes, lets leave this until the next playtest please.

@pchote pchote referenced this pull request Jul 8, 2018

Open

Chrono vortex #9778

@KOYK

This comment has been minimized.

Copy link
Contributor

KOYK commented Jul 11, 2018

@pchote I think the vortex idea is perfect. Adds to the game as a new exciting feature (To OpenRa specifically, because it already exist in the original, tho a bit different) And also serves as a good counter for the allied chronosphere without removing\changing the chronosphere ability it self. And creating the need for team micromanagement when the user decides to chrono an mcv on enemy territory.

Tho there is a small problem, not all mcv chronos are for invading enemy bases. Some times you chrono an mcv to an island to get the ore when blocked by enemy navy and you are unable to sent out a sea transport.
In that case I think that maybe having the vortex actually attack move to the chronosphere building last position it self, would be more preferable and Ill explain why:

Most users will place the chronosphere building in a safe location with some defenses and probably a nuke or tech center near by, thus having the vortex attacking that building location would make the user think twice before doing so. And also will cost him a great deal.
If he decides to place the chronosphere building in a far location then it would be still vulnerable from attacks by the enemy.

So in essence I think this will make it like a knife that cuts both sides, and that includes the users allies who would might also suffer from his mcv chrono.

Also adding to that I think it will need a cumulative number of uses in order for the chrono vortex to appear, For example this number could be based on the number of the allies the user has, considering the support he will get on a such (chrono mcv attack) so the higher the number of the allies will result in higher chances for vortex to appear. So you get 10% chances for vortex if you are in 2vs2 and 100% if you are on a game with 5vs5 or more players.

And about the vortex it self, please add some terrifying sound to it, that would make it epic.

@KOYK

This comment has been minimized.

Copy link
Contributor

KOYK commented Jul 11, 2018

Sorry for double posting my browser is retarded. I strongly recommend to add a lobby option for the entire pr (not for the IC)

Code updated.

@pchote

This comment has been minimized.

Copy link
Member Author

pchote commented Jul 22, 2018

As @abcdefg30 has explained in IRC that he is taking a few-month break from OpenRA, waiting for an updated review is only serving to delay the playtest. Any remaining issues can be addressed in a followup PR.

@pchote pchote merged commit fd49e48 into OpenRA:bleed Jul 22, 2018

2 checks passed

continuous-integration/appveyor/pr AppVeyor build succeeded
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.