Jump to content

Bug and Crash Report Thread for Beta Pre-Release(3/25)


lucid
 Share

Recommended Posts

Hello everyone,

Please use this thread to report bugs, until I have a chance to clean the bug-tracker of bugs that no longer apply to this build. Things are much more tightly integrated and compartmentalized in a way much more suited to the framework than the previous version. In other words, there shouldn't be a such thing as 'general instability'. If there are crashes, there is a very specific cause. Please help us to find these remaining crashes and bugs, so we can release a fix in the short term. Please report all relevant information including OS, and what exactly you were doing when the bug occurred. This is especially important for crashes. If you can figure out the exact process to reproduce a crash, but can get it to happen often, and you're able to screen record it happening, then I may be able to figure out what caused it.

Thanks for testing everyone.

Daily Builds

Will be updating this thread from time to time with incremental builds. This will not be a forever ongoing daily build thing, but while we squash these first bugs and until we can remove the "pre-" from preBeta, will be posting updates here as I fix things. This should not be considered official releases, and is merely to accelerate the testing/fixing process. Also, when I do this, unless it's a mac or linux specific fix, it will be the Windows version only simply because that is what my development machine is, and building 3 versions for these in-betweens will significantly slowdown overall development. That being said, the arm situation is still ongoing, so I won't give a firm estimate, but there will not be a long delay between official versions again, 2 weeks at the longest. I will post fixes as I need them to be tested, could be multiple times a day, or none at all, whichever makes testing/developing fastest. To install them, simply drop them in the install directory for the current pre-beta.

Link to comment
Share on other sites

  • Replies 52
  • Created
  • Last Reply

Top Posters In This Topic

I will repost my bug list from here, so you'll have it all in one place. If I find something new, or manage to reproduce one of these, I'll make a new post to keep things clear.

1. If you drag an image from the file palette to the Z-order gui element, it will appear in the editor, but won't show up in the Z-order list. This leads to strange effects and can even (and most likely will) cause the application to crash (even if you were able to successfully remove the object).

2. It sometimes crashes under different circumstances giving an error like

Module: QtGui4.dll

Exception Code: c0000005

Operating system is Windows 7 64-bit. I wasn't able to reproduce that one, yet. It happens quite often, though.

3. Sometimes objects (images and bones) disappear in the hierarchy. Selecting the object makes it visible again. This happens while moving around objects in the hierarchy (like parenting to bones).

4. Extending the timeline makes the editor window jump.

5. Spriter sometimes freezes without Windows giving an error message (I was messing around with keyframes. Couldn't reproduce it, yet).

6. The preview for switching images doesn't always show the image. Presumably if it was added later:

preview.png

7. Selecting a default pivot point doesn't seem to work. It always resets to default for me. The pivot point editor window also doesn't stay inside Spriter's main window. When used in fullscreen, it is practically not usable. (dual monitor setup)

Link to comment
Share on other sites

8. If you place a new image in the scene, you can't immediately shift-scale it. You have to deselect and than reselect it first. It also works if you scale it once and then release the shift key and try to scale again. Maybe the shift key is not registering properly at some point.

9. When changing the Z-order, the view is not always updated immediately. You have to move one of the objects first.

10. Deleting an animated bone causes the attached image to stretch. That is also true for all children. Child-bones are also being messed up:

stretch.png

Link to comment
Share on other sites

Currently, operating the timeline is my biggest woe, though I suspect this may stem from the complexity of the sprites I'm working with.

There was significant lag between whenever I was making changes in the main window and when then proceeding to click & drag to navigate the timeline. My initial clicks sometimes do not register, and pushing the time line too fast when trying to get it to read my mouse clicks leads to 90% of my crashes. Thus far I've alleviated this by patiently waiting between each edit and when trying to navigate the timeline, even then it seems to hit a few spikes that cause it to choke and give up entirely, crashing.

Running windows 7, 64 bit, on a fairly beefy alienware (though I'll also be using this on mac). Not sure if this is more of a driver / memory thing or if I'm just pushing the beta version too much.

Good luck.

Link to comment
Share on other sites

Hi guys. Haveconquest, if possible, please send your zipped project folder to lucid@brashmonkey.com (will delete after testing), and I will see i can find the source of the slowdown.

Will be updating this thread from time to time with incremental builds. This will not be a forever ongoing daily build thing, but while we squash these first bugs and until we can remove the "pre-" from preBeta, will be posting updates here as I fix things. This should not be considered official releases, and is merely to accelerate the testing/fixing process. Also, when I do this, unless it's a mac or linux specific fix, it will be the Windows version only simply because that is what my development machine is, and building 3 versions for these in-betweens will significantly slowdown overall development. That being said, the arm situation is still ongoing, so I won't give a firm estimate, but there will not be a long delay between official versions again, 2 weeks at the longest. I will post fixes as I need them to be tested, could be multiple times a day, or none at all, whichever makes testing/developing fastest.

That being said. (@Pfaeff)This fix is for the multiple monitor problem. I can't reproduce the pivot points not updating, but the only two reports were in tandem with the offscreen pivot editor. Please verify it fixes the offscreen problem, and let me know (not sure why it would, but...) if it also fixes that pivot point update bug. Just drop this in the installed directory - 3/26/13-15:39

Link to comment
Share on other sites

lucud,

I assumed mine was the other pivot window / dual screen bug report, so I went ahead and tried the fix you posted.

I can confirm that the window now appears fully inside the main screen, but the pivots still reset to 0,0 every time I set them.

Link to comment
Share on other sites

The dual screen issue seems to be resolved. Though when using a smaller window size, the window now appears at weird places.

The pivot point still resets to (0,0), though.

3/26/13 - 18:27

fixed the bug where deleting a bone between frames would cause it's children to shift position

Seems to work just fine now :).

Link to comment
Share on other sites

Latest build is really shaping up! Great work dudes,

I've uncovered a weird bug in the SCML generation though. Essentially, within the Mainline, spriter is assigning a keyId of the 6, when it should be 2.

In the attached video, you'll see 3 mainline keys(0, 158, 319), but only 2 "footsmall" keys (0, 319). In mainline entry @ 158, for footsmall it's specifying keyId=6, this is the final frame @ 1800ms, instead it should be pointing to the keyId=2, @ 319ms.

https://vimeo.com/62797995

Link to comment
Share on other sites

I just had a strange issue, where I had just created a new animation in the animation window and then tried to add an object to the scene. The object didn't appear in the scene, but its name showed up in the Z-order and Hierarchy windows (no image was shown there, though). When selecting the image in the Z-order window, the scene window showed me a big triangle like shape that filled the entire editor window (not sure if this was my object). I also couldn't delete the object. I was able to delete the animation though, but when creating a new one, it showed the same behaviour. It seems to work after reloading the project.

Link to comment
Share on other sites

I am having issues with the Object Palette but I'm not sure how it is supposed to work, so not sure if it is a bug or not?

It seems to be displaying way too many objects, for example 5 "head" images all the same, and they are all renamed to "object_001, object_002" etc and/or greyed out - when I only have 1 head in the scene, and showing in the Z-Order and Hierarchy windows.

I thought it might be displaying ALL objects from EVERY keyframe, but I only have 2 keyframes in the animation, so it's way too many for that too.

It may be related to importing Spriter 4.1a projects, as all the names seem to renamed in the Z-Order and Hierarchy windows as well when doing this, but it does happen with new projects as well, but I can't reproduce it just yet.

Can you clarify what it is supposed to show and how it is supposed to work?

Also, make the File Palette the default selection upon program start. :)

Link to comment
Share on other sites

I'll look into all the bugs.

And yes, we need some new tutorials, but I'll give a thorough rundown of the object palette, and the object system here:

An object is a sprite or bone. The object palette displays all objects across all animations. If you start a new animation and wish to re-use the object from a previous animation, drag the object from the object palette instead of the file palette.

The are 2 benefits within the editor at the moment for sharing an object across animations.

One is that it maintains selection across animations. If you select "head" on your walk animation, and then switch to your idle animation, "head" will still be selected. The second benefit is that when you right click an object to use the image selection strip, when using the object as the image source, you have all images that object uses in any animation in the strip. In the object list, it shows all the images used for that object next to it's name.(the same image used multiple times will only appear once next to the object name)

For developers, the advantage is that if your api or game engine has a concept of an 'object', you can now keep these objects persistent. You can expose individual sprites to your api for access by name, and the name would be guaranteed to be unique. If you want to make the "visor" object translucent using some shader effect on your platform of choice, you wouldn't have to memorize id's or multiple names, just look for "visor", if your api is designed to take advantage of this. Regardless of current z-order, animation, or image, you know which object you've got.

Now, as for your current mess of named objects when you load your old projects that had unnamed objects. This is because Spriter has no way of knowing that all these are supposed to be the same object across multiple animations unless they were named the same when you saved them. It can't just assume the same image used means it's the same object because for all it knows you have a hydra animation with 3 "head" objects all using the same sprite, or any other number of circumstances. I was considering creating some intelligent auto-combining thing to assume if enough similarities (like image used, or bone hierarchy similar) it would automatically make them combined, but the amount of dev time it would have taken would have outweighed the benefits.

However, though the process isn't automated, you can combine them manually very quickly and easily: Simply select multiple objects you want to combine, and and right click the target object and select "combine selected objects with...". The target object is just the one that has the name you want to use for this new combo object. so if you have "head", "head_000", and "head_001", select all of them, you can right click on "head" and select "combine...", and it will combine them into a single head object named "head". Instead of right clicking, you can also save yourself a click by dragging one or more selected objects onto the target object to combine them.

Remember, this is just a one time necessity upon loading a project saved from the previous alpha(which didn't require every object to have a name). With the new version it will just be automatic for the animator. Objects will be automatically given a unique name when you drag new sprites from the file palette, or create new bones. You can double click object names anywhere they appear in the interface(timeline,object palette, z-order list, and hierarchy widget) to rename them. When cloning an animation they will automatically use the same objects. And when you drag an item from the object palette onto the layout, you are dragging an instance of that object. The image you clicked to drag will be the starting image. Also note, that you can only have one instance of an object at a time in a keyframe. You can't have 2 "hand_a"s on the screen at a time. They need to be separate objects.

Link to comment
Share on other sites

Thanks for the in-depth write up lucid - I had no idea about any of that and have been dragging everything from the File Palette thinking that all new objects were instances of that image (ie. only loaded once into vram).

Although this is a 1 time fix (the combine with...), will this need to be done every time a project is saved from 4.1a and loaded into the new version?

I ask as I am still using 4.1a for my game, due to the lack of copy paste in the beta and if I'll have top do it every time I will just leave them until such a time when the beta becomes featured enough to be my main program of use.

The "visor" example - this is not possible from within Spriter yet is it, its just a planned feature?

I have improved the SpriterImporter code for my language to enable me to colour/alpha etc individual body parts, but its not as elegant as having it set from the editor, and then output a nice list of body parts (optional :))

esDotDev: Nice sprites! :)

Link to comment
Share on other sites

Thanks for the in-depth write up lucid - I had no idea about any of that and have been dragging everything from the File Palette thinking that all new objects were instances of that image (ie. only loaded once into vram).

The images are only loaded once into vram even if used in multiple objects. But remember it's not instances of images, it's instances of objects. You can have an object "right hand", that uses "hand.png" on the first frame, "openhand.png" on the second, and peacesignhand.png" on the third. It would always be the same "right hand" sprite object

Although this is a 1 time fix (the combine with...), will this need to be done every time a project is saved from 4.1a and loaded into the new version?
. If you combine and save them with b0, and load back into 4.1a, they should stay combined. Alternatively, you can just name them the same names across all animations in 4.1a(which also has an earlier version of the object palette), and when loaded into b0, things named the same on different animations will be considered the same object. Make sure if you save with b0, use save++ or manually save to a different name since one of the above bug reports has to do with saving.
The "visor" example - this is not possible from within Spriter yet is it, its just a planned feature?
Shader support within Spriter will probably not be coming in the forseeable future, since shader support will be determined on the target platform, and in most cases, shaders available to Spriter won't be the same even across PC,Mac, and Linux, let alone all the target api's and platforms. The "visor" example is meant to illustrate that if you want to use your target platform to make an object clickable, or apply a shader, or apply physics to it, or any other special feature unique to the platform, and not available in Spriter, being guaranteed a unique name for each object is useful. In that sense, it is already implemented Spriter.
I have improved the SpriterImporter code for my language to enable me to colour/alpha etc individual body parts, but its not as elegant as having it set from the editor, and then output a nice list of body parts (optional :))
color and alpha will be coming back on the way to 1.0
Link to comment
Share on other sites

I just had a strange issue, where I had just created a new animation in the animation window and then tried to add an object to the scene. The object didn't appear in the scene, but its name showed up in the Z-order and Hierarchy windows (no image was shown there, though). When selecting the image in the Z-order window, the scene window showed me a big triangle like shape that filled the entire editor window (not sure if this was my object). I also couldn't delete the object. I was able to delete the animation though, but when creating a new one, it showed the same behaviour. It seems to work after reloading the project.

Was the triangle white, or orange by any chance? Not that I know why this would have happened yet, but if it was, it was probably a super wide bone. In try widening a bone to roughly the same size - Alt Click and drag to create and size a bone. Hold Control to access dimension controls for the bone.

Latest build is really shaping up! Great work dudes,

I've uncovered a weird bug in the SCML generation though. Essentially, within the Mainline, spriter is assigning a keyId of the 6, when it should be 2.

In the attached video, you'll see 3 mainline keys(0, 158, 319), but only 2 "footsmall" keys (0, 319). In mainline entry @ 158, for footsmall it's specifying keyId=6, this is the final frame @ 1800ms, instead it should be pointing to the keyId=2, @ 319ms.

https://vimeo.com/62797995

Thanks esDotDev. Is there anyway you can send me the zipped project folder, so I can take a closer look, and debug it while it happens? Also, do you know if this is happening regularly or is it a one time thing? And finally, does the project still load back into Spriter correctly when it does that?

Link to comment
Share on other sites

One more thing guys. I think I mentioned this somewhere else, but I still can't get it to crash. If anyone else has crashing issues, please give me any additional info you have, and even better, if it crashes frequently, catch a crash on a screencap, so I can see if there's something unique to your workflow that's causing it.

3/27/2013 - 18:18

Fixed a bug that left a 'ghost' object in the canvas if you dragged something through the canvas, and then tried to drop it in another window

Link to comment
Share on other sites

A friend of mine and I have crash issues all the time. The circumstances always seem to be different, though.

Was the triangle white, or orange by any chance? Not that I know why this would have happened yet, but if it was, it was probably a super wide bone. In try widening a bone to roughly the same size - Alt Click and drag to create and size a bone. Hold Control to access dimension controls for the bone.

It looked grey-ish, so it could have been one of the bones.

EDIT: I recorded a video of a crash happening. I had some serious performance issues using the recording program, though. The mouse jumping around and the gui sometimes not reacting stems from that.

You'll probably need the lossless codec from here to be able to view the video.

Here you can download the video

I used Windows 7 64-bit in that case.

Link to comment
Share on other sites

Great plugin an update!

This is a problem with the Construct 2 implementation. My guess is that it doesn't like the new individual timelines--I can use older SCML files that had every object changing on every keyframe and they work. But an object that has the legs move differently from the rest, for instance, the object positions glitch all over the place and the animation doesn't seem to play all the way through. I was also not having a finishing keyframe at the end of the loop (since it would just animated back to the origin point), but this seems to cause issues, too. There's a definite problem any time that an object is not referenced with a little dot on the starting keyframe of the animation. I hope an update can make it more flexible, and I can PM a zip of my file and objects if you need.

Link to comment
Share on other sites

I first thought that that was a duplicate key bug (that's why I was messing around with the mouse), but if you look closer you see that it actually is the last selected keyframe that moved to that position. This might have happened due to performance issues because of the recording.

As far as I can recall, it crashed in the following situations so far:

1. Manipulating a bone

2. Using undo

3. Deleting a keyframe

4. Moving a keyframe

The error message provided by Windows always looks the same, but I was never able to reproduce it. I can do more videos, if you want to.

If I had recorded the whole session (which was about ~5 minutes longer), I might be able to just redo all the steps in order to reproduce it.

Link to comment
Share on other sites

yes pfaeff, thank you. Especially helpful if you can record the video with the history window showing so we can try to find what they have in common near the end if anything. Will be trying to test with lots of what you just mentioned to see if it crashes over here

Link to comment
Share on other sites

I just hit the stop recording button, because I thought, I won't get it to crash. Immediately after that, I created a new project in the same directory. The history was still there, so I clicked on the ""-entry and it crashed.

The "dragging an object onto the Z-order window"*-bug is guaranteed to trigger that kind of crash, though.

*Simply drag an object from the file palette to the Z-order window and then delete it.

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.

×
×
  • Create New...