Jase00's Recent Forum Activity

  • JULIUS 😘🖤

    **HELLO,**

    GIVEN THE GROWING NUMBER OF COMPLAINTS FROM CONSTRUCT 3 USERS, MYSELF INCLUDED, I BELIEVE IT IS TIME FOR YOU TO SERIOUSLY RECONSIDER THE FREQUENCY OF THE SOFTWARE'S UPDATES.

    RATHER THAN HELPING, the constant stream of updates has become a real headache for many developers. Every new release brings changes, adjustments, or unexpected issues that force us to spend time testing and adapting our projects instead of focusing on what truly matters: developing our games.

    IT OFTEN FEELS LIKE WE SPEND MORE TIME KEEPING UP WITH UPDATES THAN ACTUALLY CREATING.

    WOULDN'T IT MAKE MORE SENSE TO REDUCE THE FREQUENCY OF RELEASES AND PUBLISH ONE OR TWO MAJOR UPDATES PER YEAR, thoroughly tested, stable, and optimized?

    Many users would greatly value stability and reliability over a constant flow of changes that, in many cases, end up slowing down or disrupting our work.

    PLEASE LET US DEVELOP AND FINISH OUR PROJECTS IN PEACE.

    **LET US LIVE!**

    THANK YOU. 😈🎮🖤

    Dramatic

  • I agree with others, try taking a screenshot, see if it's blurry.

    You could also check this website, see if the top test looks blurry: testufo.com

    There's a chance it could be due to your computer's screen. You get different types of computer screens, maybe you recognise "OLED"? There's OLED, IPS, VA.

    VA screens tend to be the most blurry with movement - I bought a cheap 240hz monitor that has a VA display... It looked awful and was very distracting even for 3D first-person shooter games. It had various settings to reduce the blurry/smearing issue, but none were any good, even at 240hz!

    The thing is though, you would have noticed this in ANY game you play... Curious...

  • WackyToaster This is huge, thank you so much!!

    I didn't understand the purpose of the minimap beyond quicker scrolling, I was adding lots of blank space to give a visual idea of where things are... but then memorising that was futile.

    Definitely going to utilise everything you've shared, I really appreciate it.

  • Thank you Ashley, very good to know, been exploring more and have learned a lot!

    WackyToaster ... hahahahahha... yes you are correct on what I was looking for. After over year of on-and-off attempts to use detune, I finally figured it out yesterday, and, the disappointment I felt...

    The link explaining detune is vague, it does seem like it is for pitch-shifting without tempo change, but nope, all along, just a variation of playback rate. I cannot believe it.

    On the flip side, I found SoundTouchJS, which allows real-time pitch/tempo shifting, and I managed to get it to work (whether I've implemented it the correct/optimal way, how much it can integrate with Audio plugin or not, who knows... the important thing is, it works!).

    github.com/cutterbl/SoundTouchJS

    I'm on the fence about handling audio entirely through script. It's making sense, so maybe, but then all benefits from Audio plugin, effects, headaches that Scirra already handled for us... Hmm...

  • Good 'noon!

    I'm new to scripting, but have a good grasp on most areas... except Audio.

    I had a few questions, they will be noobish, enjoy:

    1. What's the difference between using C3's Audio scripting AudioContext, compared to creating a new one entirely?

    2. How much can be read/changed with C3's AudioContext? E.G. Could I change a value of an existing "distortion" effect that I added in C3 event sheets? Could I read the "duration" of a loaded audio buffer?

    3. Could unavailable features be crammed into C3's AudioContext, e.g. "detune": developer.mozilla.org/en-US/docs/Web/API/AudioBufferSourceNode/detune (Detune is particularly interesting to me)

    4. I think I understand that "audio tags" are deeply-rooted in C3 rather than being something we can use within Audio scripting, but can any info about tags be gained, whether scripting an "is playing" or scripting "play sound with tags", or must we always make C3 bridge functions to achieve this?

    From historical memory of Ashley's replies, C3 handles a heck-tonne of quirks from the Web Audio API, iirc things like tags, or even getting the playback time, so I am certainly not curious to "make my own audio system", but I do hope to poke with as much as possible.

  • Trying my luck whether this is a somewhat minor change eheh... or maybe I can cry "it's an oversight!" lol, anyway:

    We can change Event Sheet tab colours at the top of C3, but not the tab colour for script files (or any "files", e.g. plain text files for notes).

    Could it be possible to allow updating the colours of script tabs?

    Tab colours help a huge amount - Where I've used Event Sheets for years, I gained muscle memory of "Green is 'Gameplay' sheet", "Black is 'Debug' sheet", etc. Even if tabs reordered, it is easy to recall the colour and spot it immediately. Even if reusing a similar "Green" tab, its only 2 greens to look for, they stand out clearly. Lesser-used event sheets remain grey.

    I understand if no. I became hopeful it could be a minor addition as I figured an "open script file in C3" has some form of UI data to store for its position in the tab list at the top of C3.

    EDIT: I only now discovered collapsing code in scripts... this is GREAT, but sadly, once you save your proj, close, reopen - all collapsed code in scripts are no longer collapsed....

    ... could this be something C3 could track when saving/closing proj/reopening?

    I apologise, suddenly 2 "minor suggestions" that probably are huge/risky (especially since it involves project save data). Tab Colours are certainly the most desired.

    .

    .

    .

    Below is miscellaneous stuff I wrote but may be of use

    It's been great working with scripts. I have focused hard on learning JS in past months (Slow learner, took me YEARS to comprehend Ashley's Learn JavaScript in Construct tutorials, along with... *gasp*... using AI to answer my excessive noob questions). I have essentially transformed huge amounts of my project into scripts, and it's honestly been extremely fun! Took me a while to comprehend the best setup for "imports/exports" but finally understood, and thus split my scripts even more.

    Navigating Tabs, and navigation in long scripts, have been the only things slowing my workflow down. I try to learn as much as I can to improve my workflow, and discover new things all the time within scripting - E.G. Features like "CTRL+Click on a property". Even ol' familiar features are extremely useful when scripting, like C3's "Find" bar.

    Tab Colours

    My workaround is using dummy event sheets named "=UI=" or "=Input=", set the tab colour, place at left of script tab. Sadly it's a bit wonky to use - tabs jump around when resizing left/right C3 panes, and clicking on tabs will slightly alter tab widths and sometimes readjusts tabs to the next line - this makes my eyes dance around from right to left, not the most optimal but better than nothing.

    I even tried making dummy sheets where the tab is pure black, so I could use them as "spacers" or to try and keep tabs on the correct lines. This was painful and I stopped doing this!

    Collapsing Script Code

    I thought I solved my woe of "navigating long scripts" by splitting into separate script files, but I am over-doing this quite a lot (e.g. 4 scripts for Mouse-related things, simply because it was a nightmare to scroll around when it was just 1 or 2 scripts), but to be able to collapse a long function that I rarely need to look at, is immensely useful - Just wish it remembered it in C3!

    I have a feeling this is more tricky than a "minor addition" since it's interfacing with Monaco, which might be a pain.

    Could Monaco report back to C3 when the user collapses/expands something in the specific script it was done within, or if another command like "collapse all/expand all" is used, or when opening a project, can Monaco be commanded to auto-collapse scripts based on however Scirra stores the collapsed entries? Who knows.

    Besides Monaco, I understand the script could be modified externally - C3 could behave strictly and simply discard the tracked entry of a collapsed line in a script if the expected text does not match the line number?

    Lastly, on a random note, I have explored VSCode, gave it a shot, but backed away when I saw weird effects when running my project with "auto-reload on preview" - This has been reported (indeed not a "bug" but it freaked me out to see things revert and I didn't know why/which scripts changed). Will revisit, but overall, I prefer staying within C3, feels far smoother to work with: easily click "preview" in C3, add objects, visit layouts, add/open other "Files" in your project - all without switching between C3/VSCode repeatedly, and without me trying to adapt to a new workflow of dual-monitors with both open (I already have a purpose for my dual monitor).

    Anyway yes, thank you for reading yet another wall of text from me.

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads

  • I also get this on my main project and the project is huge so haven't got around to tearing it apart.

    My suspicion is using dynamic layers to add layers during runtime, maybe it was an oversight when adding the new sampling modes per layer - Do you use dynamic layers in your project, too? If not, I am also clueless!

    Someone else also reported it but also did not have a repro, so it was closed: github.com/Scirra/Construct-bugs/issues/8918

  • I have had this happen, too, with pixel data reverting when closing the animation editor. It was a while ago but I remember copy/pasting with selection tool.

    More commonly, like Tokinsom mentioned, origin points move around after clicking a different anim/closing animation editor. This was more recent and common, and I know what I was doing (but didn't investigate) - I was copying single animation frames from the frame bar, then pasting into another existing Sprite's animation (usually a new animation), then adjust the origin point, then click a different anim/close animation editor...boom, sometimes origin point moves...or not...

    I do wish we could report bugs that haven't been repro'd but are known or severe - e.g. I had reoccurring project corruption bug from Return Functions (since been fixed) but couldn't repro for months, so posted anyway, but was doomed to be closed and lost... Thankfully I figured the very specific way to trigger it (as you would with a project corrupting bug... Which turned out to be trivial to hotfix your project... Had I known).

    I have a bug I really don't like, discovering it as I clean up a long-term project - deleting objects and reorganising their folders, saving often, sometimes the save fails once with a specific error, and then I KNOW what comes next - click save again, it will work this time, but close project, reopen, and project will fail to open due to a missing image file (often from an object NOT deleted). Thankfully console gives logs of exact files and can pull the image from backups. Only clue I noticed, is the filename differences sometimes, like some images end with 0001 but others don't (maybe due to it being a project from over 4 years).

    LASTLY and I wonder if anyone else had this - moving a family into a folder, suddenly the family's events do not run (yes, in the project bar, just to organise your families).

    Edit: Protip that helped me identify the obscure Return Function project corruption issue - use recording software like Nvidia Shadowplay that let's you hit a keyboard key to save the last 5 or 10 mins of whatever you were doing... Helped me retrace steps (although still difficult as the "trigger" of the bug may have happened far earlier or from something excruciatingly subtle).

  • safe mode already exists btw: construct.net/en/make-games/manuals/addon-sdk/guide/safe-mode

    ...!? So that's the response for a panicked support email sent to Scirra. SDKV3 was mentioned due to crashes on boot from Editor addons, yet there exists a way to remove such an addon already.

    Also skymen 's reply shows that there's not a extremely bad scenario of C3 boot crashes (Addons are not loaded until the editor itself is fulled loaded), no chance of a blank white screen when opening C3 due to an addon, etc.

    The crashes prompts in C3 should have a link to the Safe Mode URL.

    MasterPose Thank you for the info! Admittedly I tried to remain vague about this, but I don't know why - It's out there and Scirra will make a judgement. The fact it returns user choice and lets us choose our own risks (as both this addon and the SDKV1 addons both could break at any time, but hey, can stay on older C3 version).

    I figured to write about my thoughts about Scirra's support email concerns:

    Support Emails - Third-Party Addons

    I am presuming that the types of support emails that Scirra receive, are from users that have an expectation for Scirra to resolve any/all things Construct, they may not post on the forum, they may not want to contact third-parties, or perhaps the user doesn't understand the separation of Scirra and third parties and simply expect Scirra to provide a solution at all costs.

    I am also assuming that the reason this is a problem, is due to a massive amount of these types of emails relating to third-party addons. I am unsure whether to presume there's a dire impact such a reputational damage for Scirra, or loss of business.

    I presume Scirra do not support legitimate compliant third-party addons.

    With all that said, here are my confusions. These apply to BOTH compliant addons, and the non-complient addons that use undocumented features:

    • A user emails Scirra, the addon broke on latest C3 update, red-screen crash when opening project. The advice would be to remain on previous C3 version, and contact the addon dev.
    • A user emails Scirra, the addon broke on latest C3 update, their project opens and they did months of work elsewhere within their project, and only just realised the addon is not functioning. The advice would be... check for updates, contact addon dev, or remove the addon since the project is able to be opened.
    • A user emails Scirra, their browser crashes when using an Action from a legitimate compliant addon. The crash is not C3's fault and has always existed in this addon. Would Scirra investigate, since the addon is compliant? Lets assume they may, but the addon is highly complex; this would be a more time-consuming support email to deal with, compared to a templated email response of "We don't support third-party addons".
    • A user emails Scirra, WebView2 doesn't detect their gamepad suddenly, or Steam overlay suddenly doesn't work - It's reproducible and affects all users. Scirra kindly do their part and reach out to the third-party companies. The companies don't respond quickly/at all. I presume Scirra either keep replying to these support emails with updates, or ask the user to track the bug report that Scirra wrote. This type of email seems way more difficult to handle, you can't give a definite "Yes this will be resolved", you can't give timeframes, and the user will remain frustrated and impatient. At least with Addons, it's an easy "We do not support this, contact the addon dev". If a user becomes more frustrated at both "We are waiting on Valve/Microsoft" and "We do not support third-party addons", then... well, there comes a point where it's not Scirra/Valve/Microsoft/Addon devs fault, it's the temperament/communication style of the user that is causing strain.

    The ironic lesson from SDKV2 being implemented was "What do I do if an addon suddenly breaks in a C3 update?", as that is what SDKV2 had to cause.

    Back with SDKV1, there were choices: Stay on previous C3 version, remove the addon, contact the addon dev, pay the addon dev, pay someone else, fix it yourself.

    Even with a non-compliant addon, you still have the chance to see a fix.

    But with SDKV2 going live, some addons became a choice of: Stay on previous C3 version, remove the addon...

    ...that's all we can do... way more hopeless.

    Or of course, feature suggestion voting... Best hope there's demand and you're good at rallying the community to vote.

  • I wrote an enourmous reply but may save it for another time... or later. Mainly some epiphanies about SDKV2 and the Scirra support email concerns.

    SDKV2, I came to accept; easier for me to say when I'm no addon dev, but I did have to give up some addons that I still miss and want to use again (Clipping Mask, I will miss you... thank you for that skymen!)

    But even as a typical user, some addons I needed to update were compliant and simplistic, and heavily used in my project... but the updated addon had changes to ACEs... Red screen crashes on project opening... wasn't competent enough back then to edit the addon myself... Uninstalled, tracked down the specific version I was using, installed, going through all ACEs and writing comments of what it was, the expressions... install updated addon, go through all comments and re-add. mannnnnnnn

    After dealing with all of that - To think that we might get an SDKV3 because, even 1 random person could coax it into happening... especially when knowing the goal provides no tangible benefits to users, causes controversy, demoralises addon devs, and just obfuscates further...

    ... ykno... obfuscation the thing we know not to over-engineer - There's always someone out there determined to find their way around it - I'm baffled from the other topic that there's hacky shenanigans with recent SDK, whether it's safe or not (which... would be ironic if it was less safe compared to SDKV1, but I digress).

    Anyway... From that thread, with the catastrophic concept of your editor plugin potentially causing crashes, which you explained is very separated so unlikely, but lets assume it did - Would the worst-case crash always be Construct reaching at least anything - The start page, or the loading page at the start?

    I thought of two ideas:

    1. If a red-crash screen would always appear, it could have 2 possible buttons: One to manage addons (only to list and uninstall), and a button to start C3 in a sort of "Safe mode" where no addons load.

    2. A "Safe mode" URL. I'm less knowledgable on domain/data read/write access, but say there was editor.construct.net/safemode - It is NOT C3 but a very simple web page, addon manager to uninstall again, a link to the C3 editor so you can "uninstall, click link, see if it works".

    Frustrated user emails Scirra, Scirra provide that URL and suggest to uninstall any addon they believe is related to the Editor. Also helpful for general users that play around with addons and get crashes on startup and don't want to clear their entire browser cache.

  • What an exciting thread!

    I really appreciate the ethos of Construct 3, where things are tied together. Sometimes things have to happen (like HTML layers), other times it's a logical situation (expecting 2 behaviours to not conflict with each other), but beyond that, very rarely will you encounter a feature in C3 that doesn't work with another feature.

    My ignorance is probably going to be shown with what Three.JS offers, but, I feel confident that Scirra can tackle their own 3D implementation - Three.JS is excellent from what I've seen/read, but at the end of the day, Scirra have figured out extremely effective and optimal design choices for 2D game design, from cheap collisions to optimised rendering, all without the user barely needing to configure anything. Maybe it's bad for me to say this as it makes third-party addon devs, or those familiar with Three.JS, have less use for their skillset or become restricted in some ways, but I stand by my point as of now.

    With 3D, I thought I'd share what I feel would be the most-categorically-important starting point, and also share a list of the features I feel are more deserving of a voting-based system.

    In order, starting with most important, here is what I feel is most needed:

    1. Full rotation of a 3D shape.
    2. Upgraded Layout view for 3D objects.
    3. Loading in gltf model files.
    4. 3D Bounding box collision.
    5. Basic 3D lighting (New Object: 3D Light).
    6. Basic 3D animation (from gltf files).

    Then the features I feel should be a voting case:

    • Enhanced 3D Collision (Raycasts, esp for FPS games with shooting, but also for allowing users to design effective movements for their platformer games and such. Hopefully the ability to get useful information such as X Y Z, reflection angle, or perhaps even the name of the part of the model (assuming you can separate, e.g. a Person model's head and body, then it's much easier for someone to make a "headshot" system). If these types of info are expensive to generate, then allowing to disable/enable would be great.
    • Enhanced 3D Lighting (Whether a different form of lighting, shadows, etc).
    • 3D Physics
    • Further usage from the gltf file format (unsure on what could be gained from this, but bones, leaf tree visibility hierarchy, etc).
    • Multiple 3D Cameras (Placeable even within a layout, e.g. a TV effect, or a car's rear-view mirrors, without relying on Drawing Canvas (which may not even be possible!)).

    With all 5 important points added, it feels like a beginner could easily step into C3 and get cracking on many types of 3D games, from First Person Shooters to Platformers - Whereas right now, every point listed becomes an issue for someone trying to get started.

    1. Full rotation - A requirement that does not need an explanation!
    2. Upgraded Layout view - Needed for ease of designing a 3D game - Free cam and such.
    3. Loading in gltf models - IMO This is a critical barrier and is high on the priority list - Being limited to just a few shapes is not what someone expects, there must be some way for someone to load their own objects in.
    4. 3D Bounding Box collision - A great starting point for simple collisions; whilst alone is not capable for wacky 3D projects, it's still extremely powerful to get started. I am unsure on the appropriate way for Scirra to handle this, whether the bounding box should expand/shrink depending on object rotation, or if its size shoudl remain static, or if the bounding box should also rotate (imo I think not, to keep collisions cheap and efficient - Although choice is always good to have!).
    5. Basic 3D Lighting - I am noob with 3D overall, but I understand gltf models come with normal data to help with lighting, I presume "vertex lighting", so a new plugin for "3D Light" would be amazing to see, allowing beginners to throw together a scene and make a nice atmosphere.
    6. Basic 3D Animation - Again, I am noob, but I presume there's a variety of animation types, from a likely-simple "move vertices" to "bone animations". As long as there's some form of animation, even if one must adapt their model file to utilise this, then this is the last feature to make a valid game - Rotations, collisions, lighting, sound, animation - All good!

  • You do not have permission to view this post

Jase00's avatar

Jase00

Member since 5 Jan, 2012

Twitter
Jase00 has 12 followers

Trophy Case

  • 14-Year Club
  • Jupiter Mission Supports Gordon's mission to Jupiter
  • Forum Contributor Made 100 posts in the forums
  • Forum Patron Made 500 posts in the forums
  • Forum Hero Made 1,000 posts in the forums
  • Regular Visitor Visited Construct.net 7 days in a row
  • Steady Visitor Visited Construct.net 30 days in a row
  • Enduring Visitor Visited Construct.net 90 days in a row
  • Unrelenting Visitor Visited Construct.net 180 days in a row
  • Continuous Visitor Visited Construct.net 365 days in a row
  • RTFM Read the fabulous manual
  • x28
    Quick Draw First 5 people to up-vote a new Construct 3 release
  • x9
    Lightning Draw First person to up-vote a new Construct 3 release
  • x9
    Great Comment One of your comments gets 3 upvotes
  • Email Verified

Progress

28/44
How to earn trophies