Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

LogBlock is it still maintained? #568

Closed
Chevels opened this issue Sep 20, 2014 · 9 comments
Closed

LogBlock is it still maintained? #568

Chevels opened this issue Sep 20, 2014 · 9 comments

Comments

@Chevels
Copy link

Chevels commented Sep 20, 2014

Hello,
LogBlock is it still maintained? I ask this because it's been a long time that has not been updated. What worries me most is the new UUID system. My database is 1GB and prior to migrating to another plugin I dare ask: Should I wait for a compatible version for Minecraft 1.7.9 or 1.8?

In any case, thank you for this great plugin that is very useful last 3 years!

(Sorry for mistakes, English is not my native language but I try to improve myself)

@Mahagon
Copy link

Mahagon commented Oct 15, 2014

just guessing, but i think they wont continue without being sure what happens to bukkit.

-> http://forums.bukkit.org/threads/bukkit-org-now-and-the-future.313693/

@DarkArc
Copy link

DarkArc commented Oct 15, 2014

I can't speak for the others, but I won't be continuing.

http://forums.spongepowered.org/t/goodbye-and-good-luck/2794

@frymaster
Copy link
Member

My personal motivation is I still run a server and I still want grief protection; there's been a really bad conjunction or real-life timesinks meaning I haven't been as active as I should (and having the bukkit project torpedoed by an ex-staff member wasn't good for motivation) but I still intend to have a UUID-compatible build out soon (one exists, but it won't migrate pre-existing records, and it still queries by name)

Long-term, what happens depends on what plugin API exists. If sponge takes off, chances are there will be a Prism version; if I can convince the lead dev to adopt a logblock-style consumer, I will probably contribute to that (any time I find a bug in Logblock that also exists in Prism I tend to pass it on anyway)

@PiLoT-
Copy link

PiLoT- commented Nov 16, 2014

Frymaster, with news that spigot WILL be updated any further comment?

@md-5
Copy link
Member

md-5 commented Nov 16, 2014

If LogBlock breaks and stops working I'll fix it. Aside from that, not sure.

@PiLoT-
Copy link

PiLoT- commented Nov 16, 2014

ah md-5 looking forward to the new spigot release. curious if small things like adding frames to logging will be brought in?

@md-5
Copy link
Member

md-5 commented Nov 16, 2014

Probably not by me, can't speak for anyone else though.

@PiLoT-
Copy link

PiLoT- commented Nov 17, 2014

no problems

@johnjuhl
Copy link

Sorry if it's inappropriate to derail this, but there is a bug that isn't game-breaking that I posted an issue about, but is indeed annoying. It probably wouldn't take long to fix, as you would just need to add the new door types to the plugin I assume. Wish I knew java so I could help :^)

#571

frymaster pushed a commit to frymaster/LogBlock that referenced this issue Feb 12, 2015
…is. Fixes LogBlock#538, fixes LogBlock#568

This creates a new column in the lb-players table called UUID. If this is in the form of a UUID,
it's assumed to be a player. If not, it's assumed to be a server entity (zombie, sheep, or
WaterFlow, LavaFlow etc.). LogBlock will set the UUID of entities to "log_" plus their name
(i.e. log_zombie or log_sheep)

To assist this is a new class Actor, which wraps a name/UUID pair, with constructors that will
generate one from server entities, or SQL results. Every listener and every class in Consumer
needed to be updated to deal with this

As of yet, only the playername is displayed in results (although the queries do return UUID data).
Similarly, you can only query by name (the database stores the last name they have logged in as).
In addition, the WorldEdit hook has been disabled (is not compiled) since LB needs to be updated
to use their new API, and the LB code hook has to extract UUID information for insertion.

The UUID importer assumes any player with an onlinetime of 0 is a server-generated source, and set
the UUID as above (log_sheep etc.).  For everything else, it sends 100 names at a time to Mojang's
name->UUID service, and records them if available.  If no result is found, it records their UUID as
noimport_theirname.  As this is more likely than other updates to be interrupted mid-way, the
importer is tolerant of e.g. the column already being added, and will resume where it left off.
frymaster pushed a commit to frymaster/LogBlock that referenced this issue Feb 14, 2015
…is. Fixes LogBlock#538, fixes LogBlock#568

This creates a new column in the lb-players table called UUID. If this is in the form of a UUID,
it's assumed to be a player. If not, it's assumed to be a server entity (zombie, sheep, or
WaterFlow, LavaFlow etc.). LogBlock will set the UUID of entities to "log_" plus their name
(i.e. log_zombie or log_sheep)

To assist this is a new class Actor, which wraps a name/UUID pair, with constructors that will
generate one from server entities, or SQL results. Every listener and every class in Consumer
needed to be updated to deal with this

As of yet, only the playername is displayed in results (although the queries do return UUID data).
Similarly, you can only query by name (the database stores the last name they have logged in as).
In addition, the WorldEdit hook has been disabled (is not compiled) since LB needs to be updated
to use their new API, and the LB code hook has to extract UUID information for insertion.

The UUID importer assumes any player with an onlinetime of 0 is a server-generated source, and set
the UUID as above (log_sheep etc.).  For everything else, it sends 100 names at a time to Mojang's
name->UUID service, and records them if available.  If no result is found, it records their UUID as
noimport_theirname.  As this is more likely than other updates to be interrupted mid-way, the
importer is tolerant of e.g. the column already being added, and will resume where it left off.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

7 participants