I may have figured out my issue after all this time. Step 5 in the Construct 3 AdMob Documentation:

"Submit your business and payment details to your AdMob account and wait for them to verify (which may take 24 hours). This must be done before ads can be served."

I'm assuming this needs to be done, before even displaying test ads. I just noticed that in my AdMob account, it had a message saying that ads would not be served until the account was verified.

If so, that was probably the issue the entire time... I just submitted my info, and waiting for verification. If that was the issue, I feel really dumb right now.

EDIT: I was finally able to get a test version of the game uploaded to the Play Store. Not sure what changed, but I did the same exact thing I did over a dozen times over the past week, and for some reason it went through this time. Now to wait for AdMob verification, and see if the ads work after that. Thanks again to everyone who has provided helpful input in this thread. I really appreciate it.

EDIT 2: I'm calling this one Solved. I feel like a dumb***, after re-reading the documentation. It's just been one of those weeks *facepalm*. I think it's time to catch up on sleep over the next few days.... Thanks again for your time lionz, and fredriksthlm. And, Happy Holidays Construct 3 community :) I appreciate you all.

EDIT 3: Everything is working fine using the test ad units from AdMob. For some reason I thought ticking the Test box in MobileAdvert object, would just automatically play test ads. Just a matter of the AdMob Account becoming verified, and then I can Publish the copy that was uploaded to Google Play earlier.

Happy Holidays! I hope everyone is doing well. Apologies for any wasted time.

Also from what you wrote it sounds like you didn't set up admob? It's not just for the store, you need to be verifed and running an app on admob side for adverts to work. I don't know about the bundle but as far as I know that's only required in the store, try using an APK and see if the adverts work, assuming admob is set up. The reason they won't show could be a number of things.

Thanks again for responding with some guidance, I really appreciate it. I've had my AdMob account setup for weeks, the app is in there. And, all the required fields in the MobileAdvert object are filled in. With the Application IT, Publisher ID, etc. Sorry if I wasn't totally clear. I believe once it is up on the play store, there is more to do to basically "link" or "Activate" the AdMob side of things to the app. I could be wrong. I have everything in Testing mode while I try to sort this out.

I'll give an .apk build a shot, and see what happens. Thanks again :)

EDIT: Also using separate interstitial ads for each. One for the Play Button, and another for Player Death. Using the proper IDs to load those up in the event sheets. I'm going to have something to eat, and test the .apk. Do you recommend just exporting to an unsigned .apk?

Correct it doesn't work in remote preview, check the manual there is a giant warning. You don't need to upload to the store to test, you can export it as a local APK with test mode ads.

Thanks for confirming! That's what I figured. Although, I thought it may have changed.

I thought I read somewhere along the way that AdMob ads were also working in web browsers, and I have that setup in the properties as well, using my Publisher ID.

In any case. I've been testing it directly on my phone as well, and still no ads. I'm exporting as an unsigned .aab, and then using another app on my phone to install the package. And, then running it directly on my phone. Game runs great, just no advertisements.

Hello there,

I have been playing around with the construct3 3d demo. I'm relatively new to the new Construct 3 functions. I wanted to combine three 3d games (first-person view from one, third person from another, jump action from another example).

In the third-person view, the camera seems to work just fine. However, when you switch to the first-person camera view, if you try to lock the mouse and move around, the camera will randomly glitch (it's like a lag, the camera will look somewhere else randomly). I have no idea if I did some bad logic, I tried to disable almost all the events and the glitch seems to happen all the time. Even if I disable the third-person view, the glitch is still there.

I have been trying to figure out what's happening for 2 days now. I tried 2 or three times with several logics, but all the time I get always the same glitch. Note that the first-person view is taken from one demo which works perfectly.

Here is the project: https://umbriadesign.it/first-camera-test.c3p

To switch the camera, press 1. to jump press space.

Thank you

I just downloaded your .c3p, and everything seems to work fine on my end. Unless I'm just not noticing the glitch you mentioned. I tested it at a few different refresh rates. 60hz, 120hz, and 185hz. The FPS HUD always matched the refresh rate in game(as it should).

I ran around the entire level multiple times in third, and first person view, and I didn't notice any random camera movement in first person view. It seems to follow my mouse exactly as the First Person example built into Construct 3 does.

Maybe someone else can also give it a test run on their machine, and check it out as well?

Thank you so much for all of your help and insight oosyrag, and thanks again for your knowledge Ashley, and calminthenight!

I had tested the enemy.y+(7*dt*60) the other day, but it had broken everything. The problem was... I was missing the parenthesis around the "x*dt*60". I just tested it real quick at multiple refresh rates, and it works perfectly now.

I really appreciate the deeper insight into "Every X Seconds" as well. I'm making a mental note of everything in this thread, for all my current and future projects. So I can design them properly for any refresh rate.

With all of that I think this issue is now solved. I'll work on redoing my Event Sheet to take dt into account asap. For now, I'm off to get some rest.

Thanks again everyone. All the help, and deeper knowledge is much appreciated :)

Thanks for your response, as always oosyrag. I really appreciate the support. I'm more concerned about people playing a commercial game on various mobile devices, and it not playing the same on every device. I'm still a bit confused on how accomplish incorporating delta time in all my Events, and Actions. This is what my Every Tick Group currently looks like: https://i.ibb.co/Fqt0XrW/everytick.png

What I just tested, was changing it up to something like Set position to Enemy1.X, Enemy1.Y+900*dt for that first enemy, and it feels right about the speed I'd like it to be at. Does that seem like a proper way to go about it?

EDIT & SIDE NOTE: So the "Every X seconds" condition is not ideal for times below 1 second, but should be okay to utilize for Events that run every 1 or more seconds? If not, I'm going to have to rethink this entire Event Sheet.

> I had everything that moves down the screen under an "Every Tick". I just had to change that to "Every 0.016 seconds" to simulate the same speed at any refresh rate.

I would advise against doing that - very small times in 'Every X seconds' can still actually be framerate-dependent, as noted in the manual. For example if the game dips to 30 FPS on a slower machine, "Every 0.016 seconds" will actually be running every 0.033 seconds, and hence the game slows down in a framerate-dependent way. Also at higher framerates like 120 FPS, you'll have a janky appearance from moving things at a lower framerate than the game is actually rendering at.

The correct solution is, as before, to use dt. There is probably some movement happening in "Every tick" that isn't using dt and ought to be using it.

Thanks for the heads up. I've been sick, and fighting something the past few days(all signs of Covid, but can't get a test anywhere...). Was laid up on the couch yesterday, just seeing your post tonight.

Is there any simple way to check "dt" for an entire event? Or is it done in each action within the event? Everything I did the other day to move the objects based on delta time broke everything.

Common practice for platformers is to use a rectangular invisible helper sprite as your base object for collision purposes, and pin the visible texture/sprite to it. This helps to minimize many potential collision issues.

Great to know oosyrag. Thanks for sharing your knowledge :). That makes sense now that I sit and think about it. This is a game I made a few months back, and was just trying to grab video footage of it for something, when I noticed the glitch.

Just like you said at the end. My current projects I use a square base sprite, with another sprite objects with all the animations pinned to that base sprite for that player/enemy/whatever. So all my current projects, it hasn't been an issue. Definitely good design practice!

I'm learning a ton. Love this community. Thanks again everyone, for taking the time to explain this to me. I really appreciate it.

EDIT: The Vertical Scrolling SHMUP was an even easier fix. I had everything that moves down the screen under an "Every Tick". I just had to change that to "Every 0.016 seconds" to simulate the same speed at any refresh rate. Now I can just tweak the seconds value, to adjust the speed to where it won't be too easy or too difficult.

Apologies for the double post. I may have that enemy collision glitch at 185hz worked out. I noticed the Origin Point was not a whole number. Would that for some reason cause an issue? Still reading through the article on DT.

All I did was widen the collision box by one pixel(double checked on every frame, as "Apply to All Animations" missed it on a collision point or two by a smidge(off by .03-.2 pixels), so I could set the Origin Point centered within the collision box using a whole number, now "60", rather than "59.5".

I set the blocks in the Event Sheet for mirroring on the boundary object as enabled. And now the enemy is reversing direction, and flipping the sprite as intended. I'm going to get some fuel to my brain, and finish up this Delta Time article. Thanks for all of the assistance, everyone!

Everyday, I learn something new. I love to learn, so it's all fun to me haha.

EDIT: Or perhaps it was one of the collision points being barely off by a fraction of a pixel, and I didn't realize it, until I manually checked each one. Either way, it's working now. Been sitting here, reading, and watching this guy bounce back and forth for a while now.