Printable View
Hey All
Now to let gms have GM acess to my server, I put their IP in server hotuk's.
How can I do that to have GM acess you need to have ID + PW setted on the hotuk?
my GM section in server's hotuk is :
Ty,Code:*DEBUG_IP
*ADMIN_IP
*ADMINISTRATOR_IP
*ADMIN_LOGIN
*ADMIN_NAME
*ADMIN_COMMAND
*ADMIN_COMMAND
*ADMIN_COMMAND
Avi
i've never really seen it layed out like this,Quote:
Originally Posted by avi20
i've only ever seen it like this:
obviously where Johnwayne is the person id would beCode:*DEBUG_ID "Johnwayne"
and it must have the speech marks in :thumbup:
Ya but I need it to check both ID and IP before let gm acess.
not only ID or only IP .
IP + ID.
get your gm's to either use whatsmyip on google.Quote:
Originally Posted by avi20
i don't see what you're asking for? o.o
If you list their ID, it will work from any IP, if you list the IP it will work for any login... that's how the server exe works.
So to check both IP AND ID before allowing access, you have to recode the way the server executable works.
What you are asking for, doesn't exist, so you would have to make it your self... would be nice though.
try put the ip+id in the server hotuk and see what happends cant promise anything btw bobsbol i am sure you can answer that the hotuk text wrote in wich language?maybe we able to add some parameters if we will understand if its works and that might help avi
What happens I have already experienced... what happens is chaos where some GMs can log in and others can't and some players can log on as GM and some players can't log in at all. It just confuses the heck out of the server.Quote:
Originally Posted by tnrh1
The hotuk text in what language? What hotuk text? The full server hotuk text or just the client hotuk?
The Admin mode activation line in the client hotuk is almost universally written in fluent nonsense. It is a deliberatly obfuscated meningless line of drivvel. But it's different in each client... and of course you can replace it with whatever line of text you like, or put it in a different file, or in the registry, or expect it to be passed as a parameter on the command line as the uPT client does.
These things may add to the confusion for a hacker who isn't really a hacker but just finds a guide somewhere on the web that he thinks he can follow. It doesn't make it any harder for the person who doesn't care to read how someone else did it, but is prepared to work it our for themselves from scratch, and capable of doing just that.
i mean the server hotuk.
how the server.exe read the houtk i mean if i add new line "event drop" its will not effect how all this buisness going maybe in the server exe they turn you to the hotuk on some lines?i explained my self very bad i think lol i hope you understand me
I think I understood your last post better than this one. :lol:
The server reads its' hotuk the same way the client reads its' one.
Many server hotuk commands get left in the clients, and all the client hotuk commands still exist in the server.
How they read commands and parameters is kinda listed in my blog here... I'm still working on breaking out all the functions, but I should really make another post. Unfortunately, the code listing I have commented and labelled is too big for a RZ blog post. :(:
The PT code is largely very functional programming as far as I can see, and sports many so-called "global variables". These are declared outside "void main()" in C, or as "Dim Shared" in most Basic dialects. This analysis may be tinted by the fact that I was taught, and prefer to use functional programming, but my understanding is that in C++ (C#, Java or any other OOP language) you would instantiate a public settings object, with properties accessible to all other areas of the code.
The reason I don't think this is how PT works, is because it keeps those settings in an area of pre-declared memory with read and write (but not execute) access memory, set up by the PE header. Specifically, the .data section. Most C++ compilers I am acquainted with perform kernel malloc() calls to set up memory stores for objects on their instanciation.
Anyway. Those memories are zeroed as the hotuk processing routine begins... then lines are read, one at a time from hotuk.ini. The first word (before any tab or space character) is separated from the rest of the line, and compared to several arrays of known commands, grouped by the sort of settings they affect.
Each array of commands compared to the current lines first word (command) in a switch case, or select case style, and on the cases where it matches the current iteration of the array, the code is branched off to specific routines for that command, each of which is passed the remainder of the line (with white space trimmed to the left) to deal with as it sees fit.
But I'm really not sure that any of this information (interesting and useful in general as it is) is particularly helpful to avi20 at this particular moment. I share, because the question was asked, and I may be wrong... it could be helpful in a way I have not considered.
yea..
btw about the viod main..c++ and java i started learn that in school for be able to understand and work better with the pt files hope one day ill see the connection between this languages and pt about avi i guess u cant set it in the hotuk maybe we able find this commands in the client and edit them bobsbol?ill take a look
Okay, check this post for one of my old custom clients with completely re-written configuration file reading.
I say completely re-written, when I'm done fixing up the PPT client it will technically be more completely that that old ZPT one, but the effect will still be more noticeable in the ZPT client.
Build "hello world", or better yet, the second part that asks for your name and then says printf("Hello %s!", name) in 3 to 5 different languages and a couple of dialects of each. Say C, C++, Basic and Pascal, on VC++2005, Borland C++ and GNU GCC, FreeBasic, VisualBasic and Moonrock, FreePascal, Borland Turbo Pascal and Delphi.
Olly the executables built by each. But when you do the C and C++ comparisons, make sure you printf and getch and char * in one and cout, cin and new * the other, then you will see how functional C initialises the memory as the program is loaded in memory by the kernel, and Object Oriented C++ allocates the memory from the kernel at run-time... because each object can have another instance created at any time during the operation of the program, where a global variable declared outside the program will exist before the program is run, and continue it's existence throughout the execution life-cycle up until it exits cleanly back to the OS.