It probably has something to do with the built-in standard of 50fps for the Add Object Actuator. Notice in the example blend file that on the 6th tic, life shows 5.

Yeah, the life/time parameter is a pseudo-second of sorts. It looks like it assumes 50fps, which is not very accurate:

	if (lifespan > 0)
	{
		// add a timebomb to this object
		// for now, convert between so called frames and realtime
		m_tempObjectList->Add(replica->AddRef());
		// this convert the life from frames to sort-of seconds, hard coded 0.02 that assumes we have 50 frames per second
		// if you change this value, make sure you change it in KX_GameObject::pyattr_get_life property too
		CValue *fval = new CFloatValue(lifespan*0.02);
		replica->SetProperty("::timebomb",fval);
		fval->Release();
	}

If this is fixed to be actual seconds, it could break existing games. So, this probably isn't worth fixing. On the other hand, it is hard to be precise with the time parameter since it is based on framerate. If precision is an issue, you can always use the Python time module and KX_GameObject.endObject() to handle this yourself.

I don't really see how it would break existing games if the value would be determined by the logic tic rate.

CValue *fval = new CFloatValue(lifespan/getLogicTicRate())

It would alter the timing, which could throw off existing games.

Hi moguri,

Thanks for answering.

I think you're talking about the case where game developers purposely used other values to work around this limitation. For example, setting time to 50 so the object is removed after one second, even when the logic tic rate is 60.

If such a developer would like to run/export his (old) game with a Blender version without this limitation, indeed he would be forced to change time to 60. But if you ask me, I think he would gladly do so, because he'll never have to deal with this limitation ever again, when working on future projects.

I will ask people for their opinion on the Blender Artists Forum and keep you posted.

Thanks

I was thinking more off people you just played with the number until it "felt right." These people will have their games subtly changed. This may be a problem or it may not. Regardless, this won't be fixed for 2.71, since I don't want to introduce any potentially game breaking changes at this stage.

Also, if this is going to be changed, it will be changed to just use seconds, and not be framerate dependent.

I feel that whilst this is a valid argument, there are already enough inconsistencies in the engine timing design as it is, and we should address them asap.

If it breaks existing games, it won't be difficult to alert users of the change. New users should find it simpler to use with seconds. I don't believe we should encourage "compatibility" with such bugs, especially when they aren't mainstream features (the life attribute of an object is rarely used by most blend files I've investigated).

If we change over to seconds for this, some other (potentially breaking) changes would happen as a result:

• The lifetime would no longer be framerate dependent (this could alter timing, but would overall be a good change)
• KX_GameObject.life would return values in seconds instead of frames (the docs say seconds, but currently the number of frames/tics remaining is actually being returned)

I'm all for changing to seconds. You can read about opinions on BA: Your opinion about fixing the addObject 'time' parameter?