CoopTranslocator

[Buggie]

5 version.

- Support extends Translocaltor for reorder like Barbie server does.

CoopTranslocator5.zip

[Barbie]

Thanks for V5.
I stumbled over these lines:

Code: Select all

// remove old CoopTranslocator if already have
...
if (Inv.isA('CoopTranslocator')) {
	if (Inv.class != class'CoopTranslocator')
		Inv.Destroy();

This means that you destroy all sub classes of class'CoopTranslocator'.

The question raises what happens if you have Actors with the same name from different packages. Can you keep apart them? Is the usage of the package name in "IsA()" valid? Like "IsA('Packagename.Actorname')".

[Buggie]

This means that you destroy all sub classes of class'CoopTranslocator'.

No. This means destroy all CoopTranslocator and its subclasses except current. Which it is CoopTranslocator5.CoopTranslocator.

It is happens because linker expand class'CoopTranslocator' to first matched loaded package. Which currently CoopTranslocator5.
But if I specify in EditPackages
EditPackage=CoopTranslocator
EditPackage=CoopTranslocator5

Then class'CoopTranslocator' == class'CoopTranslocator.CoopTranslocator' and class'CoopTranslocator' != class'CoopTranslocator5.CoopTranslocator'.

The question raises what happens if you have Actors with the same name from different packages. Can you keep apart them? Is the usage of the package name in "IsA()" valid? Like "IsA('Packagename.Actorname')".

class'Packagename.Actorname' is 100% work.

native(303) final function bool IsA( name ClassName );

isA require name as param. So you can not use double quotes here (which produce string). You need single quotes.
When you use single quotes it is name. Name can not contain dot. So no, you can not specify package in isA call.

But you can get class and check is it subclass of your desired class via:
native(258) static final function bool ClassIsChildOf( class TestClass, class ParentClass );
if (ClassIsChildOf(actor.class, class'Packagename.Actorname'))

-----
I choose this behavior (delete all other CoopTranslocators) because CoopTranslocator can be embedded into MH and can not be switched off.
I do not think exists any other CoopTranslocator which not CoopTranslocator at all and something else AND server admin want them both (this one and another).

[Eternity]

There once was the same problem with 'B_MonsterSpawner' class that comes from packages named differently. For this reason related code (of the counter that counts not spawned Scripted Pawns) worked properly only for the class that comes from the one package - that one which the code was compiled with. (?..) The function IsA('B_MonsterSpawner') was returning 'True' only for the class loaded from that one package (?..)

[Buggie]

I show how to do such check above. Nobody change IsA implementation and break A LOT of exists code.

Code do what do. Not what you want or mean when write code.

[Eternity]

Thank you for info.
I have done a little test to understand 'IsA()' behavior for myself... (pastebin.com/xcAxdHaX)
No this question anymore.

[Buggie]

6 version.

- Can not use tele for hacks anymore.
- Can not tele to players when they move up. Usually it break jump and destroy traectory, so target can fall in lava or die by this fall.
- The player can temporarily disable teleportation to himself via the "mutate cooptrans disable" command. The administrator can disable this behavior in UnrealTournament.ini.

If a player has disabled teleportation to himself, then he himself cannot teleport to other players.
The disable time is set separately. If you specify zero time, the function will be disabled.

Code: Select all

[CoopTranslocator6.CoopTranslocator]
DisableTargetTime=30
DisableUseTime=30

CoopTranslocator6.zip

[Barbie]

Very nice that you improve existing stuff.

If a player has disabled teleportation to himself, then he himself cannot teleport to other players.
The disable time is set separately. If you specify zero time, the function will be disabled.

If I've understood it correctly, the CoopTranslocator activates itself after *DisableUseTime* seconds? Is it possible that you can make it just toggling between on/off? Of course there should be a fixed delay after activation to avoid nut picking (disable it while you are in a good position and enable it only if you want to get to a player with a better position).
Also messages on activating/deactivating would be nice.
To make it fully configurable, you could add the following INI values:

Code: Select all

[CoopTranslocatorX.CoopTranslocator]
;Mutate command. Use empty string to disable mutate function.
CoopTranslocatorMutateCommand="CoopTranslocator"
;Number of characters from left that must match the command string ("0" means "all").
;E.g. "5" means that "CoopT" to "CoopTranslocator" will result in the same command
CoopTranslocatorMutateCommandMinMatchChars=5
CoopTranslocatorMutateCommandEnable="enable"
CoopTranslocatorMutateCommandDisable="disable"

Ofc all strings case insensitive.

Examples:
________________________________________
mutate CoopTranslocator enable
>Your CoopTranslocator will be usable in xy seconds.
________________________________________
mutate coopt disable [disable seconds time]
>Your CoopTranslocator is switched off now and you cannot be reached by team mates. Use "mutate CoopTranslocator enable" to activate it.
>Your CoopTranslocator is switched off now for xy seconds.

[Buggie]

Initially, I was going to do it just on / off. But you just said it wasn't very good. Therefore, such a scheme was implemented.
Perhaps I misunderstood your idea.

In general, both approaches have the right to life. we just need to understand what problems we are going to solve with them.

It may be necessary to make a 3 second invulnerability after teleportation to solve some problem.

It all depends on the essence of the problem.

At the moment I see problems like this:
1. Chasing the player using teleports. (For example, to cure Miro )
2. Inexperienced teleportation which leads to a team kill.
3. Teleportation to the player, which results in a sharp deterioration in the situation. For example, it teleports and collects very strong monsters on you, which kill you immediately.

It is necessary to determine which problems will be solved and in what ways.
---
Also, the chosen solution should not allow malicious or selfish use.
---
Why make a fully customizable command system? To hide this possibility and leave only the knowledgeable?

[Eternity]

Nice idea, fixes old bad problem...
But it must be easy to use... Normally players don't [like to] use console commands, especially if they contain more than a few symbols...
Player would rather prefer to select an item 'Translocator disabled' in the list of targets than to write a command or to have a hotkey assigned for this command.

[Buggie]

Only two buttons use for weapons. So do not much choices. Users can bind any mutate command for any key if they want.

[Buggie]

Version 7.

- Fix disable translocator by user.
- Different scheme for disable translocator.

Read ReadMe.txt inside zip for details.

11. The player can disable teleportation to himself via the "mutate cooptrans disable" command. The administrator can disable this behavior in server UnrealTournament.ini.
If a player has disabled teleportation to himself, then he himself cannot teleport to other players.
To enable, use the command "mutate cooptrans enable". After the delay, the translocator will be turned on, and you will receive a corresponding message.

[CoopTranslocator7.CoopTranslocator]
;Mutate command. Use empty string to turn off disable feature.
Command=cooptrans
;Delay for use after enable.
DisableUseTime=30

CoopTranslocator7.zip

[Buggie]

Version 8.

12. Prevent telefrag on teleportation.
13. Bots can use this translocator for follow you when you order 'Cover me'.

CoopTranslocator8.zip

Now bots can be really helpful even if mapper not make valid paths network for them.

[Buggie]

Today found: Tele to you can kill you on some unlucky conditions.
If you walk on stairs, for example, and space above you head enough only for another player, possible when he tele to you, you will be pushed into floor and die, even in god mode.

But this is rare case, as I already say.

[Eternity]

In one similar modification it translocates the player to some location nearby/around the target player. But the script that performs a valid location selection is complicated - because a set of checks has to be done:
1. Target player must be visible from the target location to avoid locations behind the walls and movers (to prevent cheating...).
2. Collision with another Pawn (of any class) in the target location must not occur to avoid telefrag cases...
3. There must be Mover or Level in some short distance (e.g., less than 250 units, which can be configurable value) beneath the target location to avoid player fall cases (it is very useful on the "bunny tracks").
4. If at least one of the previous conditions fails, selector script picks up another location in a specified (configurable) radius around the target player (selector uses 2 algorithms: fast one - with low precision, and slow one - with higher precision, for the cases if the fast one fails, that often happens on "bunny tracks").

Also, there must be some "buffer" distance (more than 2*CollisionRadius) between the translocated player and the target player, otherwise telefrag cases may happen (probably because of some delays) if target player is moving in the direction towards the translocation target location...

Maybe it doesn't worth the time and efforts spent for writing this implementation, but the result is very nice, especially if Bot uses this CoopTranslocator...