I mean live editing has been around for a while? This looks like mostly just a quick way to select objects from the game window, rather than going to the remote node tree and selecting there. Super nice nonetheless though but you can pretty much do this in a more roundabout way in older versions too
yea we've always had live editing / hot loading. so far, the new feature seems be just an alternative object picker. it wasn't even necessary to go to the remote scene tree like joshua suggests. you can click on objects/nodes at runtime in the editor's scene viewport just as well, even allowing you to do live edits with mouse drag & drop rather than to type in values. perhaps once the game window can actually be embedded into the editor it might become a little bit more interesting, but currently I don't see all that much of a point.
@@joshuaanderson6609 I was thinking the same thing. I've seen people before, mention that Godot is missing the feature to interact with the running Scene Tree from the editor, but I think it is just that they never discovered the "Remote" tab. It is nice they make it more visible and the introduction of a debug camera means we wont have to add one to every 3D project any more :)
@@JakobKobberholm I think the remote tab is just not as intuitive or obvious as it is in Unity. Unity forces you to run the game in the editor every time you hit play, while Godot does not. It's easy to misinterpret that and just get used to running the game, stopping the game, making changes and then running it again.
@@jefreestyles I'm pretty sure that's how it works. It sends a ray from the mouse pointer into the game world and whatever gets hit first is the snapping surface. You can actually see it snap to the side of the boxes in the video.
It appears to attach to the walls of the boxes, not sure if it places the origin of the object in the collision location or if it then uses the collision mesh of what you're moving to push it out form the point. I think it's just finding the location and not taking collision of the placed object in mind, but it wouldn't be too hard to add either. The main issue if it tried to fit the placed object is if you hover over a spot without room, it would have to detect that so it can skip fitting the object or you'll get the jank of overlapping objects suggesting the box you are placing belongs on the moon.
You still cannot use both tabs together like you can in unity. Honestly, this godot engine is just backwards. It is inferior to unity 5 in so many ways and unity 5 launched a decade ago.
@@leeoiou7295 oh shut up. in godot I can change values of nodes and have them update in game and then remembered when the game stops, you can't do that in unity. I can edit the labels on a panel, have them show in game, and then stop the game and they are saved.
@@leeoiou7295 So stop watching videos about it, then. Oh sorry, I forgot - you're a wannabe Godot contributor, but you found out you haven't got the skills for it and have had a chip on your shoulder ever since.
Honey wake up, new Unity version just dropped and for some reason has a blue robot on the cover. Seriously tho, this changes are amazing, can't wait to try them out.
I remember shortly after Unity changed its pricing, someone opened an issue about live editing being a blocker for people switching to Godot, and people said anything related to it would take a lot of resources (people, time and money) or would be impossible. Just over a year later, and it's in beta. Open Source is amazing.
Native dialog got improvement for all major platform (desktop & mobile) For camera native device, currently only works on MacOS and iOs, someone still workin on it I believed Prolly "the native things" will has more impact for non game developer (app developer) then game developer will pleased by that (native notification, bluetooth, & etc.)
I hope they could offer two choices for the game tab. The current operation of the scene tab offers a unique approach by having a single window appear, making it convenient for me to shift it to another monitor and experiment. This is due to my aversion to having the game and scene tabs next to each other in Unity on my 24-inch screen, as it feels quite limited. It’s possible that some people who have spent many years using Unity and have a wide 21:9 monitor are currently critiquing me, but that’s exactly what I desire.
Godot not having a runtime inspector and easy testing was the biggest annoyance for me. The remote inspector thing they had felt more like a bug than a feature since the changes were being saved in the editor. Look like Godot is getting closer to unreal-unity debugging and testing.
I think they don't set it in the metadata folder is because they would then have to track a mapping between the file and the metadata. Imagine you have a custom resource called "character_data.tres" inside the character folder and for some dumb reason you also have a resource called "character_data.tres" inside the enemies folder. With the uid file being side by side with the main file, the editor will move both when you move the main file and users are instructed to move both if they do it outside of Godot. With the file being on the metadata folder, first you have the issue of two "character_data.uid" files inside the metadata folder. What should they do? Replicate the project folder structure inside the metadata folder? Add some sufix to the file name? Second, there is the issue of users moving the file outside of Godot. Now the user needs to remember this uid file exists and needs to find it inside the metadata folder. So I think the reason they didn't do it that way is because it wouldn't work.
Thats pretty cool. Now if they can map the tilemap detachable or mountable on other sides. You lose so much screen real-estate while trying to make maps and it keeps conflicting with the file system being down below.
@@GoblinArmyInYourWalls Very true. Last time I tried to learn gamedev and Godot it was 3.2. I've enjoyed watching Godots improvements since but havnt really jumped back into it seriously.
The whole goal of UIDs is to allow users moving around files in their native explorer without breaking their game (Godot cannot keep track of files if they get modifed/moved around outside of it, it's not possible). As a consequence, those RID files are next to their respective file, so that users can move them along with the original file. Having RIDs stored in a metadata folder or file would basically defeat the only reason why those got implemented. Edit: Also, I'd like to add something. You know, Godot devs aren't that inaccessible. I promise maintainers put a lot of thought in such impactful decisions and you'd probably understand those decisions a bit better if you reached out. I think most of us are pretty happy to answer such questions, especially considering the wide audience you have.
Super happy to have the uids so moving resources around is more seamless in the editor. While I’m not remotely clever enough, I do understand the prickly points around having to manage more files within the explorer
I've had nothing but UUID problems. There have been times where my entire project got bricked because of UUID corruption. It's not fun having to rebuild a project because of jank shit in Godot. Right now things are fine, and if I need something moved, deleted or renamed, I do it in the Godot editor so things get updated. But every once in a while, I have to go fix UUID errors in my resource assignments.
I agree... I think there should be some "Metadata" folder to house most things such as icon.png, readme etc... Leaving just project.godot and the project folders out. I like the way visual studio does to these stuff you add straight to the solution - it creates a folder named "Solution Items". Usually, IMO, the less stuff in your face (ie in your project root), the better.
They recently uploaded status about the foundation and I don't know what to think about the part about trademarks. I hope It's not the start of the road of making the engine less open
all big open source projects (or at least ones im aware of) protect their project identity like that. i don't think there's any cause for concern here.
@@stinky_mousepad that's wishful thinking. Trademarking is the opposite of freedom. You may be sued by the distributing files with trademark involved. That's why RHEL clones exist and have tedious work for removing any copyrights from sources. And Red Hat already exploited the trademarks - you can read about that, how do they block access to the sources because they're trademarked.
the part with the crate is not a bug when it falls inside, it's applying a normal to the surface you point your mouse on and places the object along that normal vector. if you put your mouse on a horizontal surface the normal will point up and will place the crate on top, but when you point on wall for example the side of that box, the normal points to left, (
I really hope those UID files are optionally generated if/when needed instead of autogenerated for everything. I rarely if ever use the newish unique id feature since if you plan your project structure well it’s mostly unneeded since it really only comes into play when refactoring. It also seems worse for reusability across multiple projects
No they are not i see so many people who dont understand resource files. They are really important when working together with version control systems since your not committing the .godot folder thus everyone cloning the project has other uids for the same resources. For that reason scenes get random changes when editing across different machines or people which put noise in git diffs or breaks project when combining merge conflicts
There's plans to put the game inside the tab before 4.4 is completed for those who don't want the separate window. Which is why you have the tab in the first place now. Technically you had the remote view before, but you had to use the 3D window to pick items which lacked the live updating of objects. Making it operate through the game window itself seems like a pretty good idea, in unity you wind up having objects moving in the editor window that then have to reset when you stop playing. In Godot it's always been more clear that your live changes are just modifying the running game not the scene itself, mostly because you can't even see the changes in the view. Now with it being synced in the game view you still have the separation of states but will regain the ability to pick objects and look around the live world to see what's going on.
1:15 everything happened there just as should be my dawg just look at your cursor, where you positioned it, the box was trying to align it's pivot there, and the pivot of the box is probably at the box's bottom
Sooooooo hyped for the interactive game mode! That was one of Godot's biggest shortcomings compared to Unity and Unreal. Edit: AND A REPL?! This version is HUGE!
Those are honestly just mid features. They aren't even new features, just some editor UI to make it slightly easier. Ubershaders are a more important addition, not mentioned in the video for some reason.
@@polaritymakina8440 but only for you, it wouldn't fit many others needs and would only serve to be a problem for most games. An addon that does it the way you want specifically would be better for everyone.
Every time I watch your videos I wonder if you have any projects? Do you work as a developer in some studio or maybe developing a project as an indie developer? I would love to look if you have something!
Looks like when you make a video on one dev snapshot, the next snapshot comes out the following day. Can you make a video for Dev 6 tomorrow? Really looking forward to Dev 7 on Saturday. Thanks!
Hm I wonder if the new UID update will decrease the amount of times I have to blow up my .Godot folder because some import file got corrupted during live play. It's a neat new feature. I think the .UID files should be hidden and move automatically if the main file is moved. But I think that's an OS thing and might require more Registry configuration.
What we need or I need, is: A picture in picture feature, so I can have a camera view not take up the entire viewport. Embeded run time game window. A means to view 2d elements over 3d without running the game, or needing to overlay snapshots. An over haul of the animation system, that isn't full of jank as it is now (what part of Godot isn't? lol) Visual shader features that are available else where but not in Godot. Also for jank to be fixed. Material icons to retain themselves and not get mixed up with others or compoletely lost. All jank addressed, without excuses. I'm on the edge of trying Unity to see if it's a viable alternative. The grass seem so much greener over there. The only thing I won't like is load and compile times, or other shit the corporation pulls. Also C# seems quite complex and at times complicated.
Man... Just let the kids fo things that they like, if you don't like them go to another site where they talk about the things you like instead of being an asshole @@addmix
Yeah the UID files is something I don't know how I feel about. Have or not have, and along with file or metadata folder. Too many pros/cons for all, my brain can't process.
I think they should make that game mode just like Unity where your game runs inside the editor. One of the things I don't like about Godot is that pesky separate game window.
Excellent features, thanks for the info! I wonder, for that "physics placement", would there be a way to do that on walls? for instance, I have a made a light switch but I want to be able to place it directly on the wall with ease... Is there a way to do that?
I used Godot to make a small light game for my friends in about 2 weeks, uploaded to Itchio so they could web play it and only half of them could run it. Now I don't use godot. Hope they can fix that.
I can't wait that they add a meshlet / cam culling nanite-like system with advanced rendering features to compete with Lumen, substrate and Megalights. Then, it will be the ultimate game engine.
When that happens, I predict it would be as an extension, not as a built-in feature. The reason is that makes the engine much heavier, and it's only useful for a few kinds of games.
@@gokudomatic why not, all of this is can be implemented as optional features. I really like the engine, especially the lean, polished and consistent part of it, I just feel it's a shame it's stuck with indie games only for now. If it had advanced graphics capabilities, it could be the new base for solid franchises' updates such as simulators, or RPGs with higher graphics needs and a bunch of Unity ports. So far, the low poly/lambertian look of all Godot games make it a VERY NICE proof of concept, but unfortunately, rarely the final decision for true mid to large scale productions.
Wait a decade, Vulkan was implemented 7 years after standard release. Besides that, it seems that a few teams really implemented virtual geometry. It's not been like wide Vulkan adoption.
I like everything I saw besides the metafile non-sense nightmare that unity uses. To me, why can't we just have a big table that we setup with aliases instead? Then we change the file path, we change the dictionary look-up for the path. It'll be great if it's somehow auto-generated. Like files are being tracked by the system and updating this big table. It's human readable and easily fixable. Seeing random ass numbers in editor files makes for too much indirection. I've moved on to Unreal now and they have a renaming system call Core Redirects. I don't know how much better it is in practice yet but at least it's freakin human reading and works similarly to what I described. Metafile stuff can burn.
@@TheHelderVinicius There used to be a saying "If you going to do something, do it right", and "Practice doesn't make perfect. Correct practice makes perfect." There's no excuse releasing jank shit.
@@rremnar "Dev snapshots are in-development builds of the engine provided for early testing and feature evaluation while the engine is still being worked on." From Godot's github. So yeah, if you found "jank", it's good because you can help getting rid of it, that's the entire point of dev versions.
@@friendlyfox2189 it'll never catch up to Unreal, but itll get to a point where it's a great choice regardless. Unreal will always be cutting edge technology, for better or for worse.
Eh, not really. Imo authoring 3D scenes in Godot is pretty clunky compared to Unreal where every tool you could ever ask for is readily available. Programming in Godot is definitely more pleasant though.
The devs said it'll be optional and it's just doing some trickery with the window scaling to make it look like it. The game won't actually be embedded into the editor the same way Unity is.
I'm hoping they will consider using NTFS Alternate Data Streams for storing the ID, it'd be more elegant than having a side-car file and work for moving the file in the file system without breaking anything. The only time it'd be an issue is if you move the project to another computer and then shift files around before opening it so that new ADS or side-cars can be created if it's not on NTFS.
Similarly to you, I cringed when Juan posted about the .uid files. Godot could definitely use some polish when it comes to handing the file system. Cool to see these features coming though.
This update is super exciting, there's a couple of really cool things being worked on I hope make it into 4.5, like part 2 of the game window where you have the option to have it embedded into the editor itself instead of a separate window.
sigh, you can make changes to nodes from the editor through the *REMOTE* tab in 4.3, we've had this feature for a looooong time. the only thing this changes is highlighting selected nodes and selecting in the game window.
@@CebGIN we can do that with the remote tab too, this just adds a virtual camera so you don't have to code it yourself. it improves workflow for some people, but lets not act like this is some "unity only" feature that was not possible before.
You can click on an object for example enemy or box on screen and you can edit its properties. In remote tab you have to find the node and click on it. Eventualls the game tab will also allow to have game embeded.
well, i might be biased cause i never really needed to touch the camera. usually i just tp the character and directly change values. I guess in a team game it can be useful but i always work alone, so i know where to find every single node since i'm the one who created everything in my project.
I think Godot has good enough usability, I think I would rather more structural changes to allow for better performance. Scene tree multithreading, GDScript compilation, Native C++ scripting, etc.
gds is already compiled to bytecode, and gdnative or making your own module allows c++ scripting for performance areas. godot has been good enough for years..
@@Digitalgems9000 This isn't true. GDScript is not compiled in any way. GDScript is directly interpreted. There have been proposals for JIT compiling, or bytecode compilation, but the godot foundation has passed these features up for more flashy 3D features, to appease corporate interests, for the likes of Meta and Microsoft. Sure, GDExtension is very powerful, and allows for C++ code, but it is fundamentally incomplete, not allowing for references to classes declared in GDScript, and GDExtension code itself not being able to be used as scripts on objects. Regardless all of these statements, scene processing being single-threaded is the bottleneck for Godot, as *all code in your game* is scene processing, this includes physics-engine tie-ins, such as _integrate_forces(), which heavily limits custom simulation. Stop parroting basic information to valid criticism, especially if you are factually incorrect.
@@addmix If you have to force the cryptic C++ syntax on godot users, at least use rust instead. In any case, gdscript is cleaner and easier to use, and I don't want to have to write C++ code just to move an object in a straight line. That's why it's available as extension and not as built-in. Thanks for the idea, but no thanks.
@@gokudomatic you can just say that you have no clue what you are talking about about, you don't have to make statements like this to make us understand. C# has native scripting in Godot. If you used C++ in godot, you'd understand that C++ code cannot be used as scripts, only being used as global classes, heavily limiting their use. C++ in Godot also requires a cumbersome setup procedure which is entirely unnecessary. Notice how I never mentioned anything about removing GDScript, instead I mentioned compiled GDScript, which would mean better performance. You have no experience with rust either, as it is even more cryptic than c++, due to the extreme complexity of the borrow checker while having the same godot-related shortcomings as C++. In the future, please do not make assertions about topics you are ignorant about
@@addmix I see, your line of argument is to insult others. I can tell that you love C++, and rust not so much since you call it more cryptic. It's your right, but you should keep it as your personal preference. Many don't want to fight with C++. By the way, C# is not scripted in Godot. It's always compiled. Sure, it's more convenient than GDExtension yet, but it's nevertheless compiled every time. Also, I heard recently about C++ scripting brought into Godot. I don't know if it's as module or as a GDExtension, but that project exists and it's already giving results. Maybe you should use that instead of trying to add yet another language in Godot itself. I get that you didn't want to remove gdscript from everyone, rather you suggest it to be compiled. But that doesn't make much sense. That language is not meant to write critical code. Compiling it would indeed make it faster, but that wouldn't be noticeable in 99% of the game. It's clearly meant that all parts that need performance should be written in C# or as GDExtension. Thus, the gain in compiling GDScript is almost zero. You might be pretty focused on raw performance, but you should see that it doesn't always matter. In the future, please respect other opinions.
do I see that correctly that once a property is favorited, it is removed from its usual place and appears exclusively at the top? if so, that's so silly... very unfortunate. I pointed that issue out early in the proposal, but looks like it's been ignored. literally the only possible result of the property disappearing from its usual place is this: user navigates to the usual place, is confused for a couple of seconds unable to find the property, then remembers that they favorited it earlier or the other day, scrolls up to the top and finally finds the property to edit. yeah, great time saving... this decision comes with no up sides at all, only down sides. but imho this entire feature isn't all that thoughtful anyway. keep in mind that you now have the expense of maintaining your favorite properties which I suspect is actually just as or even more costly than filtering or navigating to the property as before. by the time you realize that you are frequently accessing a property and that it would probably be useful to favorite it, you are likely halfway done implementing the thing you need the property for, and then it quickly turns into clutter as you no longer need the property and now need to go out of your way unfavoriting it... this why back then, I proposed a stack of recently modified properties instead. this would automatically and immediately be responsive to what you are currently doing and therefore have a much better shot at actually saving you some time. unfortunate that they gave manual pins/favorites the priority.
It's not silly or unfortunate at all. Using a favourites system means I get to decide what's in there. Your proposal takes that decision from me. Your proposal is therefore inferior. When it comes to UI customisation, the user is ALWAYS right.
@@Gladstone-hk9xw no. in this case, the manual control over pinned properties is counter-productive as explained. you may think that you will be using property x, y, z for the feature you are about to work on, but there's a high chance that something entirely different will end up being relevant instead. there's no way for the user to make consistently accurate predictions here. however, a stack of last modified properties would always reflect what you are actually doing and therefore needing right now without any requirement for cumbersome pin maintenance. my proposal is superior without a doubt. I can see a case being made for "why not both? let the user decide via editor settings", but the implementation order is unfortunate. there's no doubt in my mind that if Juan would have been the one to propose last modified stack and I the one to propose property pinning, the priorities would've been flipped and you would be fending for last modified right now.
LOVE GAMEFROMSCRATCH! I have to finish some project on Godot 3, and once again Godot 3 must exist and little more love for that engine. Just keep him alive, the makers know they must exist, I run full migration to fab, everything is there, and I change the engine. It's time. Must finish some old projects from Godot, the games are almost finish, that's all android games no big thing, Epic just pull to yourself everything. I don't know that have geopolitics and lows reasons, my opinion, that is it. Godot very nice keep alive in this turbulence, but I tell the version 3 is the something on what must more work, no future tu put on android just stability and politics and founding i think on version 4. Just keep going, this channel, I love this place it's nice to be a part gamefromscrach!
yeah but the issues like the light bleed and the culling errors are they fixed?? instead of wasting time on trivial aspects they should really must fix these issues.
I'm liking that real-time debug feature. It was something that was pretty annoying in previous versions that you couldn't make changes to the scene while running, just for testing purposes.
My main problem with Godot is Godotscript aka Python. Its the worst lenguage one can use. And no, C# dosnt make it better just more of a chaos. The should have supported BASIC.
@SenkaZver And what about the people who are legit game devs that DO have criticism towards Godot, or at the very least, the leadership behind the engine?
@@MrERJ1992they're probably spending their time criticising said real problems and not getting mad on twitter about culture war distractions from the real world.
I think Godot will be the top engine in a few years. With all the community support and unity dropping the ball, Godot is now next in line after Unreal.
"This year will be the year of Linux desktop". "FreeCAD is widely used in serious commercial projects". "GIMP is a replacement for Adobe products". These all statements are false. I don't see any reason why your assumption will be true. Godot still is not full replacement for Unity, and you're trying to compare it with Unreal.
*Links*
gamefromscratch.com/a-sneak-peek-at-godot-4-4/
-----------------------------------------------------------------------------------------------------------
*Support* : www.patreon.com/gamefromscratch
*GameDev News* : gamefromscratch.com
*GameDev Tutorials* : devga.me
*Discord* : discord.com/invite/R7tUVbD
*Twitter* : twitter.com/gamefromscratch
*BlueSky* : bsky.app/profile/gamefromscratch.bsky.social
-----------------------------------------------------------------------------------------------------------
how long to LTS release of 4.4?
Godot is getting closer (conceptually) to Blender in terms of contributions per release and that's really lovely
That's really good!!
And Godot is only 10 years old, meanwhile Blender is 30 years old!
I've seen that mantra on Godot subreddit eight years ago.
@@Capewearer well, blender 8 years ago isn't the same blender today as well :D
@@Beryesa. it was used in Spider Man movie for GCI decades ago.
Even 8 years ago Blender was good, unlike Godot.
I expected live editing in 5 but not in 4. Trully remarkable
I mean live editing has been around for a while? This looks like mostly just a quick way to select objects from the game window, rather than going to the remote node tree and selecting there. Super nice nonetheless though but you can pretty much do this in a more roundabout way in older versions too
yea we've always had live editing / hot loading.
so far, the new feature seems be just an alternative object picker.
it wasn't even necessary to go to the remote scene tree like joshua suggests.
you can click on objects/nodes at runtime in the editor's scene viewport just as well, even allowing you to do live edits with mouse drag & drop rather than to type in values.
perhaps once the game window can actually be embedded into the editor it might become a little bit more interesting, but currently I don't see all that much of a point.
@@joshuaanderson6609 I was thinking the same thing. I've seen people before, mention that Godot is missing the feature to interact with the running Scene Tree from the editor, but I think it is just that they never discovered the "Remote" tab.
It is nice they make it more visible and the introduction of a debug camera means we wont have to add one to every 3D project any more :)
@@JakobKobberholm I think the remote tab is just not as intuitive or obvious as it is in Unity. Unity forces you to run the game in the editor every time you hit play, while Godot does not. It's easy to misinterpret that and just get used to running the game, stopping the game, making changes and then running it again.
That Physics snap looked like it was sending the Ray form the mouse position, so when passing between the little gaps it cast to the floor
I'm not sure how they implemented it. But it'd be great if it could snap to walls and ceilings as well.
@@jefreestyles I'm pretty sure that's how it works. It sends a ray from the mouse pointer into the game world and whatever gets hit first is the snapping surface. You can actually see it snap to the side of the boxes in the video.
Sma ething as warframe its whatever surface is under the mouse and then the object should be perpendicular. Its the simplest thing
It appears to attach to the walls of the boxes, not sure if it places the origin of the object in the collision location or if it then uses the collision mesh of what you're moving to push it out form the point. I think it's just finding the location and not taking collision of the placed object in mind, but it wouldn't be too hard to add either.
The main issue if it tried to fit the placed object is if you hover over a spot without room, it would have to detect that so it can skip fitting the object or you'll get the jank of overlapping objects suggesting the box you are placing belongs on the moon.
@jefreestyles That would imply having to differentiate between walls and ceilings. And it's not an easy thing to do...
Being able to have transform at the top of the inspector is a welcome change.
The shader compilation changes are huge for 3d games, no more making buffer screens to prevent shader comp lag, its fixed now!
It's been frustrating, because they fixed it when 3.5 released, but it wasn't fixed in 4.0
Man, they really are building Godot up. I got excited to see that i can interact in-game like in Unity. I need to start messing with Godot more.
Same
You still cannot use both tabs together like you can in unity. Honestly, this godot engine is just backwards. It is inferior to unity 5 in so many ways and unity 5 launched a decade ago.
@@leeoiou7295 oh shut up. in godot I can change values of nodes and have them update in game and then remembered when the game stops, you can't do that in unity.
I can edit the labels on a panel, have them show in game, and then stop the game and they are saved.
@@leeoiou7295 So stop watching videos about it, then. Oh sorry, I forgot - you're a wannabe Godot contributor, but you found out you haven't got the skills for it and have had a chip on your shoulder ever since.
@@leeoiou7295When you code it.
Honey wake up, new Unity version just dropped and for some reason has a blue robot on the cover.
Seriously tho, this changes are amazing, can't wait to try them out.
I remember shortly after Unity changed its pricing, someone opened an issue about live editing being a blocker for people switching to Godot, and people said anything related to it would take a lot of resources (people, time and money) or would be impossible. Just over a year later, and it's in beta. Open Source is amazing.
This is one of the few channels where I'm always excited to see new content!
the "Game" editor for better runtime debugging is amazing, i hope the feature make it through the 4.4
Live editing, REPL and Typed Dicts are going to be HUGE for my game projects!
Typed Dicts are gonna be great for data entry type things. Maybe "Structured Dicts" is a better term though.
Yes I am. Also looking forward to typed dictionaries.
Me too
This update is nothing short of bliss
Native dialog got improvement for all major platform (desktop & mobile)
For camera native device, currently only works on MacOS and iOs, someone still workin on it I believed
Prolly "the native things" will has more impact for non game developer (app developer) then game developer will pleased by that (native notification, bluetooth, & etc.)
i love the favorites feature. godot is now like VSCode used to be - developers keep finding great quality of life improvements.
I hope they could offer two choices for the game tab. The current operation of the scene tab offers a unique approach by having a single window appear, making it convenient for me to shift it to another monitor and experiment. This is due to my aversion to having the game and scene tabs next to each other in Unity on my 24-inch screen, as it feels quite limited. It’s possible that some people who have spent many years using Unity and have a wide 21:9 monitor are currently critiquing me, but that’s exactly what I desire.
Godot not having a runtime inspector and easy testing was the biggest annoyance for me.
The remote inspector thing they had felt more like a bug than a feature since the changes were being saved in the editor.
Look like Godot is getting closer to unreal-unity debugging and testing.
Favorites and editing by clicking the game window are a lot more significant than 4.3 so ill switch to this once its ready.
I think they don't set it in the metadata folder is because they would then have to track a mapping between the file and the metadata.
Imagine you have a custom resource called "character_data.tres" inside the character folder and for some dumb reason you also have a resource called "character_data.tres" inside the enemies folder. With the uid file being side by side with the main file, the editor will move both when you move the main file and users are instructed to move both if they do it outside of Godot.
With the file being on the metadata folder, first you have the issue of two "character_data.uid" files inside the metadata folder. What should they do? Replicate the project folder structure inside the metadata folder? Add some sufix to the file name? Second, there is the issue of users moving the file outside of Godot. Now the user needs to remember this uid file exists and needs to find it inside the metadata folder.
So I think the reason they didn't do it that way is because it wouldn't work.
this is absolutely insane! i'm definetely looking forward to work with godot 4.4
ok any sort of effort towards live editing is a BIG W
Thats pretty cool. Now if they can map the tilemap detachable or mountable on other sides. You lose so much screen real-estate while trying to make maps and it keeps conflicting with the file system being down below.
They're slowly making the interface more approachable as time goes on.
@@GoblinArmyInYourWalls Very true. Last time I tried to learn gamedev and Godot it was 3.2. I've enjoyed watching Godots improvements since but havnt really jumped back into it seriously.
@@ShaneUrbas don't blame you. Game dev is like playing an instrument. You have to do it everyday, which is tiresome
Since 4.x the windowing has improved so much, everything is detachable
@ not tilemap though.
The whole goal of UIDs is to allow users moving around files in their native explorer without breaking their game (Godot cannot keep track of files if they get modifed/moved around outside of it, it's not possible). As a consequence, those RID files are next to their respective file, so that users can move them along with the original file. Having RIDs stored in a metadata folder or file would basically defeat the only reason why those got implemented.
Edit: Also, I'd like to add something. You know, Godot devs aren't that inaccessible. I promise maintainers put a lot of thought in such impactful decisions and you'd probably understand those decisions a bit better if you reached out. I think most of us are pretty happy to answer such questions, especially considering the wide audience you have.
Super happy to have the uids so moving resources around is more seamless in the editor. While I’m not remotely clever enough, I do understand the prickly points around having to manage more files within the explorer
I've had nothing but UUID problems. There have been times where my entire project got bricked because of UUID corruption. It's not fun having to rebuild a project because of jank shit in Godot. Right now things are fine, and if I need something moved, deleted or renamed, I do it in the Godot editor so things get updated. But every once in a while, I have to go fix UUID errors in my resource assignments.
Or they could just add relative paths 😅
niksamer la réinsertion 🎉
@@Kapendev What do you mean by relative paths?
I agree...
I think there should be some "Metadata" folder to house most things such as icon.png, readme etc... Leaving just project.godot and the project folders out.
I like the way visual studio does to these stuff you add straight to the solution - it creates a folder named "Solution Items".
Usually, IMO, the less stuff in your face (ie in your project root), the better.
They recently uploaded status about the foundation and I don't know what to think about the part about trademarks. I hope It's not the start of the road of making the engine less open
all big open source projects (or at least ones im aware of) protect their project identity like that. i don't think there's any cause for concern here.
@@stinky_mousepad that's wishful thinking. Trademarking is the opposite of freedom. You may be sued by the distributing files with trademark involved. That's why RHEL clones exist and have tedious work for removing any copyrights from sources.
And Red Hat already exploited the trademarks - you can read about that, how do they block access to the sources because they're trademarked.
the part with the crate is not a bug when it falls inside, it's applying a normal to the surface you point your mouse on and places the object along that normal vector.
if you put your mouse on a horizontal surface the normal will point up and will place the crate on top, but when you point on wall for example the side of that box, the normal points to left, (
I really hope those UID files are optionally generated if/when needed instead of autogenerated for everything. I rarely if ever use the newish unique id feature since if you plan your project structure well it’s mostly unneeded since it really only comes into play when refactoring. It also seems worse for reusability across multiple projects
Is that what this is about??? I thought the UIDs were only for the engine to keep track of files... That's a kinda stupid feature ngl.
No they are not i see so many people who dont understand resource files. They are really important when working together with version control systems since your not committing the .godot folder thus everyone cloning the project has other uids for the same resources. For that reason scenes get random changes when editing across different machines or people which put noise in git diffs or breaks project when combining merge conflicts
Yes they are also for refactoring youre right sry its 2 am didnt want to come of as rude ❤
There's plans to put the game inside the tab before 4.4 is completed for those who don't want the separate window. Which is why you have the tab in the first place now. Technically you had the remote view before, but you had to use the 3D window to pick items which lacked the live updating of objects.
Making it operate through the game window itself seems like a pretty good idea, in unity you wind up having objects moving in the editor window that then have to reset when you stop playing. In Godot it's always been more clear that your live changes are just modifying the running game not the scene itself, mostly because you can't even see the changes in the view. Now with it being synced in the game view you still have the separation of states but will regain the ability to pick objects and look around the live world to see what's going on.
with you on the UID system, kinda a big change for a small portion of people who have asked for it
OH MY GOD, THIS GAME FEATURE
Is there a way to save the changes In the game mode ?
that game tab is going to be so useful.
I always had to make my own hacky debugging tools for this
OH THAT FAVORITE PROPERTIES OPTION IS SO GODDAMN NICE HOLY SHIT
I wonder if it's specific to just the node you favourite it on or any node of that node type
"If Godot is so good why isn't there a 4.4th one?"
1:14 Ah yes, a ray casted ray, of course
How do you access a resource using uid ? I wish you explained that. But yes, cluttering the file system is annoying. .meta alone drive me crazy 😂
1:15 everything happened there just as should be my dawg just look at your cursor, where you positioned it, the box was trying to align it's pivot there, and the pivot of the box is probably at the box's bottom
Nice! Such a super useful update. Gimme gimme.
Sooooooo hyped for the interactive game mode! That was one of Godot's biggest shortcomings compared to Unity and Unreal.
Edit: AND A REPL?! This version is HUGE!
Those are honestly just mid features. They aren't even new features, just some editor UI to make it slightly easier. Ubershaders are a more important addition, not mentioned in the video for some reason.
Just need a complete terrain editor now please
No real reason to put one in godot, terrain can be done in too many different ways. Get an addon
@GoblinArmyInYourWalls add ons are OK, but could be better. A seamless one integrated into godot would be much better. For me personally.
@@polaritymakina8440 but only for you, it wouldn't fit many others needs and would only serve to be a problem for most games. An addon that does it the way you want specifically would be better for everyone.
Every time I watch your videos I wonder if you have any projects? Do you work as a developer in some studio or maybe developing a project as an indie developer? I would love to look if you have something!
Looks like when you make a video on one dev snapshot, the next snapshot comes out the following day. Can you make a video for Dev 6 tomorrow? Really looking forward to Dev 7 on Saturday. Thanks!
that evaluator thing is soooo good.
Godot keeps cooking with updates
Thanks for sharing this update, Godot 4.4 looks promising.
Is the scene graph updated in game mode so you can select nodes there as well?
Hm I wonder if the new UID update will decrease the amount of times I have to blow up my .Godot folder because some import file got corrupted during live play. It's a neat new feature. I think the .UID files should be hidden and move automatically if the main file is moved. But I think that's an OS thing and might require more Registry configuration.
What we need or I need, is:
A picture in picture feature, so I can have a camera view not take up the entire viewport.
Embeded run time game window.
A means to view 2d elements over 3d without running the game, or needing to overlay snapshots.
An over haul of the animation system, that isn't full of jank as it is now (what part of Godot isn't? lol)
Visual shader features that are available else where but not in Godot. Also for jank to be fixed.
Material icons to retain themselves and not get mixed up with others or compoletely lost.
All jank addressed, without excuses.
I'm on the edge of trying Unity to see if it's a viable alternative. The grass seem so much greener over there. The only thing I won't like is load and compile times, or other shit the corporation pulls. Also C# seems quite complex and at times complicated.
There’s a plugin that lets you view a camera preview which GFS has reviewed in his Godot plugins video, if it helps.
Go try Unity. No sense in using an engine that you dislike.
Man... Just let the kids fo things that they like, if you don't like them go to another site where they talk about the things you like instead of being an asshole @@addmix
The UID file could be moved into the NTFS Alternate Data Streams. Though this wouldn't doable in other operating systems.
Yeah the UID files is something I don't know how I feel about. Have or not have, and along with file or metadata folder. Too many pros/cons for all, my brain can't process.
I think they should make that game mode just like Unity where your game runs inside the editor. One of the things I don't like about Godot is that pesky separate game window.
they said they're working on that
I'd so love that Unity-style game window/editor window dual mode...
If that fixes the issue of double VRAM usage, that would be really great.
There already exists an addon for embedding the game window on the editor preview. But it seems they are trying to implement it officially
REPL is a gamechanger for debugging
The new Game tab is AMAZING!
Excellent features, thanks for the info! I wonder, for that "physics placement", would there be a way to do that on walls? for instance, I have a made a light switch but I want to be able to place it directly on the wall with ease... Is there a way to do that?
for game mode they should put window into editor window someday, I hope
8:05 That's similar to ".meta" files in Unity.
REPL is big life saver!
I used Godot to make a small light game for my friends in about 2 weeks, uploaded to Itchio so they could web play it and only half of them could run it. Now I don't use godot. Hope they can fix that.
Yea, you are going to face build issues on any engine. Increase your troubleshooting skills
If the live changes are done on the inspector does that mean I'm interacting on the Remote tab on hierachy?
nevermind, I found "Remote" object name on the node in inspector
i feel the same with the uid stuff directly on filesystem, it's not a good approach.
So the Game tab is basically just a better Remote tab
I can't wait that they add a meshlet / cam culling nanite-like system with advanced rendering features to compete with Lumen, substrate and Megalights. Then, it will be the ultimate game engine.
When that happens, I predict it would be as an extension, not as a built-in feature. The reason is that makes the engine much heavier, and it's only useful for a few kinds of games.
@@gokudomatic why not, all of this is can be implemented as optional features.
I really like the engine, especially the lean, polished and consistent part of it, I just feel it's a shame it's stuck with indie games only for now.
If it had advanced graphics capabilities, it could be the new base for solid franchises' updates such as simulators, or RPGs with higher graphics needs and a bunch of Unity ports.
So far, the low poly/lambertian look of all Godot games make it a VERY NICE proof of concept, but unfortunately, rarely the final decision for true mid to large scale productions.
you will need to wait long until that happens. even the bassic rendering features are kinda unpolished and badly optimized.
Wait a decade, Vulkan was implemented 7 years after standard release. Besides that, it seems that a few teams really implemented virtual geometry. It's not been like wide Vulkan adoption.
Nanite is a flawed system. The current auto-lod system fills a very similar purpose though.
My PR is still not merged :(
You and 3,000 others lol
ha I recently started using godot 4.3 and I've been looking how to do REPL like in Visual Studio and IntelliJ... no wonder why, it's not in yet lol
I like everything I saw besides the metafile non-sense nightmare that unity uses. To me, why can't we just have a big table that we setup with aliases instead? Then we change the file path, we change the dictionary look-up for the path. It'll be great if it's somehow auto-generated. Like files are being tracked by the system and updating this big table. It's human readable and easily fixable. Seeing random ass numbers in editor files makes for too much indirection. I've moved on to Unreal now and they have a renaming system call Core Redirects. I don't know how much better it is in practice yet but at least it's freakin human reading and works similarly to what I described. Metafile stuff can burn.
4.4 dev5 has many interface errors, for example, a flashing pop-up menu.
also favorites does not work correctly, it does not change the parameters
It's an alpha build for a reason
Yeah, I suppose it's not ready for production, being an alpha version...
@@TheHelderVinicius There used to be a saying "If you going to do something, do it right", and "Practice doesn't make perfect. Correct practice makes perfect." There's no excuse releasing jank shit.
@@rremnar "Dev snapshots are in-development builds of the engine provided for early testing and feature evaluation while the engine is still being worked on."
From Godot's github. So yeah, if you found "jank", it's good because you can help getting rid of it, that's the entire point of dev versions.
@@rremnarThis isn't a "release" but rather bugtesting. But we both know that already, so why don't you just stop trying to push your agenda?
code does what you tell it to do, not what you want it to do
Very nice!
Ah... The Unity feature that kept me from using Godot is finally here.
The UX is still bad, but at least it's here 🎉
I wish godot could offer more in performance with skeletons
That's actually still really clunky, but at least they're working on it.
Wait wait wait…interactive editor inside of VR!?!?
uid is same as unity meta files, and it will have same workflow
Embed the game window already. I know there is a plugin to do this but it really should be there as standard.
There is a PR for that. Gonna be merged soon.
The more I use Godot, the more I realize how bad UE5 is from user experience standpoint.
really?
yeah thats why I never chose unreal over godot even with its advance features, plus godot will catch up eventually in terms of 3d capabilities
@@friendlyfox2189 it'll never catch up to Unreal, but itll get to a point where it's a great choice regardless.
Unreal will always be cutting edge technology, for better or for worse.
@@friendlyfox2189 it will never catch up.
Eh, not really. Imo authoring 3D scenes in Godot is pretty clunky compared to Unreal where every tool you could ever ask for is readily available. Programming in Godot is definitely more pleasant though.
I'm going to be so mad if they force the game render to be in editor. Its one of the best things about Godot is it doesn't do that
The devs said it'll be optional and it's just doing some trickery with the window scaling to make it look like it. The game won't actually be embedded into the editor the same way Unity is.
I'm hoping they will consider using NTFS Alternate Data Streams for storing the ID, it'd be more elegant than having a side-car file and work for moving the file in the file system without breaking anything. The only time it'd be an issue is if you move the project to another computer and then shift files around before opening it so that new ADS or side-cars can be created if it's not on NTFS.
Everything seems to be about 3D now, missing ANYTHING for 2D...
2D is production-ready, 3D is not.
3D is not so mature and developed as 2D already is in the engine
Similarly to you, I cringed when Juan posted about the .uid files. Godot could definitely use some polish when it comes to handing the file system. Cool to see these features coming though.
If you read Juan messages often, you'll die of cringe. Especially when he claimed in Mastodon that "he is too innocent for that world".
This update is super exciting, there's a couple of really cool things being worked on I hope make it into 4.5, like part 2 of the game window where you have the option to have it embedded into the editor itself instead of a separate window.
sigh, you can make changes to nodes from the editor through the *REMOTE* tab in 4.3, we've had this feature for a looooong time. the only thing this changes is highlighting selected nodes and selecting in the game window.
Also being able to move the camera for debug
@@CebGIN we can do that with the remote tab too, this just adds a virtual camera so you don't have to code it yourself.
it improves workflow for some people, but lets not act like this is some "unity only" feature that was not possible before.
sneak peak
i don't really understand the game tab knowing we already had the "remote" one
You can click on an object for example enemy or box on screen and you can edit its properties. In remote tab you have to find the node and click on it. Eventualls the game tab will also allow to have game embeded.
This one is much more powerful!
Not sure that we could use free camera with Remote, for example ;-)
well, i might be biased cause i never really needed to touch the camera. usually i just tp the character and directly change values.
I guess in a team game it can be useful but i always work alone, so i know where to find every single node since i'm the one who created everything in my project.
@@kiryonnakira7566 Same! But that's still a good addition for community ;-)
At this point just stick the game to the game tab and you have a real time debugging tool. I like what I see :)
yeah the way it works right now is really weird
They are working in this
Can't believe I'm here before a bot
I think Godot has good enough usability, I think I would rather more structural changes to allow for better performance. Scene tree multithreading, GDScript compilation, Native C++ scripting, etc.
gds is already compiled to bytecode, and gdnative or making your own module allows c++ scripting for performance areas. godot has been good enough for years..
@@Digitalgems9000 This isn't true. GDScript is not compiled in any way. GDScript is directly interpreted. There have been proposals for JIT compiling, or bytecode compilation, but the godot foundation has passed these features up for more flashy 3D features, to appease corporate interests, for the likes of Meta and Microsoft. Sure, GDExtension is very powerful, and allows for C++ code, but it is fundamentally incomplete, not allowing for references to classes declared in GDScript, and GDExtension code itself not being able to be used as scripts on objects. Regardless all of these statements, scene processing being single-threaded is the bottleneck for Godot, as *all code in your game* is scene processing, this includes physics-engine tie-ins, such as _integrate_forces(), which heavily limits custom simulation.
Stop parroting basic information to valid criticism, especially if you are factually incorrect.
@@addmix If you have to force the cryptic C++ syntax on godot users, at least use rust instead. In any case, gdscript is cleaner and easier to use, and I don't want to have to write C++ code just to move an object in a straight line. That's why it's available as extension and not as built-in. Thanks for the idea, but no thanks.
@@gokudomatic you can just say that you have no clue what you are talking about about, you don't have to make statements like this to make us understand. C# has native scripting in Godot. If you used C++ in godot, you'd understand that C++ code cannot be used as scripts, only being used as global classes, heavily limiting their use. C++ in Godot also requires a cumbersome setup procedure which is entirely unnecessary. Notice how I never mentioned anything about removing GDScript, instead I mentioned compiled GDScript, which would mean better performance. You have no experience with rust either, as it is even more cryptic than c++, due to the extreme complexity of the borrow checker while having the same godot-related shortcomings as C++.
In the future, please do not make assertions about topics you are ignorant about
@@addmix I see, your line of argument is to insult others. I can tell that you love C++, and rust not so much since you call it more cryptic. It's your right, but you should keep it as your personal preference. Many don't want to fight with C++. By the way, C# is not scripted in Godot. It's always compiled. Sure, it's more convenient than GDExtension yet, but it's nevertheless compiled every time. Also, I heard recently about C++ scripting brought into Godot. I don't know if it's as module or as a GDExtension, but that project exists and it's already giving results. Maybe you should use that instead of trying to add yet another language in Godot itself.
I get that you didn't want to remove gdscript from everyone, rather you suggest it to be compiled. But that doesn't make much sense. That language is not meant to write critical code. Compiling it would indeed make it faster, but that wouldn't be noticeable in 99% of the game. It's clearly meant that all parts that need performance should be written in C# or as GDExtension. Thus, the gain in compiling GDScript is almost zero. You might be pretty focused on raw performance, but you should see that it doesn't always matter.
In the future, please respect other opinions.
do I see that correctly that once a property is favorited, it is removed from its usual place and appears exclusively at the top? if so, that's so silly... very unfortunate. I pointed that issue out early in the proposal, but looks like it's been ignored.
literally the only possible result of the property disappearing from its usual place is this: user navigates to the usual place, is confused for a couple of seconds unable to find the property, then remembers that they favorited it earlier or the other day, scrolls up to the top and finally finds the property to edit. yeah, great time saving... this decision comes with no up sides at all, only down sides.
but imho this entire feature isn't all that thoughtful anyway. keep in mind that you now have the expense of maintaining your favorite properties which I suspect is actually just as or even more costly than filtering or navigating to the property as before.
by the time you realize that you are frequently accessing a property and that it would probably be useful to favorite it, you are likely halfway done implementing the thing you need the property for, and then it quickly turns into clutter as you no longer need the property and now need to go out of your way unfavoriting it...
this why back then, I proposed a stack of recently modified properties instead. this would automatically and immediately be responsive to what you are currently doing and therefore have a much better shot at actually saving you some time. unfortunate that they gave manual pins/favorites the priority.
It's not silly or unfortunate at all. Using a favourites system means I get to decide what's in there. Your proposal takes that decision from me. Your proposal is therefore inferior. When it comes to UI customisation, the user is ALWAYS right.
@@Gladstone-hk9xw no. in this case, the manual control over pinned properties is counter-productive as explained.
you may think that you will be using property x, y, z for the feature you are about to work on, but there's a high chance that something entirely different will end up being relevant instead. there's no way for the user to make consistently accurate predictions here. however, a stack of last modified properties would always reflect what you are actually doing and therefore needing right now without any requirement for cumbersome pin maintenance.
my proposal is superior without a doubt. I can see a case being made for "why not both? let the user decide via editor settings", but the implementation order is unfortunate. there's no doubt in my mind that if Juan would have been the one to propose last modified stack and I the one to propose property pinning, the priorities would've been flipped and you would be fending for last modified right now.
LOVE GAMEFROMSCRATCH! I have to finish some project on Godot 3, and once again Godot 3 must exist and little more love for that engine. Just keep him alive, the makers know they must exist, I run full migration to fab, everything is there, and I change the engine. It's time. Must finish some old projects from Godot, the games are almost finish, that's all android games no big thing, Epic just pull to yourself everything. I don't know that have geopolitics and lows reasons, my opinion, that is it. Godot very nice keep alive in this turbulence, but I tell the version 3 is the something on what must more work, no future tu put on android just stability and politics and founding i think on version 4. Just keep going, this channel, I love this place it's nice to be a part gamefromscrach!
Godot is getting better and bettter. This is truly my skibidi.
yeah but the issues like the light bleed and the culling errors are they fixed?? instead of wasting time on trivial aspects they should really must fix these issues.
Good...
I'm liking that real-time debug feature. It was something that was pretty annoying in previous versions that you couldn't make changes to the scene while running, just for testing purposes.
My main problem with Godot is Godotscript aka Python. Its the worst lenguage one can use. And no, C# dosnt make it better just more of a chaos. The should have supported BASIC.
and yet i cant build for android using c# (i tried 20 times) im back to unity now
Have you submitted a bug report?
@@brahillms1374 no , it might be just my problem because everyone can export but ill wait for some updates and try again then ill report a bug
I love godot so much. Everything about godot is just so great!
Apart from the rainbow cult running it.
@SenkaZver And what about the people who are legit game devs that DO have criticism towards Godot, or at the very least, the leadership behind the engine?
@@MrERJ1992they're probably spending their time criticising said real problems and not getting mad on twitter about culture war distractions from the real world.
This is HUGE 😍
You sound different. Flu?
I think Godot will be the top engine in a few years. With all the community support and unity dropping the ball, Godot is now next in line after Unreal.
"This year will be the year of Linux desktop".
"FreeCAD is widely used in serious commercial projects".
"GIMP is a replacement for Adobe products".
These all statements are false. I don't see any reason why your assumption will be true. Godot still is not full replacement for Unity, and you're trying to compare it with Unreal.
GODOT plsssssss update the mobile version because it's just SUCKS