Tulamide's pretty much nailed it, but even I got confused reading the second last paragraph.

Images are stored with a fixed amount of pixels - eg. 512x512, and that takes up a certain amount of space (format, compression etc).

When it comes to printing, and the dpi/ppi (dots/pixels per inch) is relative to physical size on paper. Monitors are fixed at either 72 or 96 dpi (I'm not certain which). Either way, it doesn't matter on screen because everything is measured in absolute pixels, regardless of resolution or screen size. 512x512 on a 36" monster screen will be physically larger than 512x512 on a cheap 14" LCD.

Paper is a different story, because it doesn't have pixels, rather it has cm/inches. Most printers will do 300dpi at least, but 600 and 1200 dpi aren't uncommon, particularly in laser printers. What happens is your 512x512 image is upsampled to 300/600/1200 dpi by the print driver. Ie. it stretches that 512x512 to 2135x2135 (300 dpi), or 4264x4264 (600dpi).

This is why printing jpgs from the Internet makes them look jaggy and terrible, because they're upscaled so much.

That's probably worth submitting as a bug, including the solution you found. That way they can patch it up.

There is a wait object that can put a delay into actions. It depends if you are trying to simply delay something within the action, or if you want it paused indefinitely.

To delay an action:

On <some condition>

--Do: create sprite1 at x,y

------ play sound "somesound.wav"

------ wait 2,000 ms

------ change animation to "DoneTaunting"

If you want the action paused indefinitely, then I have no idea how you might do that. I would look at using some kind of toggle condition rather than trying to switch at the action level. Something like:

Is global('Something') = 1

--Do: Set global('something') = 0

If you don't set it 0 immediately, then this action will repeat every tick (unless that's what you want it to do).

---- do other things

On SomeOtherCondition

--Do: set global('Something') = 1

Note:

I've found that wait acts strangely in loops. What I *think* is happening, is that each iteration of the loop starts another wait cycle in parallel, effectively nullifying it.

If I did:

ON SomeEvent

--Repeat 12 times

------- spawn an object

------- play a sound

------ wait 1000ms

I find that all 12 appear instantly, and all the sounds play seemingly at once. It's as though 12 'waits' are created simultaneously.

Ok so what I think you're trying to do is add speech samples to supplement the text.

So:

(I'm using example paths and so on, but just substitute for your data structure).

On start of period "blah1"

Xaudio2 autoplay file "Audio\Speech\NPC\bob_blah1.wav"

Play the sound file.

Set Variable_Holder_SpriteObject.value('Last_Speech") to xaudio.lastplayed

This saves the number of the last channel in a variable holder object, substitute with a global if that's your preference. This is so that you can stop the specific sound playing if the player skips this line of dialogue.

Dialog_text write "What began as a conflict over the transfer of consciousness from mind to machine would escalate into a war that would span over 4,000 years, and destroy thousands of worlds"

Type the actual dialogue into the text box. Adjust speed to match your sound file.

On end of period "blah 1"

Xaudio stop channel Variable_Holder_SpriteObject.value('Last_Speech')

On start of period "blah2"

rinse, lather, repeat.

fixed

I just found a major snafu that has been there since probably around the time I started using Construct, as I found it way back in my backups from weeks ago. (I've only been using construct about 1-2 months). It was probably the result of me experimenting with Construct itself, before I had any idea how some features work.

The idea for this thread is to create a reference of silly mistakes that will probably help others, and will be a general source of amusement also.

Here are some of my bonehead mistakes:

Put the keyboard/mouse object as a container with another object. For months I thought it Construct was tying player control to the first created controllable object. I made all kinds of work arounds to keep that object alive so that keyboard controls would still be there on the next run. *facepalm*

(the problem here is that when the object is destroyed, the keyboard/mouse object is also destroyed due to the container behaviour - and hence no kb/m control).

Somehow managed to put random(50) into the initial value of a private variable. This crashed the hell out of Construct but ONLY after I'd uncovered and fixed another bug that was essentially suppressing this.

Inappropriate use of 'while's

Never use while, unless you ABSOLUTELY understand exactly what it does and why it's there.

Granted though, I was experimenting mostly but I found one in there that was eating a lot of CPU time and causing issues because I'd forgotten about it. Removing it had no effect on the behaviour of the items but freed up quite a bit of CPU time.

Post your own crazy Construct screwups.

It certainly is, but you'll need to be a lot more specific for anyone to be able to help you.

That makes sense. If you use "get angle between point A and Point B" (and then rotate the result 180� so that it's the opposite direction) and then apply force, you should have a radial push outwards.

There is already a warning when you remove a global variable. It states "any events tied to this variable will be removed"

On any moderately complex event sheet it's going to be quite difficult to definitively find where that might be, and sometimes the search doesn't quite catch everything.

It would be nice to have a list of events/actions/expressions that are tied to that variable presented when deleting.

Eg.

Global('MyVar') is used in:

Line 44 - if Myvar = 10 set text "You're FANTASTIC player!"

Line 230 - (Always) set myvar = 5

I used to do that too until I read the wiki page on optimising.

My project is usually at about 70-80% CPU waiting, so as the tutorial explains, improving CPU efficiency in events isn't going to amount to anything.

This sort of problem is better left to the pros, I surmised .

I've made any number of bonehead mistakes that boil down to one simple logic problem like that.

It would have been better to leave your original post in so that others can make use of your newfound wisdom.