Is it possible to tell a progs.src to continue in another document

[MadGypsy]

Is it possible to tell a progs.src to continue in another document?

progs.src

../progs.dat

defs.qc
subs.qc
//all the rest

@import['some_url/continue.src']

continue.src

my_mod.qc
yet_another_mod.qc

//etc

summin like that or different but achieves the same results. If not, can you make that spike? Would it be hard to tell it to look for a continue file?

[MadGypsy]

Hmmm, maybe I should explain why I want this. I went to all the trouble to make my QC and dev environment, real clean and polished. I've decided I want to add to the QC with more mods of my own. Actually I hope for my QC to be used as a base QC for some mods as I intend to release the .ent and .fgd that compliments it.

Anyway, anyone that is using it may want to modify it. This means that their progs.src could change from my original. This would make an update potentially a nightmare, depending on how much everything has changed. Sooo... by allowing for a continue.src, my updates are simply appended to whatever they have already done....making an update cake.

I release a continue.src with my extra code and fte takes care of the rest.

That's why i want this (and/or) hope it exists

[Spike]

with fteqcc, I've been using a progs.src containing only the following for some time.

#pragma sourcefile csprogs.src
#pragma sourcefile ssqc.src
#pragma sourcefile menu.src

but I'm not sure that's what you mean...

there's a #includelist pragma:

#includelist
file1.qc
file2.qc
#include "foo.src"
#endlist

Actually, not sure #include works properly in there. If it does you'll still have issues with the progs.dat named inside the foo.src file.


But... I'm really not sure what you're trying to get from it. So you can add extra .qc files later?
Is there *any* qc mod out there that is actually clean enough to cope with that properly? (eg: monster obituaries are hardcoded by classname, while weapons all have pre-assigned flags) Simply put I'm not sure how useful it would actually be in practise. :s

You can just name an empty file at the end, and when you put something in there, you can #include another (initially empty) file at the end of that.

[MadGypsy]

Yup, that's what I need.

yeah, I'm aware that this could be a disaster. I believe if I handle it properly it doesn't have to be a complete disaster though.

oh and thank you, that was a really fast reply.

[MadGypsy]

wait I screwed up. I misunderstood you. The first way will actually create 3 separate progs, correct?

Can I make an include list but not name a progs.dat in the "foo.src" file, hence simply appending the new .qc list to the original, and it is all compiled into one, as if it was always one?

[Spike]

#pragma sourcefile foo.src
will compile using 'foo.src' after the current compile has finished.
so yes, separate progs.

If your progs.src is just a series of #includes or a #includelist, you can specify the progs.dat separately (say, from within defs.qc) with a '#pragma PROGS_DAT "../progs.dat"', if that's what you're after.
Or something like that, anyway.
If your compile script then uses some hidden .src file that #includelist\n #include "progs.src"\n #endlist then you might get something similar to how you want it, just with the progs.dat named elsewhere.

[argonator]

#pragma sourcefile foo.src
will compile using 'foo.src' after the current compile has finished.
so yes, separate progs.

If your progs.src is just a series of #includes or a #includelist, you can specify the progs.dat separately (say, from within defs.qc) with a '#pragma PROGS_DAT "../progs.dat"', if that's what you're after.
Or something like that, anyway.
If your compile script then uses some hidden .src file that #includelist\n #include "progs.src"\n #endlist then you might get something similar to how you want it, just with the progs.dat named elsewhere.

I am new at Quake C, however I have used c++ and other 4gl languages like Turbo Pascal, COBOL(like dead as in Latin), and some 6502C assembler.
I did some branch analysis of control panels talking to an NDIS driver, so am familiar with logic and data types used in today's IDE.
However the documentation on how the IDE for Quake C is needed from a basic start to finish using both the original PAK0/PAK1 scenario and dealing with add on code for an existing PROGS.DAT.
It may seem like a newb question, but no wiki has clearly illustrated the process.

I have a similar situation, I have the source for Quake Mega TF from Xavior at tastyspleen.net and a complete source for Quake in c++ circa 2006.

Xavior has made many mods to Mega TF and Classics TF(added a few weapons). His current server is running at 74.86.171.201:27500

It's a slam dunk of addons such as monster coop, survival mode, last man standing, a merchant to buy power ups with gold recovered from dead monsters..etc.. His skins and models/sound paks include the quake 1 addon packs 1,2, doom 1, doom2, tf, and megatf.

Now what I want to do is take his existing progs.dat and append the quake C mods from Painkeep. Shithead at Weenieville Painkeep has blessed this marriage and still has the source and his modifications of Painkeep.
Mostly I want to just add the weapons, bind the impulses for those weapons, be able to add the ammo to an existing map if it doesn't have the spawns specified for it in the (.ent?) file.

Mainly painkeep was a hard core death match addon with bear traps, exploding shotgun ammo, a viscous grappling hook that does frag players and monsters, a gravity well, airfist, chainlightning gun.
It wasn't available in single player, server only.
There is a lot of logic checking for which mode the game was in versus coop or single player. I will chop that out and let the exiting logic code for MegaTF coop by Xavior sort it out.

His base code supports COOP against monsters, and multiple teams which would be DM with monsters. But on maps without monsters defined like the original DM1-DM6 and others, it's just a death match. If someone joins the opposing team. It does have the CTF code for opposing teams also.


There are a few bugs in the code still ongoing like a player cannot launch grenades after a set is exhausted. It makes it hard to suicide since the server states active grenades are still there, but they are done exploding. I want to contribute and help troublehshoot this since it affects survival mode since you basically have to self frag, which ends the game with one person on the server, or in a a team coop scenario you lose the flawless kill all monsters bonus.

The other purpose to add Painkeep and possibly runequake(which is in MegaTFCOOP at tastyspleen.net) to ClassicTF. There is a cadre of about 10-30 players that complain they dont have the same powerups and weapons used on similar servers with 1 or 2 of the mods.

I hope its possible to just add a statement that addresses 1-3 basic sourcefiles which includes the .qc mods themselves.

Is there a main() loop which I haven't noticed on the quakeC mods that states what is included and allow for possible expansion?

PS I already merged the .mdl, .lit, and sound files from both mods into the same fortress directory. I have not seen anyone mention a limit on how many .mdls or .wav files can be processed by a Quake server or client. I know it has to be precached, but I assume the engine has a 16bit or 32bit counter able to address the amount of memory used by the extra files.

Cloud and I want to repacking it as Open Source GNU and make sure it doesn't violate any copyrights.

Tentative name is ARG's UBERTF as to distinguish it from megatf.
I plan on hosting a few servers on my ludicrous speed Comcast business grade connection, and make some sort of installer for both EZquake and MDSV/QWSV(blech) . Even though people can just unrar it, make it even simpler with a self extracting .EXE (duh).

[Spike]

quakec has no 'main()' loop. it starts with spawn functions and then keeps running via callbacks (self.think = foo; self.nextthink = time + 0.1; as well as touch and stuff).

spawn functions are functions with the same name as the classnames of the various ents in the .ent file or .bsp/.map

vanilla protocols (ie: ezquake+mvdsv) are limited to 256 model or sound precaches per map. you can still use different ones on different maps.