Show Posts
286
Science / Re: The Ye Science Thread
« on: January 05, 2014, 09:52:48 AM »
The FTL neutrino beam experiment was proved to be an error in the experiment. Einstein prevails again.
|
| P | Q | |
| T | T | F |
| T | F | T |
| F | T | T |
| F | F | F |
This is P XOR Q. The exclusive or function is Boolean function. How is this related to game theory? Post your answer, explain your result in 50 words or less.
291
0x1337c0de / Re: Getting started with the Quake 2 source
« on: September 21, 2013, 11:34:07 PM »
Necrotic thread but I watched your video and I never saw you actually compile your project. You created a project and opened the files in the editor but I never saw you run LCC.
The compiler (if it's keeping to its Linux roots) will evaluate the Makefile and use it as a guide to build the project.
In Linux, the command is done from a shell window in your project source folder and the command is simply 'make'. The make progam looks for Makefile and that file tells it what files to use to build the project and what to call it.
As it says in the instructions you were following, the DLL will be located in the source directory where you built it. The gamex86.dll files are always located in the mod folder for their respective mods. When you tell the quake2.exe what mod to run with the +set game mymodname command line the engine will look into the mymodname folder for your DLL, expecting it to be named gamex86.dll, it loads that DLL and that becomes the modification to the game engine and your running your mod.
OK, so I'm a curious guy and I have some time on my hands tonight so I installed LCCWin and copied the Quake2 v3.21 source into the lcc folder in one big chunk since I don't know where your Combat18 mod source is.
OK, I followed it all up to the point of adding the game.def file and since I was using the "working" game.def as-is from my copy of the Q2 sources I left it alone. Later I tried to write GetGameAPI=GetGameAPI into the file but Wedit but it wouldn't make the change. I don't believe it needs to read that way anymore. I believe that was the old VC 6.0 syntax.
Anyway, once you have all your files "loaded" into wedit, you need to build the project.
Click Compiler, Generate Makefile.The system will create the Makefile.
Click Compiler, Rebuild All. The compiler will run scrolling output to a split window in wedit, finally ending in a list of warnings and errors.
Errors will stop the build process. Warnings won't. Double clicking on a warning or error line will take you to the source file where the warning occurred. If you have so much as one error, your dll won't be built, don't look for it. Warnings are permissible and you can deal with them as needed. I am strict about my code, I want it to produce no warnings so I will investigate and fix them.
If you don't see "Return code: 0" at the bottom of the warnings list, you don't have a DLL.
The ultimate question is Where's my DLL? The answer to that question is found in the wedit project configuration.
Click Project, Configuration and then the Linker tab. The output filename you find there is where your DLL will be if there were no errors in the build. I ended up finding it at c:\lcc\Quake2source\game\lcc\gamex86.dll.
I also found all the .obj files in that same folder. The .obj files are built by the compiler from each source file.
The compiler (if it's keeping to its Linux roots) will evaluate the Makefile and use it as a guide to build the project.
In Linux, the command is done from a shell window in your project source folder and the command is simply 'make'. The make progam looks for Makefile and that file tells it what files to use to build the project and what to call it.
As it says in the instructions you were following, the DLL will be located in the source directory where you built it. The gamex86.dll files are always located in the mod folder for their respective mods. When you tell the quake2.exe what mod to run with the +set game mymodname command line the engine will look into the mymodname folder for your DLL, expecting it to be named gamex86.dll, it loads that DLL and that becomes the modification to the game engine and your running your mod.
OK, so I'm a curious guy and I have some time on my hands tonight so I installed LCCWin and copied the Quake2 v3.21 source into the lcc folder in one big chunk since I don't know where your Combat18 mod source is.
OK, I followed it all up to the point of adding the game.def file and since I was using the "working" game.def as-is from my copy of the Q2 sources I left it alone. Later I tried to write GetGameAPI=GetGameAPI into the file but Wedit but it wouldn't make the change. I don't believe it needs to read that way anymore. I believe that was the old VC 6.0 syntax.
Anyway, once you have all your files "loaded" into wedit, you need to build the project.
Click Compiler, Generate Makefile.The system will create the Makefile.
Click Compiler, Rebuild All. The compiler will run scrolling output to a split window in wedit, finally ending in a list of warnings and errors.
Errors will stop the build process. Warnings won't. Double clicking on a warning or error line will take you to the source file where the warning occurred. If you have so much as one error, your dll won't be built, don't look for it. Warnings are permissible and you can deal with them as needed. I am strict about my code, I want it to produce no warnings so I will investigate and fix them.
If you don't see "Return code: 0" at the bottom of the warnings list, you don't have a DLL.
The ultimate question is Where's my DLL? The answer to that question is found in the wedit project configuration.
Click Project, Configuration and then the Linker tab. The output filename you find there is where your DLL will be if there were no errors in the build. I ended up finding it at c:\lcc\Quake2source\game\lcc\gamex86.dll.
I also found all the .obj files in that same folder. The .obj files are built by the compiler from each source file.
292
0x1337c0de / Toward a Better MOTD
« on: September 21, 2013, 07:37:41 PM »
LOX has a feature that sends a motto of the day (MOTD) to players when they connect. This code was originally in-line in the ClientBeginDeathmatch function and it was an UGLY part of an otherwise simple ClientBeginDeathmatch function.
Today I decided to clean it up a bit, make it a callable function and publish it for use by other mod developers who might be interested in using a MOTD in their mod. I don't know where the original code came from, it was a part of LOX from a very long time ago and also exists in WODX and presumably WOD from where LOX and WODX derive their pedigree.
ClientBeginDeathmatch isn't called frequently so there is no advantage to writing the code in-line and avoiding a function call. It also goes against discipline to write something in line where a function will be more advantageous and the resulting code much more clear.
The ClientPrintMOTD function prototype belongs at the top of p_client.c or in g_local.h if you intend to access it globally:
void ClientPrintMOTD (edict_t *ent);
The function body belongs in p_client.c:
Define the necessary CVAR in GameInit:
Add the CVAR to g_local.h:
Restore the ClientBeginDeathmatch to it's original beauty.
You will notice the ClientPrintMOTD function has a trapdoor in the gMOTD pointer. It's initialized at definition to -1 and the function sets it to NULL if there's a problem initializing the cache it is supposed point to that contains the MOTD text. I'm not sure I would have done it exactly that way but you may see a modified version later, I decided to publish this as-is and may polish it up another time. The trapdoor closes the first time the function is called and the gMOTD pointer either points to a valid MOTD string or it is NULL. The trapdoor prevents the function from taking the time to open/read/close the motd.txt file every time someone connects. The problem with this technique is that if you change the MOTD file you must restart the server to get it to read it again and update the cache.
Add a motd.txt file to your server's mod folder and enjoy your center-printed MOTD.
Today I decided to clean it up a bit, make it a callable function and publish it for use by other mod developers who might be interested in using a MOTD in their mod. I don't know where the original code came from, it was a part of LOX from a very long time ago and also exists in WODX and presumably WOD from where LOX and WODX derive their pedigree.
ClientBeginDeathmatch isn't called frequently so there is no advantage to writing the code in-line and avoiding a function call. It also goes against discipline to write something in line where a function will be more advantageous and the resulting code much more clear.
The ClientPrintMOTD function prototype belongs at the top of p_client.c or in g_local.h if you intend to access it globally:
void ClientPrintMOTD (edict_t *ent);
The function body belongs in p_client.c:
Code: [Select]
// Store the message of the day in memory.
char *gMOTD = ((char *)-1); // initialized at startup as bad pointer
cvar_t *motdfile;
void ClientPrintMOTD (edict_t *ent)
{
FILE *in;
char motdPath[MAX_QPATH + 1];
int c;
int motdBytes;
char *here;
// If the MOTD hasn't been loaded, do so.
if (gMOTD == ((char *)-1))
{
// Generate the path to the MOTD file.
if (gamedir == NULL || motdfile == NULL
|| !gamedir->string[0] || !motdfile->string[0])
{
gMOTD = NULL; // null pointer means we'll never try again
return;
}
sprintf (motdPath, "./%s/%s", gamedir->string, motdfile->string);
// Open the file.
in = fopen (motdPath, "rt");
if (in == NULL)
{
gi.dprintf("Opening MOTD file failed, error: %i.\n", errno);
gMOTD = NULL;
return;
}
// Count the number of bytes in the file.
motdBytes = 0;
while ((c = fgetc (in)), c != EOF)
motdBytes++;
// Make space for that many bytes.
gMOTD = gi.TagMalloc (motdBytes + 1, TAG_GAME);
gi.dprintf("Allocating %i bytes for MOTD\n", motdBytes +1);
// Now read the MOTD in for real. Null-terminate the string.
fclose (in);
in = fopen (motdPath, "rt");
here = gMOTD; //extra pointer for writing into gMOTD
while ((c = fgetc (in)), c != EOF)
{
*here = c;
here++;
motdBytes--;
}
*here = '\0';
// If anything went wrong, warn the console.
if (motdBytes != 0)
gi.dprintf ("MOTD error: off by %d bytes", motdBytes);
}
if (gMOTD != NULL) // If a MOTD was successfully loaded, print it.
gi.centerprintf (ent, "%s", gMOTD);
return;
}
Define the necessary CVAR in GameInit:
Code: [Select]
motdfile = gi.cvar ("motdfile", "motd.txt", 0);
Add the CVAR to g_local.h:
Code: [Select]
extern cvar_t *motdfile;
Restore the ClientBeginDeathmatch to it's original beauty.
Code: [Select]
/*=====================
ClientBeginDeathmatch
A client has just connected to the server in deathmatch
mode, so clear everything out before starting them.
=====================*/
void ClientBeginDeathmatch (edict_t *ent)
{
G_InitEdict (ent);
InitClientResp (ent->client);
// locate ent at a spawn point
PutClientInServer (ent);
if (level.intermissiontime)
MoveClientToIntermission (ent);
else
{
// send effect
gi.WriteByte (svc_muzzleflash);
gi.WriteShort (ent-g_edicts);
gi.WriteByte (MZ_LOGIN);
gi.multicast (ent->s.origin, MULTICAST_PVS);
gi.bprintf (PRINT_HIGH, "%s entered the game\n", ent->client->pers.netname);
}
ClientPrintMOTD(ent);
// make sure all view stuff is valid
ClientEndServerFrame (ent);
return;
}
You will notice the ClientPrintMOTD function has a trapdoor in the gMOTD pointer. It's initialized at definition to -1 and the function sets it to NULL if there's a problem initializing the cache it is supposed point to that contains the MOTD text. I'm not sure I would have done it exactly that way but you may see a modified version later, I decided to publish this as-is and may polish it up another time. The trapdoor closes the first time the function is called and the gMOTD pointer either points to a valid MOTD string or it is NULL. The trapdoor prevents the function from taking the time to open/read/close the motd.txt file every time someone connects. The problem with this technique is that if you change the MOTD file you must restart the server to get it to read it again and update the cache.
Add a motd.txt file to your server's mod folder and enjoy your center-printed MOTD.
293
Quake / Re: my server no longer shown on q2servers.com
« on: May 25, 2013, 09:33:21 AM »I'm not the OP. (original poster). i was just sharing information with the OP on the masterservers from my config. i only host 1 server. it is a local one. i have no problem with seeing it in the q2server browser."setmaster master.q2servers.com" what is wrong with this master server? i posted this on my 1st post.
fish is having problems. i just figured he didn't have the right master servers in his config. there seemed to be a little confusion as a result.. my mistake. disregard that. so now that's out of the way, you can concentrate on his issue.
There is nothing wrong with that server. But you need to view the list of servers on http://q2servers.com/ or with R1ch's Quake2 Server Browser, a Windows application.
If you keep seeing nothing but heartbeat messages then your firewall settings are incorrect. You must open the Quake2 server port (27910 by default) for UDP inbound and outbound.
294
Quake / Re: my server no longer shown on q2servers.com
« on: May 25, 2013, 01:21:36 AM »
Sheesh. 
I didn't pay close enough attention to the threading. I hate web forums for that reason. One of these days someone is going to invent a way for web forums to display threaded posts.
Fishxz can use the information from my last post to figure it out, I'm sure.
I didn't pay close enough attention to the threading. I hate web forums for that reason. One of these days someone is going to invent a way for web forums to display threaded posts. Fishxz can use the information from my last post to figure it out, I'm sure.
295
Quake / Re: my server no longer shown on q2servers.com
« on: May 25, 2013, 01:06:16 AM »I see one server, 71.190.92.212:27910, Golgo13's Lithium CTF.
yea, i dunno dude. those are just acknowledges from the masters i thought. you're better at techical jargon. i just put what was showing in my console.
I don't know what this means. You didn't answer any of my questions about your servers and IP's. I am telling you I see one server in your name on the q2servers.com active servers list. If you have more, tell us what they are named and what their IP's are. If they are hosted on the same computer you are going to have problems if you don't properly configure them and open your ports on your router for them.
You appear to have only one valid server active and listed.
The server/master handshake looks like this:
server master
->ping-> server pings master until it receives ack
<- ack <-
master prepares to poll server
master polls server periodically once it has listed the server as active:
<- ping <- master pings server to see if it's alive
-> ack -> server is alive
<- status <- master asks for game status
-> print -> server sends game status and variables (player list, etc.)
<- ack <-
Between pings and status dialogs, every 5 minutes the server sends a heartbeat frame to the master.
->heartbeat ->
<- ack <-
... repeat
If this handshake fails the master will not list the server. It can take several tries before a master will list a server as active since this all occurs on UDP and delivery is not guaranteed by the protocol.
At server shutdown the server sends a "shutdown" frame to the master and terminates the process and the master deletes the server from the list. The server does not expect an ack to the shutdown frame. The master will delist the server immediately if it receives the shutdown frame but if it doesn't receive the shutdown frame it can take 10 minutes for the master to delist the server. If a server crashes unexpectedly the master will delist the server after it fails to receive acks to its pings.
What you will see in your console if this is all working as expected:
Ping acknowledge from 173.236.101.34:27900
Sending heartbeat to 173.236.101.34:27900
Ping acknowledge from 173.236.101.34:55708
Ping acknowledge from 173.236.101.34:55708
Ping acknowledge from 173.236.101.34:55708
Ping acknowledge from 173.236.101.34:55708
Ping acknowledge from 173.236.101.34:55708
Ping acknowledge from 173.236.101.34:55708
Sending heartbeat to 173.236.101.34:27900
Ping acknowledge from 173.236.101.34:55708
Ping acknowledge from 173.236.101.34:55708
Ping acknowledge from 173.236.101.34:55708
Ping acknowledge from 173.236.101.34:55708
Ping acknowledge from 173.236.101.34:55708
Ping acknowledge from 173.236.101.34:55708
Sending heartbeat to 173.236.101.34:27900
Ping acknowledge from 173.236.101.34:55708
Ping acknowledge from 173.236.101.34:55708
296
Quake / Re: my server no longer shown on q2servers.com
« on: May 24, 2013, 06:13:44 PM »
I see one server, 71.190.92.212:27910, Golgo13's Lithium CTF.
297
Quake / Re: my server no longer shown on q2servers.com
« on: May 24, 2013, 12:20:47 PM »
The listmasters results you show would indicate you are communicating with the master. If you are communicating the number in the lastmsg column will change each time you use the listmasters command.
The setmaster result says otherwise.
All the other servers you have listed no longer exist as happy friar points out.
Netdome.biz doesn't respond as a Q2 master server.
The owner of q2servers.com is R1ch. He may respond if you post you question on his forum.
Check your firewall settings on the servers, if they are hosted sometimes hosting companies will block outbound traffic on the ports Q2 uses.
Make sure you aren't filtering your server list too. R1ch's quake 2 server browser remembers the filter settings and caught me off guard a couple of times.
What are your server names and IP addresses? I will take a look too.
The setmaster result says otherwise.
All the other servers you have listed no longer exist as happy friar points out.
Netdome.biz doesn't respond as a Q2 master server.
The owner of q2servers.com is R1ch. He may respond if you post you question on his forum.
Check your firewall settings on the servers, if they are hosted sometimes hosting companies will block outbound traffic on the ports Q2 uses.
Make sure you aren't filtering your server list too. R1ch's quake 2 server browser remembers the filter settings and caught me off guard a couple of times.
What are your server names and IP addresses? I will take a look too.
298
Quake / Re: my server no longer shown on q2servers.com
« on: May 23, 2013, 10:11:59 PM »
master.exhale.de has been gone for at least a year. I took it off my configurations that long ago when I noticed it wasn't responding to my server pings. The exhale.de domain is still valid but the subdomains master.exhale.de or masterserver.exhale.de are no longer registered.
fishxz: r1q2dedicated defaults to master.q2servers.com without the need for it to be set with the setmaster command. I don't know if this is true for q2pro but it might be worth looking into. I know q2pro was following r1ch's development and using many of his changes. I still prefer r1q2 as a server, though. Check the server console logs and see if the server is acknowledging your server pings. You can see it in the server console stream if you set con_filterlevel 0, if q2pro supports the con_filterlevel and logfile_filterlevel that exist in r1q2.
You should also check that the domain name is properly resolved on your Q2 server machine.
Use nslookup master.q2servers.com to be sure it resolves.
If your servers are properly reaching master.q2servers.com you will get: "Ping acknowledge from 173.236.101.34:xxxxx" in your log stream. If the server can't resolve the IP address of a master server r1q2 server will print "Bad address: ..." in the console.
Also, commanding "setmaster" in the console of r1q2 will force a ping of the master server, thus:
If sv_global_master is 1, r1q2 will automatically use master.q2servers.com:27900 as its master.
I do not know if there are any other valid q2 master servers in existence.
One of the nice commands in q2pro server is the "listmasters" command which will tell you if the master is communicating with your server. This command doesn't exist in r1q2.
fishxz: r1q2dedicated defaults to master.q2servers.com without the need for it to be set with the setmaster command. I don't know if this is true for q2pro but it might be worth looking into. I know q2pro was following r1ch's development and using many of his changes. I still prefer r1q2 as a server, though. Check the server console logs and see if the server is acknowledging your server pings. You can see it in the server console stream if you set con_filterlevel 0, if q2pro supports the con_filterlevel and logfile_filterlevel that exist in r1q2.
You should also check that the domain name is properly resolved on your Q2 server machine.
Use nslookup master.q2servers.com to be sure it resolves.
If your servers are properly reaching master.q2servers.com you will get: "Ping acknowledge from 173.236.101.34:xxxxx" in your log stream. If the server can't resolve the IP address of a master server r1q2 server will print "Bad address: ..." in the console.
Also, commanding "setmaster" in the console of r1q2 will force a ping of the master server, thus:
Quote
setmaster
Sending heartbeat to 173.236.101.34:27900
Ping acknowledge from 173.236.101.34:55708
If sv_global_master is 1, r1q2 will automatically use master.q2servers.com:27900 as its master.
I do not know if there are any other valid q2 master servers in existence.
One of the nice commands in q2pro server is the "listmasters" command which will tell you if the master is communicating with your server. This command doesn't exist in r1q2.
299
Trouble Shooting / Re: CTF maplist file
« on: May 13, 2013, 10:14:09 PM »
What mod are you trying to run in CTF mode?
The original game code allowed for you to set sv_maplist as you indicated. You also want to make sure that dmflags is not setting bit 5 (value 32) or it won't rotate levels.
There were a couple of mods out there that didn't use a maplist file. You had to specify the map rotation on the command line, which was rather limiting.
The original game code allowed for you to set sv_maplist as you indicated. You also want to make sure that dmflags is not setting bit 5 (value 32) or it won't rotate levels.
There were a couple of mods out there that didn't use a maplist file. You had to specify the map rotation on the command line, which was rather limiting.
300
Trouble Shooting / Re: r1q2 issue
« on: January 09, 2013, 07:04:26 PM »7904 was what I had. That said modified client.
Works fine now, not getting kicked and blocks don't appear when I run cfg.
I did some more troubleshooting..
I updated r1q2 again, is said mine was old (the just installed 7904), it said it was downloading 7904.
when I ran it it was build 8012 again, and did the same block thing.
I removed ALL paks from baseq2 except pak0 and pak1.
ran the game again, was stock text, conchars.pcx.
far as I could tell everything was stock again (shudders)
ran my cfg and the white blocks came back.
I try and find out what in the cfg is triggering it. But something is screwed on r1q2 if its updating a b7904 to b7904 and actually loading b8012.
Maybe I need to update the updater
bbl
Thanks Derv
The 7904 to 7904 update message is a known bug. I am not sure if it's the updater sending the wrong version number or something in the data it fetched from the web server. I suspect it's a copy-paste bug in the text in the database on the web server since the updater wouldn't have any pre-knowlege about the version numbers. At any rate it gets the b8012 version and that binary is stamped with the correct version number.