Here, have a chat indicator.

[lavacano201014]

I made a thing for my server (which I'm sure I advertised here once) that basically puts a speech bubble above a player when they have the chat window open (they pressed [by default] Y). It's parented to the player, it (should be) set to be perma-nocollided (MOVETYPE_NONE).

I didn't put it in the Releases forum because it doesn't use ULib or ULX.

I THINK it's the model for the commentary nodes in HL2.

The only real bugs I've found are:

 - You can shoot it and it will react to being shot at.
 - Sometimes, the entity won't get deleted. I haven't figured out what causes this yet. But any ol' player can just remove it if they see someone moving themselves around with an indicator above their head, so no harm no foul.

Both attachments go in lua/autorun. I'm not putting this on Facepunch because I didn't want a bunch of idiots going "i extractd the zip in 2 addons but it doesnt work???" because they couldn't read the OP.

[JamminR]

We allow non-ULib releases in the Releases section.
We encourage and prefer ULib related of course, but many other community members have released here.
If you want us to move it, let us know.

[Megiddo]

Sweet

[KnowledgeJunkie]

Do you think this could be added to or replicated in such a fashion as to indicate when players are in other states? I'm thinking specifically:
-Spawn menu open
-Context menu open (Maybe indicates use of a certain tool)
-ULX menu open

I'd attempt this myself, but I don't want to steal, besides the fact I don't have any lua experience, or knowledge of the proper hooks.

Come to think of it (and just to be super duper picky) could this indicator's usage be controlled via groups? So admin can see when users are in certain states, but not newbies? OK done being useless now.


EDIT: OK, I looked at the server .lua, and I'm wondering (agian, noobish here):
Is the reason the prop can be shot (and perhaps why it doesn't delete sometimes) because its spawned as a prop_physics? Can it not be a prop_static or dynamic or what have you with "MOVETYPE_NONE"?

[lavacano201014]

Do you think this could be added to or replicated in such a fashion as to indicate when players are in other states? I'm thinking specifically:
-Spawn menu open
-Context menu open (Maybe indicates use of a certain tool)
-ULX menu open

I'd attempt this myself, but I don't want to steal, besides the fact I don't have any lua experience, or knowledge of the proper hooks.

Spawn and context menus are easy enough. ULX menu...not so much. I'd have to edit the actual ULX Menu function, I think. No es bueno.

Come to think of it (and just to be super duper picky) could this indicator's usage be controlled via groups? So admin can see when users are in certain states, but not newbies? OK done being useless now.

No, due to the fact that I'm using server side entities. I really don't wanna take the time to convert it to clientside entities. I'm lazy :-P

EDIT: OK, I looked at the server .lua, and I'm wondering (agian, noobish here):
Is the reason the prop can be shot (and perhaps why it doesn't delete sometimes) because its spawned as a prop_physics? Can it not be a prop_static or dynamic or what have you with "MOVETYPE_NONE"?

I don't know how prop_dynamic works (who uses that anyway?), but prop_static winds up getting compiled in as part of the worldspawn entity (meaning it becomes part of the map), so you can't really add and remove prop_static entities on the fly.

[MrPresident]

The main way that a prop_dynamic and a prop_physics differ is that a dynamic prop can be animated. Doors in HL2 are dynamic props. Also dynamic props do not require physics rendering because they are either stationary or move only when moved and then basically stay frozen or suspended when let go. Think if you've ever physgunned something you shouldn't have on a map without protection on.

So that being said... your chat bubbled SHOULD be prop_dynamic. This may seem minimal.. but it's good practice to use the correct entity type. If you have ever played my Stranded gamemode, every tree and rock are dynamic props.

You are correct about the static props though.. It is impossible to spawn a static prop post compile.

One last thing.. being a static prop does not stop bullets, you would have to set it's collision type for that, however since bullets are tracers if you set them to not be able to get shot, you would also not be able to use any tools on them (i.e. deleting with the tool gun in the case of a glitch...)

One thing you could do to fix this is assign the entity to the player and remove all entities assigned to the player when they close the chat menu every time, so that way if it glitches once, the next time they chat it'll delete it. Also you could have it check to see if one already exists for that player and not create another one so that way if it glitches and they chat again, it'll just reuse the current bubble and then delete it on close.

One more hacky way to get rid of a glitched bubble would be to create a remove timer on every bubble as it's spawned. Let's say 2 minutes for example. After 2 minutes it checks to see if the bubble is still there and deletes it if it is. Obviously some people are slow typers so that number might need to be higher.



just my 2 cents Sorry for the rambling.

[JamminR]

Spawn and context menus are easy enough. ULX menu...not so much. I'd have to edit the actual ULX Menu function, I think. No es bueno.

Actually, with SVN new hook, no, you shouldn't have to change ULX at all.
Would take some testing and tweaking, but, every(?) ULib command called now calls a hook.
ULibCommandCalled

In line 9 (as of latest svn of this posting) of addons\ulx\lua\ulx\modules\sh\menus.lua , a Ulib command is called.

Code: [Select]

ULib.clientRPC( calling_ply, "ulx.showMainMenu" )
It would take some research to determine if a ULib command is executed when a menu is CLOSED, but in theory you could use our hook to monitor menu openings (and hopefully, closing)
Basically, in logic (not actual lua)

/addons/youraddon/ulx/modules/sh/youraddon.lua

Code: (fake_lua_ULib_logic) [Select]

function myfunction(calling_ply, command, table)
if command = clientRPC then
  find in table "ulx.showmainmenu"
  if found, do your code for showing they're in menu
  check for close menu command, do code to close/stop your indicator (Closing may not be clientRPC.)
  if not do nothing
return <NOTHING, just plain return or it will stop our code>
end

hook.Add("ULibCommandCalled","mysearch", myfunction)

I actually like KnowledgeJunkie's ideas for indicating mode of player.
I occasionally visit a server that shows gears turning/rising no matter what mode the player is in.
Though it's pretty cool, it doesn't tell me a thing if they can't see my text chat because they're in spawn menu or another menu.

[KnowledgeJunkie]

Well, I've learned just enough Lua to suggest something that probably won't work because I don't know enough about Lua. Since functions are actually values, can we hook when a menu (local function) is given a value (non-nil), then check for the next time the value becomes nil to see when the menu is exited? Maybe it would even work in JamminR's methodology:

Code: [Select]

function checkforulxmenu (calling_ply, command, table)
if command = clientRPC then
  find in table "ulx.showmainmenu"
  if found, spawn ulxisopenicon
  else delete ulxisopenicon (hopefully would delete all instances if there were some problem deleting before)
return <NOTHING, just plain return or it will stop our code>
end

hook.Add("ULibCommandCalled","IsULXMenuOpen", checkforulxmenu)