vscript additions and fixes 2

[samisalreadytaken]

This PR mainly fully implements CNetMsgScriptHelper for custom network message communication, but also adds clientside debugoverlay (that I had planned to include previously but forgot about), CBaseEntity::SetContextThink for more complex thinking from script, fixes user script execution order and clientside player script instance registration, moves all documentation under the __Documentation namespace from global scope, and some misc improvements.

---

A (not necessarily good) example of server to client, then client to server messaging below. The server queries the screen position of a world vector, client responds with the screen position to server to draw on client's screen with debugoverlay. This example simulates the debugoverlay.EntityTextAtPosition functionality using ScreenText.

if(IsServer()){functionstart(){player.SetThink(function(){localpos= Entities.FindByClassname(null,"npc_rollermine").GetOrigin()
QueryScreenPos(pos)returninterval_per_tick},0)}function QueryScreenPos(pos){NetMsg.Start("EntityPos")
NetMsg.WriteVec3Coord(pos)
NetMsg.Send(player,true)}NetMsg.Recieve("ScreenPos",function(ply){localbFacing= NetMsg.ReadBool()
if ( bFacing ){localx=NetMsg.ReadNormal()
local y = NetMsg.ReadNormal()debugoverlay.ScreenText(x,y,"O",0,255,0,255,interval_per_tick+0.25)}else{debugoverlay.ScreenText(0.5,0.5,"NOT FACING",255,0,0,255,interval_per_tick*2)}})}if(IsClient()){
local m_ScreenXY =[0,0]
NetMsg.Recieve("EntityPos",function(){localpos= NetMsg.ReadVec3Coord()localbFacing=ScreenTransform(pos,m_ScreenXY)
local x=m_ScreenXY[0]
local y =m_ScreenXY[1]
NetMsg.Start("ScreenPos")NetMsg.WriteBool(bFacing)if(bFacing){NetMsg.WriteNormal(x)
NetMsg.WriteNormal(y)}NetMsg.Send()})}

Or simply call a clientside function

if(IsServer()){functionCallClientsideFunction(ply){NetMsg.Start("CallFunction1")
NetMsg.Send(ply,true)}}if(IsClient()){NetMsg.Recieve("CallFunction1",MyFunction1)}

The security of this communication in multiplayer depends all on the user. Clients cannot execute arbitrary code on server, and the sender is passed to the reciver function so the user can check if the client has permissions to run whatever to run.

---

The logic of script context thinking differs from Source 2. In Source 2, the execution order of added think functions are not serial, and change depending on the context name; in my implementation it follows the added order.

For example executing the snippet below in Source 2 will print "231", while here it is "123"

player.SetContextThink("1aaa",function(self){print(1)},0)
player.SetContextThink("2",function(self){print(2)},0)
player.SetContextThink("3",function(self){print(3)},0)

Passing null instead of a closure stops thinking.

CBaseEntity::SetThink now internally executes SetContextThink with an empty context.

---

IScriptVM::Get/Set/ClearValue additions are something Valve should have already implemented. They allow accession of any type as table keys instead of just strings, and also allow script array modification.

---

With the addition of hash maps for the save/restore tables and event listeners, I removed the context length limit as the strings are no longer allocated. Event lookup on WriteEventData should also now be much faster.

PR Checklist

• My PR follows all guidelines in the CONTRIBUTING.md file
• My PR targets a develop branch OR targets another branch with a specific goal in mind

[Blixibon]

This PR is very timely considering the recent work towards client-side VScript applications (including the in-progress #78). I was already wondering how data and events could be conventionally transmitted between the server/client for VScript purposes, but CNetMsgScriptHelper's new custom user message functionality seems to solve that problem completely. I could already see it being one of the most vital tools for client-side VScript in the future.

---

I had already noticed the player instance was missing from client-side VScript during my experiments and I was also planning on investigating any potential overhead from the ever-increasing documentation, so thank you for working towards the other misc. improvements and optimizations.

---

I also greatly appreciate the fact this corrects a few of my own mistakes and typos from prior updates. I especially apologize if I mis-attributed the origins of some of your work when I transferred some of it to vscript_singletons.cpp.

Thank you very much for your continued contributions to Mapbase's implementation of VScript. I'll test this on my end later and merge it if I think it's ready.

[samisalreadytaken]

This PR mainly fully implements CNetMsgScriptHelper for custom network message communication, but also adds clientside debugoverlay (that I had planned to include previously but forgot about), CBaseEntity::SetContextThink for more complex thinking from script, fixes user script execution order and clientside player script instance registration, moves all documentation under the __Documentation namespace from global scope, and some misc improvements.

---

A (not necessarily good) example of server to client, then client to server messaging below. The server queries the screen position of a world vector, client responds with the screen position to server to draw on client's screen with debugoverlay. This example simulates the debugoverlay.EntityTextAtPosition functionality using ScreenText.

if(IsServer()){functionstart(){player.SetThink(function(){localpos= Entities.FindByClassname(null,"npc_rollermine").GetOrigin()
QueryScreenPos(pos)returninterval_per_tick},0)}function QueryScreenPos(pos){NetMsg.Start("EntityPos")
NetMsg.WriteVec3Coord(pos)
NetMsg.Send(player,true)}NetMsg.Recieve("ScreenPos",function(ply){localbFacing= NetMsg.ReadBool()
if ( bFacing ){localx=NetMsg.ReadNormal()
local y = NetMsg.ReadNormal()debugoverlay.ScreenText(x,y,"O",0,255,0,255,interval_per_tick+0.25)}else{debugoverlay.ScreenText(0.5,0.5,"NOT FACING",255,0,0,255,interval_per_tick*2)}})}if(IsClient()){
local m_ScreenXY =[0,0]
NetMsg.Recieve("EntityPos",function(){localpos= NetMsg.ReadVec3Coord()localbFacing=ScreenTransform(pos,m_ScreenXY)
local x=m_ScreenXY[0]
local y =m_ScreenXY[1]
NetMsg.Start("ScreenPos")NetMsg.WriteBool(bFacing)if(bFacing){NetMsg.WriteNormal(x)
NetMsg.WriteNormal(y)}NetMsg.Send()})}

Or simply call a clientside function

if(IsServer()){functionCallClientsideFunction(ply){NetMsg.Start("CallFunction1")
NetMsg.Send(ply,true)}}if(IsClient()){NetMsg.Recieve("CallFunction1",MyFunction1)}

The security of this communication in multiplayer depends all on the user. Clients cannot execute arbitrary code on server, and the sender is passed to the reciver function so the user can check if the client has permissions to run whatever to run.

---

The logic of script context thinking differs from Source 2. In Source 2, the execution order of added think functions are not serial, and change depending on the context name; in my implementation it follows the added order.

For example executing the snippet below in Source 2 will print "231", while here it is "123"

player.SetContextThink("1aaa",function(self){print(1)},0)
player.SetContextThink("2",function(self){print(2)},0)
player.SetContextThink("3",function(self){print(3)},0)

Passing null instead of a closure stops thinking.

CBaseEntity::SetThink now internally executes SetContextThink with an empty context.

---

IScriptVM::Get/Set/ClearValue additions are something Valve should have already implemented. They allow accession of any type as table keys instead of just strings, and also allow script array modification.

---

With the addition of hash maps for the save/restore tables and event listeners, I removed the context length limit as the strings are no longer allocated. Event lookup on WriteEventData should also now be much faster.

PR Checklist

• My PR follows all guidelines in the CONTRIBUTING.md file
• My PR targets a develop branch OR targets another branch with a specific goal in mind

[Blixibon]

This PR is very timely considering the recent work towards client-side VScript applications (including the in-progress #78). I was already wondering how data and events could be conventionally transmitted between the server/client for VScript purposes, but CNetMsgScriptHelper's new custom user message functionality seems to solve that problem completely. I could already see it being one of the most vital tools for client-side VScript in the future.

---

I had already noticed the player instance was missing from client-side VScript during my experiments and I was also planning on investigating any potential overhead from the ever-increasing documentation, so thank you for working towards the other misc. improvements and optimizations.

---

I also greatly appreciate the fact this corrects a few of my own mistakes and typos from prior updates. I especially apologize if I mis-attributed the origins of some of your work when I transferred some of it to vscript_singletons.cpp.

Thank you very much for your continued contributions to Mapbase's implementation of VScript. I'll test this on my end later and merge it if I think it's ready.

[samisalreadytaken]

This PR mainly fully implements CNetMsgScriptHelper for custom network message communication, but also adds clientside debugoverlay (that I had planned to include previously but forgot about), CBaseEntity::SetContextThink for more complex thinking from script, fixes user script execution order and clientside player script instance registration, moves all documentation under the __Documentation namespace from global scope, and some misc improvements.

---

A (not necessarily good) example of server to client, then client to server messaging below. The server queries the screen position of a world vector, client responds with the screen position to server to draw on client's screen with debugoverlay. This example simulates the debugoverlay.EntityTextAtPosition functionality using ScreenText.

if(IsServer()){functionstart(){player.SetThink(function(){localpos= Entities.FindByClassname(null,"npc_rollermine").GetOrigin()
QueryScreenPos(pos)returninterval_per_tick},0)}function QueryScreenPos(pos){NetMsg.Start("EntityPos")
NetMsg.WriteVec3Coord(pos)
NetMsg.Send(player,true)}NetMsg.Recieve("ScreenPos",function(ply){localbFacing= NetMsg.ReadBool()
if ( bFacing ){localx=NetMsg.ReadNormal()
local y = NetMsg.ReadNormal()debugoverlay.ScreenText(x,y,"O",0,255,0,255,interval_per_tick+0.25)}else{debugoverlay.ScreenText(0.5,0.5,"NOT FACING",255,0,0,255,interval_per_tick*2)}})}if(IsClient()){
local m_ScreenXY =[0,0]
NetMsg.Recieve("EntityPos",function(){localpos= NetMsg.ReadVec3Coord()localbFacing=ScreenTransform(pos,m_ScreenXY)
local x=m_ScreenXY[0]
local y =m_ScreenXY[1]
NetMsg.Start("ScreenPos")NetMsg.WriteBool(bFacing)if(bFacing){NetMsg.WriteNormal(x)
NetMsg.WriteNormal(y)}NetMsg.Send()})}

Or simply call a clientside function

if(IsServer()){functionCallClientsideFunction(ply){NetMsg.Start("CallFunction1")
NetMsg.Send(ply,true)}}if(IsClient()){NetMsg.Recieve("CallFunction1",MyFunction1)}

The security of this communication in multiplayer depends all on the user. Clients cannot execute arbitrary code on server, and the sender is passed to the reciver function so the user can check if the client has permissions to run whatever to run.

---

The logic of script context thinking differs from Source 2. In Source 2, the execution order of added think functions are not serial, and change depending on the context name; in my implementation it follows the added order.

For example executing the snippet below in Source 2 will print "231", while here it is "123"

player.SetContextThink("1aaa",function(self){print(1)},0)
player.SetContextThink("2",function(self){print(2)},0)
player.SetContextThink("3",function(self){print(3)},0)

Passing null instead of a closure stops thinking.

CBaseEntity::SetThink now internally executes SetContextThink with an empty context.

---

IScriptVM::Get/Set/ClearValue additions are something Valve should have already implemented. They allow accession of any type as table keys instead of just strings, and also allow script array modification.

---

With the addition of hash maps for the save/restore tables and event listeners, I removed the context length limit as the strings are no longer allocated. Event lookup on WriteEventData should also now be much faster.

PR Checklist

• My PR follows all guidelines in the CONTRIBUTING.md file
• My PR targets a develop branch OR targets another branch with a specific goal in mind

[Blixibon]

This PR is very timely considering the recent work towards client-side VScript applications (including the in-progress #78). I was already wondering how data and events could be conventionally transmitted between the server/client for VScript purposes, but CNetMsgScriptHelper's new custom user message functionality seems to solve that problem completely. I could already see it being one of the most vital tools for client-side VScript in the future.

---

I had already noticed the player instance was missing from client-side VScript during my experiments and I was also planning on investigating any potential overhead from the ever-increasing documentation, so thank you for working towards the other misc. improvements and optimizations.

---

I also greatly appreciate the fact this corrects a few of my own mistakes and typos from prior updates. I especially apologize if I mis-attributed the origins of some of your work when I transferred some of it to vscript_singletons.cpp.

Thank you very much for your continued contributions to Mapbase's implementation of VScript. I'll test this on my end later and merge it if I think it's ready.

[samisalreadytaken]

This PR mainly fully implements CNetMsgScriptHelper for custom network message communication, but also adds clientside debugoverlay (that I had planned to include previously but forgot about), CBaseEntity::SetContextThink for more complex thinking from script, fixes user script execution order and clientside player script instance registration, moves all documentation under the __Documentation namespace from global scope, and some misc improvements.

---

A (not necessarily good) example of server to client, then client to server messaging below. The server queries the screen position of a world vector, client responds with the screen position to server to draw on client's screen with debugoverlay. This example simulates the debugoverlay.EntityTextAtPosition functionality using ScreenText.

if(IsServer()){functionstart(){player.SetThink(function(){localpos= Entities.FindByClassname(null,"npc_rollermine").GetOrigin()
QueryScreenPos(pos)returninterval_per_tick},0)}function QueryScreenPos(pos){NetMsg.Start("EntityPos")
NetMsg.WriteVec3Coord(pos)
NetMsg.Send(player,true)}NetMsg.Recieve("ScreenPos",function(ply){localbFacing= NetMsg.ReadBool()
if ( bFacing ){localx=NetMsg.ReadNormal()
local y = NetMsg.ReadNormal()debugoverlay.ScreenText(x,y,"O",0,255,0,255,interval_per_tick+0.25)}else{debugoverlay.ScreenText(0.5,0.5,"NOT FACING",255,0,0,255,interval_per_tick*2)}})}if(IsClient()){
local m_ScreenXY =[0,0]
NetMsg.Recieve("EntityPos",function(){localpos= NetMsg.ReadVec3Coord()localbFacing=ScreenTransform(pos,m_ScreenXY)
local x=m_ScreenXY[0]
local y =m_ScreenXY[1]
NetMsg.Start("ScreenPos")NetMsg.WriteBool(bFacing)if(bFacing){NetMsg.WriteNormal(x)
NetMsg.WriteNormal(y)}NetMsg.Send()})}

Or simply call a clientside function

if(IsServer()){functionCallClientsideFunction(ply){NetMsg.Start("CallFunction1")
NetMsg.Send(ply,true)}}if(IsClient()){NetMsg.Recieve("CallFunction1",MyFunction1)}

The security of this communication in multiplayer depends all on the user. Clients cannot execute arbitrary code on server, and the sender is passed to the reciver function so the user can check if the client has permissions to run whatever to run.

---

The logic of script context thinking differs from Source 2. In Source 2, the execution order of added think functions are not serial, and change depending on the context name; in my implementation it follows the added order.

For example executing the snippet below in Source 2 will print "231", while here it is "123"

player.SetContextThink("1aaa",function(self){print(1)},0)
player.SetContextThink("2",function(self){print(2)},0)
player.SetContextThink("3",function(self){print(3)},0)

Passing null instead of a closure stops thinking.

CBaseEntity::SetThink now internally executes SetContextThink with an empty context.

---

IScriptVM::Get/Set/ClearValue additions are something Valve should have already implemented. They allow accession of any type as table keys instead of just strings, and also allow script array modification.

---

With the addition of hash maps for the save/restore tables and event listeners, I removed the context length limit as the strings are no longer allocated. Event lookup on WriteEventData should also now be much faster.

PR Checklist

• My PR follows all guidelines in the CONTRIBUTING.md file
• My PR targets a develop branch OR targets another branch with a specific goal in mind

[Blixibon]

This PR is very timely considering the recent work towards client-side VScript applications (including the in-progress #78). I was already wondering how data and events could be conventionally transmitted between the server/client for VScript purposes, but CNetMsgScriptHelper's new custom user message functionality seems to solve that problem completely. I could already see it being one of the most vital tools for client-side VScript in the future.

---

I had already noticed the player instance was missing from client-side VScript during my experiments and I was also planning on investigating any potential overhead from the ever-increasing documentation, so thank you for working towards the other misc. improvements and optimizations.

---

I also greatly appreciate the fact this corrects a few of my own mistakes and typos from prior updates. I especially apologize if I mis-attributed the origins of some of your work when I transferred some of it to vscript_singletons.cpp.

Thank you very much for your continued contributions to Mapbase's implementation of VScript. I'll test this on my end later and merge it if I think it's ready.

[samisalreadytaken]

This PR mainly fully implements CNetMsgScriptHelper for custom network message communication, but also adds clientside debugoverlay (that I had planned to include previously but forgot about), CBaseEntity::SetContextThink for more complex thinking from script, fixes user script execution order and clientside player script instance registration, moves all documentation under the __Documentation namespace from global scope, and some misc improvements.

---

A (not necessarily good) example of server to client, then client to server messaging below. The server queries the screen position of a world vector, client responds with the screen position to server to draw on client's screen with debugoverlay. This example simulates the debugoverlay.EntityTextAtPosition functionality using ScreenText.

if(IsServer()){functionstart(){player.SetThink(function(){localpos= Entities.FindByClassname(null,"npc_rollermine").GetOrigin()
QueryScreenPos(pos)returninterval_per_tick},0)}function QueryScreenPos(pos){NetMsg.Start("EntityPos")
NetMsg.WriteVec3Coord(pos)
NetMsg.Send(player,true)}NetMsg.Recieve("ScreenPos",function(ply){localbFacing= NetMsg.ReadBool()
if ( bFacing ){localx=NetMsg.ReadNormal()
local y = NetMsg.ReadNormal()debugoverlay.ScreenText(x,y,"O",0,255,0,255,interval_per_tick+0.25)}else{debugoverlay.ScreenText(0.5,0.5,"NOT FACING",255,0,0,255,interval_per_tick*2)}})}if(IsClient()){
local m_ScreenXY =[0,0]
NetMsg.Recieve("EntityPos",function(){localpos= NetMsg.ReadVec3Coord()localbFacing=ScreenTransform(pos,m_ScreenXY)
local x=m_ScreenXY[0]
local y =m_ScreenXY[1]
NetMsg.Start("ScreenPos")NetMsg.WriteBool(bFacing)if(bFacing){NetMsg.WriteNormal(x)
NetMsg.WriteNormal(y)}NetMsg.Send()})}

Or simply call a clientside function

if(IsServer()){functionCallClientsideFunction(ply){NetMsg.Start("CallFunction1")
NetMsg.Send(ply,true)}}if(IsClient()){NetMsg.Recieve("CallFunction1",MyFunction1)}

The security of this communication in multiplayer depends all on the user. Clients cannot execute arbitrary code on server, and the sender is passed to the reciver function so the user can check if the client has permissions to run whatever to run.

---

The logic of script context thinking differs from Source 2. In Source 2, the execution order of added think functions are not serial, and change depending on the context name; in my implementation it follows the added order.

For example executing the snippet below in Source 2 will print "231", while here it is "123"

player.SetContextThink("1aaa",function(self){print(1)},0)
player.SetContextThink("2",function(self){print(2)},0)
player.SetContextThink("3",function(self){print(3)},0)

Passing null instead of a closure stops thinking.

CBaseEntity::SetThink now internally executes SetContextThink with an empty context.

---

IScriptVM::Get/Set/ClearValue additions are something Valve should have already implemented. They allow accession of any type as table keys instead of just strings, and also allow script array modification.

---

With the addition of hash maps for the save/restore tables and event listeners, I removed the context length limit as the strings are no longer allocated. Event lookup on WriteEventData should also now be much faster.

PR Checklist

• My PR follows all guidelines in the CONTRIBUTING.md file
• My PR targets a develop branch OR targets another branch with a specific goal in mind

[Blixibon]

This PR is very timely considering the recent work towards client-side VScript applications (including the in-progress #78). I was already wondering how data and events could be conventionally transmitted between the server/client for VScript purposes, but CNetMsgScriptHelper's new custom user message functionality seems to solve that problem completely. I could already see it being one of the most vital tools for client-side VScript in the future.

---

I had already noticed the player instance was missing from client-side VScript during my experiments and I was also planning on investigating any potential overhead from the ever-increasing documentation, so thank you for working towards the other misc. improvements and optimizations.

---

I also greatly appreciate the fact this corrects a few of my own mistakes and typos from prior updates. I especially apologize if I mis-attributed the origins of some of your work when I transferred some of it to vscript_singletons.cpp.

Thank you very much for your continued contributions to Mapbase's implementation of VScript. I'll test this on my end later and merge it if I think it's ready.

[samisalreadytaken]

This PR mainly fully implements CNetMsgScriptHelper for custom network message communication, but also adds clientside debugoverlay (that I had planned to include previously but forgot about), CBaseEntity::SetContextThink for more complex thinking from script, fixes user script execution order and clientside player script instance registration, moves all documentation under the __Documentation namespace from global scope, and some misc improvements.

---

A (not necessarily good) example of server to client, then client to server messaging below. The server queries the screen position of a world vector, client responds with the screen position to server to draw on client's screen with debugoverlay. This example simulates the debugoverlay.EntityTextAtPosition functionality using ScreenText.

if(IsServer()){functionstart(){player.SetThink(function(){localpos= Entities.FindByClassname(null,"npc_rollermine").GetOrigin()
QueryScreenPos(pos)returninterval_per_tick},0)}function QueryScreenPos(pos){NetMsg.Start("EntityPos")
NetMsg.WriteVec3Coord(pos)
NetMsg.Send(player,true)}NetMsg.Recieve("ScreenPos",function(ply){localbFacing= NetMsg.ReadBool()
if ( bFacing ){localx=NetMsg.ReadNormal()
local y = NetMsg.ReadNormal()debugoverlay.ScreenText(x,y,"O",0,255,0,255,interval_per_tick+0.25)}else{debugoverlay.ScreenText(0.5,0.5,"NOT FACING",255,0,0,255,interval_per_tick*2)}})}if(IsClient()){
local m_ScreenXY =[0,0]
NetMsg.Recieve("EntityPos",function(){localpos= NetMsg.ReadVec3Coord()localbFacing=ScreenTransform(pos,m_ScreenXY)
local x=m_ScreenXY[0]
local y =m_ScreenXY[1]
NetMsg.Start("ScreenPos")NetMsg.WriteBool(bFacing)if(bFacing){NetMsg.WriteNormal(x)
NetMsg.WriteNormal(y)}NetMsg.Send()})}

Or simply call a clientside function

if(IsServer()){functionCallClientsideFunction(ply){NetMsg.Start("CallFunction1")
NetMsg.Send(ply,true)}}if(IsClient()){NetMsg.Recieve("CallFunction1",MyFunction1)}

The security of this communication in multiplayer depends all on the user. Clients cannot execute arbitrary code on server, and the sender is passed to the reciver function so the user can check if the client has permissions to run whatever to run.

---

The logic of script context thinking differs from Source 2. In Source 2, the execution order of added think functions are not serial, and change depending on the context name; in my implementation it follows the added order.

For example executing the snippet below in Source 2 will print "231", while here it is "123"

player.SetContextThink("1aaa",function(self){print(1)},0)
player.SetContextThink("2",function(self){print(2)},0)
player.SetContextThink("3",function(self){print(3)},0)

Passing null instead of a closure stops thinking.

CBaseEntity::SetThink now internally executes SetContextThink with an empty context.

---

IScriptVM::Get/Set/ClearValue additions are something Valve should have already implemented. They allow accession of any type as table keys instead of just strings, and also allow script array modification.

---

With the addition of hash maps for the save/restore tables and event listeners, I removed the context length limit as the strings are no longer allocated. Event lookup on WriteEventData should also now be much faster.

PR Checklist

• My PR follows all guidelines in the CONTRIBUTING.md file
• My PR targets a develop branch OR targets another branch with a specific goal in mind

[Blixibon]

This PR is very timely considering the recent work towards client-side VScript applications (including the in-progress #78). I was already wondering how data and events could be conventionally transmitted between the server/client for VScript purposes, but CNetMsgScriptHelper's new custom user message functionality seems to solve that problem completely. I could already see it being one of the most vital tools for client-side VScript in the future.

---

I had already noticed the player instance was missing from client-side VScript during my experiments and I was also planning on investigating any potential overhead from the ever-increasing documentation, so thank you for working towards the other misc. improvements and optimizations.

---

I also greatly appreciate the fact this corrects a few of my own mistakes and typos from prior updates. I especially apologize if I mis-attributed the origins of some of your work when I transferred some of it to vscript_singletons.cpp.

Thank you very much for your continued contributions to Mapbase's implementation of VScript. I'll test this on my end later and merge it if I think it's ready.

[samisalreadytaken]

This PR mainly fully implements CNetMsgScriptHelper for custom network message communication, but also adds clientside debugoverlay (that I had planned to include previously but forgot about), CBaseEntity::SetContextThink for more complex thinking from script, fixes user script execution order and clientside player script instance registration, moves all documentation under the __Documentation namespace from global scope, and some misc improvements.

---

A (not necessarily good) example of server to client, then client to server messaging below. The server queries the screen position of a world vector, client responds with the screen position to server to draw on client's screen with debugoverlay. This example simulates the debugoverlay.EntityTextAtPosition functionality using ScreenText.

if(IsServer()){functionstart(){player.SetThink(function(){localpos= Entities.FindByClassname(null,"npc_rollermine").GetOrigin()
QueryScreenPos(pos)returninterval_per_tick},0)}function QueryScreenPos(pos){NetMsg.Start("EntityPos")
NetMsg.WriteVec3Coord(pos)
NetMsg.Send(player,true)}NetMsg.Recieve("ScreenPos",function(ply){localbFacing= NetMsg.ReadBool()
if ( bFacing ){localx=NetMsg.ReadNormal()
local y = NetMsg.ReadNormal()debugoverlay.ScreenText(x,y,"O",0,255,0,255,interval_per_tick+0.25)}else{debugoverlay.ScreenText(0.5,0.5,"NOT FACING",255,0,0,255,interval_per_tick*2)}})}if(IsClient()){
local m_ScreenXY =[0,0]
NetMsg.Recieve("EntityPos",function(){localpos= NetMsg.ReadVec3Coord()localbFacing=ScreenTransform(pos,m_ScreenXY)
local x=m_ScreenXY[0]
local y =m_ScreenXY[1]
NetMsg.Start("ScreenPos")NetMsg.WriteBool(bFacing)if(bFacing){NetMsg.WriteNormal(x)
NetMsg.WriteNormal(y)}NetMsg.Send()})}

Or simply call a clientside function

if(IsServer()){functionCallClientsideFunction(ply){NetMsg.Start("CallFunction1")
NetMsg.Send(ply,true)}}if(IsClient()){NetMsg.Recieve("CallFunction1",MyFunction1)}

The security of this communication in multiplayer depends all on the user. Clients cannot execute arbitrary code on server, and the sender is passed to the reciver function so the user can check if the client has permissions to run whatever to run.

---

The logic of script context thinking differs from Source 2. In Source 2, the execution order of added think functions are not serial, and change depending on the context name; in my implementation it follows the added order.

For example executing the snippet below in Source 2 will print "231", while here it is "123"

player.SetContextThink("1aaa",function(self){print(1)},0)
player.SetContextThink("2",function(self){print(2)},0)
player.SetContextThink("3",function(self){print(3)},0)

Passing null instead of a closure stops thinking.

CBaseEntity::SetThink now internally executes SetContextThink with an empty context.

---

IScriptVM::Get/Set/ClearValue additions are something Valve should have already implemented. They allow accession of any type as table keys instead of just strings, and also allow script array modification.

---

With the addition of hash maps for the save/restore tables and event listeners, I removed the context length limit as the strings are no longer allocated. Event lookup on WriteEventData should also now be much faster.

PR Checklist

• My PR follows all guidelines in the CONTRIBUTING.md file
• My PR targets a develop branch OR targets another branch with a specific goal in mind

[Blixibon]

This PR is very timely considering the recent work towards client-side VScript applications (including the in-progress #78). I was already wondering how data and events could be conventionally transmitted between the server/client for VScript purposes, but CNetMsgScriptHelper's new custom user message functionality seems to solve that problem completely. I could already see it being one of the most vital tools for client-side VScript in the future.

---

I had already noticed the player instance was missing from client-side VScript during my experiments and I was also planning on investigating any potential overhead from the ever-increasing documentation, so thank you for working towards the other misc. improvements and optimizations.

---

I also greatly appreciate the fact this corrects a few of my own mistakes and typos from prior updates. I especially apologize if I mis-attributed the origins of some of your work when I transferred some of it to vscript_singletons.cpp.

Thank you very much for your continued contributions to Mapbase's implementation of VScript. I'll test this on my end later and merge it if I think it's ready.

[samisalreadytaken]

This PR mainly fully implements CNetMsgScriptHelper for custom network message communication, but also adds clientside debugoverlay (that I had planned to include previously but forgot about), CBaseEntity::SetContextThink for more complex thinking from script, fixes user script execution order and clientside player script instance registration, moves all documentation under the __Documentation namespace from global scope, and some misc improvements.

---

A (not necessarily good) example of server to client, then client to server messaging below. The server queries the screen position of a world vector, client responds with the screen position to server to draw on client's screen with debugoverlay. This example simulates the debugoverlay.EntityTextAtPosition functionality using ScreenText.

if(IsServer()){functionstart(){player.SetThink(function(){localpos= Entities.FindByClassname(null,"npc_rollermine").GetOrigin()
QueryScreenPos(pos)returninterval_per_tick},0)}function QueryScreenPos(pos){NetMsg.Start("EntityPos")
NetMsg.WriteVec3Coord(pos)
NetMsg.Send(player,true)}NetMsg.Recieve("ScreenPos",function(ply){localbFacing= NetMsg.ReadBool()
if ( bFacing ){localx=NetMsg.ReadNormal()
local y = NetMsg.ReadNormal()debugoverlay.ScreenText(x,y,"O",0,255,0,255,interval_per_tick+0.25)}else{debugoverlay.ScreenText(0.5,0.5,"NOT FACING",255,0,0,255,interval_per_tick*2)}})}if(IsClient()){
local m_ScreenXY =[0,0]
NetMsg.Recieve("EntityPos",function(){localpos= NetMsg.ReadVec3Coord()localbFacing=ScreenTransform(pos,m_ScreenXY)
local x=m_ScreenXY[0]
local y =m_ScreenXY[1]
NetMsg.Start("ScreenPos")NetMsg.WriteBool(bFacing)if(bFacing){NetMsg.WriteNormal(x)
NetMsg.WriteNormal(y)}NetMsg.Send()})}

Or simply call a clientside function

if(IsServer()){functionCallClientsideFunction(ply){NetMsg.Start("CallFunction1")
NetMsg.Send(ply,true)}}if(IsClient()){NetMsg.Recieve("CallFunction1",MyFunction1)}

The security of this communication in multiplayer depends all on the user. Clients cannot execute arbitrary code on server, and the sender is passed to the reciver function so the user can check if the client has permissions to run whatever to run.

---

The logic of script context thinking differs from Source 2. In Source 2, the execution order of added think functions are not serial, and change depending on the context name; in my implementation it follows the added order.

For example executing the snippet below in Source 2 will print "231", while here it is "123"

player.SetContextThink("1aaa",function(self){print(1)},0)
player.SetContextThink("2",function(self){print(2)},0)
player.SetContextThink("3",function(self){print(3)},0)

Passing null instead of a closure stops thinking.

CBaseEntity::SetThink now internally executes SetContextThink with an empty context.

---

IScriptVM::Get/Set/ClearValue additions are something Valve should have already implemented. They allow accession of any type as table keys instead of just strings, and also allow script array modification.

---

With the addition of hash maps for the save/restore tables and event listeners, I removed the context length limit as the strings are no longer allocated. Event lookup on WriteEventData should also now be much faster.

PR Checklist

• My PR follows all guidelines in the CONTRIBUTING.md file
• My PR targets a develop branch OR targets another branch with a specific goal in mind

[Blixibon]

This PR is very timely considering the recent work towards client-side VScript applications (including the in-progress #78). I was already wondering how data and events could be conventionally transmitted between the server/client for VScript purposes, but CNetMsgScriptHelper's new custom user message functionality seems to solve that problem completely. I could already see it being one of the most vital tools for client-side VScript in the future.

---

I had already noticed the player instance was missing from client-side VScript during my experiments and I was also planning on investigating any potential overhead from the ever-increasing documentation, so thank you for working towards the other misc. improvements and optimizations.

---

I also greatly appreciate the fact this corrects a few of my own mistakes and typos from prior updates. I especially apologize if I mis-attributed the origins of some of your work when I transferred some of it to vscript_singletons.cpp.

Thank you very much for your continued contributions to Mapbase's implementation of VScript. I'll test this on my end later and merge it if I think it's ready.