Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - oripessach

Pages: 1 ... 9 10 11
Sorry - I don't get that anymore, and I'm not sure what I did back in December to make the problem go away. I may have cleaned my game, or started from scratch.

I get a modal dialog that shows this message:

Unexpected problem on thread pool-2-thread-4: InputStream cannot be null
java.lang.IllegalArgumentException: InputStream cannot be null
   at javax.xml.parsers.DocumentBuilder.parse(
   at stencyl.sw.util.FileHelper.readXMLFromStream(
   at stencyl.sw.editors.snippet.designer.EditArea.<init>(
   at stencyl.sw.editors.snippet.designer.EditArea.XMLToCode(
   at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(
   at java.util.concurrent.ThreadPoolExecutor$

Ask a Question / Re: "90% Memory Usage" Message is back
« on: December 03, 2014, 11:15:00 pm »
I'm pretty sure that Stencyl is leaking memory. I have one game that I always get 90% memory warnings with, no matter what I do. I just need to load the game and click test a few times (downloading it to an Android device.) Takes a few minutes.

I can also reliably get a memory warning just loading and closing a scene, repeatedly. I can see the process size increasing until the warning starts showing up.

It's a bug. Fix it.

Archives / Re: Version control / Source control
« on: October 18, 2014, 11:00:34 am »
Any updates on this?

At the very least, some guidance on which directories need to be checked in and which ones contain only generated files will be greatly appreciated. Even if the code isn't ready for parallel development yet, version control is extremely important even for a single developer. I've seen enough users posting about not being able to load their projects to worry about not being able to easily roll back to a previous version.

Completed / Re: Feature request: Time stamps in logs
« on: August 07, 2014, 09:55:54 am »
Awesome. I know this is an obnoxious question to ask, but what's the ETA for 3.2?

This is what the documentation on github has to say about the game loop:

"Here's the order in which things execute within one STEP of the game loop.

Update Tweens
Mark physics objects as on/off screen
Update Mouse / Trigger Mouse Events
Update / Trigger Timed Tasks (do later, do every N seconds)
Update Keyboard / Trigger Keyboard Events
Native Mobile Events
Update Physics
Update Regions
Synchronize Animations
Update Actors
Update Animated Tiles
Update Transitions
Update Camera
Poll Input (Mouse, Keyboard)"

This is not how things are actually done, apparently. I was able to fix my problem by moving the call to invokeListeners2() from where it currently is, right after the code to handle native mobile events, to right before the call to draw() in postUpdate.  This is all done in com/stencyl/Engine.hx, by the way.

Specifically, I think the problem is that updating tweens is done a lot later in the game loop than the above quote from the engine documentation claims that it happens. This is what's causing the problem. I think there are other discrepancies between the documentation and the code, but they haven't caused me any problems. My testing is in no way exhaustive, though.

Completed / Re: Feature request: Time stamps in logs
« on: July 02, 2014, 09:20:14 pm »
Cool - thanks for the pointers.

Thanks for the answer.

Like I said, the first actor is moving using a moveTo() method, which means that I don't have ready access to the place in the code where the actor moves itself. The engine is moving the actor. I suppose I could rework the code so that the first actor's "updated" event modifies the second actor's coordinates, but my understanding is that all the "updated" events are supposed to run together, and not be separated by frame redraws. Is this correct? Even if it is, the engine appears to have its own ideas on when actors' coordinates should be changed, and it seems to happen separately from when the "updated" events run. Otherwise, there wouldn't be a visible lag between when one actor is moved by the engine and when the other actor is moved by my code.

If anyone with knowledge of how the engine handles "updated" events can chime in, I would really appreciate it. Right now my best guess is that the "updated" events run before the engine has a chance to deal with tweens, which would definitely cause this problem, and which I would consider an engine bug - or at least a misfeature...

Completed / Re: Feature request: Time stamps in logs
« on: July 02, 2014, 08:38:29 pm »
 I suppose I could, but then again, log timestamps are a pretty standard feature of debug log libraries, and there's a good reason why that is so - they make debugging timing issues a lot easier, and in some cases, they make debugging those issues at all possible.

Besides, if Stencyl has a block to get the current time, I haven't been able to find it. :)

I have an actor that's being moved using a slide block (actually, a call to moveTo() in a code block) and another actor that's attached to it using a separate actor behavior (in the attached actor) that sets the second actor's (x, y) coordinates to the first actor's coordinates, in the "updated" event.

This works, mostly, but the second object seems to drag a bit (by a pixel/frame) behind the first object. I would like the two actors to move together, with no visible drag.

Is this the expected behavior? If it is, is there another way of achieving the same effect? I believe the documentation called the problem I'm trying to solve "the Zelda problem." At this point, I can think of a few other, less polite names to call it...

Completed / Feature request: Time stamps in logs
« on: June 30, 2014, 10:10:31 am »
Some types of bugs are unnecessarily difficult to figure out without sub-second time stamps in the debug log. Anything that's timing related, in particular. It would be helpful if the standard trace() logs included a time stamp.

Resolved Questions / Re: Very odd TimedTask behavior
« on: June 29, 2014, 02:43:44 pm »
You're right - that is weird. And not an engine problem, as it turns out. It seems like dereferencing a null object has some unpredictable and amusing effects, and invoking random callbacks is probably the least of your worries if you do that. :)

So this one was a bug in my code - a null reference.

However, while debugging this issue I realized that the part of the engine that deals with TimedTask instances is potentially fragile. It looks as if it can handle new tasks being added in timer callbacks, but if a timer callback ever calls removeTask, bad things will happen. It's usually good practice to break down this kind of operations into two parts: The first loops through the tasks and adds any tasks that need handling into a temporary array, and the second part iterates over the temporary array, calling all the update() methods and removing any tasks that need to be removed.

Resolved Questions / Very odd TimedTask behavior
« on: June 28, 2014, 10:07:56 pm »
I'm having a problem with a TimedTask that's set to run every 5 seconds, but occasionally decides to run every 10 ms, instead. I poked around in the engine source and found that the timer member of the TimedTask instance reaches zero, and then -10, -20, etc. etc.

What's more, doExecute() doesn't seem to return to the update() method. I tried modifying TimedTask.hx to catch exceptions around doExecute(),  but that didn't make a difference - doExecute() just seems to somehow quit without returning, although I'm pretty sure that can't (and probably doesn't) actually happen.

Any ideas what's happening here?

Having recently spent 3 days refactoring a trivial amount of code, it became clear that Stencyl needs a way of quickly packaging a scene's (or actor's) events as a behavior. Copying and pasting individual custom blocks and events doesn't really do the trick, since any calls to custom blocks are not modified to make the call relative to the new behavior.

Suggestion Archives / Feature request - resize code blocks
« on: June 20, 2014, 08:15:59 pm »
The size limitation on code blocks makes editing non-trivial code very difficult. I find the width especially troublesome - the default tab width in a code block is 5 characters, so editing nested blocks becomes very difficult very quickly.

It would be nice to be able to either enlarge the code block dynamically for easier editing, or to use an external editor without having to cut and paste the whole method after each edit.

Pages: 1 ... 9 10 11