Inform me!

This is more of a general wish than a special feature request.

Don't let Construct just ignore my instructions!

If something can't be done I want to be informed. But with the size of a project growing also a deviant behavior occurs more and more. Some things are just ignored. No error message, no crashing, nothing but just not executing an action. Posting something like this to the tracker wouldn't help much, as the occurences are like random. Here are two examples from a quite complex project:

(A) The ballad of the cursed Tempo Display

I was working on a Tempo Display. The user may click on the panel thus making it editable. Keyboard input then is converted to a value which is stored in 's'. By hitting 'enter' this value is used to display the new Tempo by switching frames of a sprite.

<img src="http://www.mediafire.com/imgbnc.php/d8d9d39158415446cb2a0c053f3c56352g.jpg"><img src="http://www.mediafire.com/imgbnc.php/f6db1d67ee0cca0f4872f59d6914d40b2g.jpg">

I1: The Tempo Display

It was one of the first things I implemented after the core engine, and it worked like a charm. I was working for almost a week on other parts of the project, and one day the Tempo Display suddenly didn't work correctly anymore. The frames were still updated during editing, but as soon as hitting 'enter' the old value was shown. I first thought that I messed it up unintentionally and looked at the code. But everything was as always, no change at all. Even more, if I used a textbox instead of the font sprites, it worked as intended.

<img src="http://www1.mediafire.com/imgbnc.php/449cd1f396a87babdcfb232f795cd31e6g.jpg">

I2: One Event of the Tempo Display with the action that is igored

For days I tried to get this working as it worked before but had no luck. Then, totally desperate, I thought:

"Well, this is ridiculous, but what if Construct had not enough time to do all of the instructions within a tick. But instead of doing it the next tick then, it just ignores the instruction?"

I know, it seems like nonsense, like a delusion of a tired out man smoking to much, but nevertheless I gave this idea a chance. I changed the code accordingly...and it worked! Unexplainable. And you have to find the clue without any help from Construct.

<img src="http://www1.mediafire.com/imgbnc.php/4b1b66bc18972aa04187b5140763bb9c6g.jpg">

I3: The same event of the Tempo Display with the action working

(B) The jinxed Position Display

At least I found a workaround for the Tempo Display. That's more than I can say about this one. This time, a Position Display shows the musical positon while music is playing. No user input implemented yet. Every musical tick a position value is updated, converted to a special format and finally shown in the display.

<img src="http://www1.mediafire.com/imgbnc.php/4a8cd42c6cb1e32a23f48569ed45d37c6g.jpg"><img src="http://www3.mediafire.com/imgbnc.php/cb289bc83581a9a0bc648034b917a8aa6g.jpg">

I4: The Position Display

Again, it worked. Unfortunately I embedded the code for the conversion directly in the event that is responsible for the display. But I need it to be seperate because the conversion is done in other situations, too. Well, I changed the positions of some events (and not the content) and called the events seperately. For the life of me I can't figure out, why it's happening, but the last two digits now get ignored (and only them). Again, when using text boxes it works, just not with the sprites.

<img src="http://www2.mediafire.com/imgbnc.php/7c340ff94d668ec0c7491ae69326ed556g.jpg"><img src="http://www1.mediafire.com/imgbnc.php/4adee969f4dca5855dd9d8dd67e538f26g.jpg">

I5: The Position Display with the last digits never updated

It's not the order of events. I tried several combinations (even reversed order) and it always resulted in the last two digits not being updated. I could isolate it to the one event responsible for displaying the digits.

<img src="http://www4.mediafire.com/imgbnc.php/fdcb8204611250f07482303f28bb3aa26g.jpg">

I6: The event for the Position Display

<img src="http://www.mediafire.com/imgbnc.php/46e926f9ba18c461a5af98afd7567be66g.jpg">

I7: The event for the Position Display like it is not working

Again, there is no feedback from Construct. It just ignores my instructions. So let me please repeat my wish from the beginning of this post:

Don't let Construct just ignore my instructions!

Thank you

This.

[quote:m4qlry1k]"Well, this is ridiculous, but what if Construct had not enough time to do all of the instructions within a tick. But instead of doing it the next tick then, it just ignores the instruction?"

Pretty sure a function within a function will be another tick. In fact I often use "call function after delay" because it takes another tick to retrieve something from the gpu. Probably the same sort of thing happening with the font thing as well.

Pretty sure a function within a function will be another tick. In fact I often use "call function after delay" because it takes another tick to retrieve something from the gpu. Probably the same sort of thing happening with the font thing as well.

Please believe me, If it were that easy I never would have created the post. It is more than this. You can't rely on something working, because a few days later the same code without changes suddenly doesn't work anymore.

Besides, we shouldn't be forced to wildly guess when to use a delay of a function. Construct should handle it automatically or at least give a error message.

The examples show the randomness of the problem and that is contra-productive. If it were a matter of delaying a function, then why the heck are 6 of 8 instances of a sprite correctly updated while the other two are simply ignored? No matter what you change.

No, if there are problems for Construct executing something I need feedback about it to handle it.

You should probably upload an example. There's no way to tell if this is v-synced, or how to tell how your updating function parameters.

But honestly I just don't think you can get the precision your wanting in a tick based system.

All I can say is you cant count on having precision down to less than 10 milliseconds, and when it comes down to timedelta that will make a big diference, and even if you get the timing right on your system, it could vary wildly on others.

One thing I could suggest is using some sort of interpolation, or percentage to set your animation.

You should probably upload an example. There's no way to tell if this is v-synced, or how to tell how your updating function parameters.

But honestly I just don't think you can get the precision your wanting in a tick based system.

All I can say is you cant count on having precision down to less than 10 milliseconds, and when it comes down to timedelta that will make a big diference, and even if you get the timing right on your system, it could vary wildly on others.

One thing I could suggest is using some sort of interpolation, or percentage to set your animation.

I'm afraid I was misunderstood completely. Maybe I'm explaining it wrong or my language skills are not sufficient. Sorry for that.

The music engine has its own timing, independent of the UI one.

I don't care about or need timing precision with the user interface of my app. On the contrary, I rely on the fact that I can change a sprite's animation frame whenever I want to, not at a specific time. It doesn't need to be changed on a special tick, it can be updated a few ticks later, even updating it a second later is ok. But I need it to be changed at all

I still see no logic in the circumstance that one calls a function and the sprite's frames are changed within this function, and just because your project grows in size you have to delay the very same function a week later to make it work again. Besides, it is still working without delaying it, just the sprite's frames are not changed. Text boxes changed within this function work, as an example.

According to that logic, I guess I need to raise the delay time as soon as my project grows by a certain size again. IMHO that's not acceptable.

Last but not least: The problems occur with whatever you do or use. It doesn't matter if you use v-synced or unlimited mode (delaying it by TimeDelta makes the Time Display work under both modes and not delaying it makes it not working under both modes) Also, order of events don't count for this particular problem.

[quote:1efw3har]According to that logic, I guess I need to raise the delay time as soon as my project grows by a certain size again. IMHO that's not acceptable.

I think you kind of answered yourself there. As a project grows, or with more stuff you have going on, you have a greater chance of frame skip. That means that even though the music stuff is being preformed correctly, there's a chance that if it does get bogged down the graphics side may not get updated. Of course in unlimited mode, or with proper use of timedelta that shouldn't happen. Once I figure out which S your using I'll see if there's not some sort of solution.

Thank you.

I sent you a pm, but I'm afraid you're thinking too complex. The frames are not updated every Construct tick but only in certain situations and only once then. Would be a remarkable coincidence if the processor load would be too high at exactly those moments repeatingly. But I am fond letting you proof me wrong

Perhaps its something to do with frames?

Frames are 1 based so if you use 0 it wont work, now you have +1 on the end of your action, and int()to ensure a whole number, but I haven't found where your assigning the return value for the function yet, and I have no idea what mid()means.

+ Font: Value 'Digit' Equal to 1
-> Font: Set animation frame to int(mid(Function.CurrentUITick, 2, 1)) + 1
[/code:21pwo90d]

Perhaps its something to do with frames?

Frames are 1 based so if you use 0 it wont work, now you have +1 on the end of your action, and int()to ensure a whole number, but I haven't found where your assigning the return value for the function yet, and I have no idea what mid()means.

+ Font: Value 'Digit' Equal to 1
-> Font: Set animation frame to int(mid(Function.CurrentUITick, 2, 1)) + 1
[/code:dbxoganm]

Yes they are 1 based and I make sure not to call zero

The trick is easy but effective. The musical tick is a value in different ranges, depending on the time signature the user selects. With 4/4 it's a value from 0 to 3, with 16/16 it's from 0 to 15.

To represent this value I use two sprite instances, one for the ten's place and one for the unit place. To get these the number is converted to a zero-padded string, thus getting "01" instead of 1 or "16" instead of 16.

CurrentUITick returns this string. the mid function looks at a string and creates a substring beginning at position with length number of letters. So mid(string, 2, 1) returns the substring with a length of 1 beginning at position 2. If CurrentUITick returns "08" then mid("08", 2, 1) returns "8".

This is converted to a number (int) and the frame number representing the number 8 is 9, so +1 is added (if the returned value were "0" the frame number would be set to 1 etc.)

EDIT: You don't need to create a variable to hold the return value of the function. You are allowed to call the function directly within an expression. Have a look at the wiki:

http://sourceforge.net/apps/mediawiki/construct/index.php?title=Function_Object

From looking at your screenshots you are using functions for all your changes. Functions are triggers outside of the eventsheet so they shouldn't be affected by tick speed issued. Every time a trigger is called is should work every time instantly perfectly, but maybe newt is right that because the functions work this way, the function is called and mid event execution the frames might be going out of sync. Is your cpu to gpu ratio low?. Functions haven't been explored by the community enough so people are bound to expereience there issuess. I always found functions calling ofther functions buggy in the past with crashes and such so at least the new builds aren't crashing on you.

Either way, I agree you definately need more information to be able to avoid this. It looks like the type of app you want to make would combersome without more info.

Could you give some more directions on how to get the error? The only time it does not update the tens position is when I go over 08/08 in the time signature. That would be almost on track, if there is only one note per measure.

Could you give some more directions on how to get the error? The only time it does not update the tens position is when I go over 08/08 in the time signature. That would be almost on track, if there is only one note per measure.

You should have had the error already. To clear it: The position display is 1 based, as long as you never see "00" or "000" it means there is no problem. The error is not updating the frames at all, they stay at their default frames (which is frame 1, "0"). And that wouldn't surprise me, it proofs once more the randomness I'm talking about. Would you do me a favor and switch every delayed function call of the tempo display to normal calls and see if it works correctly?

No change, but as far as I can tell it seems to work. I mean the frames change as long as I don't go over 08/08. Also I don't know that would have changed anything anyways. It was set to call the function after timedelta, and that can be way sooner than 10 ms.

Sorry tulamide, but it looks to me that function is working correctly, and the only conclusion I have is that something is messed up in the conversion.

No change, but as far as I can tell it seems to work. I mean the frames change as long as I don't go over 08/08. Also I don't know that would have changed anything anyways. It was set to call the function after timedelta, and that can be way sooner than 10 ms.

Sorry tulamide, but it looks to me that function is working correctly, and the only conclusion I have is that something is messed up in the conversion.

I think you don't see the real problem here. See my previous posts.

1) Of course it was set to call after timedelta, because that made the function (better said: updating the sprites) work again. Directly calling it didn't work (and does still not on my computer). So you proofed that it sometimes works (on your computer for example) and sometimes not. And there is no feedback if the sprites are not updated. That leads to

2) It's not the function itself that isn't working. It's just updating the sprite's frames that does not work. I wrote in a previous post that I can output the values of the function to text boxes. That works absolutely correct (incl. the values)

3) The 10 ms are not of interest, because the function calls are independent from the music sytem. I can call updating the sprite's frames as often as I like, they should show the current value, whatever it is at that point of time.

4) The sprite's frames are also updated above 8/8, you just don't see a difference. The reason is the system behind the presentation of the values. The time signature describes how many beats of what note value are in each measure. The first value tells the number of beats, the second the note value. 4/4 means four quarter notes, 6/8 six eighth notes, etc. The length of an eighths note equals the length of 2 sixteenth notes, the length of a quarter note equals the length of 2 eighth notes etc. So a beat with a note value of quarter may contain 4 sixteenth notes, whereas a beat with the note value sixteenth only contains 1 sixteenth. The position display shows (from left to right) Bar (or measure), Beat and Sixteenth. 1.1.1 means first bar, first beat, first sixteenth. 4.2.3 means fourth bar, second beat, third sixteenth. Now, when setting something like 10/16 for the time signature, the position display would go 1.1.1, 1.2.1, 1.3.1 ... 1.10.1, 2.1.1, 2.2.1 etc, because there only is one sixteenth position in the beat. That's why it stays at one. The error on the other hand does not sometimes not update the frame, but never. Never. The display then always shows "00" no matter what.

We won't solve this I'm afraid, but I appreciate your help. It was very kind and helped me seeing that the error has a kind of random nature, it seems to be associated to the hardware the app is run on or a special subversion of DirectX.

Thank you very much newt

I may have run into a similar kind of error as yours using functions.

I worked around it using what is probably a dirty trick, but it works beautifully. Instead of calling the function directly, I have a global (or holder sprite) variable set and then use that to trigger a new function next tick. My problem was with Selected Object Lists causing hassles. It wasn't something that could be fixed with "Forget objects", and I can't remember exactly why now, only that it worked. :p

SomeEvent: Action: Do stuff, set global variable Schedule_SomeFunction=1

Always

Schedule_SomeFunction=1: Call Function "SomeFunction"; Set Schedule_SomeFunction=0

Alternatively, a variable holder sprite/box can handle all the private variables and won't clog up your app/game with globals.