Annoying crash from g_syscalls.c


(S. Monkey) #1

How does trap_GetConfigString in g_syscalls.c work? A modification I’ve made is causing problems when the code calls that function.

The game freezes, accesses the disk for about 30 seconds, then annoys windows enough for it to step in and tell me its crashed.

Any help would be appreciated.


(S. Monkey) #2

Ooops. trap_GetConfigString isn’t crashing anything. It’s whats in the config string thats causing the problems.

It would still be helpful to know how it works, if anyone could enlighten me.


(Rain) #3

trap_GetConfigstring(number, buf, bufsize)
trap_SetConfigstring(number, buf)

Configstrings are various pieces of text data that are communicated to all clients upon change, to new clients when they connect, and written to the start of demos. The first two (CS_SERVERINFO, 0, and CS_SYSTEMINFO, 1) are managed by the engine and shouldn’t be changed from gamecode. All configstrings after the first two are used by the qagame module to communicate things such as the MOTD, vote status, models indices, sounds indices, assorted player info (e.g. names), and a slew of other stuff to clients.

The format of a configstring can be any text that ET allows (ASCII 1-36 and 38-127), although several of them are infostrings (see the Info_* functions in q_shared), which basically consist of a bunch of \key\value pairs.

The configstring numbers (except for the first two) are defined in bg_public.h (CS_MUSIC is the first in etmain.)

You can dump the contents of the configstrings in a client with /configstrings (only non-empty configstrings will be listed):

 618: models/mapobjects/radios_sd/compostalliedclosed.skin
 619: models/mapobjects/radios_sd/compostallieddamaged.skin
 689: n\^7|^0NE^7|R^5a^di^4n^7-^d42^7	\2\c\1\r\0\m\0000000\s\0000000\dn\\dr\0\w\8\lw\8\sw\7\mu\0\ref\0\p\0\ss\0\sc\0
 753: \spawn_targ\Axis Garrison\x\7089\y\4852	\1
 754: \spawn_targ\Allied Camp\x\1153\y\2879	\2\c\1
 755: \spawn_targ\Old City\x\3732\y\7352	\1

(S. Monkey) #4

Thanks for the help.

It’s specifically the CS_PLAYERS ones that I’m having trouble with. Is there any problem with changing the number of classes/skills?


(Rain) #5

There shouldn’t be a problem, but there are probably a lot of things that expect the number of classes that are there now…

For starters, did you increase NUM_PLAYER_CLASSES? (bg_public.h) Did you add your class to bg_axis_playerclasses and bg_allies_playerclasses in bg_classes.c?


(S. Monkey) #6

Yes, and yes. I went through bg_classes.c and updated every function. Still throwing a strop whenever I select the new class :frowning: