#fake metadata

1 messages · Page 1 of 1 (latest)

scarlet oar
#

joe mama

woven tartan
#

ok

#

great!

#

what i was about to ask you (a thread)

#

so tell me ur knowledge wise programmer

#

🙂

#

how do you do fake metadata

scarlet oar
timber cradle
scarlet oar
#

I believe

#

There's the nms guide too, if you're new to packets

#

Now, datawatchers:

woven tartan
timber cradle
#

i better shut my mouth

scarlet oar
#

You'll need to have an NMS entity, the type doesn't matter

#

ProtocolLib internally just makes a fake egg that's never spawned in

woven tartan
#

i tried with NMS, but no success due to datawatchers, whenever i try to send a ClientboundEntityMetadataPacket, it requires an EntitySyncheed (previously called DataWatcher)

woven tartan
#

the NMS entity is bound to the server, so whenever something happens on the client, it will happen on the server too

#

i mean, how do you make a fake entity in the first place

scarlet oar
#

You can create an nms entity instance and just... not spawn it in

woven tartan
#

yes ofc, but then i have another problem

#

I'd need to "deep copy" an existing entity into that fake entity

scarlet oar
#

Yeah that's easy

woven tartan
#

because what i'm trying to do is just "fake update" an existing (on server and client) entity

scarlet oar
#

SynchedEntityData#getAll

#

SynchedEntityData#assignValues

# 
Entity originalEntity = ...; // original nms entity
SynchedEntityData originalData = originalEntity.getEntityData(); // original nms entity data

ThrownEgg egg = new ThrownEgg(EntityType.EGG, null);

SynchedEntityData datawatcher = egg.getEntityData();
datawatcher.assignValues(originalData.getAll()); // deep copy the original data

datawatcher.set(new EntityDataAccessor<>(123, EntityDataSerializers.BOOLEAN), true);

ClientboundSetEntityDataPacket packet = new ClientboundSetEntityDataPacket(original.getId(), datawatcher, true);
#

not that hard

woven tartan
#

aha i see

#

So ur sure that originalEntity will not be updated too (due to some madness in datawatchers that would be somehow connected by the entity id or sth)

scarlet oar
#

try it and see

woven tartan
#

datawatcher.set(new EntityDataAccessor<>(123, EntityDataSerializers.BOOLEAN), true);
What does this do?

#

and why 123

scarlet oar
#

sets the field at index 123 with the boolean value of true

#

123 will obviously crash the client, you need to find the metadata id in the protocol page

woven tartan
scarlet oar
#

it was just an example

#

replace 123 with whatever you want

woven tartan
#

ahh

#

ok

#

that was an example of modification/update

#

right

scarlet oar
#

ye

woven tartan
#

i see thank you

#

now i need your opinion on sth else related to packets

#

Here's my current situation:
I keep spamming packets that updates the map of certain ID (with new data/image) to players, in order to make "animated images", works flawlessly
There are plenty of optimisations too I done, which happen dynamically according to their TPS (send the packet if the entity the map is bound to is within their view distance, not hidden, and at a more less far distance/view angle according to their TPS, also i higher or lower the framerate according to their TPS)
I don't think I could have done it better tbh, except for one stuff.

Since I'm tracking the entities too (the itemframes) to do the optimisations I mentioned above, I imagined the following scenario:
Instead of sending them packets to UPDATE a certain map continuously, generate N fake entities (fake itemframes), N being the amount of frames of the gif. Send them only once the packet to update each map id of the frames. Then I can assume that they cached every frames of the gif in their client (each corresponding to a different map id), and what i keep spamming them is fake entity update packets, to fake change the map id inside of the itemframe they are viewing.

scarlet oar
#

Ooh maps

#

make sure you optimize the basics first

#

color maps, optimize raytracing if you're doing that

woven tartan
#

I was thinking doing this change because my theory is that entity update packets are lighter than "map packets"

scarlet oar
#

They are, yes

woven tartan
scarlet oar
#

how extreme eyeszoom

woven tartan
scarlet oar
#

Done any graphs?

woven tartan
#

xd

scarlet oar
#

I've had a period of my life where I worked nonstop for like a week without sleep, just optimizing this very problem

woven tartan
# scarlet oar Done any graphs?

well, i have let it very customizable (dynamic framerate, adjustable view distance, view angle, and so on, based on their tps) but haven't got time to tweak the configs optimally (didn't do much testing)

scarlet oar
#

I mean micro optimization

#

Like making sure that any raycasting runs under 100 microseconds etc

woven tartan
#

oh yeah, that is done really really well and my algorithm for ray tracing is pretty smart i think (O(n) with n the distance from player to itemframe entity)

scarlet oar
#

Run a few iterations and time it :)

#

something tells me we already had this conversation like 3 months ago?

woven tartan
#

will do ^^ (i first have to fix my workaround, which has no java, no IDE etc) (new comp)

woven tartan
#

i made a break

#

(a full stop to be precise)

#

cuz studies are intense haha

woven tartan
scarlet oar
#

Uhh, possibly

#

the client can have some issues handling it though

#

like flickers and all

woven tartan
#

yeah ofc

#

with my current code, no flickers on JE and no flickers on BE

#

pretty smooth even

#

I'd just hope that i can spam more to phones at the same time

#

cuz rn it works for phone players, but cuz i cap for them at 10 map updates at a time

scarlet oar
#

Try limiting your connection somehow

#

to like 100kbps

#

and trying it out

#

on a remote server obviously

#

That'll give you a feel for the experience

woven tartan
#

u want me to play MC from a remote server on which i cap the connection for testing purposes?

scarlet oar
#

Yes

#

mobile data is often that bad

woven tartan
#

yeah true

#

thx for the tip

#

also, do you think that (given that i tweaked it so TPS does update at an extremly small interval instead of 5 seconds by default) TPS is a good measurement for player lag?

scarlet oar
#

no

#

Ping is a nice measurement for player lag

#

you should do the rendering part async

#

so there's no point in measuring tps

woven tartan
#

my bad i meant ping indeed

#

lol i'm dumb

#

i mismatched the words

#

but yeah i meant ping ofc

scarlet oar
#

Well... ping isn't always accurate but it's as close as it gets

#

ping matters a lot jess than jitter, for example

woven tartan
scarlet oar
#

They're dispatched in their own dedicated thread

woven tartan
#

well i do it async already^^

#

my server handles it very well (no freeze, or lag for the server)

#

Anyway thank you @scarlet oar, if i get the courage to maintain it, i'll keep you updated; and i have plenty on my list and probably another lifetime to spend on this haha, for example i'm not satisfied enough with floyd steinberg dithering, and i'm planning to pick on heaviier error diffusing algorithms, and i'm also considering do some "animation dithering" (essentially when a red pixel quickly turns to a blue pixel, it gives the Illusion of a purple pixel)

#

the biggest thing is probably testing tho,

#

cuz ur right, i really need to have a clearer idea of what type of connection can support what

woven tartan
woven tartan
#

added a spawn packet too, didn't change anything

woven tartan
#

it works

#

actually it's cuz i'm so dumb, i tested it inside "PlayerInteractEntityEvent" LOL

#

So obv when the event triggers, afterwards the entity updates (unless the event is cancelled, thing which i haven't done) to what it is supposed to be (not fake) lol

scarlet oar
#

You might want to intercept packets and "fix" data

woven tartan
#

protocollib is good when you just wanna make sure they get an illusion
But not only i want to make an illusion, i also want to change this illusion to another illusion constantly

scarlet oar
#

the puns

woven tartan
#

😛

woven tartan
#

@scarlet oar brooooo, crazy shit
So I made the update I talked to you about and the change is really significant.
To give you an example, in my horny dungeon with loads and loads of GIFs, pictures have 5x6 dimensions so it's really a big amount of maps, before the caching+"fake metadata" update, I would get maybe 3000ms ping with my connection. (In the situation where I do look at most pictures so most of them have to animate). Now I may get these 3000 ms for the "download" time only. Once frames are all cached in the client, further animation doesn't make them lag at all. Now I could be at 30ms while watching them all haha.
To fix that "download" lag, I will add a dynamic config for my plugin (configurable mathematical function according to player ping) which would determinate the maximal "download" rate. When the server is about to send a new frame to client (and for the first time, which means servers needs to send the map data too so the client can "download"), but the amount of frames sent to this client exceeds the download rate, server will not send the map data this time. (But will do it later on, when the queue will be less busy), which means ofc that the gif might be longer to load for client ofc.
Ofc I could already have added this feature before this update, but since it was "constant downloading" (no caching involved), it would affect the overall framerate. (Which is a bit unfortunate)

scarlet oar
#

or you can just... not download them on the network thread and wait a bit?

woven tartan
#

Adapt to the user

#

Just like bunch other settings like view angle, view distance which varies based on player ping