CEG bug: Giant expanding CEGs

[SanadaUjiosan]

So in our first actual game of CT since making a lot of muzzleflare CEGs, we noticed that sometimes, for no apparent reason, a CEG would flash across the screen at about a hundred times the size it should be. Wondering if anyone has any input on this, if its a common problem that can be remedied, or what.

Not sure what other info I could provide, I guess ask and I'll try and provide.

Here is a link to our issue for this, for no good reason:

http://code.google.com/p/conflictterra/ ... %20Summary

[knorke]

Not sure what other info I could provide

if it happend for everybody or just you, screenshot, replay, file, ...

[SanadaUjiosan]

Happened for both snoop and I at least. We were on Mumble during the game.

Attached replay.

Build is 1369, map is ye olde Tropical.

First to notice was the drone's binderbeam CEG (actually not supposed to be in the game...), and later noticed the muzzle flares off of cruisers, I think anyways... happens very fast.

[smoth]

I have NEVER seen this. Paste the offending ceg please.

[SanadaUjiosan]

I have NEVER seen this. Paste the offending ceg please.

Probably the most assuring thing I could hear.

Well, after watching the replay for the first time, I was sad to see it wasn't actually happening. Then, my poptarts popped so I paused the replay to go get them, and BAM! All of the CEGs on the screen popped up real big, and then returned to normal as the game was paused. I was able to make it repeat this each time I paused the game; the CEGs did their thing.

Which makes me wonder, maybe the cause for this before was little moments of lag in the game. Almost seems like if the game stops, the CEGs continue in their grow tag for a second longer or something.

Anyways, here is the requested example Smoth:

Code: Select all

return {
	["ct_binderbeam"] = {
		bitmapmuzzleflame = {
			ground             = true,
			air                = true,
			water              = true,
			class              = [[CBitmapMuzzleFlame]],
			count              = 1,
			underwater         = 1,
			properties = {
				colormap           = [[0 0.85 0 1	    0 0.85 0 1     0 0.85 0 1]], --Colour map progress from one to next. Colors in RGBA
				dir                = [[dir]],
				frontoffset        = 0.5,
				fronttexture       = [[ct_jumpjet_front]],
				length             = 15,
				sidetexture        = [[ct_binderbeam_side]],
				size               = 2,
				sizegrowth         = 1,
				ttl                = 1,
			},
		},
	},
}

[smoth]

nothing looks abnormal here. can you try and repeat the process in gundam?

[SanadaUjiosan]

I briefly tried but of course got nothing. Do any of your units fire a CEG that's not weapon related? The binderbeam is a constantly running CEG, like this:

Code: Select all

	local function binderbeam()
		Turn(binderbeampiece, y_axis, 1.5, 10)
		while (true) do
			EmitSfx(binderbeampiece, ct_binderbeam)
			Sleep(1)
		end
	end

	function script.Create(unitID)
		StartThread(binderbeam)
	end

[smoth]

You are firing that ceg 30~ times a second.... that is a bit much man. try a sleep of 30 instead of 1..

[FLOZi]

Sleep is in milliseconds, not frames!

That is running 1000 times a second, unless LUS is updated only every frame itself - and in that case, Sleep(30) would be no different to Sleep(1), or no more than a single frame different anyway.

[smoth]

oh. I thought it was in frames.

[knorke]

Which makes me wonder, maybe the cause for this before was little moments of lag in the game. Almost seems like if the game stops, the CEGs continue in their grow tag for a second longer or something.

pretty sure it is this.

There is/was def. something strange with effects and fps lag/pause etc.
In old spring all debris and particles would continue flooding in their direction when the game had ended. Smoke clouds would grow superlarge because they did not died after game end. On pausing they would continue to grow for a moment and then "snap back."
And I think in e&e I sometimes noticed that when pausing, the smoke clouds over powerplants would become very large for a brief moment.
I guess it is something like that.

sizegrowth = 1,
ttl = 1,
maybe try sizegrowth = 0,
effect is only alive for 1 frame so i dont see how it should have time to grow anyway.

Anyway, when posting replays..at least give time and position.
otherwise nobody watches them.

[Rafal99]

Sleep is in milliseconds, not frames!

That is running 1000 times a second, unless LUS is updated only every frame itself - and in that case, Sleep(30) would be no different to Sleep(1), or no more than a single frame different anyway.

I remember doing tests for this and Sleep() is indeed updated once per frame so that Sleep(1) = Sleep(30).

[SanadaUjiosan]

So... does this mean that Sleep(1) through Sleep(30) yields the same result, and anything over Sleep(30) is accurate?

Or does it work in some kind of crazy way in that Sleep only works in intervals of 30?

[FLOZi]

So... does this mean that Sleep(1) through Sleep(30) yields the same result, and anything over Sleep(30) is accurate?

Or does it work in some kind of crazy way in that Sleep only works in intervals of 30?

The latter, and it's hardly crazy if you understand how spring works.

[SanadaUjiosan]

So... does this mean that Sleep(1) through Sleep(30) yields the same result, and anything over Sleep(30) is accurate?

Or does it work in some kind of crazy way in that Sleep only works in intervals of 30?

The latter, and it's hardly crazy if you understand how spring works.

Not at all, so I maintain my stance of crazy, haha.

So, if Sleep isn't a multiple of 30, does the engine just round to the closest multiple?

[MidKnight]

IT IS LATE AND I EXPLAIN SPRING GAME MECHANISM NOW TO YOU
http://dl.dropbox.com/u/14204175/MK%20e ... accent.mp3

I WILL LIKELY REGRET THIS TOMORROW
SORRY

[oksnoop2]

IT IS LATE AND I EXPLAIN SPRING GAME MECHANISM NOW TO YOU
http://dl.dropbox.com/u/14204175/MK%20e ... accent.mp3

I WILL LIKELY REGRET THIS TOMORROW
SORRY

omglol wow *downloadedandsavedforever*

I had to listen to this multiply times because I could not hear you over my laughing. I don't know why you did this but it was hilarious and we should be friends. On a serious and on topic note. This is still happening.