[OSP] Punishments Manager (Name Server Addon)

Users who are viewing this thread

Dodo, there seems to be an issue with this OSP.  I am having huge problems implimenting script system to it, but when I add my code and url responses to default PW system I have no issues. 

The integers and strings are not set to conflict in url response, I checked everything hardcore, this is my second time trying to implement your system with mine. 

I noticed the NS returns in your code have no strings to look for and i'm wondering if just listening for integers is causing a conflict.

Cheers.
 
Hello' Peasant. So, if I correctly understood your issue, you tell me this addon perfectly works on a native version of Persistent World but not on your edited one. You got troubles setting your own messages handler, right ?
Ok, so, effectively, when a message is received, no strings are compared to check wich part of the code is start. The Punishments Manager (PM) and the Name Server (NS) are both triggered via a pre defined integer. Each message returned by the web server will contain this ID as reg0 parameter.

In order to implement your scripts, you will also need to set an identifier as reg0 parameter, this one must be > 2 since 1 & 2 are already used for PM and NS. In the scripts, here is how it's implemented:
Code:
# Link: http://localhost/pwnameserver/server-request/check-player.php?uid=1000&id=5&name=User | Result: 1|0|Welcome|5 | Const: reg0{Identifier}
	  (try_begin),
		  (eq, 1, reg0), # Identifier: 1 -> Punishments Manager
	    (assign, ":status", reg1),
	    (assign, ":player_id", reg2),
	    (player_is_active, ":player_id"),
	    (multiplayer_send_string_to_player, ":player_id", server_event_local_chat, s0),
	    (try_begin),
	      (eq, ":status", 1),
		    (store_mission_timer_a, ":time"),
		    (val_add, ":time", name_server_kick_delay_interval),
		    (player_set_slot, ":player_id", slot_player_kick_at_time, ":time"),
	    (try_end),
			
	  (else_try),
		
		  (eq, 2, reg0), # Identifier: 2 -> Names Server
                   ...
                   ...
                   ...

If you look at the first line, you can see an example of what returned value by the PHP script will look like. There are four parameters, three of them are integer and one is a string. Only the first integer is interesting because it's the one used as identifier, as set on the third line of the code above. Same for the NS at the last line. This identifier is a pre-defined constant wich must be used to identify an action (1=PM, 2=NS), and is set in your PHP file wich will be triggered upon your custom link request.

If it did not fix your issue, please, send as many details as possible such as your code etc.
 
it doesn't make sense to me, I make sure to add a buttload of extra strings for filtering on my system, making sure it does not conflict with the name server.  hmmmm. 

Maybe I am doing something wrong, in your system your first return is an integer, i'm not sure if this matters, but here is an example of my format.  Though my custom strings are a little crude lol.

This is the first recieve response which works.

Code:
 (try_begin), # playernames|EQUIP|ARMOR|AND|WEAPONS|FROM|********|DATABASE|1375631|20|88|0|0|218|-1|0|0|1337
 
         (eq, ":integer_count", 10),
		 (eq, ":string_count", 8),
		 (assign, ":player_id", reg9),
         (assign, ":head", reg1),
         (assign, ":body", reg2),
         (assign, ":feet", reg3),
         (assign, ":hands", reg4),
         (assign, ":equipment1", reg5),
		 (assign, ":equipment2", reg6),
		 (assign, ":equipment3", reg7),
		 (assign, ":equipment4", reg8),

and when the second response comes in it stops working

Code:
 (try_begin), #playernames|GET|********|****|ASS|*****|POSITION|1375631|30198|0|600|1337
	  (eq, ":integer_count", 5),
	  (eq, ":string_count", 7),
	  (assign, ":player_id", reg5),
      (assign, ":posx", reg1),
      (assign, ":posy", reg2),
      (assign, ":posz", reg3),
 
my question is, yours responds with int, int, string, int. 

mine responds with string,string,string,string,string, int, int, int, int

i am pretty sure by assigning to reg, it will start with reg0 - reg3, assigning only ints because it is reg. and if I wanted to store strings I would store them in so s1 s2 s3 s4 s5 ect..

is my system flawed?

Hmmmm I see you are filtering with (eq, 1, reg0), instead of

(eq, ":string_count", 1),
(eq, ":integer_count, 3),

could that be the issue?  if one of my scripts happens to respond with 1 as reg0?

The only time my system responds with 1 or 0 as reg0 when when I use the update function, I do not filter those responses because they are uneeded, but they do echo back the result of 1 or 0 regardless.  Could that mess with the name server and punishment manager?  0 means account does not exist in database and 1 means it does exist when updating database data.  Essentially, I force return the peremeters i need for lets say banking, the only update command which has a filtered response.  would we need to shut off the responses of 0 and 1 when updating databse data?  and instead use our forcereturn command to return data we will be filtering? 

it does not seem our system will conflict with vornn's 2 reg0 response, which is why our code works in the normal version of pw?
 
As said above, the first INTEGER (reg0) is essential. If you do not have your first parameter as an integer, add one (must be the first one).
Once done, assign it an ID (constant) on your PHP page, the one you want (as long as it's bigger than 2). Once done, at your receive_url script, you do the 'filtering' as you call it with it. If this step is not understood, you should re-read my previous post.
 
yeah dodo, it's not your system it is mine.  for some reason my filtering is not working correctly and I am getting invalid player ID errors.  I have both tried sending the player id directly from the script being called, and also tried storing it in the database and calling it from the database on the receive script.  Though the bank withdraws it does not deposit when it did when i would update the playerid in the database everytime the deposit or withdraw feature was used.

I'm not sure what the problem is, I assign first int as reg0 and go up from there, armor saving works, weapons are not equiping.

I'm not sure what I am doing wrong, is there a way to get the player ID using the unique ID from the database?  would be be like (get_agent_id, ":agent_id", ":unique_id"), than (agent_get_player_id, ":player_id", ":agent_id"), ?  because for some reason receiving the player_id and assigning it from the url response is not working. 

:sad:
 
Xaphan said:
I'm not sure what I am doing wrong, is there a way to get the player ID using the unique ID from the database?  would be be like (get_agent_id, ":agent_id", ":unique_id"), than (agent_get_player_id, ":player_id", ":agent_id"), ?  because for some reason receiving the player_id and assigning it from the url response is not working. 
No, because a particular player id and unique id are only linked for a play session while the client stays connected to the server: storing a player id in an external database makes no sense, because the numbers are reused for other players (unique ids) when disconnected, reconnected, or the server is restarted.
Xaphan said:
is my system flawed?
I will quote my reply from earlier in this thread about why distinguishing different url response types by integer count and string count is a non-standard and bad idea:
Vornne said:
I discourage the practice of distinguishing web server replies by the number of parameters, i.e. the (eq, ":integer_count", 2), (eq, ":string_count", 1) added in the first else_try block of script game_receive_url_response. It has somehow become popular with people writing simple guides for web servers with Warband, but it is a bad idea: no other message types can then use 2 integers and 1 string, having to add useless extra parameters to avoid conflicting, confusing anyone trying to merge different features that use a web server. You have a "status" value in reg0, which is very close to the right idea: it should be a unique "return code" to work in with the official name server and any other web server feature desired, so like the slots in module_constants, people only need to check one place for conflicts when merging code (that all the "return code" / "message type" numbers are unique). I didn't define the return code constants in the module system, because the languages of the module system and web server are different (Python, PHP) making it seemingly impractical to try use the same list; so the return codes are only named in the web server configuration, manually using the same numbers in script game_receive_url_response (you might have a better idea).
To reiterate: use a message type number at the start, like basically every other well designed network message format (strings are a bad choice because the computer only understands them as much longer numbers anyway, and in this case the M&B module system can't compare strings at all - no operations for it). Other examples you might be aware of are things like HTTP 404 in a web browser (not found) or 503 (service unavailable), etc. This way many different people can transmit many different types of messages over the same system, by just maintaining a global list of numbers corresponding to message types. Similarly to how slots work in the module system: two different mod developers might write code that uses various agent slots, for example, and they happen to use numbers that conflict: all you would need to do to merge the code together is to change some slot numbers in module_constants so all are unique.

The PW name server system is designed in a similar way, though with two places for message ids rather than one, since compilation is done in two different languages (Python and PHP): in pwnameserver/private/config.php, the const members of pw_name_server_config, and in script game_receive_url_response, any (eq, ":return_code", number) operations. To integrate different web servers written by different developers with the same Warband server, they all just need to follow the convention that the first integer (reg0) is a message type, and it will always be a number chosen to be unique compared to all the other message types used in other code. For example, since the name server code uses -3, -2, -1, 0, 1, 2, 3, 4, you might choose to use message numbers (type / return code / id / whatever you want to call it) from 30 to 40, or 100 to 200, or 4332 to 4387 - you can use whatever numbers tickle your fancy, as long as you make them unique for each kind of message. If you wanted to combine a punishments manager and a random welcome message generator, but the developers of each both decided to use message type / return code 47, you would just change one of them to 57, or something else. If the code was written using named constants like the name server, you would only have to change in one place - the number in the private/config.php file, for example, and all the other code using the named constant (like pw_name_server_config::name_invalid_error) would be automatically updated.

It would be possible to wrap entire groups of messages with unique numbers, as Ra'Jiska suggested, but that is more intrusive and harder to maintain: because you are adding a new number to the front of every format, rather than adjusting a message type number already existing for every message type, merging different web server features would require going through all the module system code and string formatting that composes or reads the message values for each type, incrementing the register numbers used, and making sure you understand all of the code to avoid introducing subtle errors.
 
so essentially if I decided I wanted 30 to trigger the return code for example, setting a players position from stored xyz values, I would want my first integer to be 30 in the response?

than instead of (eq, ":string_count", 9999999), and (eq, ":integer_count", 3), I could simply use (eq, reg0, 30),?

I'm having horrible luck with the string and integer method which worked in the last system I used, but when creating my own, it works 1/4th of the time.

I'm pulling my hair out as we speak. 
 
Xaphan said:
than instead of (eq, ":string_count", 9999999), and (eq, ":integer_count", 3), I could simply use (eq, reg0, 30),?
Essentially, yes. Just make sure you reserve the first integer as the message type / return code for every single web server script you use, otherwise something that returns a player id as reg0 could randomly trigger other message handlers (your example when the player id happens to be 30, a PW name server script handler if the player id happens to be 1 - 4, etc). Having the first number returned always be a unique return code should prevent many likely errors of the wrong script trying to handle a web server message.
 
Vornne said:
Xaphan said:
than instead of (eq, ":string_count", 9999999), and (eq, ":integer_count", 3), I could simply use (eq, reg0, 30),?
Essentially, yes. Just make sure you reserve the first integer as the message type / return code for every single web server script you use, otherwise something that returns a player id as reg0 could randomly trigger other message handlers (your example when the player id happens to be 30, a PW name server script handler if the player id happens to be 1 - 4, etc). Having the first number returned always be a unique return code should prevent many likely errors of the wrong script trying to handle a web server message.

We can define a header or multiple headers in the python web API now, just waiting on the next update and fixes before I get crackin.  so when I call the script for say on player join, I set out header with the headers command at the end of the url, including what data i want to retrieve, it is quite nice, but unfortunately the developer picked up some more projects and i feel he put the web api on the back burner for a lil while.  for example just to promote the python OSP web api

( if you wanted to retrieve armor, items, horse, health, you would use this url depending on your database table names )

http://urltowebsystem/get.py?table=accounts&lookupkey=uniqueid&values=head,body,feet,hands,item1,item2,item3.item4.horseid,health&headers=30

in receive area

(eq, reg0, 30),
assign items horse and health from relieved reg order.

It works quite well, it is kind of a hassle to install the websystem though, django can be brutal. 

Warband does not like _ in the url which is why I'm waiting for the update where $ will be converted into _ for example.  Thus making it compatible with vornne's name server "because i am lazy and do not want to write a script to check if account exists / create account if it does not". :razz:

It totally by passes the need to create custom php files anytime you write a new script.  And even has tools to compare two db entries both strings and ints.

I say it's almost 100% foolproof.

And we added echo=false feature, so upon updating, there is no return back to the server which ends up in errors in my debugging tests.
 
Yup, currently doing some little updates, dunno how long it'll take since I'm on several different projects at the same time, but it'll definitely be back before the end of this week.
 
Ra'Jiska said:
Yup, currently doing some little updates, dunno how long it'll take since I'm on several different projects at the same time, but it'll definitely be back before the end of this week.

Forbidden

You don't have permission to access /Downloads/Punishments_Manager.rar on this server.

WAS I A BAD BOI D:
 
Sorry for the late answer chunky_monkeh.
I am doing an update that would make it better before putting the link public again,
unfortunately, I am submerged under the mass of the work I have to do (not only with this).

If you really do wish it, there is no problem, you can send me a PM and I'd give it to you.
It goes for anyone else who want it.
 
Back
Top Bottom