Talk:Every-time-argument - Revision history

Shade at 12:11, 10 August 2007

2007-08-10T12:11:23Z

← Older revision		Revision as of 12:11, 10 August 2007
Line 2:		Line 2:

	*Yeah, it's "evaluate" rather than "execute". I corrected it accordingly. The reason I put that bit about the framerate is because <tt>[[when]]</tt> uses optimizations to skip those parts of the sexp which have already become known. <tt>[[Every-time]]</tt> clears those optimizations in each frame, so it will always evaluate the whole thing. Now, you're on the right track; this is far from the most processor-intensive part of the code. That honor probably belongs to something with the models or graphics -- probably the collision detection. The more important issue is understanding the logic behind the concept. [[User:Goober5000\|Goober5000]] 22:52, 9 August 2007 (CDT)		*Yeah, it's "evaluate" rather than "execute". I corrected it accordingly. The reason I put that bit about the framerate is because <tt>[[when]]</tt> uses optimizations to skip those parts of the sexp which have already become known. <tt>[[Every-time]]</tt> clears those optimizations in each frame, so it will always evaluate the whole thing. Now, you're on the right track; this is far from the most processor-intensive part of the code. That honor probably belongs to something with the models or graphics -- probably the collision detection. The more important issue is understanding the logic behind the concept. [[User:Goober5000\|Goober5000]] 22:52, 9 August 2007 (CDT)

			Yeah, shield collisions probably take that prize. But, even if it's a relatively small difference in load, it's still useful for people to know that there ''is'' an impact on performance, so it should definitely be here. Stuff like this is exactly why I insist on still keeping the seperate SEXP pages even when we have the big list. I also went and put a similar warning on the FRED example page that uses them most heavily so people won't think they can just throw 50 of those events into a mission and get away with it. - [[User:Shade\|Shade]] 07:11, 10 August 2007 (CDT)

Goober5000 at 03:52, 10 August 2007

2007-08-10T03:52:24Z

← Older revision		Revision as of 03:52, 10 August 2007
Line 1:		Line 1:
	Need to clear something up: Isn't it that they are evaluated every frame rather than executed every frame? While the conditions are not met they should not add a greater load than a standard when or when-argument (which are also evaluated every frame, at least until they've triggered once). I see no problem with having the warning there, they definitely should only be used with care and by those who know what they're doing, just want to make sure it doesn't give out wrong info. [[User:Shade\|Shade]] 07:22, 8 August 2007 (CDT)		Need to clear something up: Isn't it that they are evaluated every frame rather than executed every frame? While the conditions are not met they should not add a greater load than a standard when or when-argument (which are also evaluated every frame, at least until they've triggered once). I see no problem with having the warning there, they definitely should only be used with care and by those who know what they're doing, just want to make sure it doesn't give out wrong info. [[User:Shade\|Shade]] 07:22, 8 August 2007 (CDT)

			*Yeah, it's "evaluate" rather than "execute". I corrected it accordingly. The reason I put that bit about the framerate is because <tt>[[when]]</tt> uses optimizations to skip those parts of the sexp which have already become known. <tt>[[Every-time]]</tt> clears those optimizations in each frame, so it will always evaluate the whole thing. Now, you're on the right track; this is far from the most processor-intensive part of the code. That honor probably belongs to something with the models or graphics -- probably the collision detection. The more important issue is understanding the logic behind the concept. [[User:Goober5000\|Goober5000]] 22:52, 9 August 2007 (CDT)

Shade: New page: Need to clear something up: Isn't it that they are evaluated every frame rather than executed every frame? While the conditions are not met they should not add a greater load than a standa...

2007-08-08T12:22:45Z

New page: Need to clear something up: Isn't it that they are evaluated every frame rather than executed every frame? While the conditions are not met they should not add a greater load than a standa...

New page

Need to clear something up: Isn't it that they are evaluated every frame rather than executed every frame? While the conditions are not met they should not add a greater load than a standard when or when-argument (which are also evaluated every frame, at least until they've triggered once). I see no problem with having the warning there, they definitely should only be used with care and by those who know what they're doing, just want to make sure it doesn't give out wrong info. [[User:Shade|Shade]] 07:22, 8 August 2007 (CDT)