News | Forum | People | FAQ | Links | Search | Register | Log in
Coding Help
This is a counterpart to the "Mapping Help" thread. If you need help with QuakeC coding, or questions about how to do some engine modification, this is the place for you! We've got a few coders here on the forum and hopefully someone knows the answer.
First | Previous | Next | Last
Serious Engine Open Source 
The Serious Engine (Serious Sam 1) is on Github https://github.com/Croteam-official/Serious-Engine 
 
so... there's a +/-use... how can we (if possible) use this? 
Checking On Func_togglewall 
There's a bit of hacky code in a func_togglewall and I wanted to understand why it's safe. The togglewall is turned non-solid by directly adding '8000 8000 8000' to its origin by, always putting it outside the maximum coordinate range (at least until some newer engines came along).

This violates one of the normal golden rules of QC, which is to always use the setorigin function to move an entity. Clearly in this case we get away with the trick, and I wanted to check if I understand why:

The purpose of setorigin is to make sure that when an entity is moved, the engine correctly links the entity. My layman's understanding is that linking makes sure that the entity is correctly renderer and collided against. The point for a togglewall is that we neither care if it renders correctly (it's invisible) or that it collides correctly (it's non-solid).

Getting right into the details of the collision stuff, normally entities are linked into particular regions of the map. Regions are an efficiency feature, so the engine can skip testing for collisions between entities far apart in the map. When we skip the call to setorigin the togglewall remains linked to the region it started in, which may be wrong for its new location. But this is OK: things in the region it started in keep checking if they collide with it, but never do because it's so far away. Meanwhile, it's not in the region for its new location, but in theory nothing should be in that region anyway, and we don't need those collisions either.

If the above is correct, then I assume when we reactivate the togglewall to move it back, the original region link is still in place. So we go back to colliding with things in the vicinity, without needing setorigin here either.

Am I somewhere near the mark? I know I've glossed over the case where entities straddle regions, and I'm sure some of the terminology is different. I really just want to be sure why we get away with it here, to check if the same trick is OK in similar circumstances. 
Is There A Way To Load Multiple Progs.dat? 
Like, a mod for weapons,another for monsters, in a single game? FTE or Darkplaces wise...
Is that possible? 
No 
 
@kalango 
yes. it is possible with FTE. whether its practical is a different matter.

the addon* cvars allow you to name addon dat files to load within the ssqc vm. these addons can interact with other dat files with the externset+externvalue builtins, or entirely via fields+new spawn functions.
the catch is that the engine's builtins are only able to understand one set of globals, which means you tend to need to use externvalue(0, "&whatever") to get a pointer to the global from the main progs, along with some preprocessor magic to hide the uglyness of this.
function types are just references in qc, this means that addons can query+replace function 'variables' in other dats in order to hook them to do whatever the addon needs them to do.

(make sure you don't compile your addon.dat files with -O3, as this strips needed string information)


tldr: so yeah, you can do it in fte. whether its actually practical to do so is a different matter. generally its only usable if you can make your addition entirely self-contained. 
 
that is really cool. unfortunately, in order for mods to be truly modular in a way that would work for that, you'd really need to code with that modularity in mind. :( 
Awesome! Ty Spike 
 
Preach 
That was my conclusion as well.

I did a bit of work with these (having them visible and used for other things as well) and decided that the hack is just what it appears to be. The position is never updated just out of laziness rather than for a specific need.

I tested resetting their position to see if it changed something in the map but couldn't notice any difference. But my knowledge is more limited than yours on these matters. 
Preach 
setting force_relink (eg, triggering a teleporter) or reloading a game will force those entities to be relinked in whatever position that they're currently in.
if they're then moved back then they'll be non-solid in their original location.
if neither of those two events happen, then the entity's pvsbits and areanodes won't change, so as long as its reset to the original position it was setmodeled in, it'll be fine.

additionally, fte can trigger relinks from vid_restarts (worldmodel is reloaded, so the old pvs is possibly no longer be valid). I assume other engines might do the same. 
Two Replies In Reverse Order 
setting force_relink (eg, triggering a teleporter) or reloading a game will force those entities to be relinked in whatever position that they're currently in.

I can understand the concern with save games, it seems to me that the hack should fall down there. I tried the following to test it:

1) trigger a togglewall to "become non-solid" i.e. leave the map
2) make a save file
3) load the save file
4) trigger the togglewall again to bring it back into the map

This doesn't exhibit a bug, the wall worked fine - it collided with me, even though it shouldn't be in the correct areanode. Is there a chance that areanodes are calculated with the coordinates "wrapping round", so that the precise distance displaced is saving the day?

The position is never updated just out of laziness rather than for a specific need.

I wondered if the intent might be to avoid "trigger in clipping list" type errors, the kind caused by changing things during a physics update. Potentially a togglewall can be triggered during a touch function. 
 
that's interesting because the func_laser in rubicon2 calls setorigin in its use function, and i don't think it causes any problems. 
Might Be Remembering Wrong 
I'm mostly backing this up with a comment from client.qc

// we can't move people right now, because touch functions are called
// in the middle of C movement code, so set a think time to do it

But I guess I must be misinterpreting it if I'm banning setorigin during a touch function, or else how would a trigger_teleport hope to function?

Is it changing the solid status of an entity which is forbidden then? Is it particular to messing around with a trigger? 
 
i remember having problems with doing setorigin in touch... but i think it only happened with triggers of some kind. sorry, really long ago, forget all the details. :S 
 
SV_TouchLinks walks through the various triggers in a fairly lazy way. you can relink non-triggers inside trigger touch events, but if you relink any solid_trigger entity there then the loop can end up referring to the wrong entity, potentially resulting in references to null or infinite loops. sometimes you might be lucky and get away with it, it really depends on the ordering.

this can be seen on e2m2 - shoot one button then jump across and you'll touch a trigger that killtargets another trigger, resulting in a crash.

non-triggers touching non-triggers should be safe, as the node-walking is separated from the qc callback, limiting movements to touch only one other solid entity.

because triggers and non-triggers use separate node lists, relinking the player won't hurt the trigger lists, which is how come teleporters never cause any problems.

by relinking, I mean calling setmodel/setsize/setorigin, or alternatively removing an entity.

bug-fixed engines will probably just build a list of the triggers that need touching and *then* trigger the events if the triggers were not removed by a different trigger, thereby avoiding the crash at the risk of dropped touches (if its a player then it'll just get touched next frame anyway, although monsters might not re-trigger it any time soon if they stop walking at that point). 
Rcon Tool 
Ok, Im needing something that can remotely rcon Quake engines, mainly pq for now. Turns out if you have a server on 2 ports, the rcon commands always wind up heading to port 2600 by default. SO you can use rcon_address and rcon password fine, and even status will show up ok on the non std port but any command telling it to change a setting winds up going to port 26000. SO I found this small app that claims to be able to rcon to Quake servers: [ http://www.codeproject.com/Articles/21885/Send-RCON-Commands-to-Quake-Based-Games ]

They want an email address sand pw so the dl is accessable, so I think any email address will work, it dont seem to send out a verify, then you can just dl the code.

So its C language, and I have had such rotten luck using Visual Studio trying to compile a Quake engine, but since this one was small , decided to try. Turns out I have Visual Studio 10, and it said it needed to convert, which it did, and seemed that it was successful, so I clicked on the proj file, and did a build, and to my amazement, it built an exe in bin/release and also in obj/release. However my excietment was short lived, as the app does run, when you enter a server address and pw and command, it locks up indefinately and has to be shut down in task manager.

Anyone here have some advice on what Im doing wrong or is the code itself just crappy? 
Modify Player View Pitch Through QuakeC 
Is this possible? I notice an entity member idealpitch but changing it doesn't make a difference.

I'm trying to add gun climb, where firing a weapon makes the player look up. 
 
yup, totally possible. set .fixangle to 1. the player's view will snap to whatever is in .angles. 
 
nnnnnoooooo!
you can spam fixangles as much as you want. each time will cause the player's view to snap to something that they were not aiming at at the time.
this is especially bad over a network. you simply cannot use it for only pitch or only yaw.

it can be kinda rough even in single player, even a single frame's delay will snap you back to your yaw angle from the previous frame. repeat and your angles are now locked.

there is a .punchangle field that you can use to bias the pitch angle, however, it tends back towards 0 and there's not really anything you can do about that. It WILL judder regardless, especially in QW where you'll probably overcompensate and cause it to go completely haywire.

if you want full control over the camera angles, or the client->server angles, the only place you can reliably do that is clientside. Ie, in csqc. Doing it serverside will just result in fighting with the client, and the lag (even in single player) will prevent you from reconciling. 
 
Okay, so I tried fixangles and the behavior is very unexpected. Spike (is that you, Spoike?) is correct, I've tried it in Quakespasm, Darkplaces, FTEQW and it does snap to something i wasn't aiming at (even after using angles/v_angle = angles/v_angle + 'x y z') in all of them.

punchangle is also cosmetic and doesn't effect gameplay. I'm messing around WriteEntity() now... will let you know how that goes... 
 
Got it i think. After I calculate the new angles, I use WriteByte ( MSG_ONE, 10 ); Now, I dont know if this adjusts v_angle or angle, but hey... it works for now. Here is the code chunk for anyone interested;

ang_x = -8 - random() * 2;
ang_y = random() * 2 - 1;
ang_z = 0;
ang = ang + self.v_angle;

msg_entity = self;
WriteByte ( MSG_ONE, 10 );
WriteAngle( MSG_ONE, ang_x );
WriteAngle( MSG_ONE, ang_y );
WriteAngle( MSG_ONE, ang_z );

I'll throw together a tut soon (hopefully) 
Impulse Processing Takes Place After Physics? 
I'm wondering why is the W_WeaponFrame() function called in the PlayerPostThink() and not in the PlayerPreThink(), moving it doesn't appear to make a difference. Is it arbitrary? Or, did the developers intend to queue command processing for next frame after all entities had been processed?

I know pre and post run before and after player physics processing (or is it before and after all entities have had their physics processed?), when does the animation tie in to the flow of a single game step? In my own WIP game engine, the flow at every step is:

1) Capture events
2) Process logic/AI for all 'actors'(entities)
3) Animate all actors
4) Run physics on all actors
5) Render everything 
Different Weapon Pickup Sounds Crashes Quakespasm 
For my mod, I made sure that each weapon pickups have their own sounds. Same thing for armors and ammo boxes.
It works without a problem on darkplaces, but picking a weapon in quakespasm stops the current game and displays this:
http://image.noelshack.com/fichiers/2016/16/1461326522-spasm0000.png

Here's my code for armors:
http://pastebin.com/7DywCzPm
My code for ammo boxes:
http://pastebin.com/eKKZUVqu
And finally, my code for weapon pickups:
http://pastebin.com/Mwr4NtnG

As you can see, I used for all of them that "self.noise" trick that allows me to add different sounds for each items.
I find it wierd because picking up ammo boxes with that method in quakespasm doesn't crash it, even though they use the same technique. At first I thought that was because the whole "self.noise" root declaration was put after all the individual weapon pickup lines, while it was put before for the ammo boxes. So I tried to do that for the weapons, but while testing in darkplaces the weapon pickup sounds don't play. 
 
you need to precache sounds in the spawn functions, not the touch functions. Your armor and ammo code are doing it correctly. Your weapon code is doing it wrong. 
Thanks, It Worked! 
 
First | Previous | Next | Last
You must be logged in to post in this thread.
Website copyright © 2002-2024 John Fitzgibbons. All posts are copyright their respective authors.