Hey Hug0h,
try to divide the light falloff values by "Layoutscale" when zooming.
It's not a proper solution, but it should mitigate the issue.
Breaking changes so early should always be fine, so don't feel guilty about it. As long as it improves the feature on the long run, it's a really tiny price to pay. Thanks for the improvements! An amazing beta cycle so far.
I believe this isn't the right place to address concerns about another addon. However, I'm confident that NormalMapExtended works well, as I've used it previously and NormalMap32 is built upon it. I've addressed the mentioned issue in the NormalMap32 example project events, so the evidence is right in front of your eyes. ;)
Nevertheless, I highly recommend NormalMap32 since it offers various improvements.
That's not a bug, it's just the example project which doesn't account for scrolling. While the NormalMap32 examples handle it accordingly.
But glad you like it.
Thank you very much for the path-finding improvements. Reminds me a lot of the path-finding customization from Lernie Ang:
youtube.com/watch
Although your implementation is still slightly biased towards top-down path-finding due to the invisible grid... It will still help a lot in isometric projects for more natural movements.
en.wikipedia.org/wiki/QWERTZ
Oh, i just found out that you can run multiple debug layouts using Alt-Click onto the Debug Layout preview button.
Didn't know that's a thing until now...
"Multiplayer: add decompressed bandwidth and compression percentage to debugger"
Does that mean we finally get a debugger interface while running multiple previews? Otherwise i don't understand how this could be of any help.
Would love to see a benchmark of "prototyping" sophisticated nested loops running through thousands of instances using the event sheet, and then compare it with 1:1 JS replacement for your next blog entry.
Was super excited at first, but then realised that you will simply skip all the main issues Construct has, by coding it mainly in javascript.
Unfortunately that's not how the majority of your customers use Construct.
I beg you to force yourself into using your product with its built-in features (Event Blocks and Editor ), not just mainly javascript.
Otherwise you won't even have a glimpse what it means to truly use Construct as a user and stay in your javascript programmer bubble. Yes, you want to show the true capabilities (performance) of Construct by utilizing javascript as much as possible. But it won't show you the smaller and bigger issues Construct users run into.
Eitherway, i'm excited to see the results, and hopefully many editor improvements that evolved from it.
Will be a good experience for everyone, that's for sure. Looking forward to it :)
If you use them for a game design workshop, there's an educational plan available:
construct.net/en/make-games/buy-construct-3/educational-plans
It's not like any teacher has to pay anything out of his own pocket...
Also, you're not losing anything.
You can still continue using C2 if you just can't cope with moving on.
So where's the big deal?
A little too dark and overuse of "dirty" colors for my taste.
Especialy when hovering over events i expected text to light up a bit, but it just makes it even harder to read.
Like the rounded edges though.
What's next for Construct 3?
I think i'm talking for a lot of customers when i say that it would be great to have some insights on what we can expect in near and/or far future.
Thanks a lot for the update.
Would be great to have some kind of an official roadmap so we can see what's coming up in the future.
Member since 24 Jun, 2014