DavidJCobb / ReachVariantEditor

A tool for editing Halo: Reach game variants.
24 stars 9 forks source link

Questions About Megalo Capabilities #16

Closed Sopitive closed 5 months ago

Sopitive commented 3 years ago
  1. Is it currently possible to set the physics of an item using megalo script? I am trying to spawn in hill markers, 4 each on either side of the player and I need the physics to be set to normal. The reason I am using hill markers is because they are invisible during gameplay. The idea is to prevent fly hacking by reading the speed of 4 items placed on all sides of the player (front, back, left, right) and if the speed of all 4 items is above a certain threshold, the player is airborne. It is 4 items because you can get a false positive if the player is standing on a ledge and the item falls off said ledge. If they are airborne for too long, they are flying and I can handle them (e.g. kill them, take their weapons etc). In order for it to be practical, I need the objects not to be visible. In writing this, I realize I can set the scale of an item so small it is not visible, but nonetheless it might be useful in the future in case I need to modify item physics at all.

  2. Is it possible to get the angle the player is looking relative to another player? What I wish to accomplish with this is to detect and handle the use of aimbots. According to the wiki, the two function calls I saw for this that I thought I might use were get_orientation and get_crosshair_target. If I used get_crosshair_target then it would trigger the detection if they killed the player but their crosshair was not red, so I would rather it be based on the angle that the player is facing/looking. In reading get_orientation, I can see that it always indicates which "face" is facing upward, but if I called that function on a player biped, it would always return the same result (top is up) unless the player biped was dead and I was checking all bipeds in the game.

  3. Is it possible to detect and react to awarded medals? I absolutely hate yoinkers and I would like to be able to subtract score from those players and add score to the person performing the assassination instead if they yoink an assassination and possibly do other things to them also. The tags I saw were assisted_kill_of (to detect the assist) and the ability to actually send the incident "yoink". The first function would detect ALL assists, which is not what I want and the second one simply is able to send the yoink medal.

  4. Is there any other way to detect the death of a spartan biped other than using the on object death event? The idea is that I want to create an in game "menu" that spawns in spartans with various weapons and on their death, will change some aspect of the game (such as setting player scale or applying traits) based on the weapon they were wielding. It would be very useful to change some of the settings in game without having to return to the main menu and setup the game again. If it will be too complex, I will probably just end up spawning objects in forge with shapes that you can stand in to select various options.

  5. Is it possible to detect a specific gamertag? The idea is to initially only allow me to do certain things from within the game variant, such as the menu thing until I can get things tweaked correctly. I will create another issue about the following, but basically if you type in the script "if current_player == "DutifulLake" then the entire program will crash if you attempt to compile the code. Detecting specific gamertags might be useful in a few other situations too, such as using the "menu" feature to apply traits to a specific player whose gamertag matches a specific value (to apply traits/do stuff to players who quit and rejoin).

  6. Is it possible to detect who the host of a match is? Again, the "menu" feature should only allow the host of a match to change settings. It would be pure chaos if everyone in game could just change settings willy nilly. Detecting the host would be extremely useful in various applications such as this.

At the end of it all, I wish to be able to create a game variant that can handle speed hacks, fly hacks, and aimbots, handle afk players, and allows the host to change settings in game. Currently, I have a game variant that is able to detect speed hacks and kills the player biped if they go too fast, and will also detect afk players and set their scale and traits to make them invisible to other players. Flying is what I will be working on next, and if I can reduce false positives, I might possibly incorporate an assassination minigame of sorts where I teleport all players to a central location with the hacker in the middle for somebody to assassinate them until they rage quit.

DavidJCobb commented 3 years ago

Apologies for the delayed response. I tend to pay more attention to the tool's NexusMods page.

  1. No, you cannot directly influence physics that way. Spawning a small object that naturally has Normal physics is the approach I'd go with. If you use a weapon, you can change its pickup permissions to disallow all players from picking it up; not sure if that allows it to be picked up as spare ammo, however, though using something like a skull or flag eliminates that concern.

  2. No, you can't get a player's looking angle directly. You might be able to fuzz it by spawning Hill Markers relative to them (i.e. a Hill Marker five units in front of each player) and checking the positions, or something along those lines, but you'd basically have to implement trigonometric functions by hand using only integers, and with a position precision of 0.1 Forge units. Ultimately, I don't think Megalo in Reach is capable of handling your desired use case of detecting aimbots.

  3. You can't detect incidents (including medals) in Reach. I believe Halo 4 added that as an extension to the Megalo engine, but my tools don't work for Halo 4.

  4. No, the only way to detect biped deaths is through the object death event or, if it's a player biped, by detecting when that player no longer has a biped. I'll note that you can spawn hill markers with Forge labels on them, though not with spawn sequence values (an object.number variable should be a suitable replacement however), so that may be a Forge-free way to implement a menu.

  5. No, you can't detect a player's gamertag through script.

  6. Not to my knowledge. The on local event can be used to run code locally on each player's machine, so there could possibly be some clever workaround based on that, but I wouldn't know offhand. Alternatively, I think player.get_crosshair_target may be local-only i.e. host-only, but I'm not sure on the details.

Gamergotten commented 3 years ago

scrolling through the github and came across this, think i may beable to contribute to some of your (or for anyone else who comes across this's) questions, if they're still relevant,

  1. no and yes but mostly no, you could run a player.get_crosshair_target with an on local: do trigger but the point of aimbots is to make the crosshair red, in order to get that aim assist boost. however if you were able to see that the player isn't looking at the player they just killed that frame, you could do a local player based action to message the host eg. current_player.push_upward() and since this action can only really take effect on client, you could execute this code on every client (on local) and even the host and they will not beable to affect the location of that player, only the client themself can. although this would need testing as im not absolutely sure this is the case

  2. alternatively you could check the health status of an object, so long as it doesn't delete itself upon death you would beable to read if its "dead"

  3. i have a very unrefined script for this that i used in my backpack mode; in order to display different strings for different players. since you cannot just store hud_player you must use a client based condition or action to determine which player in your local game is the local player and then see if this local player is actually the host. but if you mean the current CGB session leader, then no, i do not think there is a way to do that. since the host of a CGB session is actually the server.

do global.number[0] = 1 -- this is declared as local, so only the host can read this as '1' end

on local: do for each player do if current_player.number[1] == 1 then

     -- we search through all of the players in our local session to see which we have stored a local value for
     -- then when we find the one we said was our local player (we get to that in a sec),
     -- we branch execution of code based on whether or not they are the host of this session
     --
     if global.number[0] == 0 then 
           --
     end
     if global.number[0] == 1 then 
           --
     end
  end

end if global.number[1] == 0 then for each object with label 0 do if current_object.object[0] != no_object then -- -- here we stick a biped irritatingly infront of the player to force them to look at it

     end
  end
  for each player do
     global.object[0] = no_object
     global.object[0] = current_player.get_crosshair_target()
     if global.object[0] != no_object then 
        current_player.number[1] = 1 -- there we go, we found the local player based on the fact that it returned an object 
        global.number[1] = 1 -- and here we swap our code from looking for a target to executing local code
     end
  end

end end

that of course, being the code to find the local player (or at least my method), have a great one guys