|
Post by sekator on Dec 28, 2010 18:58:59 GMT -5
I have a thing for lasers. REAL lasers, BEAMS, not just some glowing balls of whatever shot by a funky gun that some jerk has for some reason, called "laser".
I would like to tamper with Quake 2 to create an instakill laser weapon, kind of similar to those laser traps scattered around strogg installations. However, I have stumbled upon a problem - there is no modding tutorial for this game!
Seriously, I have tried googleing some info about weapon modding in Quake 2 for some time since now, and so far I have failed. Where did you guys learn this stuff? Also, in one place I've read that turning hyperblaster into hitscan laser beam is EASY mod. Sure...
So, does anybody know some site where they explain some basics of modding Quake 2?
|
|
|
Post by peeweerota on Dec 28, 2010 20:43:01 GMT -5
|
|
|
Post by Wixen1 [Q2C] on Dec 29, 2010 8:42:33 GMT -5
Thanks Peewee... -W1
|
|
|
Post by sekator on Dec 29, 2010 9:41:37 GMT -5
Thank you very much. Much appreciated. @edit: By the way, this tutorial says how to replace hyperblaster bolt with green BFG laser... which is nice, but is there any way to replace it with red or blue laser trap instead?
|
|
|
Post by peeweerota on Dec 29, 2010 12:16:16 GMT -5
Thank you very much. Much appreciated. @edit: By the way, this tutorial says how to replace hyperblaster bolt with green BFG laser... which is nice, but is there any way to replace it with red or blue laser trap instead? That is a little more complicated. This tutorial ALMOST does that: webadvisor.aupr.edu/noc/Othertutorials/qdevels/-%20Star%20Wars%20Blaster%20.htmlEDIT*** Here is the description of how it works from the tut: One last important detail to keep in mind about "RF_BEAM". How LONG is the beam? Well, just to be clever, the beam only exists between the location in space defined by s.origin, and s.old_origin. The variable s.old_origin is supposed to hold the value of where our "origin" (the x,y,z coordinates of our object) was last game tick (also known as "frame"), if we are an object in motion. Since beams are supposed to be stationary, and have no movetype, s.old_origin would normally be unused. We, on the other hand, take special advantage of it.
We calculate our velocity using the direction and speed we are passed in. This velocity is the distance our entity will travel every turn. Our s.origin is automatically copied to s.old_origin every round in g_main.c right before calling the physics code that moves our s.origin. Now, by setting the s.origin and s.old_origin that much apart to begin with, we ensure that the two positions will always remain that far apart. Thus, our velocity determines the length of our beam.
If you wanted the beam length to be any longer or shorter than the velocity, you would have to change our movetype to MOVETYPE_NONE, and give our entity a think function where you code your own movement code to remove the relationship between s.old_origin and our velocity. Also notice our "clipmask" is MASK_SHOT. These clipmasks determine how soon we decide we have collided with a valid target. Some entities only want to collide with walls, while others want to be notified of collisions with monsters, players, or substances like water. Feel free to play around with the masks, but I have found that incorrect masks used in determining collisions has been the leading reason for objects I code to fall out of levels.
|
|