Addon Idea - No jail switch releases......

[tarquin]

I must have removed too many packages from the compile list...

Remember the JDN too.
In fact, now it's on the JDN, the list on the forums should probably go.

 

[Mychaeel]

It's obviously been a while since I coded in Uscript...

See this posting of mine. It has an updated UMake version.

 

[tarquin]

/me feels rusty.

I have forgotten everything I ever knew about Jailbreak!

How do I get hold of the other team's JBTagTeam.CountPlayersJailed() so I know to start an arena match? -- EDIT -- got it, I think.

And any ideas on the correct way to disable the switches?

And what sort of visual effect should the switches have?
Isn't there another Addon that disables switches? Perhaps switch-disabling should be moved into the switch class?

Also, all our maps have only one arena. Is it safe to assume this will always be the case? A map with more than would mostly get the first one playing if I do that.

Not sure how to detect an arena win & open the jail either. EDIT: I am stupid...

 

[Jrubzjeknf]

JBAddonOvertimeLastChance locks the locks P)

 

[The_Head]

That only happens instead of overtime.
This addon means locks don't happen throughout the whole match.

Although some of the code could overlap quite a bit I guess

 

[tarquin]

Problems...

The script log shows this after I win in the arena:

Warning: JBInfoJail JB-Boring-015.JBInfoJail1 (Function Jailbreak.JBInfoJail.CancelRelease:0010) Accessed None 'Team'
Warning: JBInfoJail JB-Boring-015.JBInfoJail1 (Function Jailbreak.JBInfoJail.CancelRelease:00C3) Accessed None 'Team'
Warning: JBInfoJail JB-Boring-015.JBInfoJail1 (Function Jailbreak.JBInfoJail.CancelRelease:00DF) Accessed None 'Team'
Warning: JBInfoJail JB-Boring-015.JBInfoJail1 (Function Jailbreak.JBInfoJail.CancelRelease:00FA) Accessed None 'Team'
Warning: JBInfoJail JB-Boring-015.JBInfoJail1 (Function Jailbreak.JBInfoJail.CancelRelease:0122) Accessed None 'Team'
Warning: JBInfoJail JB-Boring-015.JBInfoJail1 (Function Jailbreak.JBInfoJail.CancelRelease:0151) Accessed None 'Team'
ScriptLog: Winner's pawn: JB-Boring-015.xPawn
ScriptLog: Winner's team: 0
Warning: JBInfoJail JB-Boring-015.JBInfoJail0 (Function Jailbreak.JBInfoJail.CancelRelease:0010) Accessed None 'Team'
Warning: JBInfoJail JB-Boring-015.JBInfoJail0 (Function Jailbreak.JBInfoJail.CancelRelease:002D) Accessed None 'Team'
Warning: JBInfoJail JB-Boring-015.JBInfoJail0 (Function Jailbreak.JBInfoJail.CancelRelease:0053) Accessed None 'Team'
Warning: JBInfoJail JB-Boring-015.JBInfoJail0 (Function Jailbreak.JBInfoJail.CancelRelease:006F) Accessed None 'Team'
Warning: JBInfoJail JB-Boring-015.JBInfoJail0 (Function Jailbreak.JBInfoJail.CancelRelease:008A) Accessed None 'Team'
Warning: JBInfoJail JB-Boring-015.JBInfoJail0 (Function Jailbreak.JBInfoJail.ResetObjectives:00AA) Accessed None 'Team'
Warning: JBInfoJail JB-Boring-015.JBInfoJail0 (Function Jailbreak.JBInfoJail.ResetObjectives:00B2) Accessed None
Warning: JBInfoJail JB-Boring-015.JBInfoJail0 (Function Jailbreak.JBInfoJail.CancelRelease:0151) Accessed None 'Team'
ScriptLog: Winner's pawn: JB-Boring-015.xPawn
ScriptLog: Winner's team: 0

The function in the game rules is:

function NotifyArenaEnd(JBInfoArena Arena, JBTagPlayer TagPlayerWinner)
{
  // for each jail, trigger with the pawn of the TagPlayerWinner
  local JBInfoJail firstJail, Jail;

  firstJail = JBGameReplicationInfo(Level.Game.GameReplicationInfo).firstJail;
  for (Jail = firstJail; Jail != None; Jail = Jail.nextJail) {
    Jail.Trigger(TagPlayerWinner.GetPawn(), TagPlayerWinner.GetPawn() );
    log( "Winner's pawn:" @TagPlayerWinner.GetPawn() );
    log( "Winner's team:" @ TagPlayerWinner.GetTeam().TeamIndex  );
  } 
}

any thoughts?
my brain is melting & I'm off to bed...

and I think there's a bug in JBInfoJail:
line 801, CancelRelease(TeamRelease);
It's possible to get to this line and TeamRelease be None.

 

[Mychaeel]

Call the JBInfoJail.Release method (line 369) if you wish to release a team from a given jail. (The "Release" method doesn't query JBGameRules anymore, though, but that's probably desirable here anyway.)

// release all players from the winner's team
for (thisJail = firstJail; thisJail != None; thisJail = thisJail.nextJail)
  thisJail.Release(TagPlayerWinner.GetTeam(), None);

That said --

The Trigger method expects a GameObjective as its first argument (ActorOther, may be None), i.e. the Actor which was triggered by the instigator -- not the instigator itself; on the other hand, given the Pawn you pass as the second argument, that shouldn't be a problem (if that Pawn actually belongs to a team).

You're right that the CancelRelease call should be inside the preceding "if", given that that "if" is there in the first place.

 

[tarquin]

The Trigger method expects a GameObjective as its first argument (ActorOther, may be None), i.e. the Actor which was triggered by the instigator -- not the instigator itself; on the other hand, given the Pawn you pass as the second argument, that shouldn't be a problem (if that Pawn actually belongs to a team).

That's what I was thinking too!
Bit baffled as to what's going on, but your suggestion has fixed it anyway.

the code:

  log( "Winner's tag -> pawn:" @TagPlayerWinner.GetPawn() );
  log( "Winner's tag -> team:" @ TagPlayerWinner.GetTeam().TeamIndex  );
  log( "Winner's tag -> pawn -> team:" @TagPlayerWinner.GetPawn().GetTeam().TeamIndex );

and the log:

ScriptLog: Winner's tag -> pawn: JB-Collateral.xPawn
ScriptLog: Winner's tag -> team: 0
Warning: JBGameRulesProvingGround JB-Collateral.JBGameRulesProvingGround (Function JBAddonProvingGround.JBGameRulesProvingGround.NotifyArenaEnd:00C0) Accessed None 'Pawn'
Warning: JBGameRulesProvingGround JB-Collateral.JBGameRulesProvingGround (Function JBAddonProvingGround.JBGameRulesProvingGround.NotifyArenaEnd:00C9) Accessed None
ScriptLog: Winner's tag -> pawn -> team: 0

What does "Accessed None 'Pawn'" actually mean -- that the Pawn it tried to access is None, or that a property of the Pawn is None?

You're right that the CancelRelease call should be inside the preceding "if", given that that "if" is there in the first place.

Want me to fix that?

I'm destroying all GameObjectives in NotifyRound, and my log shows I'm finding some. Any idea why I still see them in game?

 

[Wormbo]

Accessed None warnings include variable names, i.e. a property called 'Pawn' in this case. However, this is not very reliable when accessing return values of functions directly.

 

[tarquin]

A question for you all:

What about restoring the release switch for the Last Man to have something to aim for?
Eg, if only one blue player free, the blue switch opens up again.
If only one of each team, it's like regular JB again.
... until other playes are released, of course.

 

[The_Head]

Now that is a cool idea
with one of each team the switchs should stay block imo. Perhaps Even transfer the players across to the arena and they battle it out for the round?

 

[tarquin]

with one of each team the switchs should stay block imo. Perhaps Even transfer the players across to the arena and they battle it out for the round?

The arena is nearly always in use with these rules. Hard to start another match in it.

Which reminds me, if there's a tied arena match, another one should be started right away.

As soon as I can fix this problem removing the switches (help welcome ), I'll release an Alpha and we can all try it & see what we think of the gameplay this produces.

 

[The_Head]

Ok, are you just de-activating the switchs, or litrally removing them?
I'm no coder but I imagine the latter would be easier.
Just have them not even loaded up on start of a match.

 

[tarquin]

Ok, are you just de-activating the switchs, or litrally removing them?
I'm no coder but I imagine the latter would be easier.
Just have them not even loaded up on start of a match.

For now, removing them -- or at least I would like to. I can't get it to work.

In the longer term, deactivating them, so we could allow for features such as restoring them for certain game conditions.

 

[Jrubzjeknf]

JBAddonOvertimeLastChance already deactivates switches, even though it's only in overtime. Get some code from there

 

[Mychaeel]

I'm destroying all GameObjectives in NotifyRound, and my log shows I'm finding some. Any idea why I still see them in game?

There's a problem -- most (if not all) GameObjectives placed in UnrealEd are bStatic and/or bNoDelete (inherited from NavigationPoint) and thus cannot be destroyed at runtime.

Perhaps I could add another few hooks in JBGameRules, say, "CanBotAttackObjective" and "CanBotDefendObjective", which would be queried whenever bot support wants to know whether to consider sending a bot to attack or defend a switch. Would that help?

 

[tarquin]

Perhaps I could add another few hooks in JBGameRules, say, "CanBotAttackObjective" and "CanBotDefendObjective", which would be queried whenever bot support wants to know whether to consider sending a bot to attack or defend a switch. Would that help?

Yes, that would help. I was wondering how to stop the bots from going for it.

Since several add-ons seek to disable switches, what about moving the common code into the switch class?
(The addons would need to check for the case that maps use another type of device to open jails, but I don't we have any maps like that.)

 

[Mychaeel]

What does "disabling switches" entail other than implementing "CanRelease", "CanBotAttackObjective", "CanBotDefendObjective" in JBGameRules?

If there's nothing else, perhaps there could be a single additional method "IsObjectiveEnabled" in JBGameRules which is then used in the inherited default implementation of those other three methods.

 

[tarquin]

Visual effects?

EDIT: scratch that.
The Overtime Add-on puts a blocker around the switches, but I think for this one I'd just want the lock & basket to disappear.

 

[Mychaeel]

Yes, that would help. I was wondering how to stop the bots from going for it.

I've mulled over that a bit... (bear with me, this is going to be a little technical.)

Bot deployment is reassessed every couple of seconds during gameplay, individually for each team. This happens on two tiers:

• First, the bot code ponders the current situation and decides how many players (including human players!) should be attacking or defending each switch, in total. Individual players (or bots) aren't looked at at this stage. (This is why Jailbreak needs to figure out what human players are up to as well, as displayed in the scoreboard.)
  
  
• Then, the bot code goes through all bots and reassigns those which are currently surplus at the switch they're attacking or defending to the nearest objective which still needs more attackers or defenders.

Each of those stages could provide a JBGameRules hook:

• The first tier could provide a CanObjectiveBeAttacked/CanObjectiveBeDefended hook. You couldn't prevent individual bots from attacking or defending a given switch, just keep an entire switch from being attacked or defended (by bots) as a whole; but that could be intelligently taken into account by to deploy more bots to other switches, for example.
  
  
• The second tier could provide a CanBotAttackObjective/CanBotDefendObjective hook. You could decide whether a certain bot can attack or defend a given objective, but global team tactics wouldn't be able to take that decision into account anymore. (Another bot who hasn't been given such a distaste for that particular objective might fill in for him, though.)