Hello everybody

Here it the strange thing...

If compiling an original, unchanged Source Code from Abyss of Pandemonium v2.0 using FTEQCCGUI.exe
there is an ammo counter bug occurs while switching weapons after shhoting.

For example if type "impulse 9" and start shooting from Nailgun, for instance from 200 nails to 188 and then switch to Super Nailgun you will see 189 nails in ammo instead of 188!

If you shoot from Super Nailgun from 188 nails to 182 for example and then switch to Nailgun, you will see 184 nails in your ammo counter instead of 182!

So cycling forward after shooting adds 1 piece of ammo to the weapons which share the same ammo type with the previous one and cycling backwards adds 2 pieces of ammo to the weapons which share the same ammo type with the previous one.

Same problem goes to shotgun weapons, lightning, and rocket/grenade launchers.

Could you guys tell me what may cause this proble and how to eliminate it? 

no idea, but some things to check:

does the big ammo counter on the HUD match the values of the 4 small ammo counts? if not, it may be a problem with setting self.currentammo

otherwise, there are very few places where things like self.nails, self.shells, etc. are set, at least in vanilla code -- but maybe AOP adds some weird new code that has a bug. In that case, search for something like ".ammo_nails =" and see what you can find that looks suspicious 

As Seven from QuakeOne.com said

"It happened during decompilation of the original source.
As you know, the AoP progs.dat was reverse engineered !
FrikQCC´s decompiler made some bad decisions, so..."

He provided me with the "cleaned" source code and now I'm making the patch for AOP v2.0 to make it more enjoyable (like vanilla) Quake.

Thinking of releasing it here, when I'm finished with this. 

Hey everyone! Sorry for the dumb question but is this the right place to post regarding QC coding help?

If it is, here's my question:

I've been trying to work out what might be the best way to add more vocalization for the player. Like adding some smack talk (i.e. Duke Nukem). One way I was thinking might be an inverted obituary function? But not entirely sure tbh, is there a better way of doing this? Point in the right direction? 

Hi MrC. I'd say you were along the right lines with looking at the obituary function. In my view the place to start is the function which calls the obituary function, which is a function called Killed in combat.qc.

If you look at the function, there's a block which starts

if (self.flags & FL_MONSTER)

I'd add a bit of code inside that block:

if (attacker.classname == "player")
    PlayerRemarkOnKill(attacker, self);

Then your PlayerRemarkOnKill function looks like:

void(entity player, entity monster) PlayerRemarkOnKill =
{

};

I'll leave you to play around with what you actually want to do with the remarks. Because the monster entity is passed to the function, you have the option of playing lines that are specific to a particular enemy type. 

Whoa, thanks Preach! Just got it all added and it works perfectly. And good call with checking classnames for specific commentary :) 

Ok, so onto my next conquest... I was curious about frame functions and if there were any little tools out there for generating QC frame functions? I mean, not to sound lazy or anything.

I know there are alternative methods like framegroups but how about calling sounds etc... at specific frames when using this method?

Thanks again and sorry if this is such a basic question, still learning my way around. 

(NOTE: Posting here because "getsurfacenearpoint" and "surface" keywords show up in this thread more than anywhere else on the web)

Goal: Specify FTE particles when entity touches the sky on any quake 1 maps inlcuding mission packs.

Background: As we know, the vanilla "pointcontents(self.origin) == CONTENT_SKY" code doesn't work as intended on many original maps. Fortunately, getsurfacenearpoint in FTE works great for getting surface texture names. I've used it for coding quakec entities (bullets, missles, etc) to fly through the sky without exploding or leaving decals. However, I can greatly simplify the code if someone could tell me how to use FTEQW's "clippeddecal" particle parameter.

Question: The help for clippeddecal states, "The two extra args allow you to spawn these decals ONLY on surfaces with matching surfaceflags." What surfaceflags are recognised, and where are they called from? Any examples? FWIW, using getsurfacenearpoint & getsurfacetexture gives "sky1" on original mission maps. 

Here's an exemplar video showing the Lava Nails flying across the sky, from my question above. All effects are FTE particles, except for the bullets through the sky which I had to code in quakec. So, to eliminate the QuakeC coding, I would really like to know if FTE's clippeddecal surfaceflags can be used instead??? 

What are the major differences between the Q1 engine and the Q3 engine?

Are there any differences in physics between vanilla quake 3 and the defrag mod?

Are the certain limitations in the quake 1 engine? 

the QdQstats mod is kind of like that, it has built in timers for speedrunners. I don't know enough about the dfrag mod to answer more. 

Unfortuantely all qc documentation there is, is spread all over the net. Any leads?

btw, long time no see ^^ 

Hi wakey. I haven't seen a re-implementation of func_door before, and I can think of a few reasons why. Firstly, the code for the func_door is one of the more complex parts of standard Quake, it's certainly a longer .qc file than any of the other brush objects (in fact, it's longer than misc.qc which contains definitions of dozens of different classes). Aside from doing lots of stuff, the bits about e.g. linking doors are complex in themselves.

Often when writing a mod, a good degree of compatibility with existing maps is desirable. It would be tough to ensure the rewritten code had that compatibility - remember that the func_door is a really flexible entity, often used to create platforms and other moving objects. Trying to remain compatible with the core function is one thing, staying compatible with all the unusual use cases is harder.

Lastly, it's worth pointing out that some of the standard functionality of a func_door depends on "library functions" like SUB_CalcMove and SUB_UseTargets. Can a re-implementation assume those still exist, or should it also code those functions from scratch?

Given all of that, I hope you don't mind me asking first why you want to write func_door from scratch? If it was for a Total Conversion where you create a 2D platformer in Quake, then a lot of the concerns above go away, your mod only runs on the maps you make for it, so compatibility isn't an issue. If it's for a more standard Quake mod I worry that it's a lot of writing and testing code for a benefit I can't yet see... 

Yes, total conversion.(though, not a 2D platformer).

Everything else is already coded from scratch, more or less.(roughly following Ender's "quake from scratch" tutorials, to get basic functionality up and running)

The standard door.qc files all have dependencies that are not implemented yet, thus I can't just drop them in like that.

Lastly, as stated by my colleague, the documentation of the DarkPlaces engine is severely lacking(fragmented at best), when compared to the engines I'm used to (e.g. Unity, Godot, or eaven UE4). 

The best way for you to get working doors is to add doors.qc, and then fix all the compile errors by pasting the missing functions into the top of doors.qc. Serious advice.

To expand on that a bit: the scratch tutorials are great at what they do. They look at the duties QuakeC has to perform - the things that it's basically impossible to do without, and perform the simplest possible thing to accomplish those duties. It's hard to fit doors into that framework; they aren't essential, and it's unclear what the simplest version of a door is.

The other problem actually really ties into what you're saying about the infrastructure being missing. If you were writing the simplest possible implementation of doors, it's likely you could write a reduced version SUB_CalcMove which does just enough for the doors to function. But that short-sightedness would come back to bite you when you decide later to add trains. It's a catch-22 for the scratch tutorial writer, the simpler you make the current tutorial, the worse a basis for building on you've created.

The thing with infrastructure is that how much of it you need really depends on what your big picture goals for the TC are. If you're only going to include doors in two highly controlled places in your entire game, you probably need less infrastructure that standard Quake - just hard code everything into the mod! On the other hand if you're creating a mappers toolkit complete with detailed customisation of the door acceleration profile, you probably need to build a lot more! 

it's appreciated, Preach :)

As far as i could get it, the0programmer has chosen an mixed approach, between using standart doors.qc and his own code. Works like a charm.

Now we have yet another challenge to come over: How do ssqc and csqc communicate?
He told me something of "hacks" with stuffcmd and cvar's, now i was asking myself if that is the standart approach or if there is another way?

Basically he wants to grab information of a csqc entity for use in ssqc. 

Although I've never written anything in CSQC, I'd start with getting to grips with https://quakewiki.org/wiki/EXT_CSQC
There's a section on sending data to the client and it seems like those methods would be better than stuffcmd.

There's also a worked tutorial at
https://web.archive.org/web/20080828083732/http://qexpo.tastyspleen.net/booth.php?id=165&page=317 

Hello everybody,

I don't know whether the title of this thread is correct.
I currently work on an Hexen II project where I'd like to put some RPG sequences the way Heretic II does.

That is:

1. the view switches to a third person view thanks to a camera_remote (a handy thing we have in H2 which does basically the same as the intermission view, but triggerable mid-map)

2. the view represents the player facing a monster and they interact by talking (with centerprints) or doing something (like one killing the other or running away) by triggering the corresponding animations on the models.

3. the view returns to the player and the adventure goes on.

Has everyone ever tried to do that (would it be thanks to hack or programming)? Succeeded? How?

Thank you in advance for your insights! :-) 

Although HexenII is more advanced then Quake there is a mod called Visions, which has a Capture Camera Kit.

It has about everything you mentioned, but supports only QuakeI. Maybe with a bit tweaking you could port it to HexenII? 

@madfox Sounds promising! Any idea where I could find it?

Yet, just to be sure there is no misunderstanding, because English is not my mother tongue and it's sometimes hard for me to be clear: my actual problem is not the 1. and 3. above because triggered cameras are a native feature in Hexen II.

The real challenge is to tell monsters and the player how to behave during such cutting scenes: tell them to run, to stand idle, to jump or whatever. What I want to do is puppet mastering. Never mind whether it is the actual monsters and player acting in front of the camera or just fake entities reusing their mdl. 

I used this Camera scene Construction Kit in a map to explain a coming event in the game.
It works with scripts from the moment the trigger_camera is touched. The player changes into a moveless point, while the entities can be turned on/off hostile attacking.

There is no way to tell what entities will do, although a func_train or path_info can be used as well as textures on screen.

You can look at it at the map of DarinMcneil visions 

madfox... great link... I never knew about this! One other camera system can be found in the custents mod but it's a bit different because it's a security camera but there are controllable actors in the mod as well. 

Thank you so much for those exciting links! Hope I'll be able to do something nice from it. :-)
You'll hear about it anyway. ;-) 

Inky, in the progs tricks you were interested in how demos work. There used to be something of a scene for making Quake demos, especially in the dial-up era of the internet when youtube didn't exist. I was only an interested observer, but if you were interested in finding out more a good place to start would be reading about

https://en.wikipedia.org/wiki/The_Seal_of_Nehahra

In particular, if you look at the sources there are a couple of interviews archived from machinima.com which go into some detail as to what combination of engine tools, mod-making and live recording were used to produce the demos.