A Community discussion forum for Halo Custom Edition, Halo 2 Vista, Portal and Halo Machinima

Home  Search Register  Login Member ListRecent Posts
  
 
»Forums Index »Halo Custom Edition (Bungie/Gearbox) »Halo CE General Discussion »Referring players in scripts theory

Author Topic: Referring players in scripts theory (12 messages, Page 1 of 1)
Moderators: Dennis

cyboryxmen
Joined: Nov 7, 2010

--CG artist-- New mission. Refuse this Mission!


Posted: Jun 5, 2011 10:52 AM    Msg. 1 of 12       
I simplified my wall of text\rant into a bite-sized paragraph and a list so you'd better be thankful for that!

Telling the script which player should the command be initiated to is a pain since player numbers change frequently. Fortunately, I have a solution. The method is basically a modified version of Gamma's portable triggers. Instead of directly referring to the player, the command will be directed to it's assigned Z-lock...

1) 16 bipeds called Z-locks will be spawned in individual trigger volumes called Z-pots.

2) Every player will be assigned to a Z-lock by attaching it to the back of the player.

3) Commands that are addressing to the Z-lock are initiated by placing Z-boxes in it's Z-pot for syncing purposes.

4) The Z-lock will act as a child to the player. With the help of objects_can_see_object, all commands that are referring to the Z-lock will be redirected to the player.

5) When the player dies, it's Z-lock will return to it's Z-pot and all Z-boxes in it are teleported out of the trigger volume.

6) When the player respawns, another unused Z-lock will be assigned to it and the process repeats itself.

What do you think? Would this method be practical?
-Zekilk


SlappyThePirate
Joined: Aug 24, 2009

You are irritating, I'll release nothing


Posted: Jun 5, 2011 11:03 AM    Msg. 2 of 12       
Makes sense, and I could use this for two or three very important things.
It would be cool if someone had a completely invisible biped already tagged for us to use.


cyboryxmen
Joined: Nov 7, 2010

--CG artist-- New mission. Refuse this Mission!


Posted: Jun 5, 2011 11:41 AM    Msg. 3 of 12       
Quote: --- Original message by: ASP GRUNTS
It's Kirby who came up with portable trigger volumes. And this idea will give each player a permanent way to reference himself ONLY up till he dies. Each death resets his lock. This is useful for some applications, but by no means a breakthrough. Figure out how to make a permanent "lock" for each player, one that stays consistent even after a death, and then you'll get my attention =P.


It's hard to tell since different sources tell different stories.

Quote: --- Original message by: ASP GRUNTSEach death resets his lock. This is useful for some applications, but by no means a breakthrough. Figure out how to make a permanent "lock" for each player, one that stays consistent even after a death, and then you'll get my attention =P.


My old method involves flickering the flashlight over and over to check what the local player's number is. That method proved to be tedious so I abandoned it. I guess I could modify it to help the lock find its owner.

Fake edit: done


1) 16 bipeds called Z-locks will be spawned in individual trigger volumes called Z-pots.

2) Every player will be assigned to a Z-lock by attaching it to the back of the player.

3) Commands that are addressing to the Z-lock are initiated by placing Z-boxes in it's Z-pot for syncing purposes.

4) The Z-lock will act as a child to the player. With the help of objects_can_see_object, all commands that are referring to the Z-lock will be redirected to the player.

5) When the player dies, it's Z-lock will return to it's Z-pot.

6) Once the player respawns, unit_set_desired_flashlight_state and unit_get_current_flashlight_state will be used to help the Z-lock find it's owner.

Player numbers will no longer hinder us no more. The bond will be forever sealed even up til death. Is this enough of a breakthrough for ya?
-Zekilk
Edited by cyboryxmen on Jun 5, 2011 at 11:47 AM


cyboryxmen
Joined: Nov 7, 2010

--CG artist-- New mission. Refuse this Mission!


Posted: Jun 5, 2011 11:52 AM    Msg. 4 of 12       
Quote: --- Original message by: ASP GRUNTS
Quote: --- Original message by: cyboryxmen
6) Once the player respawns, unit_set_desired_flashlight_state and unit_get_current_flashlight_state will be used to help the Z-lock find it's owner.

Please explain this step. I'm assuming flashlight states are reset to off after being respawned, and so does the player number of the player who died.


I took this idea from your team checking script. Since flashlight states do not sync, only one player will be affected by unit_set_desired_flashlight_state and that player would be the local client. I also forgot to mention that an unsynced variable would be used to determine the local player's Z-lock.

GTG
-Zekilk
Edited by cyboryxmen on Jun 5, 2011 at 11:53 AM


SlappyThePirate
Joined: Aug 24, 2009

You are irritating, I'll release nothing


Posted: Jun 5, 2011 12:07 PM    Msg. 5 of 12       
This is cool. Please continue to expand on it.


kirby_422
Joined: Jan 22, 2006

Apparently public enemy number 1?


Posted: Jun 5, 2011 04:25 PM    Msg. 6 of 12       
Quote: --- Original message by: ASP GRUNTS
It's Kirby who came up with portable trigger volumes.

this.
Quote: --- Original message by: ASP GRUNTS
This is useful for some applications, but by no means a breakthrough.

only useful for monitoring teams, and stuff like portal gun by item_collection instead of weapon (track peoples portals instead of the weapons portals. Was gonna impliment it, but I got lazy)

Quote: --- Original message by: ASP GRUNTS
Figure out how to make a permanent "lock" for each player, one that stays consistent even after a death, and then you'll get my attention =P.

Just have a script that when the list_count goes down, turn on deathless, make it so nobody new can join (forgot the sv command, and dont have hs_doc on my laptop. change the max players to list_count players) if anyone else "dies" during that time, put them in a box for storage until the other player respawns. if 10 seconds pass and he hasnt respawned, consider him quit and kill the next person in line to be respawned, repeat, etc. have the spawn point the volume trigger that attaches their trackers, and when all the above is going on, who ever apears in there give the dead persons tracker; since the script changes the max players, you won't worry about a joiner taking his identity, and since deathless is on, nobody else will die and respawn first, you'll be controling what order they go through.



Any other questions?


SlappyThePirate
Joined: Aug 24, 2009

You are irritating, I'll release nothing


Posted: Jun 5, 2011 05:08 PM    Msg. 7 of 12       
Quote: Any other questions?

Yeah. Script plox?


kirby_422
Joined: Jan 22, 2006

Apparently public enemy number 1?


Posted: Jun 5, 2011 09:44 PM    Msg. 8 of 12       
.. do you have a reason for my to turn my explanation on how to do it into an actual script rather than letting you do it yourself?... name one thing your working on that needs to track the same player through multiple deaths.

The reason I didn't do the quicker non-continuing variant for my portal gun was because I was lazy, and your expecting that ill do the more advanced variant for you when there is almost no point to tracking this stuff?.. Local Player is like the only thing worth tracking so you can do camera scripts for them without effecting everyone.


SlappyThePirate
Joined: Aug 24, 2009

You are irritating, I'll release nothing


Posted: Jun 5, 2011 10:05 PM    Msg. 9 of 12       
I got a bunch of things.


cyboryxmen
Joined: Nov 7, 2010

--CG artist-- New mission. Refuse this Mission!


Posted: Jun 5, 2011 10:36 PM    Msg. 10 of 12       
Quote: --- Original message by: kirby_422
Local Player is like the only thing worth tracking so you can do camera scripts for them without effecting everyone.


I wished it would be that simple. Scripts like that do not even need syncing and usually just require the flashlight states command to work but after trying to make a points script for Multiplayer, things tend to get buggy. Since the goal of the map is to get as much points as possible, every machine must know every individual's points plus keeping your hard earned points in your scoreboard and not the other player's.

Using flashlight states alone is not enough. We need a specific biped made for the local player and not the(ever so changing, irritating, eye ripping, smack wapping ding dong watatata) player number. This method will also be used for inventory scripts and synced permutations *hint* *hint*
-Zekilk

Edited because my mind was suddenly thinking about other problems so the post doesn't make sense(it does that a lot lol)
Edited by cyboryxmen on Jun 5, 2011 at 10:52 PM
Edited by cyboryxmen on Jun 5, 2011 at 10:53 PM


kirby_422
Joined: Jan 22, 2006

Apparently public enemy number 1?


Posted: Jun 5, 2011 11:46 PM    Msg. 11 of 12       
Quote: --- Original message by: cyboryxmen
Quote: --- Original message by: kirby_422
Local Player is like the only thing worth tracking so you can do camera scripts for them without effecting everyone.


I wished it would be that simple. Scripts like that do not even need syncing and usually just require the flashlight states command to work but after trying to make a points script for Multiplayer, things tend to get buggy. Since the goal of the map is to get as much points as possible, every machine must know every individual's points plus keeping your hard earned points in your scoreboard and not the other player's.

I don't know where camera slipped into points, but lets go over points first.

Its true you don't want the local player to sync. Why would you want all the clients thinking their local player is the host when its not?.. you'd do it with a piece of scenery or something.

second, points.. I don't really get where your going there, but you can't check who killed who, so using this to track kills won't work. What kind of points are you looking for?.... it would work fine for counting how many times a player has died, but not really much else.


Quote: --- Original message by: cyboryxmen
This method will also be used for inventory scripts and synced permutations

Permutations, why would you care that everyone sees you the same?... and inventory, why not just be lazy and physically attach it to the player, and when the player hits their flashlight, try to detach every object in the map from them insuring if they have something its used?.. alot easier/lazier.




And slappy, do you see where im coming from? writing up that script takes alot more effort than summerizing everything that needs to be done in what order. Making that script, I don't see any benifit for me; This script won't entertain me, nor will it really do much for anyone. Why would I waste all that time toiling around making something I don't even want, nor see meaning behind?


SlappyThePirate
Joined: Aug 24, 2009

You are irritating, I'll release nothing


Posted: Jun 6, 2011 05:51 PM    Msg. 12 of 12       
Quote: --- Original message by: cyboryxmen
I wished it would be that simple. Scripts like that do not even need syncing and usually just require the flashlight states command to work

I'm interested in how you guys have done this. Mind telling how?

 

 
Previous Older Thread    Next newer Thread







Time: Sun July 5, 2020 3:27 PM 375 ms.
A Halo Maps Website