if all you want is a rope that doesn't collide with anything, including itself... it's doable.

To solve the rope position for a static rope, you just set it up at spawn: guess and then iteratively refine the locations of all entities until it's within a certain tolerance.

If you want it to be dynamic, you don't need iteration, but you give the rope some elasticity and then have it accelerate to the correct position every frame. With the right values, it will look pretty good. Otherwise it will be bouncy and rubbery and go crazy. 

You also need to render the rope. I guess you would use a model that represented a segment of rope X units long. Whenever the distance between segments is not X, you will see gaps or overlap. Or have a bunch of frames in the .mdl to represent a range of distances, and quakec can select the frame based on the actual distance between joints on that frame. 

Here's one tutorial I found, not sure how easy it would be to implement in quakec though: http://freespace.virgin.net/hugo.elias/models/m_string.htm 

If it's static, a rope hangs in a cosh curve ( http://en.wikipedia.org/wiki/Catenary ). You can just calculate it with a scientific calculator I guess :-) 

The thing I'd want the most from creating a good rope system is just frustratingly out of reach of the QC - to be able to control endpoints of a polygon independently of each other. The use would be to attach some end of a polygon to one "entity" and the other end to another, so you could create a continuous mesh that you could deform individual segments of.

Without that, I'd say you're better off just creating a static mdl prop to represent a rope. One trick that I think could work well in a map is creating a reaction to "wind", and ropes would be a great prop for displaying it. The idea is to have a global wind variable which stores a value between say 0 and 40 representing the wind force in that frame.

You'd want a slow random walk which would move the wind through these values, it's possible that adding crandom()(sic) to it every 0.1 seconds and capping the value within the range would suffice. Scaling the adjustments by frametime(and then back up with a larger constant) would allow you to recalculate the wind strength every frame which might improve the animation. It might also benefit the model to make it more likely to move the wind towards the middle values than the extremes.

You then need props through your level like ropes, "ye olde inne" signs, torches, lanterns and flags which are specially designed to react to the wind. They might be give specially designed models which have frames from 0 to 40 corresponding to the strength of the wind. Then they would only need to have think functions which regularly update the entity's frame to match the wind in that frame, maybe with some jitter.

In some cases, like the sign at the inn, you might only be going for simple rotation back and forth. Then you would be better served using .angles rotation since some engines transmit it with higher precision, and you would avoid the floating vertices rotating a sign two degrees each frame is bound to produce. You would also not need to use granular values between 0 and 40, but just use the floating point wind value directly to calculate the angle.

Then just add some howling wind and creaking timber sounds and your windswept landscape is complete! 

i was actually not going to bother continuing but those posts kind of encouraged me to at least try...

ended up with this:
http://necros.quaddicted.com/temp/ropes1.jpg

each segment is 16-32 units long (they contain 16 frames in 1 unit long increments).

each frame, i iterate through the chain and add a velocity vector pointing towards both the next and previous points.

this works somewhat, but you have to tweak the tension (speed multiplier of the velocity vector) or it jitters a lot.

it also doesn't really work with longer ropes because you need super high tension to keep it from falling apart but those levels of velocity cause excessive jittering.

so yeah, with the expense of iterating the chain every frame and needed many segments with 1 entity each, it just doesn't seem worth it.
if i do try to continue with ropes generated at run time, looks like i'll have to look into static ropes, probably with a cosh function like mwh posted (thanks for that).

it's a shame though because i had hoped to get the ropes to react to rockets passing by and explosions. oh well. :S 

if your FPS drops, the required velocity to keep the segments together becomes increasingly larger. at some point around 30-45 fps, the velocity is too high and the chain breaks. 

..my idea is to have in my map many different skinned monsters per class (4 or 5 soldiers with different colors, 4 or 5 knights, ..)

Easiest way to achieve this ?

-I'd happily skip the creation of every different skinned monster in qc code(since I want to change only clothes color for each!) 

Store the new skins in the mdls; give the monsters a "skin" "#" field in the map (# being the index number of the respective skin). 

 

there's 2 ways to create reskin monsters.

1. Create all new .qc files for each reskin, using the same frame macros but renaming the function names (so they don't conflict at compile time).

2. Integrate all the types of monsters into the same original monster code so that at key points in the code, it checks to see what type of reskin it is and then behave different accordingly.

method 1 is the easiest to understand and and read because everything is seperated into individual files. the monsters will adhere to the standard monster coding setups.
method 2 is the easiest to code because you don't have to rewrite anything and just add in little snippets for things like different attacks or a different ai_run routine.

also of note, a lot of the behaviour is controlled by the checkattack function, so simply having a seperate one of those can help distinguish between reskins.

if you're planning on doing this much coding, you should probably check out inside3d. they are more focused on coding while this board is more focused on mapping. 

re 460: clairvoyant? o.0 

i see what you meant now.

also: http://www.youtube.com/watch?v=21D-21MLrAE

not sure what those 'shivers' are... i can't only guess it is a symptom of irregular framerate. a momentary dip would cause it, i suppose, although i thought i fixed that. :P

also, i obviously need to find some way of adding in damping of some sort because those things will bounce around for ever. 

Does anyone have/have a link to the lost chapters src from qexpo? http://qexpo.quakedev.com/booths.php?tag=necros doesn't go to the page. I've seen it linked somewhere here, just can't find it.. 

http://qexpo2005.quakedev.com/booths.php?tag=necros 

 

http://necros.quaddicted.com/temp/qcgui1.jpg

another program with debatable usefulness. :P 

is it possible to determine if the player is inside a triangular space with just the info of the 3 vertices and discounting vertical axis with QC?

making a monster that traps the player inside a triangular area but it would be awesome if the monster could tell if you were actually trapped (inside) or not. 

god damn it...
as usual, after thinking about it for a few minutes, i figure it out a few seconds after posting.

i can just use the dot product of normalized vectors from the origin vertex.

we need a delete button. :P 

Ok, I've got an idea to share with y'all about making QC events that happen at high frequencies cope with the framerate dropping below that frequency. But in order to make it a bit different, I'm going to set a bit of a puzzle about it first, which comes as a piece of code and three questions:

void() generic_think =
{
���// do some kind of thing which needs to
���// occur rapidly

���self.nextthink = self.nextthink + 0.05;
���self.think = generic_think;
���if(self.nextthink <= time)
������self.think();
}

� For partial credit, what is this code trying to do?
� For full credit, why will it fail?
� For extra credit, what can we do to fix it? 

it looks like you're trying to get the think function to recursively take care of missed thinks.

i've never thought of doing it this way. usually, if i have a think function that needs to be accurate across inaccurate think times, i just use something like this:

void() thinkfunction =
{
����fraction = (time - self.ltime) / 0.05;
����self.ltime = time;

����self.nextthink = time + 0.05;
����self.think = thinkfunction;
}

and just scale whatever it is i'm doing with fraction.

doing it recursively would be easier to code, i guess, but i would think much more expensive on operations. 

That's exactly the point of the code, so here's what goes wrong with it:

The assumptions behind this bit of the code are that the QC global time stores the current server time, and self.nextthink stores the time we wanted the think to occur. One of these things is often not the case, and the other is always incorrect.

If you run a dprint on self.nextthink during a think function (but not an animated think function) you will find that nextthink is equal to 0! It's always reset by the engine, so that unless you explicitly call for a new nextthink, the engine can skip over thinking. Conversely, nothing happens to the think field when you run a think function, so if you're optimising QC code for a looping think function, you can remove the bit where you reset self.think in each call safely.

So that's the assumption that's always wrong, that the nextthink time you originally set is preserved in that variable when the think function eventually runs. But is the information lost forever? Not always! The QC variable time is set to either the current server time, or the actual nextthink time which WAS set - whichever is the largest. So as long as you don't ever set nextthink to be smaller than the server time + frametime (which calculates the server time for the NEXT frame), you get the information back.

Luckily never doing that is the point of this whole missed-think-avoidance code. All we need now is to find out the true server time during our think. This is easy though, as we just create a new global called servertime. We then use StartFrame to set servertime = time, and then refer to that in our calculation.

Our code then looks like:

void() generic_think =
{
���//do stuff
���self.nextthink = time + 0.05;
���if (self.nextthink < servertime + frametime)
������self.think();
}

As a closing remark, this function has tail recursion, so you don't actually have to fill up the callstack repeating it over and again. Just wrap it in a do...while loop for performance.

And there we go, a way to ensure that a given function executes 100 times in a second, regardless of the framerate of the server. 

clever! :) i had no idea about time being set to nextthink.

also, you could just make a new .nextthink2 var:
self.nextthink = self.nextthink2 + 0.05;
this neatly avoids the engine resetting nextthink. 

Hi,

how can I modify those .lmp files included in id/paks ?
my goal is to have a new hud for my mod (at least change color and quake guy face !) 

adquedit can import bmp and pcx (i think?) and convert them to lmp.