qc

[MadGypsy]

launch_spike(self.origin + self.view_ofs + v_up * -8 + v_right * ox, dir)

try that

[Seven]

Hello MadGypsy,

Please think before you copy/paste.

launch_spike (self.origin + '0 0 16' + v_right*ox, dir);
launch_spike (self.origin + self.view_ofs + v_up * -8 + v_right * ox, dir)

There is no difference concerning left and right position of the nails.
Only z-position is handled different in these lines.



Hello JDSTONER,

It is great to see your interest in playing around with QC.
Your idea to learn QC by using tutorials from inside3d is exactly right.
I did the very same thing and it is exciting and fun to see the results in-game.
I�d like to recommend this tutorial to you, because you will learn more than you might think from it. The topic does not sound interesting, but you will learn basic and important things simply from reading it.

The topic (nail position) you are talking about is perfect to learn the different coordinates in a 3D world like Quake.

The original 'launch_spike' call uses fixed world coordinate values:
self.origin + '0 0 16'
Wherever you are and whatever direction you are looking, the nails are always spawned 16 quake-units above your point of origin.
'0 0 16' (X Y Z)
This will result in the nails spawning out of your head/eyes when looking straight upwards. Try it and you will see.

You need to take the players view into account to prevent this behaviour. This will result in approx. the same spawn position when looking straight forward, but will always stay correct no matter in which direction you aim:
self.origin + self.view_ofs + v_up * -8


Next is the issue with the "left" and "right" position of the nails.
"Left" and "right" is not possible in a 3D world, at least with usage of world coordinates.
Because left will become right when you turn 180 degree, right ?
So you cannot simply use:
'5 0 16'
to move the nail to the "right". Because "right" would only be right, when you are looking parallel to the world coordinate.

You *could* use:
self.origin + self.view_ofs + v_up * -8 + v_right * 5
to spawn something always on the right side of the player/entity.
But Quake�s original nailgun nail code works differently !

Quake�s nailgun nail position code uses a special/fixed offset float (= value), that handles/declares their left/right position:
In player.qc the alternating functions: player_nail1 and player_nail2 set these offset values.
Originally the value is 4 and -4
These values are forwarded through the code until it ends in the launch_spike function, which then spawns the nail and sets their origin to that vectors value.

Change the values 4 / -4 to 3 / -3 to get them nearer to the mouth of your gun.


There are only vectors for up, right and forward. Use negative values if you want down, left and backwards.
Be sure to call 'makevectors' for the entitiy that you want to use these 3 vectors for. They will then face/match the entities angles.


Have fun with playing around with QC and try several inside3d tutorials.
It does not matter if you "only" copy/paste the code. Just be sure to think and try to understand what you just changed.
Reading code is important. Read much and you will understand much

Good luck,
Seven

[JDSTONE]

seven i will try out that tutorial ive read it a few times just haven't done it yet so i will give it a try hopefully it will give me a clue on how to get the sites set right so i always shoot in the center of the cross hair.

@MG Your qc development package rocks and i hope a lot of people use it but i was wondering if you would make the fix in there for the nails for anyone else that uses it that way I never hafe to play a map or a mod where it is not working right when people use your qc package.

@talisa as i get this qc figured out a big goal will be to pull in the stuff from drake. so maybe you will already have it faster then i can make it but if not i will pass it to you so we can map with drake monsters and power ups!

[MadGypsy]

I refuse to think before I paste. I only think before I create my own stuff.

Did my copy and paste straight from Sevens SMC fix the nail position?

I think Seven thought that I thought his code did something with left and right. I was just pasting his line that corresponded with yours. I didn't bother to even read it. I was even 7 minutes late for work, cause I took the time to find it for you.

If anything I should have been thinking about the time before I copy/pasted (lol)

anyway, thanks for the compliment JD. I have some other mods I intend to include shortly, and yes I will put the nail fix in my code. That's more of a correction than a mod.

[JDSTONE]

im just seeing that the ent file has the trigger for earthquake but i dont think the qc dose... its over at inside 3d so i will try to add it on my own and what the hell is the dragon path? i did not test the weather yet. it will probley crash my computer even on my better one it made everything slowmo also maybe adding fog in there too! in the first version i got from you i saw some dragon qc in there. no reason to be late for work just to look for coad man but thankyou!

[MadGypsy]

oh...wooops, those are the ent definitions for the work I did for bluntz and killpixel (lol), thanks for pointing that out, Imma go and remove those.

edit: done, it's all cleaned up, but there is no point in re-releasing anything. Just don't use monster_dragon, dragon_corner or earthquake in a map. Or simply delete these from your .ent. I have a few mod ideas that I am adding, I'll publish my QCDE when those are done.

However, I don't intend for these updates to roll on forever. When I have my QC to a level I am satisfied with, that will be it.

I also don't intend to add any mod that you would find on inside3d. Not because there is anything wrong with those, they just aren't the type of mods that I want to add, and I intend to write all the rest of the mods personally anyway.

Spike requested that I make it play nice with dp and fte simultaneously and without conflict. That's actually gonna be my next step, with this. I have to do some VooDoo, having a customized QC work on 2 different engines, while utilizing 2 different extensions, is something I need to chew on for a bit.

It will also change how a mod is made, both engines would need to be considered and thats gonna be a real pain in the ass (probably). For instance, the triggerable weather script utilized dpextensions, in order for this to work, I now have to figure out how to FTE it in the same script and wrap it all in conditions (that I haven't even figured out yet)

I'll figure it out. If all goes well, I will figure it out where the "off" extension isn't even considered.

-----

I need to find a protocol that dp and fte don't share
check against it
store some var way early on (like before most everything)
then I guess where DP and FTE differ would be handled with a switch/case of the var

and I guess it isn't impossible that sometimes the switch/case would look like this

switch(engine)
{
	case "darkplaces":
		//do a bunch of stuff
		break;
	default:
		//this engine doesn't support this
		break;
}

I'm not implying anything. It's just to say that if a mod is made and only one engine supports it, you (whomever that is) is going to be writing a lot of switch/case statements to appease the unsupporting engines. Actually everything that isn't vanilla quake will have to be put in s/c.


hmmm, this whole idea needs to be thought about more.

maybe I will just make an fte version. I can do that by changing one word.

set eng=darkplaces.exe
to
set eng=fte.exe

voila, works in FTE.

[R00k]

fixing the nail gun
so the spike shoots outside the nail gun in quake and this bugs the piss out of me and im not finding a how to over at inside3d

so im pulling this one out of my ass
in weapons qc line 667 (may be something different made a few changes already) is:
launch_spike (self.origin + '0 0 16' + v_right*ox, dir);

i changed it to
launch_spike (self.origin + '0 0 8' + v_right*ox, dir);

this seems to help solve the issue but i was wondering if there is a set number everyone uses to fix this?

reminds me of this

	
	//R00k this is a BUG, should be org not self.origin!
	//LightningDamage (self.origin, trace_endpos + v_forward*4, self, 30);
	LightningDamage (org, trace_endpos + v_forward*4, self, 30);

[JDSTONE]

are you saying to change self.origin to org?

[MadGypsy]

No he is not saying to do that. Just telling you this does not explain why.

Look at the interface for W_FireSpikes, there is one var (float ox), also, nowhere else in that function is org declared. So, if you changed it to org, QC would have no idea what you are talking about. You could look in defs.qc to see if org is global, but you will find it is not. So that makes org a variable that is local to the functions that contain it. (and they contain them independently-- grr confusing)

Now if you look at launch_spike there is an org in the interface of the function. If you go back down to W_FireSpikes where launch_spike is called you will notice the first argument is self.origin(+*-math).

You are manipulating the values of self.origin and launch_spikes considers the product to be org. Confused? Let's rip it down to nothing and you wont be.

void([color="DarkOrange"]vector org[/color], vector dir) launch_spike=
{
	[COLOR="Lime"]//org currently equals (self.origin+'0 0 16'+v_right*ox)[/COLOR]
};

void(float ox) W_FireSpikes=
{	[COLOR="Lime"]//there is no org in this function[/COLOR]
	launch_spike([color="DarkOrange"]self.origin+'0 0 16'+v_right*ox[/color], some_var);
};

When W_FireSpikes is called, it eventually calls launch_spike and places a modified self.origin in it, launch_spike considers that to be org, cause:

1) vector org, is the first argument in the declaration
2) self.origin(*+-math) is placed in the spot of the first argument in the execution

Essentially, you are passing data along and giving it a short name to represent it. Also note that you should be reading the above code in backwards order (W_FireSpikes first). In QC you have to explain things before you use them, so in a way, it's all backwards (or upside down).

[MadGypsy]

I am going to teach you the difference between local and global

float a = 20;

void(float x) a_func =
{
	local float y = 100;
};

void() test =
{
	local float z = x+y;
	//error: wtf is an x and a y I can't find that

	local float z = a;
	//ok
};

'a' is global
'x' 'y' and 'z' are local

global vars can be used anywhere in the script
local vars can only be accessed from within the function they belong to

Note that you would never declare the same var twice. I just did that with z to keep it simple.

[R00k]

are you saying to change self.origin to org?

with self.origin the lg bolt comes from the player's belly not the lg
moving it to org (where the lg function actually adjusts it)
org should be used so the bolt doesnt appear to shoot thru walls ie. rocket launcher on dm3 to lower bridge
for the nail gun org bounces left and right to simulate shooting out two barrels

[MadGypsy]

well, I had a question but I figured it out

//

for educational purposes I will state the question and answer

for the nail gun org bounces left and right to simulate shooting out two barrels

is that the v_right*ox part of the equation?

The answer is yes. Here is why. In player.qc for the nail gun animation, there are 2 functions - player_nail1, which runs and calls player_nail2, which runs and calls player_nail1 (on and on, back and forth)

in player_nail1, W_FireSpikes(4)
in player_nail2, W_FireSpikes(-4)

so if you want to go deep, 'ox' is your left and right, but it gets factored in to the rest of the equation and sent to org, which is the result. So 'org' does handle left to right for nails but it is 'ox' that provides the multiplier (decision).

//

Also, in R00ks example he was manipulating an org that was already set. In JD's case he is actually setting the initial org, so R00ks very first example is working from a different end.

[R00k]

True, that and its been ten years since i messed with all that so i wasnt 110%

[MadGypsy]

Hmmm, I wasn't criticizing you. Actually it all started with me about to ask you for information, but then I became unlazy and looked for the info myself. I just posted what I discovered.

you were right - I just wanted more.

edit: Actually, 10 years? 10 years and you remember nail gun code? That's friggin amazing! Let me think back 10 years............yup, nothin' and certainly not anything as microscopic as a var use in a tiny function.

you deserve beer

[R00k]

;P i wasnt thinking u were nor being sarcastic

you learn by diggin. something about someone telling you vs finding and then asking someone helps it all sink in. It took me months to get the flow of quakeC (before the quake source release) where i just didnt understand something then chalked it to the great wizard (the engine), and moved on until i could define what the wizard was doing.

I remember going to quakesource.org daily for the quakeC talk





_