Quantcast

A bug in animation

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

A bug in animation

James C. Wilson

I appear to have a genunine bug this time; even Pipmak itself agrees.

  I've got two nodes connected by an image sequence of a door opening. I've used this same code for many other doors with no problems.

  But when I click on the hotspot that would normally open the door, pipmak does one of three things: 1. Goes to the designated node(60), but without playing the door "video". 2, crashes to the desktop. Or 3, goes to the designated node, doesn't play the video, and prints this message, referring to the three patches used in the animation:

 

Pipmak internal error: image 67/freezerDoor_open/bottom/12.jpg collected while texture still in use (1).

This is a bug, please report.

Pipmak internal error: image 67/freezerDoor_open/back/12.jpg collected while texture still in use (1).

This is a bug, please report.

Pipmak internal error: image 67/freezerDoor_open/right/12.jpg collected while texture still in use (1).

This is a bug, please report.

 

stdout.txt, node.lua, and the function file for autoplaying the video are attached.

 

 Thanks,

 James CW


pipmak stdout.txt (108K) Download Attachment
node.lua (830 bytes) Download Attachment
playVid.lua (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: A bug in animation

cwalther
Administrator
James C. Wilson wrote:

> But when I click on the hotspot that would normally open the door,
> pipmak does one of three things: 1. Goes to the designated node(60), but
> without playing the door "video". 2, crashes to the desktop. Or 3, goes
> to the designated node, doesn't play the video, and prints this message,
> referring to the three patches used in the animation:
>
> Pipmak internal error: image 67/freezerDoor_open/bottom/12.jpg collected
> while texture still in use (1).
>
> This is a bug, please report.
> ...

Thanks for the report. A few questions:

- Your error message says "67/freezerDoor_open/", but pipmak stdout.txt
doesn't contain that, only "60/freezerDoorOpen/". Are you sure these are
from the same run?

- How are you making the playVid function known to the node.lua code?
I'm missing something like 'pipmak.dofile "playVid.lua"'. In particular,
I want to know when and in what context playVid.lua is run.

I wonder if you could be using patches that are on an already left node,
not on the current one. That doesn't work, but we should handle it more
gracefully than by crashing or generating internal errors.

  -Christian



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: A bug in animation

James C. Wilson
Ah, I've found the source of the issue: playvid.lua, since it has patch declarations, must be included in every node that the function is called--not just in the first node used, as I had mistakenly assumed. Otherwise pipmak tries to use the patches from the previous node's playvid.lua, only to crash. Do you think it's reasonable for Pipmak to crash when confronted with this problem, though?

Thanks,
 James


From: Christian Walther <[hidden email]>
To: [hidden email]
Sent: Saturday, December 17, 2011 7:44 AM
Subject: Re: A bug in animation

James C. Wilson wrote:

> But when I click on the hotspot that would normally open the door,
> pipmak does one of three things: 1. Goes to the designated node(60), but
> without playing the door "video". 2, crashes to the desktop. Or 3, goes
> to the designated node, doesn't play the video, and prints this message,
> referring to the three patches used in the animation:
>
> Pipmak internal error: image 67/freezerDoor_open/bottom/12.jpg collected
> while texture still in use (1).
>
> This is a bug, please report.
> ...

Thanks for the report. A few questions:

- Your error message says "67/freezerDoor_open/", but pipmak stdout.txt
doesn't contain that, only "60/freezerDoorOpen/". Are you sure these are
from the same run?

- How are you making the playVid function known to the node.lua code?
I'm missing something like 'pipmak.dofile "playVid.lua"'. In particular,
I want to know when and in what context playVid.lua is run.

I wonder if you could be using patches that are on an already left node,
not on the current one. That doesn't work, but we should handle it more
gracefully than by crashing or generating internal errors.

  -Christian


------------------------------------------------------------------------------
Learn Windows Azure Live!  Tuesday, Dec 13, 2011
Microsoft is holding a special Learn Windows Azure training event for
developers. It will provide a great way to learn Windows Azure and what it
provides. You can attend the event by watching it streamed LIVE online
Learn more at http://p.sf.net/sfu/ms-windowsazure
_______________________________________________
Pipmak-Users mailing list
[hidden email]
news://news.gmane.org/gmane.games.devel.pipmak.user
https://lists.sourceforge.net/lists/listinfo/pipmak-users


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: A bug in animation

cwalther
Administrator
James C. Wilson wrote:
> Ah, I've found the source of the issue: playvid.lua, since it has patch declarations, must be included in every node that the function is called--not just in the first node used, as I had mistakenly assumed. Otherwise pipmak tries to use the patches from the previous node's playvid.lua, only to crash.

Ah, as I suspected. Yes, including it in every node is the correct solution.

> Do you think it's reasonable for Pipmak to crash when confronted with this problem, though?

No, that's a bug. Will look into fixing it.

 -Christian



Loading...