What version of Construct are you using? There were some fixes for 3D Box in the 99.82 build that may solve your issue.

Yep:

<img src="http://dl.dropbox.com/u/529356/newsquares.PNG">

But I also have David's 0.83 fixes for new shaders and stuff. That's probably why it's not working for Genesys. You're probably just going to have to wait for 0.83 to come out

I'm not sure of any way to do that currently. I believe it would require a HingeForce expression to be added to Construct, if that's even possible with the Box2D engine. Physics definitely needs to be fleshed out a bit more in terms of features.

In all honesty I don't even think the Hinge Stiffness setting even does anything...

You might just have to settle with faking it by getting the force of objects hitting your hinge, or by measuring the angle between your hinged objects. Unless there's something I'm missing and some clever Constructor can pop in and correct me...

I can't confirm 82's weirdness because I don't have vanilla 82 installed and I don't want to go through the hassle of installing a second copy, but it seems to work fine for me in the 83 runtime if that's any consolation v<img src="http://www.scirra.com/forum/images/smilies/icon_confused.gif">v

There were a lot platform fixes in 99.7 that affected acceleration, speed, jumping, sustain, and whatnot so you may just need to recalibrate your speed and gravity settings in the newer build. Yeah, I know it's a pain having to do that again, but it's better than not having bugs fixed

I made a custom editbox example a while ago(just now posted it in the uploads section) that you could check out:

Custom Edit Box Example

That's a clever solution

Stuff

That's... a rather extreme method of doing things. And not something that I would recommend for the average game.

Jut keep your game tidy and optimized. If you have a very large game then you may want to look into loading graphics at runtime and using a level editor to make map files that you can also load at runtime. That will keep your .exe nice and trim.

Also, giving platform behavior to a box crashes the runtime O_o didn't happen before. (this in 972)

Hmm... it doesn't seem to be a problem in 0.99.82. Or .83 I guess.

I see. But on a similar note, you could have the player enter his name on the first screen, and save the name he enters in an .ini. Then when the game runs again, it will put that name into the box for you so you don't have to enter it every time, or the player can change the name if he wishes.

Either way, when the player does get a high score it could automatically have his name associated with it. This would also keep the player from entering his name repeatedly if he keeps getting a high score on different tracks.

IMO it just makes more sense to me to input your name on the player select screen.

At first I couldn't tell what you're talking about because it was running perfectly fine for me. Then I opened it in 0.99.62 and yeah, I see what you mean. Rest assured this is fixed in a future build. I'm using the 0.99.83 Platform runtime and it works fine.

You can safely continue working on your game in the knowledge that it will behas been fixed. Keep in mind that something else might break between .62 and .8x, so upgrading to 0.99.82 now is probably a good idea.

I don't know about Game Maker or what they're using for their buttons and input boxes, but I have a feeling that it's not the Windows control API which is what Construct is using. As in... it's Windows.

So yes, you may want to have a separate layout if you really can't be bothered to make your own button.

Also, why are you having the player enter his name at the end of each race? Shouldn't he be entering his name on the previous screen when he's picking his car? Then you can just use a simple text object to show the player's name, and it can sit anywhere on the screen you like.

Are you using a hitbox for your player or do you just have Platform movement set to your player with per-pixel collision?

Also, it would be easier to see what's going wrong if you posted a .cap.

Under normal circumstances, yes the game will be just one .exe file. You can however load sounds and graphics at runtime from folders if you like.

Also, there is really no set file size limit. Obviously you need to keep in mind system limitations, and whether or not someone is going to be willing to download a 130MB game, etc. You may want to check into some optimization:

• Don't import large graphics if you're just going to scale them down in-game. Import everything at 1:1 ratio
• Trim any excess from around the edges of your images. Also keep in mind the power-up rule... if your image isn't sized at a power of 2 then it's going to be scaled up in VRAM. If you have a 34x36 sprite, it's going to be taking up 64x64 in VRAM... so perhaps you could find a way to just redraw that sprite at 32x32?
• Compress your sounds! A lot of people skip this one. Make sure all of your sounds have decent compression on them, and that all blank space is trimmed up. Some people think they need the best sound quality at 44100Hz sampling rate when they could easily get away with 22050Hz. Don't use WAV whenever possible
• Are you using tiles wisely? Can you break up any large images into smaller components that you can use as building blocks? And no I don't mean just cut up large images into squares. I mean is there, say, a tree in your image that repeats multiple times? If so, why not just make a single tree sprite and paste a bunch of copies?

Check out more optimization tips on the wiki:

http://sourceforge.net/apps/mediawiki/c ... ation_tips

However there may be an issue with VRAM and resources not loading properly on a layout to layout basis, but somehow loading all at once, which could be more noticeable with large projects. Kayin discovered it, and David was looking into it. I'm not sure what all the details are yet.