just took a quick scan over the article... the expanding code box doesn't seem to work for me. it expands, but it's all on a single line (the <br /> tags are visible). 

That was working a few days ago, and then the gremlins messed with it...fixed! 

HI:

I know the only 3 valid sizes are point, shambler and player, but I am just experimenting with the superspike model, attempting to have it do things like ricochet off bsp's for example, and one problem was it was not pointing in the new direction after rebounding, but I found vectoangles of the velocity ought to fix it? However I was wondering how could we use that to look at the spikes angles, and do a setsize that takes us out of the models default point size, and give it a better bounding box, that is more shaped to the model? I did some rudimentary tests, and found that:

setsize (self, '1 -0.5 -0.5', '8 0.5 0.5');

(self being the spike)

Works , except if its first angle coordinate, which I am guessing is its yaw? ,Is the larger value of the 2? Im just curious if anyone here can see a formula where we could resize the bounding box depending on its angles , or maybe the velocity, so that its always covering the spike....? 

Can I use quakeC to get rid of the wiggly darkplaces models in my game? Or do I need to switch from .mdl to .mdl3? (or whayever the extension was, just a guess my friend made)

Very curious, maybe it's something completely diffrrent. 

It's best to use the LG on the Wiggles; they're a tough enemy and their armor wedgie ability can catch you out when you're least expecting it.

...

Give us more info on the problem you're having :) 

i think he's talking about vertex dancing.
in which case, yes, the only solution is to use a different model format. md3 will solve nearly all your problems. 

@ijed haha necros summed it up

@necros thanks for the info! 

.iqm is a good format as well and also supported by dark places as well. 

Oh thanks :P 

Sorry, I always forget that one since I've never used it, but I believe it might be better to do IQM because it is supported and actively being maintained in blender plugins...
I think it has skeletal animation as well? 

 

How is ltime calculated? In otherwords, why would this code have two separate entities start their movement at different times? It's starting essentially func_trains (they're not really but they are MOVETYPE_PUSH and move the same way)

local float eltime;

eltime = self.ltime; //force ltime to be the same?

stemp = self;
self = self.target1;
self.ltime = eltime;
self.think = qtrain_start;
self.nextthink = (self.ltime + 0.100);
self = stemp;

stemp = self;
self = self.target2;
self.ltime = eltime;
self.think = qtrain_start;
self.nextthink = (self.ltime + 0.100);
self = stemp;

...
...
...

I have already tried the servertime trick with StartFrame, but they still start at different times. Apparently they aren't starting on the same frame??!? 

ltime is incremented for the number of seconds the door or whatever has been moving for. If the door is blocked for whatever reason, ltime will not change and the door will freeze in place.
this ensures that the think is scheduled for when it arrives at its destination rather than in true seconds.
the whole point about ltime is that its local to the entity in question, and is allowed to freeze as required. If you want your trains to work as a pair, you'll need to ensure that if one is blocked, the other also stops moving, and take extra care to re-sync them when they start moving again.

seriously, why has noone made a map where you have to lure monsters to a certain area to block a train to desync them so you can jump from one moving platform to another? :s 

That's a cool idea! Secret area maybe?

Okay. So bprint debugging has confirmed that the nextthink's are infact the same for both entities. Does this mean that they will start at the same time though? Obviously no. Still no cookies.

So I'll step it through. Preach? Correct me if I'm wrong anyone.

Function sets think for two entities regardless of targetname (entities are stored as entities not targetname, target1 and target2 are .entities)

Function sets nextthink for two entities

Nextthinks are confirmed the same, bprint to console so I know.

Entities are set to start in nextthink seconds

This frame just set the nextthink time, so these entities will get called in the same frame in ltime+x. Well, theoretically they would. What's the tolerance for time when attempting to get two entities to start on the same frame in x seconds? + or - 1 frame? 10 frames?

These entities are not moving so ltime is not increased.

They never start then theoretically. But they start anyway just to confuse me.
1st one starts after about 2.5 secs
2nd one starts after about 4 secs

So how is ltime incremented while an object like a door is NOT moving???? 

Remember that the quake engine loops through entities and applies physics to them in a sequence. It can't process them "simultaneously". Imagine that we've already run physics on target1 this frame, but that we haven't run physics on target2. If we run your function at that moment, the two will be synced when the function ends, but by the end of the frame we'll have run an extra tick of physics on target2, desynchronising them again. Could that be what's occuring? 

a bmodel entity must have it's nextthing greater than ltime or it will not move. 

its a bit clumsy, as it tries to get the maths precise so that the train stops exactly where it needs to be even if its only a fraction of a frame away.
the ramifications of this is that ltime does not increase if self.ltime>=self.nextthink.

thus if you want a bsp object to move or spin, it MUST have a valid nextthink set.

remember that the timings are precise in that the movement covers the correct distance, rather than it arrives at the projected time. this isn't some national railway with precise time keeping. Its just trying to avoid moving through walls if you've got a low framerate.

If you have some third entity clearing everything out but the velocity, one pusher can still get blocked and ltime will not update while the other starts moving around freely.

An entire second and a half in 4 is too high for any precision issues. Are you sure its not getting blocked or anything? You're sure that you're using .ltime and not time when setting nextthink, etc? 

Turns out I had forgotten to recompile with ltime and it was still using time. However, even though with ltime it was reealllly close, I still had a discrepancy of about 0.8 to 1 game unit when the two entities started from the same point.

-Edit!-
------------------
I FIGURED IT OUT!!!!!!!

There is a latency, a lag, within a frame from one object to another when the physics are calculated. The two entities had been created several dozen entities apart in the map (about 15 min of mapping on another part of the map while I was thinking about what to do). This means that several dozen entities needed to be ran before the other entity would run, causing enough time lag for a small gap in start times.

The fix?

Duplicated lagging entity. Deleted original. Placed duplicate entity back in the same spot.

Done.

And that only took me 2 months to figure out.
Wait till you see what I use it for in my new map! 

An obscure bug with the monster that nobody cares about.

Basically, they don't move when scraping their heads against the top of the water volume they're in.

Anyone have a fix for this? I can trade you a fish model with a normal sized head when it dies... 

A simple way is to use pointcontents to check a point above the fish's head and if it is out of the water, reset the monster's z origin to the previous frame so that it can still move horizotally, but won't move upwards into a position where it will be stuck.

This has the small chance of making a fish get stuck in a wall, but you'd have to make a very specific shape of wall and water edge for it to happen. 

Banging their heads on the surface usually occurs when they're trying to swim up to the level of an .enemy who's higher up than them. You can create a dummy entity called worm. When you want a fish to swim, stash their proper enemy in a temporary variable, and set their .enemy variable to the worm. You can then position the worm to lead them where you want - place it in the direction of the real enemy, but at an appropriate height vertically. Remember to reset .enemy once you've called the ai movement functions. 

The issue was obvious really - like what happens to a scrag when it hits ceiling and you're above it.

Thanks guys. 

The above post is the good way to do things. But we don't like the proper way of doing things, we want to save an entity! The bad way to do things is to instead stash the old height of the fish's enemy, move THE REAL ENEMY down, then instantly restore that enemy's position when the movement function is done. If you're breaking the rules, you should go all the way and skip the call to setorigin - that would only cause actual collsions to occur when you want to avoid that happening. God help you if the fish collides with the enemy though... 

New QC article today - on field pointers. There are two - yes TWO - reasons to read today's article! One is if you'd like to learn what a field pointer is in QC and how to use them. They help you write generic code.

Even if you don't care about the technical knowledge, the article solves a practical problem: how do you code an entity which has templates? Templates here are where a mapper can set a single value on your entity and get a bunch of default values applied, and the mapper can selectively override these defaults.

http://tomeofpreach.wordpress.com/2013/08/07/field-pointers-in-qc/ 

As always a good read and I learned something new about function parameters. :)

I�m going to share a snippit of code from Quoth
You should one day publish that code, I imagine it would be awesome see how you organize and structure stuff. I would love to see how you implement features.