Thank you so much Davioware.

That worked like a charm. However, I am afraid that I have some bad news. I originally had the SPACE Bar set to pause the animation, and the F1 Key to resume it. However when I use these controls, their said commands do not happen.

Now I had played around w/those controls, and still, the same thing occurs.

What am I doing wrong? Any help is always appreciated.

Thanks again.

- Chris

Sounds like you were just stopping a normal animation before, and didn't change that to work with your new random animations.

If you are doing a simple 'Every X milliseconds, set animation frame ...' to animate the squares, then you cannot stop it like you can a normal animation. You should make a global variable to flag whether the squares should animate or not, then only change the frame if it is true.

Something like so:

On SPACE key pressed : set global variable 'FlashSquares' to 0

On F1 key pressed : set global variable 'FlashSquares' to 1

Global variable 'FlashSquares' equals 1

Every 100 milliseconds : set the animation frame randomly...

The height of the enemy, player and collisions is 32px. Does anyone know technical details of the line of sight behaviour?

I do know it's a bit quirky from when I attempted to use it for a roguelike top-down dungeon view. It would detect one side of a corridor that the character was in, but not the other. Quite vexing. I even tried centering the hotspots perfectly by making 31px objects instead of 32. Gave up on it eventually. That said, I think it should work fine for this.

What did you mean by 'collisions is 32px'?

Anyway, the one big variable that I noticed was the accuracy attribute of LOS. If the LineOfSight accuracy is set to 10 or below, it should work fine. I did a test of a similar setup, and it performed poorly with larger accuracy numbers, though.

Interesting topic. I have a 60 Hz display.

I tried the original, and it performed poorly for me most of the time.

In the second version, success rates seemed higher, but still not consistent.

The Timedelta override version was perfect every time for me.

The other thing that I noticed was that the 2nd and 3rd versions were a bit choppy on the side-scrolling.

I've never tried full screen with an editbox until now, and I see it doesn't work correctly.

I would guess that it doesn't work well because full screen uses DirectX to display, and it doesn't play well with Windows API. I don't know...

I don't see a way to fix that, other than not using full screen.

Perhaps you can use the Text object, or SpriteFont Plugin to do the display portion instead of the EditBox. If input is needed, there is an Input plugin in the WIP plugins forum that could be used for that. I'm sure that it's possible to emulate an EditBox.

The EditBox is a Windows object, so it does not behave like most other Construct objects do, such as sprites.

I'm not aware of any way to change any of the things that you have mentioned, other than the position and size of it.

I don't think that there is a 'On window resized' condition, but you could store the current size at start of layout in a couple of global variables, and compare those against the current size each tick, then resize the EditBox based upon the change if they are different. Then set the stored size to the current size...

The System object has expressions under it's Display category for the display size, and the Window object has similar expressions for window size.

Hi. In my experience, those options just make it so that the text contained by the EditBox can be larger than the box itself.

If you're looking to make it scroll so that you can see text that has been added to the EditBox through events, you can use the EditBox's Set Selection action to force it to show any area in the text.

The following simple example would add the amount of time that the application has been running in a new line each time the LMB is pressed, then set a null-selection the end of the text.

+ MouseKeyboard: On Left mouse button Clicked

-> EditBox: Append text Timer & NewLine

-> EditBox: Select characters len(EditBox.Text) to len(EditBox.Text)

Thanks for the example, I was looking for something like it.

Can you show me how to change the script to use double digit numbers?

That's actually pretty simple. The .split() method does that nicely. Then I just convert the string values to integers.

Change this:

l.append([int(i) for i in j if not i.isspace()])

to this:

l.append([int(i) for i in j.split()])

But, as R0J0hound pointed out with his example, parsing the text in Construct can be quite simple. It works much the same way, as well.

Reading it in from a file should be pretty simple, though I've never done it. It looks as if an EditBox, or the Binary object can do it. Probably other ways, too.

Hi. 'On a certain button clicked' type events will be true throughout the event sheet for the tick that it is true for that button, so all of those will execute in order.

Arranging them like so should work, assuming that 'ChoiceA' is zero by default:

On clicked Button:
      Value "ChoiceA" equal to 0
            a.Write Text
            b. Button.Set"ChoiceA" to 1
      Else
      Value "ChoiceA" equal to 1
            a.Write second Text
            b.Button.Set"ChoiceA" to 2
      Else
      Value"ChoiceA" equal to 2
            a.Write third Text[/code:11fyr41t]

Then you may need to reset 'ChoiceA' to zero or something that doesn't apply to those conditions, afterward, depending upon your needs.

All of the 'ChoiceA' tests are sub-events of the 'clicked button' event, and the Else conditions make sure that only one is true per tick.

Tulamide made a nice tutorial on that subject a while back: [url=http://www.scirra.com/forum/viewtopic.php?f=8&t=6880]Introduction to branching[/url].

That may help clear up the event logic for you.

For most behaviors, the object's direction is it's angle property, which defaults to zero (which is right.)

Beyond that, you can make objects move in move in other ways, too, in which case you may want to store the direction in a private variable for the object. Picking a random direction can be set up with simple events, using the system random() expression.

For your first problem, the usual method is to add the BB objects into two different families. That will allow you to pick two differing instances by family. Say you're using green and red family names:

For each paired entity, pick it's green

If green overlaps red

If red is moveable

>> Have green and red push each other in opposite directions

> If red is static

>> Have the green completely push itself out of red

... it's assuming that green is moveable ... also, the 'for each' should be literal, to be clear. There is a condition for that.

As for the other two questions, I've not used these ideas, but these two threads may help a bit:

.

Hi. It's really difficult to pinpoint these types of problems without being able to see the events, but I'll throw a couple of ideas out...

It sounds as if the logic is flawed. Go through the events, thinking of them in sort of a flowchart way, and see if whatever state variables/conditions you're using actually keep the state from advancing to the next step until the proper user input is had. For instance, if you used a variable to temporarily signal a transition, then you'd usually need to set it back to zero/off upon that transition, so that it won't go to the next immediately.

Also, make sure that you are using a 'button clicked' condition, and not a 'button down' condition. That's a common mistake.

Not sure what else may cause your problem.

[quote:37w7yvur]i want var ShieldsCurrent value to be downgraded to ShieldsTotal value. so you know, whenever it goes over ShieldsTotal var value it is fixed down.

In that case, it's always better to simply not allow that to happen. You can either test it first, then only set it if it will remain valid, or clamp it's value while setting it.

I made a simple example .cap (with Construct v0.99.96) that shows a bit of dealing with percentages, clamping values, and testing for ranges.

http://dl.dropbox.com/u/5868916/irbis1.cap

Good luck.