Multiplayer (Controlling multiple session)

Nyyrazzilyss
Posts: 334
Joined: Thu Mar 05, 2015 2:53 am

Re: Multiplayer (Controlling multiple session)

Post by Nyyrazzilyss »

SlySven wrote:we haven't (IIRC) got table capability... :geek:
I'd suggest looking at what would be needed to provide table capacity to the event structure: In local profile events, you're never passing a table/just the index of the table. Cross profile, ideally it would be the table itself.

I could write a script in lua that would allow for bi-directional profile communication. At the system level to enable that, all i'd need would be a callable event that broadcasts a single user defined table to all profiles - If you want more information sent, you just put it inside the table.

User avatar
SlySven
Posts: 1019
Joined: Mon Mar 04, 2013 3:40 pm
Location: Deepest Wiltshire, UK
Discord: SlySven#2703

Re: Multiplayer (Controlling multiple session)

Post by SlySven »

Nyyrazzilyss wrote:
SlySven wrote:we haven't (IIRC) got table capability... :geek:
... Cross profile, ideally it would be the table itself....
No ideally about it - it would HAVE to be the table - or rather it's contents - remember that the Global table / Lua State is only global to that profile - each profile has its own independent one of these. 8-)

Jor'Mox
Posts: 1142
Joined: Wed Apr 03, 2013 2:19 am

Re: Multiplayer (Controlling multiple session)

Post by Jor'Mox »

Pointedly though, the capability being asked about here could absolutely be handled with the types of arguments that are already accepted in events. Also, in a worst case scenario, you can convert a table to a string representation, and then convert back on the other side.

Nyyrazzilyss
Posts: 334
Joined: Thu Mar 05, 2015 2:53 am

Re: Multiplayer (Controlling multiple session)

Post by Nyyrazzilyss »

SlySven wrote:one active profile to raise a "Event" in a round robin to every other active profile in order (so that the sender "received" the event after all the others - so it knew it had been sent all around) ;)
That sounds correct, however, the mudlet code portion of that would also need to be single thread to prevent 'race' conditions.

Example. 4 profiles exist (A, B, C, and D). If both A and D try and raise an event at the exact same time, technically one of them would need to reach the event handling code first. We'll assume it's A.

The events sent out would need to be in the order A->B, A->C, A->D, A->A, D->A, D->B, D->C, D->D

This would allow (in lua) a profile to obtain a 'lock' on the shared data + change the value then replicate that between all the profiles, and prevent multiple profiles from changing the same data at the same time.

Nyyrazzilyss
Posts: 334
Joined: Thu Mar 05, 2015 2:53 am

Re: Multiplayer (Controlling multiple session)

Post by Nyyrazzilyss »

Jor'Mox wrote:Pointedly though, the capability being asked about here could absolutely be handled with the types of arguments that are already accepted in events. Also, in a worst case scenario, you can convert a table to a string representation, and then convert back on the other side.
That would be correct, yajl.to_value and yajl.to_string would allow passing a table through a string variable.

If the concern was in regards to sending multiple variables through the event, i'd suggest you just don't support it: A string encoded table, or potentially the actual table seem to be the correct way to go.

User avatar
Vadi
Posts: 5035
Joined: Sat Mar 14, 2009 3:13 pm

Re: Multiplayer (Controlling multiple session)

Post by Vadi »

Passing the table, unless you're creating copies of the entire table every time, doesn't seem like a good idea. Let's stick to passing the variable number of arguments only as the current event system allows. As already pointed out, if someone wants a table, they can convert it to/from json.

User avatar
SlySven
Posts: 1019
Joined: Mon Mar 04, 2013 3:40 pm
Location: Deepest Wiltshire, UK
Discord: SlySven#2703

Re: Multiplayer (Controlling multiple session)

Post by SlySven »

Well for those interested - take a look at Pull Request 339 for the development branch - it turned out that I was already on the right track - I just had to learn how to use variadic functions when writing Lua test code samples.

Anyhow this PR adds a raiseInterProfileEvent( ... ) function that takes an unspecified number of boolean, nil, number or string arguments and propagates those arguments to all active Profiles where they can be received by a sysInterProfileEvent( dummy, source, ... ) Event handler. The first argument THAT gets is a discard-able "sysInterProfileEvent" string, the next is the profile name of the sending profile and the ... is the unspecified data sent - if you have a fixed format for all your profiles for this event you probably can get a bit more specific in your argument list.

For testing I was using:
Code: [show] | [select all] lua
-- <profile name> receive profileInterLink functions
function sysInterProfileEvent( dummy, source, ... )
	profileInterLink.received = profileInterLink.received + 1
	profileInterLink.lastReceive = ...
	cecho("\n<green:white>("..profileInterLink.received..")<magenta:white> "..source..":<black:white>")
	for i = 1, select("#", ... ) do
		local data = select( i, ... )
		if i > 1 then
			cecho( ", " )
		end
		cecho( "{"..i.."}" )
		if type( data ) == "nil" then
			cecho( " (nil)" )
		elseif type( data ) == "boolean" then
			if data then 
				cecho(" (bool) true" )
			else
				cecho(" (bool) false" )
			end
		elseif type( data ) == "number" then
			cecho(" (number) "..data )
		elseif type( data ) == "string" then
			cecho(" (string) \""..data.."\"" )
		elseif type( data ) == "table" then
			display( data )
		else
			print( data )
		end
	end
	cecho( "<reset>\n" )
end
For a sample of this in use:
Mudlet_sysInterProfileEvent_in_action.png
As it happens I discovered that there was not a simple way that I could see how a script could identify the name of the profile it was running in - so I also provided a getProfileName() command that, taking no arguments, returns it as a string. Note that raiseEvent as well as these two functions has been upgraded to support Utf-8 strings...

Nyyrazzilyss
Posts: 334
Joined: Thu Mar 05, 2015 2:53 am

Re: Multiplayer (Controlling multiple session)

Post by Nyyrazzilyss »

Thanks! Hopefully a relatively minor code change that doesn't cause a ton of potential errors, but it does introduce a whole new level of scripting with muds that support multiplay.

Nyyrazzilyss
Posts: 334
Joined: Thu Mar 05, 2015 2:53 am

Re: Multiplayer (Controlling multiple session)

Post by Nyyrazzilyss »

Just built dev/pr339 for testing - From your example above (I just cut/paste):

You've included a receive side function. Is pasting it sufficient, or does it also need a registered event handler?

Send side - What is the sample code you're currently using? I tried just a straight 'lua raiseInterProfileEvent()' and it didn't do anything/returned nil

(edit)

Put it in a script, and k,error = raiseInterProfileEvent() returned

"raiseInterProfileEvent: missing at least one argument (a string, number, boolean, or nil
expected, got nothing!)"

Obvious :)

I changed it to raiseInterProfileEvent("teststring"), and it's now returning 1,nil. The receive side function I cut/paste from above doesn't appear to be getting called, however.

(edit)

I added the registered event handler, and modified the script event (example: profileInterLink.received or for that matter profileInterLink are never defined in it) - Working now :)

Suggestion: raiseInterProfileEvent seems to be a complex name. How about something simpler, like 'raiseGlobalEvent'?

(edit)

Actually, even better - Remove the command completely, and just use the existing raiseEvent engine?

example: raiseEvent("sysInterProfileEvent", ...)

User avatar
Vadi
Posts: 5035
Joined: Sat Mar 14, 2009 3:13 pm

Re: Multiplayer (Controlling multiple session)

Post by Vadi »

I think a separate command is worthwhile as this has a very special function - this event is sent to all profiles, unlike all others, which are per-profile only. raiseGlobalEvent() sounds fine to me.

Post Reply