Even MORE questions

[-Setro-]

Sorry for being so dependent, but I really want to learn TS quickly.
1. I want an output event with a table you type in while eventing to do stuff.
Somewhat like chatmsgall. How can I do this?
2. Reliable check to see if a client has the correct client for a server downloaded?
3. Making an output event admin only? (As in, only admins can put it in bricks, but anyone can trigger it?)
Thank you!

[Ad Bot]

[Amade]

#2. Create a client command that is sent to players when they connect to the server (a "ping"). Your mod should have this client command trigger the sending of a command to the server (a "pong"). If the server receives a pong, it is reasonable to conclude that a player has your add-on installed. Otherwise, they probably do not have your add-on installed.

For #3, I recommend tracing the application of events to a brick. You can enable trace with trace(1); and disable it again with trace(0);. While trace is enable, every function called, along with the arguments provided to that function, are echoed to the console. You only need to find and package the server commands that apply events to a brick.

[Val]

For #2, you should probably have the mod send the indicator that it has the add-on through the connection arguments.  This is explained pretty well in this topic, along with an example:
http://forum.blockland.us/index.php?topic=175929.0

The benefits include not having the join/leave spam that usually accompanies less sophisticated methods that do the same thing.

[Greek2me]

I would recommend that you do NOT follow Val's advice as you're likely to accidentally overwrite somebody else's mod (or have yours overwritten). Use Amade's point #2 instead. It's the safe route.

[Headcrab Zombie]

For #3, I have a resource available in environment control events (Event_EnvControl, available here) that makes doing exactly this very easy:

Code: [Select]

exec("./Support_AdminEvents.cs");
registerAdminOnlyOutputEvent("player","kill",2);
will make the player::kill event superadmin only.

Other options for the last argument are 1 for regular admin or 3 for host only

You could use it as is or dig through it and get what you need

[Val]

I would recommend that you do NOT follow Val's advice as you're likely to accidentally overwrite somebody else's mod (or have yours overwritten). Use Amade's point #2 instead. It's the safe route.

No, use my method.  The problem is the usage of it isn't standardized and we have lots of mods clashing together.  I agree we shouldn't add to the problem, but I disagree that the solution is using a workaround.  The solution isn't to avoid it and fall back to worse methods, its to make an effort to fix the problem.  The connection argument system was made for a reason.

[boodals 2]

IMO, Val's method should only be used when the client requires the add-on to join the server, period. If the client could be able to connect, load datablocks, spawn, ghost, etc without any major errors, you should use Amade's method.

Setting the connection args (while very fancy) can cause a billion issues very easily if you don't know exactly what you're doing, and thus should be avoided at all costs.

[Val]

The implication being that you want to disconnect anyone who's not compatible (or require that the information be known before any action) of course.  You shouldn't use it for anything else really.

[Ipquarx]

What val means is that there is a way you can avoid running out of arguments to use, and that's by not totally replacing an argument, but instead adding onto it and on the server side, checking if it contains a certain substring. This way all mods will be compatible

For example on the client side:
%Arg = %Arg @ "(modname shortened to 4 characters)" @ "(mod version as a plain integer)";

And on the server side:
if(strStr(%Arg, "(modname shortened to 4 characters)" @ "(mod version as a plain integer)") >= 0)

There are 16 arguments in the original function, the first 5 of which are used default by blockland. Each argument can take 255 characters, and if each string takes up say 5 characters, that's a total of 51 possible mods per argument for a total of 561 different mods that can use the command arguments, which is a lot better than 11.

[boodals 2]

%Arg = %Arg @ "(modname shortened to 4 characters)" @ "(mod version as a plain integer)";

There already is a 'standardized' way of doing this, as seen here, using tab seperated fields, with the first word as the mod name/id, and the rest as whatever you need. Its less efficient, but we don't need 561 mods.

[Ipquarx]

There already is a 'standardized' way of doing this, as seen here, using tab seperated fields, with the first word as the mod name/id, and the rest as whatever you need. Its less efficient, but we don't need 561 mods.

That "standardized" version doesn't even include all the default arguments for the function. :/