Ported Allies 01 to the New Lua API #6377

Mailaender · 2014-08-31T11:33:19Z

Changes include:

Added an objectives panel with proper instructions that get updated during the mission.
~~The ore management hack in TickIdle has been removed (as in the desert-shellmap).~~
The soviet base alert got now got a real alarm sound to make enemy behavior easier to understand.

ScottNZ · 2014-08-31T11:40:31Z

mods/ra/maps/allies-01/map.yaml

@@ -259,11 +258,6 @@ Actors:
 		Owner: Greece
 		Health: 1
 		Facing: 128
-	Harvester: harv


I kind of prefer the current setup.

Well, I don't. Instead of inventing Harvester.Harvest in Lua and micromanaging instructions for the unit, I can just let automation kick in like we do for the RA desert shellmap and all TD mission. That is far more elegant.

I explicitly wanted the harvester to start where it did in the original :/

On 31/08/2014 11:42 p.m., Matthias Mailänder wrote:

In mods/ra/maps/allies-01/map.yaml:

@@ -259,11 +258,6 @@ Actors:
Owner: Greece
Health: 1
Facing: 128

Harvester: harv

Well, I don't. Instead of inventing Harvester.Harvest in Lua and
micromanaging instruction, I can just let automation kick in like we
do for the RA desert shellmap and all TD mission.

—
Reply to this email directly or view it on GitHub
https://github.com/OpenRA/OpenRA/pull/6377/files#r16934316.

I can try to teleport it to Location: 72,60 but why?

Why not? The harvester harvesting near your units at the start of the
mission was pretty notable in the original.

On 31/08/2014 11:52 p.m., Matthias Mailänder wrote:

In mods/ra/maps/allies-01/map.yaml:

@@ -259,11 +258,6 @@ Actors:
Owner: Greece
Health: 1
Facing: 128

Harvester: harv

I can try to teleport it to Location: 72,60 but why?

—
Reply to this email directly or view it on GitHub
https://github.com/OpenRA/OpenRA/pull/6377/files#r16934350.

Can't really find a quick and clean way to do it. You can still see the harvester working during the mission. I believe the harvester placement was a workaround for limitations in the Westwood engine which did not free actors on pre-placed buildings.

Also note:

Harvester: harv Location: 72,60 [...] Actor33: proc Location: 73,58

in map.yaml.

I ended up porting the FindResources activity from legacy to the new Lua API.

It's a significant difference when you consider the map size and that
with FreeActor the harvester will have to drive all the way around the
refinery to access the ore.

On 1/09/2014 2:26 a.m., Matthias Mailänder wrote:

In mods/ra/maps/allies-01/map.yaml:

@@ -259,11 +258,6 @@ Actors:
Owner: Greece
Health: 1
Facing: 128

Harvester: harv

Also note:

Harvester: harv Location: 72,60

[...]
Actor33: proc
Location: 73,58

in map.yaml.

—
Reply to this email directly or view it on GitHub
https://github.com/OpenRA/OpenRA/pull/6377/files#r16935172.

I see. Did not get that you meant this was related to timing.

ScottNZ · 2014-08-31T11:46:56Z

mods/ra/notifications.yaml

+		Beacon: beepslct
+		Alert: buzzy1


Alert is a bit too generic for this. There are other alert sounds like bleep6.aud.

ScottNZ · 2014-08-31T11:56:03Z

The ore management "hack" was deliberate, to show the ore silos being filled up and depleted.

Mailaender · 2014-08-31T11:57:05Z

Depleted by what? There is no production in the enemy base.

ScottNZ · 2014-08-31T11:59:37Z

It was to give the impression that the enemy as a whole was spending their cash, not necessarily at the base you were infiltrating. There's also more activity going on in the base.

Mailaender · 2014-08-31T12:11:40Z

I see, but I think the mission is far too short to note such a detail.

ScottNZ · 2014-08-31T12:32:03Z

This carries over to other missions as well.

obrakmann · 2014-08-31T12:57:02Z

I agree with Scott here that we need the TickTakeOre hack sooner or later again. Might as well just add it now.

A couple of issues I noted during gameplay:

Can you set Tanya's stance to HoldFire while you're at it, please? This has always been bugging me.
You need to add at least one objective to the USSR, and either add one for England as well, or set England to NonCombatant. Otherwise the mission won't end properly.

obrakmann · 2014-08-31T13:01:07Z

mods/ra/maps/allies-01-classic/allies01.lua

-	end
+	local i = 1
+	Utils.Do(CruisersReinforcements, function(cruiser)
+		local ca = Actor.Create(cruiser, true, { Owner = england, Location = SouthReinforcementsPoint.Location })


Now that we can do addition with CPos and CVec values, maybe you could change this so the cruisers don't all start on top of one another

Good idea. Done.

Mailaender · 2014-08-31T14:20:12Z

Adding resources just to remove them every tick sounds super braindead to me, but you are the reviewers I have to satisfy. I also guess that my protest has been noted that spawning a harvester right next to the refinery and manually telling the it to find resources is more than complicated so I also give up on that.

Updated.

obrakmann · 2014-08-31T16:10:17Z

Adding resources just to remove them every tick sounds super braindead to me

It is, but it's needed to avoid the "harvester unloading forever" animation. If that worked differently, we wouldn't need it (for all I care, anyway).

Anyway, this still doesn't quite work correctly when you lose. You can fix that by marking the Soviet objective as completed instead of marking Greece's objective as failed.

(Background: the way you did it would have worked if you only had two combatants. But you have three, and the mission only ends when all non-combatants have a defined win state. When a player wins, he marks all his enemy's remaining objectives as failed. When you fail one of Greece's objectives instead, Greece has WinState.Lost and sets USSR's win state to Won, but England's win state is still undefined. When you do it the other way around, the USSR sets both Greece's as well as England's win state to Lost and the game ends.

The other case - the player winning - works because, as I mentioned above, the winning player causes his enemy's remaining objectives to fail. This causes the enemy to lose. When a player loses, he sets his enemy's win state to Won. So Greece's win causes USSR to lose which causes England to win. Now all three players have a defined win state and the game ends.

The only reason it's done this way is to ensure that all the checkboxes are crossed correctly when a player loses.

And the reason why losing and winning is handled differently is because when a player wins, it means that his enemies failed their (remaining) objectives. But when a player loses, it does not automatically mean that his enemies have completed their objectives. It does mean that they have won, though.)

Mailaender · 2014-08-31T17:22:51Z

It is, but it's needed to avoid the "harvester unloading forever" animation. If that worked differently, we wouldn't need it (for all I care, anyway).

The harvester unloading forever is also resolved by just making resources take no space.

obrakmann · 2014-08-31T17:26:30Z

Yes, in this case, where the AI doesn't actually need the money. In other maps it will be different.

Mailaender · 2014-08-31T17:28:02Z

You are in fact both right. In the second mission #6379 you will already need to harvest yourself so making ore generally take no space is a bogus workaround there.

Mailaender · 2014-08-31T18:33:12Z

Anyway, this still doesn't quite work correctly when you lose. You can fix that by marking the Soviet objective as completed instead of marking Greece's objective as failed.

I did both now.

pchote · 2014-08-31T19:46:48Z

OpenRA.Mods.RA/Scripting/Properties/AircraftProperties.cs

+
+		[ScriptActorPropertyActivity]
+		[Desc("Fly within the cell grid.")]
+		public void Fly(CPos cell)


This should be called Move, to match what we have for ground units.

Mailaender · 2014-09-28T05:48:56Z

Disposed copy. Added addtional .IsDead checks for both einstein and heli. Merged #6598 temporarily to test it.

abcdefg30 · 2014-09-28T08:34:25Z

Maybe add what @obrakmann did on gdi01:

Trigger.OnObjectiveCompleted(player, function(p, id)
    Media.DisplayMessage(p.GetObjectiveDescription(id), "Objective completed")
end)
Trigger.OnObjectiveFailed(player, function(p, id)
    Media.DisplayMessage(p.GetObjectiveDescription(id), "Objective failed")
end)

obrakmann · 2014-09-28T08:48:18Z

this can be rebased now

Mailaender · 2014-09-28T08:53:28Z

Rebased and added the automatic textual objective notifications as suggested.

abcdefg30 · 2014-09-28T09:16:01Z

👍

obrakmann · 2014-09-28T10:08:59Z

👍
Congrats! This has been quite laborious, but I think both the mission and our API are now better for it.

Ported Allies 01 to the New Lua API

obrakmann · 2014-09-28T10:11:47Z

Changelog

Mailaender · 2014-09-28T11:26:15Z

Definitely worth it. Going to finish #6379 now.

Mailaender · 2014-09-28T11:58:58Z

https://github.com/OpenRA/OpenRA/wiki/New-Lua-API/_compare/03299b312ead249e160ff8b78cc2c708b582fc6f...c1e9cce3da43fb0bf9a9fae49c6ba72ebb2d04a1

LipkeGu · 2014-10-04T08:01:57Z

Allies01: There is a prblem with the second objective, all civilians get killed right after the start of the mission :(

Mailaender · 2014-10-04T08:02:45Z

There is a problem with your reflexes, you need to be quick to power off the tesla coils. =)

LipkeGu · 2014-10-04T08:03:54Z

lol okay ;)

Mailaender changed the title ~~Ported Allies 01 to the New Lua~~ Ported Allies 01 to the New Lua API Aug 31, 2014

Mailaender mentioned this pull request Aug 31, 2014

Port missions to the new Lua API #5490

Closed

2 tasks

ScottNZ reviewed Aug 31, 2014
View reviewed changes

Mailaender force-pushed the allies-01-new-lua branch from 435179d to a588726 Compare August 31, 2014 11:45

ScottNZ reviewed Aug 31, 2014
View reviewed changes

Mailaender force-pushed the allies-01-new-lua branch 2 times, most recently from 82c320f to 42047e5 Compare August 31, 2014 11:51

Mailaender force-pushed the allies-01-new-lua branch from 42047e5 to 666f990 Compare August 31, 2014 12:21

obrakmann reviewed Aug 31, 2014
View reviewed changes

Mailaender mentioned this pull request Aug 31, 2014

Desert shellmap Lua maintenance #6378

Merged

Mailaender force-pushed the allies-01-new-lua branch from 666f990 to 3c78a89 Compare August 31, 2014 14:20

Mailaender added the PR: Review me! label Aug 31, 2014

Mailaender force-pushed the allies-01-new-lua branch from 3c78a89 to f0716d9 Compare August 31, 2014 18:33

pchote reviewed Aug 31, 2014
View reviewed changes

pchote mentioned this pull request Sep 27, 2014

Implement cell triggers. #6574

Merged

Mailaender added the PR: Has dependencies label Sep 28, 2014

Mailaender force-pushed the allies-01-new-lua branch from bf84d01 to cbaecab Compare September 28, 2014 05:49

Mailaender mentioned this pull request Sep 28, 2014

Fix Lua API interaction with destroyed actors #6598

Merged

Mailaender removed the PR: Changes requested label Sep 28, 2014

obrakmann added PR: Rebase me! and removed PR: Has dependencies labels Sep 28, 2014

port allies-01 to new Lua API

867ebce

Mailaender force-pushed the allies-01-new-lua branch from cbaecab to 867ebce Compare September 28, 2014 08:53

Mailaender removed the PR: Rebase me! label Sep 28, 2014

obrakmann added a commit that referenced this pull request Sep 28, 2014

Merge pull request #6377 from Mailaender/allies-01-new-lua

20a41d8

Ported Allies 01 to the New Lua API

obrakmann merged commit 20a41d8 into OpenRA:bleed Sep 28, 2014

Mailaender deleted the allies-01-new-lua branch September 28, 2014 11:25

Mailaender mentioned this pull request Sep 28, 2014

Ported monster tank madness to lua #6552

Merged

This was referenced Oct 16, 2014

Wish: New lua functions #5957

Open

Made use of various additional sound files in Red Alert #6601

Closed

Mailaender mentioned this pull request Oct 26, 2014

Fixed sound overlapping with full motion video clips #6848

Merged

Mailaender mentioned this pull request Dec 6, 2014

Removed the need to give NPCs fake objectives to properly end the game #7081

Merged

Ported Allies 01 to the New Lua API #6377

Ported Allies 01 to the New Lua API #6377

Conversation

Mailaender commented Aug 31, 2014

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ScottNZ commented Aug 31, 2014

Mailaender commented Aug 31, 2014

ScottNZ commented Aug 31, 2014

Mailaender commented Aug 31, 2014

ScottNZ commented Aug 31, 2014

obrakmann commented Aug 31, 2014

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Mailaender commented Aug 31, 2014

obrakmann commented Aug 31, 2014

Mailaender commented Aug 31, 2014

obrakmann commented Aug 31, 2014

Mailaender commented Aug 31, 2014

Mailaender commented Aug 31, 2014

Choose a reason for hiding this comment

Mailaender commented Sep 28, 2014

abcdefg30 commented Sep 28, 2014

obrakmann commented Sep 28, 2014

Mailaender commented Sep 28, 2014

abcdefg30 commented Sep 28, 2014

obrakmann commented Sep 28, 2014

obrakmann commented Sep 28, 2014

Mailaender commented Sep 28, 2014

Mailaender commented Sep 28, 2014

LipkeGu commented Oct 4, 2014

Mailaender commented Oct 4, 2014

LipkeGu commented Oct 4, 2014