addObject() 'time' parameter inconsistent #40402

New Issue

Raf Colson · 2014-05-28T07:01:19+02:00

Raf Colson commented

2014-05-28 07:01:19 +02:00

System Information
Windows 7 64 bit, Nvidia GeForce GT540M Cuda

Blender Version
Never worked. (tested with 2.63 up to current Hash 7fb33e5)

Short description of error
The 'time' parameter of addObject() gives inconsistent results. Generally the added object lives longer as it should. With 'time' set to 1, the object lives 2 logic tics. With 'time' set to 10, for example, the object lives 13 logic tics.

Exact steps for others to reproduce the error
Play the game. Check the messages in the System Console.

AddObject_life_bug.blend

**System Information** Windows 7 64 bit, Nvidia GeForce GT540M Cuda **Blender Version** Never worked. (tested with 2.63 up to current Hash 7fb33e5) **Short description of error** The 'time' parameter of addObject() gives inconsistent results. Generally the added object lives longer as it should. With 'time' set to 1, the object lives 2 logic tics. With 'time' set to 10, for example, the object lives 13 logic tics. **Exact steps for others to reproduce the error** Play the game. Check the messages in the System Console. [AddObject_life_bug.blend](https://archive.blender.org/developer/F91678/AddObject_life_bug.blend)

Raf Colson commented

2014-05-28 07:01:19 +02:00

Changed status to: 'Open'

Raf Colson commented

2014-05-28 07:01:19 +02:00

Added subscriber: @raco

Raf Colson commented

2014-05-28 07:13:29 +02:00

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.

Mitchell Stokes commented

2014-05-30 04:50:14 +02:00

Added subscriber: @Moguri

Mitchell Stokes commented

2014-05-30 04:50:14 +02:00

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();
	}

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(); } ```

Mitchell Stokes commented

2014-05-30 04:57:44 +02:00

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.

Raf Colson commented

2014-05-31 01:36:52 +02:00

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())

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())

Mitchell Stokes commented

2014-05-31 02:09:43 +02:00

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

Raf Colson commented

2014-05-31 10:29:31 +02:00

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

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

Mitchell Stokes commented

2014-05-31 22:07:10 +02:00

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 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.

Angus Hollands commented

2014-06-01 05:07:03 +02:00

Added subscriber: @AngusHollands-4

Angus Hollands commented

2014-06-01 05:07:03 +02:00

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).

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).

Inês Almeida commented

2014-06-27 23:01:25 +02:00

Added subscriber: @brita

Mitchell Stokes commented

2014-07-04 15:24:27 +02:00

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)

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)

Raf Colson commented

2014-07-04 18:05:59 +02:00

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

I'm all for changing to seconds. You can read about opinions on BA: [Your opinion about fixing the addObject 'time' parameter? ](http://blenderartists.org/forum/showthread.php?338508-Your-opinion-about-fixing-the-addObject-time-parameter)

Raf Colson commented

2014-07-20 02:13:02 +02:00

Maybe this could be changed from type 'Bug' to 'To do' or 'Design'. I think we all agree that changing to seconds is the best solution.

Dalai Felinto commented

2014-08-27 12:39:46 +02:00

Changed status from 'Open' to: 'Archived'

Dalai Felinto closed this issue

2014-08-27 12:39:46 +02:00

Dalai Felinto self-assigned this 2014-08-27 12:39:46 +02:00

Dalai Felinto commented

2014-08-27 12:39:46 +02:00

Agree on changing to seconds when we feel like breaking compatibility again (3.x?). Moved to the TODO . Thanks for the report.

Agree on changing to seconds when we feel like breaking compatibility again (3.x?). Moved to the [TODO ](http://wiki.blender.org/index.php/Dev:2.5/Source/Development/Todo/GameEngine#Python_API). Thanks for the report.

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

addObject() 'time' parameter inconsistent #40402