Sponge Docs Pop Quiz #9

Sponge Sponge Discussion
1

Very soon, lurkers and debaters, lovers and haters, there will be the

Sponge Docs Pop Quiz #9

Brought to you by a team of robot monkey-spiders riveted to a barrel.
Here are some of the things they typed as they drifted across the Sponge development wasteland, in pursuit of the cutting edge. Perhaps if you answer them you can enlighten us all :wink:

  1. Causes. How useful are they going to be for things you want plugins to do?
    Notwithstanding that no event happens without a prior event, Sherlock Holmes has been made redundant.
    The reasons behind the mysterious events that keep happening to you can now be tracked! Explained! Cancelled!

  2. Magnets. How the FLARD do they work?
    Minecraft has Gravity but lacks the Electro-Magnetic Force. The closest it has is redstone and the
    Extravagantly Modded Forge. What implementations of EMF would you be likely to use on Sponge servers?

  3. Would a Search function be useful for Downloads and Changelog?
    The changelog and the downloads list are a bit cumbersome to search through. More automation may not be the wisest solution, what solutions are available? Suggestions for improvements here are always encouraged, and offers of assistance greatly appreciated :wink:

Once again, thank you for examining these words, numbers and phrases; it is time for this message to evaporate and resonate inside the virtual you. Flashbacks provided for free at the disturbingly code-oriented
Docs Quiz #8. May you always tread the shiny yellow bricks of the Feynman Path. Number 9, Number 9, Number 9, Number 9, Number 9, Number 9, Number 9, Number 9, Number 9, Come In, Your Time Is Up.

3
  1. IMO causes seem to be a bit more cumbersome for what I do. You don’t know what directly caused the event. (For example, in a ChangeBlockEvent caused by a EntityExplodeEvent caused by an EntityDamageEvent causes by a Player, using first(Player.class) would return the Player who damaged the Creeper, and the Player probably didn’t intentionally make the Creeper explode. Some plugins might only want direct causes, though, and they would get messed up in a case like this.
  2. What is EMF?
  3. A Search function could be useful to tell what version of the implementation first supports a particular feature.
4

1.
It’s the exact same tradeoff the whole API enforces. Things become less simple (compared to Bukkit, since that is the only other API I’ve ever worked with) but also incredibly powerful. It may prove to be more verbose for simple Tasks, but overall the possibility of tracking each and every cause seems to be worth it. (Disclaimer: I have not used that feature yet)
2.
I do not intend to run a server myself for more than testing, so an EMF (Extravagantly Modded Forge) is of no interest to me.

3.
For now, the current changelog suffices, as it provides an overview on what changed from one dev version to another. The problem is that it is based on commit messages. Commit messages in general are 2% information for everyone, 18% information for developers, 5% expression of mental damage the programmer suffered from his own creation, 50% fixes of screwups from previous commits aptly commented with “oops” and, in Sponges case 25% “Bump API/SpongeCommon reference”.
Those might be fine for devs using dev builds, but they rather confuse than help server owners and average users. So once the project moves to a state where we actually have major and minor releases, we need a second changelog. One written by humans for humans. One with a neat list of bugfixes, a neat list of added Features and maybe a neat list of probable / possible imcompatibilities (Think “Event names for entity mating events changed in order to not lose PG-13 rating” or something).
I also see no benefit in a search function, since in order for it to work, commit messages had to be a lot more standardized.

TL/DR: For Dev builds the current system works, for major / minor builds we need an additional human-readable changelog. A search function would probably work only in the latter.

4 Likes
5

cause.root() OR, to get the last Cause, cause.all().get(cause.all().size() -1)

6

All that typing for a oft-used case, one would expect a cause.last() function for simplicity…

7

To be fair, I had originally typed cause.last() because I had expected it to exist, as well. :stuck_out_tongue:

For now, that will have to do, though.

8
  1. Very useful
  2. A vanilla-compatible implementation that is compatible with redstone might be interesting. Just think about an e-magnet powered by redstone that attracts iron-armored players or pulls their iron tools out of their inventory. Another use case would be the wireless transmission of redstone-signals (between two blocks or between a remote-control item and a block).
  3. What saladoc said.
1 Like
9

I took a look at Cause, and you could just use cause.last(Object.class).get() for the very last object in the cause. If you’re looking for something more specific, you could use cause.last(TargetClass.class).get(). In my case, I would use cause.last(Player.class).get().

However, this doesn’t address getting the base cause when it has extra data included in the Cause. In an EntityExplodeEvent caused by a DamageEntityEvent, the Cause would be [exploding mob, attacking DamageSource, attacked Entity] (I would expect; neither one is implemented yet).