(r1mulus) .time_lived tag in ticks

[drifting sparrow]

Please remove "/20", I need to get this time in ticks. Why was this even added?

[heady flicker]

(r1mulus) .time_lived tag in ticks

[heady flicker]

Hi I'm AutoThreadBot! Don't mind me, I'll just be adding the helper team to this thread so they can see it. A human will get to you soon.

[autumn gust]

Changed to Feature

Thread is now a Feature thread. This indicates a request for a new feature to the plugin, that both (A) does not already exist and (B) reasonably can be added. If you are unsure whether this applies, use </helpthread:1028674284870180883> to change back to a normal help thread.

[main berry]

!t time_lived

[sturdy elk]

Tag: <EntityTag.time_lived>

Returns how long the entity has lived.

Group

attributes

Returns

DurationTag

Mechanism

EntityTag.time_lived

[main berry]

Is this not already in ticks?

[drifting sparrow]

"div 20" ...

[main berry]

This is returning in seconds then?

[drifting sparrow]

yea

[main berry]

Eh

!t durationtag.in_ticks

[sturdy elk]

Tag: <DurationTag.in_ticks>

Returns the number of ticks in the duration. (20t/second)

Returns

ElementTag(Number)

[main berry]

Though, I see your point.

Aya/Monkey will have to comment if they feel the need to change it.

[drifting sparrow]

Its literally unnecessary and gets in the way

[wooden wigeon]

?

not a feature thread

[autumn gust]

Changed to Help/Support

Thread is now a Help/Support thread. A helper will check your thread when available.

[wooden wigeon]

use this

[urban oak]

just .mul 20

lmao

[drifting sparrow]

Please do not touch this thread if you don’t understand what it’s about, I’m asking

[wooden wigeon]

if that doesnt work its a bugthread not a featurethread

[autumn gust]

Changed to Bug

Thread is now a Bug thread. This indicates a core code bug that a developer must resolved, not an error message or other support topic. Please do not misuse the Bug label. Use </helpthread:1028674284870180883> to switch the thread back to a normal help thread if you are not 100% confident it is a code bug.

[wooden wigeon]

pr opened https://github.com/DenizenScript/Denizen/pull/2777

[visual dust]

theres no chance to understand if you dont explain or showcase the issue

[drifting sparrow]

@visual dust

[visual dust]

this was after everything

[wooden wigeon]

rimulus, you created a post criticizing a method without any further explanation, you were then provided with a solution which you again only critized without explaining what is essentially your problem

[drifting sparrow]

I can’t understand what I explained wrong, but here’s the problem: in Java, .getTicksLived() returns the entity’s lifetime in ticks, but because this value is divided by 20 afterward, it becomes impossible to get the result in ticks. For example, if I need to check whether an entity has existed for 1 tick or 2 or 16 ticks, I can only check 20, meaning one second

[main berry]

This makes sense, although I will ask why you need to check if an entity has lived for such a short period. Personal curiousity really.

[drifting sparrow]

I need to remove entities during the BlockPhysics event, but only those that appeared as a result of it. Since there’s no context for the entities, I wanted to use time_lived so I don’t remove nearby items, only those that appeared because of the BlockPhysics event

[main berry]

Huh, no entity context huh?

I mean

!e block changes block

[sturdy elk]

Event: entity changes block into block

Group

Entity

Event Lines

<entity> changes <block> (into <block>)

Triggers

when an entity changes the material of a block.

Has Player

when the entity that changed the block is a player. - this adds switches flagged:<flag name> + permission:<node>, in addition to the <player> link.

Context

<context.entity> returns the EntityTag that changed the block.
<context.location> returns the LocationTag of the changed block.
<context.old_material> returns the old material of the block.
<context.new_material> returns the new material of the block.

Has Known Location

True - this adds switches in:<area> + location_flagged:<flag name>.

Cancellable

True - this adds <context.cancelled> and determines cancelled + cancelled:false.

[main berry]

Usually during physics it turns into a falling block right?

[drifting sparrow]

I mean

!e block physics

[sturdy elk]

Event: block physics

Group

Block

**WARNING**

This event may fire very rapidly.

Event Lines

<block> physics

Switches

adjacent:<block> to only process the event if the block or an immediately adjacent block (up/down/n/e/s/w) matches the LocationTag matcher specified. This can be useful to prevent blocks from breaking.

Triggers

when a block's physics update.

Context

<context.location> returns a LocationTag of the block the physics is affecting.
<context.new_material> returns a MaterialTag of what the block is becoming.

Has Known Location

True - this adds switches in:<area> + location_flagged:<flag name>.

Cancellable

True - this adds <context.cancelled> and determines cancelled + cancelled:false.

[main berry]

Original problem is still valid and time lived should definitely be changed, just wondering if physics is related to falling blocks.

I've never used the block physics event.

[drifting sparrow]

This event triggers on any block update

[main berry]

Ah.

[silent condor]

PR has been merged

[autumn gust]

Thread Closing Reminder

Has your issue been resolved, or your question been answered?
If so, please use the </resolved:1028673926114594866> command to close your thread.
Or </invalid:1028673926898909185> if it's not possible to resolve.

If not yet resolved, please reply below to tell us what you still need.

(Note that if there is no reply for a few days, this thread will eventually close itself.)

@drifting sparrow