What kind of vectors?
Without further information, right-open is usually the best choice.
What kind of vectors?
Without further information, right-open is usually the best choice.
In that case, I might add an optional boolean toggle for use as a range. But the default should be inclusive to stay consistent with the float method... I think.
I already named the variables minimum and maximum, so inclusive should make more sense. The code generates a vector within a square/cube defined by 2 other vectors.
Those are all good questions, and yes.
I'm a fan of inclusive min, exclusive max for rng. It behaves consistently with decimal numbers in a readable way, for example int(0,100) can return 100 different integers. x<0 has a 0% chance of happening, x<50 is 50%, x<100 is 100%. If you swap with dec(0,100) you could now get 99.999 but x<50 is still exactly 50%
I do agree with amio on consistency and making sure each method added is worth the abstraction.
Realistically, whichever one is the most commonly used in your project/framework/language/whatever, so it doesn't stick out as an inconsistency. If you're wondering about this now, it's a potential point of confusion for anyone who needs to read the code, including future you.
If you want to be really picky about engineering: are you sure you do need to write the function at all? How does the new function save time/effort or make code easier to read and write? Do you write a lot of code where you need random vectors, and does "random vector" mean the same thing in all cases? Would the function itself just make more code that needs maintaining, possibly indefinitely?
You pay testers for being temporary employees that helped build your game, not the other way around...
send it over
charging to test isn't testing... that's just selling yet another unfinished product.
0/10 for charging people to test stuff
-10/10 because of the platform limitations
Editor: Increase available space for array properties
This is a good change. I cant see shit in Arrays.
If you pack 10 objects in a 4000x4000 picture, but it has like 500px margins on every side, you're wasting memory for literally no reason, that's the point I wanted to bring attention to. Unused image space consumes memory. A spritesheet that only goes to 600px horizontally, but the image file has 1200px, it's wasting resources.
Thank you for the reply.
So this is similar to a tilemap in how you pick tiles based on their position on the map. I can draw sprites with just refernces to this sheet that sounds pretty good. I gotta look into this for when i spawn large groups of enemies with various gear.
For now on my main characters I'm sticking with the 10 sprite nodes stacked.
@ICastFist @Fizz i see this is godot specific and I'm not 100% sure how godot handles it but the normal way to store your image data for sprites like this is to index them from a packed sprite sheet (there's tons of sprite packers out there, lots of animation tools have them built in), so instead of each obj being a 1000x1000png to use your example you may have a 4000x4000png with 10 objects packed in it.Most engines will handle this for you, you just have to pack the assets correctly for it.
One sprite node for the naked character, another for each part of armor (helmet, chest, pants, for instance). If every armor sprite is equally positioned in its image, you can then load different files as needed - on an equipment change, call a load("res://armor2.png") for the Texture of the armor node. You'll also need to keep the file path string saved somewhere, likely within the rest of the armor's attributes
While it may not be an immediate problem for you, keep in mind that each .png image the game keeps loaded will use some VRAM, according to its total size. For instance, each 1000x1000 png image will take ~4MB of VRAM. I recommend cropping as much unused vertical and horizontal space as feasible.
Less a question of hardware I think, as Godot had been not quite as performant as other engines for a long time. Edit: read article lol, is in fact native
Considering many ipads have M series chips, I would assume it feels pretty good.
Wow. That’s pretty impressive. I wonder how it feels for “serious” work.
from the looks of it the apple arkit is stuck on godot 3 othereise the google arcore plugin mostly works.... it does have some issues but if youre fine with landscape mode and no image tracking you should be g, the pr draft on their github does have support for portrait mode as well as plane and image tracking but doesnt work properly after 4.4.1
Oh well! Thanks anyway.
Phone based AR is a mess because while openxr did make some specs around it, google and apple never adopted them, so you need to use their proprietary bullshit instead. I don't have any experience with it myself.
https://forum.godotengine.org/t/does-godot-4-support-ar-for-android-and-ios/88658/3
Hey, good job! I wanted to ask someone that did anything XR with godot, how feasible is making a phone AR app with the engine? All I ever see in the docs is how to use headsets and I just want to spawn a 3D dinosaur behind some bushes. It's cool if you don't know!
Congrats, good job!
That looks cool, I have to try that!
The crank looks like a fun mechanic, nice work!
I thought it'd be obvious, but I specifically want vector/polygons. I don't want to see the pixels and I don't want a triangle to be a thing that needs a lot of redundant pixels to look sharp.
And I just really think the tech is neat.

Well, not just neat, but that the tech could be used further than those that pioneered it.
Honestly I wouldn't sweat too much about your scene structure. Just make the thing and when something starts becoming painful to use, then it might be time to reorganise things.
The incremental search feature on the file system tab in godot is a godsend for finding things in messy projects. Which all projects end up being to one degree or another.
If you want some sort of example structure to follow, you could take a look at how the godot-xr-tools / godot-xr-template stuff is done, though it might be overkill. Obviously that is for VR stuff but most of the structure is general.