#1.20.0.22 - Preview
1 messages Β· Page 2 of 1
fow is really annoying when you changing the movement component on the player
Yes
fov is the most wanted replaymod feature btw
Im genuinely curious...how would replay even work bc replay mod exports a file for you to edit right?
xd
it creates images of every frame
then we create video out of it
thats why its always smooth even if ur pc is trash
creating replay for bedrock is impossible cuz we can get and set packets
at most we can safe everything api offers and re produce as much as possible
Kayla can you ask navi to fix the js eventData.hurtEntity.getComponent("minecraft:health").current or js eventData.damage properties please π
This is a legitamately broken thing that needs to be rectified Con
My insanity will not end without it
say what is problem btw
in Stable js eventData.hurtEntity.getComponent("minecraft:health").current is able to step into the negative values. output message is it's current health in the entityHurt event in 1.19.8# stable.
eventData.damage outputs a flat amount based on the tool being used to hit the entity
so regardless of the remaining health an entity has, eventData.damage will output the same.
In Preview, the .current health property is locked to 0 if the entity were to die
Shouldn't this belong to bedrock oss
This means that there is no longer a method to accurately determine the damage an entity was given
ask memcy if he could return negative health values, but idk if thats solution, maybe solution is supporting damage float value in entityHurt right?
^
the solution here is making eventData.damage inherently check for js if (eventData.hurtEntity.getComponent("minecraft:health").current < 0) { eventData.damage += eventData.hurtEntity.getComponent("minecraft:health").current < 0; }
I'm in the OSS server but I've never sent a message nor looked at it
so I'm not familiar with anything going on there
There is no mention of this change in any of the 1.20.0.2# posts either
Again, there is no way for the game changelog to mention every changes in Script API.
Then it's not a full changelog
yeah
also in oss's script api channel we discuss api stuff with dev u can tell there for better response
I would rather not have a few thousand lines of script api changelog be in official game changelog lol
That's not what I meant. I don't need to know each line of code that was changed or optimized, I need to know how things changed functionally, like the health component no longer being allowed to step into negative values
or that a vanilla-data module was added
they only seem to log major changes
I think these apis are being looked at soon - basically any experimental api will be looked at as we move more to stable.
its not api sided, API dont care if entity has less then zero
so its internal MC thing and no API one
Are you in preview?
ya
ya, i just wanted to say its not API fault π
camerashake and camera should defo be moved into 1 command in the future would make sense. However inputpermission affects the inputs by the player makes more sense to be separate as the camera command is just changing/affecting how the player sees the world around them not the way they move or look around
I'm a huge fan of the noun-verb thing they've got going on lately. I love /music, for example, followed by stop, play, queue, and volume.
Makes sense, you have something, what do you want to do with it
Does anyone know what happened to the getScore() function in the 1.20 update?
When using it, it only returns 0 and can't seem to grab the players score or even the objective anymore..
Function:
function getScore(target, value, useZero = true) {
try {
const objective = world.scoreboard.getObjective(value);
if (typeof target == "string")
return objective.getScore(
objective
.getParticipants()
.find((player) => player.displayName == target)
);
return objective.getScore(target.scoreboard);
} catch {
return useZero ? 0 : NaN;
}
}
Oh and trying to make Forms seem to be really weird now too and keeps mentioning about not have privileges.
It's target.scoreboardIdentity in 1.20
okay, thanks
THE REAL CIOSICSHISAH YTOUTUBE CHANEL?
Ooo, ciciβs yt channel?
Subscribed
Subscription with no bug upvote. π¦
I've seen lots of good usage of camera in the wild - has anyone found any weird bugs with it?
not yet surprisingly, cameras are usually really finicky but this seems surprisingly stable
I do have a small piece of feedback, it's not currently possible to find the rotation values in vanilla, without add-ons. Would be nice to have current rotation displayed in auto-complete similar to position. Or perhaps show rotation with "show coordinates" enabled
@hoary tendon would there ever be the ability to use the script api to insert custom bezier values for more complex camera animations?
Good suggestion. This would be out of scope for the camera work, but is a good suggestion to improve the "Show Coordinates" feature IMO.
yeah Creator APIs for Camera are planned, and we've talked about Bezier curves for more complex movement. Probably not for the initial release though.
your angel wings are showing
The most helpful feedback for camera right now is in this order:
- Are there any bugs with what we've shipped?
- What critical attributes are we missing?
- What is the most important next camera preset?
We cringe a little when we see camera being used with armor stands right now π Would be good if we could ship enough functionality to avoid armor stand hacks.
What are people doing with armor stands?
π whats wrong with TP to armor stands
If creators stop using /tp and armor stands, I will consider my career a success.
π
π me on my way to use tp and armour stands to annoy mojangsters
I think this is how a bunch of folks are doing 3rd person cameras
Care to elaborate?
By using an entity to manipulate position and rotation, a lot more can be done with the new /camera command.
550
A data-driven 3rd person camera with enough attributes, I guess?
Oh, they just need a target then, huh? I guess a scripting interface will be great for that.
Non scripting interface wouldn't hurt too, yk π«
I'm kinda a full convert now, sorry.
could this be a part of editor mode, or at least an extension
Hyacinth try not to pester about replay mod challenge, diffculty impossible
yeah replay mod is hard - the gamestate management scares me.
iβm not, just want bΓ©zier
Seems like here armor stand is used to store and modify current camera position, which is what the camera command lacks - modifying camera position with relative coordinates to the camera itself. So you can't send a command that'd tell the camera "move 1 block up" without telling where that camera currently is
I've been called out
But I think it's a valid suggestion to think about how camera could evolve and be editable in Editor. If I imagine a far future state - would be cool to have a cutscene editor in Editor. But lots needs to happen before we can think about that.
Commit crimes, get caught
like my, suggestion?
if u don't do it, i will :]
Wait till she hears about all the hacky workarounds we do
King will beat you to it
I've already got the work done as an addon
oh I'm aware of enough "workarounds" to keep me up every night.
I'd just need to make an editor extension now
I'd be super happy to see community Editor extensions that use Camera!
Kayla: Gn
Kaylaβs brain: they are using armor stands, someone must stop them
Curious though which workaround did you learn about first throughout your 3 years at Mojang
Do you guys actually care that hobbyist creators are using hacky stuff? Isn't that what hobbyists do?
i know what im doing when i get home then :]
Was looking for an excuse to try out editor stuff
To be fair, I could've used the scripting API instead of an armour stand.
stop it Kayla needs to sleep
Funny enough as someine who hyped up editor on twitter...i havent had time to use it extensively. Mainly eaiting for v0.4 and been pkaying legends
I care in so far as I prefer you have better solutions to use. And although "backwards compatibility" is less of a concern with hobbyist content, I still want to be respectful of your time and energy.
As far as what can be added to the current camera: FOV (with easings) and Z rotation. Orthographic projection with clipping planes would also be nice as well, but it's an advanced feature, so is fine if it's not top priority rn
all i care about is making cool stuff with the camera, i already have a new game lined up
I practically finished the legends campaign and now i can only play versus π
I lost 4 hrs bc I modded legends and it deleted my saves
Cool - yeah I think z rotation and FOV are near-term goals. Orthographic is something we've discussed, but is probably longer term. So we're aligned here.
Yeah, camera fov stuff is something i'd like as well
Are they going to fix the z rotation bug in the command right now?
I've missed most of the discourse here lately.
By clamping the pitch argument they could fix it
what abt zoom?
Until we have proper Z rotation, it's a feature π
FOV is zoom
If they clamp the pitch, i can't do funny upside down stuff
Fov
Recipe cmd when
debatable
Zoom is literally FOV
What bends?
I think they mean that FoV and zoom can be controlled by the same data: a view projection matrix.
the perspective
If u wanna "zoom", shift the camera position forwards
You've used a spy glass before right?
Without fov*
Wallhack
Raycast
Def not a perfect solution
RTX

I'd much rather use fov
i should note we should also have easing on stuff like FOV
Don't see why not
You can take a look at my editor extension if you want to see how it works
I think I may have found a bug for camera
Does the camera fade block out UI or no?
fyi - we're planning to change the color values from 0-1 to 0-255
so it is a gradient-?
or more like an opacity layer
here's a bug for /camera, my video cut off but definitely will submit to jira
no - it won't change the functionality. But instead of using 0-1 values for each RGB channel, we'll use 0-255 - which is more intuitive
I'm very surprised it doesn't unload the chunks. That's a positive side
like for particles and other JSON things?
or only for camera command?
yeah if the camera is too far from the player, that'll definitely cause problems.
i believe the cause relates to this issue too
i can just make camera upside down π€
also i think it would be great to have a optional field at the end to run a command when ease is done
Not sure how that would work since the camera animation is client side
commands are also client side xd i mean
?
we can send request as player
Wouldn't it be better to just run the command after a certain of ticks? That's more predictable than relying on the client to run the command
no
Especially when said camera command could be executed on multiple players at once
Would each player tell the server to do the same command once all their animations are done?
if same camera can run on players whats issue with other one
What?
.
Yes and what about that?
whats the issue with running the other queued command on them
other command can have selectors
Undefined behaviour. They could all run in different orders, which could cause them to do different things
I just think it makes sense for command executing logic to stay on the server side
It's more predictable if it all command logic stays on the server side.
What would be more beneficial is a command that runs after a certain number of ticks
/execute after 20 ticks run ...
For example
imagine fading away as soon camera reaches player
to so for multiple players
1 we need setup for all
2 we cant predict how long one anim takes if its dynamic
queueing is the only option for advance cuts
not everyone uses scripts
You're still subject to the tick rate of the server
huh?
If you have a camera ease that lasts 1 second, just execute a command that 20 ticks later
It's guaranteed to run once the ease is finished
ur taking staic cases in count i am talking about dynamic cases
So a camera animation can have a variable defined length in the command?
Sounds like it combines them in a way, that'd fade in the fastest, stay and fade out the longest, so whether you trigger a command for fade1 or fade2, the screen will be fully faded either way, so no need to handle dynamic fade time
Actually that's kinda cool since this way you can create dynamic fades by combining 3 fade commands, each controlling one of 3 things, fade in, out or stay time
I think /camerashake can be combine with /camera
/camera move ...
/camera shake ...
nah like that
/camera @s clear
/camera @s shake ...
/camera @s fade ...
...
like more similar to current one
bc fade is not move so
Β―_(γ)_/Β―
I think more like execute subcommands
/camera <player: Player> <cameraSubCommand>
pos <pos: Vec3> <cameraSubCommand>
rot <rot: Vec2> <cameraSubCommand>
shake <camerashake> <cameraSubCommand>
color <red: number> ... <cameraSubCommand>
clear
Haha, that would be neat, but no way they'd ever do that.
:[
For consistency reasons, the target shouldn't come after the command.
I really hope they swap it in a future preview.
ya, just if they going to marge it i hope they dont divide it into shake and move subcommands no sense then, right?
ya selector could be optional like other commands does
Adding shake to it might overload the command syntax.
/execute isn't any better, but it's necessary.
@hoary tendon Do you see the second line? its not executable syntax
wait sorry nvm
That actually works.
ya
sorry i was wrong
how
bug, just set to 180 y-rot and go to 150 y-rot, thats why it starts reverted
From -180 to 180 should be a full roll as well
Use night vision please
they should just expose z
cool that even better
its not working with camera move
First run /execute anchored eyes positioned ^^^1 positioned ~~1000~ facing entity @s eyes positioned ^^^2000 positioned ~~1000~ facing entity @s eyes positioned as @s anchored eyes run camera @s set minecraft:free ease 1 linear pos ~~~ rot ~180 ~180 then run the same command but with ~180 ~-180 in the end. Vice versa also works
[Fade Yout]
smiles slightly
imagine how powerful it would be if /music or /playsound could have a pause state
btw it's only a useless thing
nomination for the top wanted command, also it don't have bugs at all