yeah that's what i mean. it should just be there regardless but something i wrote in my own code was stopping it from being defined or at least, made it look that way to the compiler.

i'm sure if i knew more about it it wouldn't be that strange but for a noob like me, it's just befuddling. 

So I haven't posted much on the old blog this year - putting together the Quoth release took up most of my Quaking time. So now that it's out the door, here's a return to posting stuff. Today we develop a bit of a hack to create an EndFrame function.

http://tomeofpreach.wordpress.com/2014/05/11/creating-the-endframe-function/

There are a bunch of extra hacky things this makes possible, but the article is tightly focused, maybe I can follow up with some of the options... 

Does this mean there's a way to reorder the entity edicts list? Is that what .chain and head are doing? Care to explain how those work, please?

I have a really cool entity that requires any linked entities to be right next to each other (or very nearly) in the edict list in order to avoid any mid-frame lag between eachother. I haven't released the entity as a standalone .qc file yet since I haven't found a workaround for telling people to "Yeah, just select the entities in the editor, copy them, delete them, then paste them to bring them back, then compile. That way the linked entities are always last on the edicts list since they are last in the map file. That way you avoid any mid-frame lag from having to calculate too many physics calls in between entities within the same frame." (DEATH to 0.100 second delays when arriving at path_corners!)

Is there a way to always make sure these entities are near each other in the edicts list so that they're physics are called together? 

.chain is set when you run findradius. the engine simply sets this on all entities in the radius so you can iterate through them.

relying on the entity spawn order for your code is dangerous and impractical. it would be better to create a new .entity field and then build your list of entities with the new field at map start once. then you can iterate smoothly without having to rely on the map playing nice. 

@Qmaster: try using copyentity to copy the slave entity towards the end of the list. combine with the entnum builtin/intrinsic/nextent so you know the order is okay. do it inside the master's spawn function if the slave already exists and you should be okay with respect to targetname stuff on other entities. 

Now, from the context clues in your post, I'm guessing you're trying to create some kind of escalator or conveyor belt contraption out of a set of func_train entities. Ensuring that all of the trains are next to each other in the entity list will not save you here. One way they can still go out of sync is if a player blocks one of the trains, but the others are free to move.

What I'd recommend is getting a copy of the "custents" mod, and looking at their func_train_sync entity, which is designed to fix this specific issue. I can't remember if the fix was complex - like ensuring all the movement shuts down when one entity is blocked, or the simpler solution of having individual entities wait at each corner until all the trains have reached their next stop. 

Incidentally I'm running into a bug now with the tutorial I posted, so hold on using it until I figure out what's causing it. It's the kind of bug that creates a substring out of a QC string, so something's really having a party on the entity... 

Ok, so it turns out that the compiler optimisations I was using with FTEQCC have an obscure bug that got exposed by the spawn() function wrapper in the previous tutorial. This was corrupting the entities, and it also managed to corrupt the linked list in CreateBackstop to obscure the fact that it should loop infinitely.

The full skinny on what form the bug takes, how to work around it, and how to fix the bugs it masked in my own code is now up on the blog:

http://tomeofpreach.wordpress.com/2014/05/20/fixing-the-endframe-function/ 

Preach, in all seriousness, get an updated version. That's an order! 

Latest version on the page is 1.0 and that's like 3 years old... 

http://triptohell.info/moodles/fteqcc/ 

Blocked by NOD32 :( 

 

Speaking of FTE things, what is the general story about the lack of public stable releases for FTEQW etc.? I ain't mad, just curious. I see there's development still churning away, but I typically avoid using dev builds of stuff unless there's a specific reason. 

as the v1 release proved, stable builds are not really that much more stable than stuff that has since been fixed...
I'm not really a milestone kind of person, thus there's not really any point where a release is any more worthy than another (generally the 'best' time is just before I commit some huge awesome feature that's likely to break everything, which means that the release is effectively crippleware).
plus I'm too lazy to figure out how to edit the site. :s 

Yeah, it seems a shame that this kind of stuff gets lost - I guess it's the downside to that continuous integration, nightly builds stuff - there's less inclination to tie things up into a release milestone. I'll make a blog post once I've messed around with it, which will at least give it a tad more coverage... 

@Spike: Nice! New version has some nice bug fixes (like not being able to minimize a fullscreen window).

The new version though is giving me a bunch of similar wierd warnings though:

client.qc:761: warning F307: type mismatch: void() to void(entity attacker, float damage) entity.th_pain

It's this line in client.qc under
void () PutClientInServer = {
...
...
self.th_pain = player_pain;
...
...
}

Uh...what?
Since when did assigning a function to a .func need a type to match?

Anyways, compiles nicely. Also, I think it's a tad bit faster. 

Functions not matching field types quickly leads to functions being called with the wrong number of paramters. Please see:

http://www.celephais.net/board/view_thread.php?id=1&start=23053&end=23102

...and...

http://www.celephais.net/board/view_thread.php?id=60398&start=185&end=200

...for the kind of fucking-awful-to-debug issues that this warning protects you from.

Now, in one direction you're probably quite safe: if you assign functions without parameters to fields which expect parameters then the engine is doing benign busy-work for no good reason. On the other hand, assigning functions with parameters to fields which aren't going to set them will send you to bug city in entirely unpredictable ways. 

> Since when did assigning a function to a .func need a type to match?

Since people tried stuff like:
string(.void(),float,string) ohnoeswtf;
void() foo =
{
self.th_pain = ohnoeswtf;
};

you get the idea... 

I had no idea that could happen Preach. That makes so much sense now. I suppose the only reason the PARMs don't get 'scrubbed' was to be more optimized? Anyways I'll definitely check these warnings out now. 

The warning lies in the original code's usage of the th_pain function. Calls to a th_pain without sending any arguments (e.g. void () player_pain... ) are generating warnings all over the place in untouched progs.dat vs 1.06. Attempting to correct this by making all instances of a pain function include "(entity attacker, float damage)" as per defs.qc's definition would still generate some warnings, for instance in the case of func_door_secret assigning .use to the pain function for shootable secrets.

Perhaps a future update could suppress these particular instances. Just FYI, I don't know how yall are ignoring these warnings, they're kinda annoying. Anyways, I'll try to ignore them. 

They are the more difficult ones to fix. I can see one way to do it, but I'm still deciding if this the best way to go about it. Keep the fd_secret_use function as it is, but create a new function as follows:

void(entity attacker, float damage) fd_secret_pain =
{
fd_secret_use();
}

This certainly fixes the warning, although it is using an extra stack frame to resolve a benign warning. In the secret door case you could get rid of the need for a pain function if you made the health of the door 1, so it dies to every attach. However, I've had the same problem on monsters which I can't afford to rewrite in that way. 

Should be able to cast it.
self.th_pain = (void(entity,float))fd_secret_use;

Essentually an 'I know, now please shut up' option. 

What's the difference between checking other.takedamage and other.health in a projectile touch function?

When a monster dies, there's a short period when it's still solid. Hitting it while it's in such condition is pretty much like hitting a regular wall. It's very hard to notice in normal circumstances, but I have a weapon that shoots ricocheting nails, and on more than one occasion nails bounced from dying monsters right into my face.

Laser touch function in hipnotic QC uses other.health rather than other.takedamage to detect a damageable entity. I tried that and it helped. What I don't understand is why. 

cthon has health (3 on hard, woo) but is not shootable.
monsters that have been killed will have a lingering <1 health value, despite no longer being shootable.
if you're paranoid about players doing exactly enough damage to drop a monster to 0 health exactly, then you might want to test for a longering th_die instead.