1. Welcome to skUnity!

    Welcome to skUnity! This is a forum where members of the Skript community can communicate and interact. Skript Resource Creators can post their Resources for all to see and use.

    If you haven't done so already, feel free to join our official Discord server to expand your level of interaction with the comminuty!

    Now, what are you waiting for? Join the community now!

Dismiss Notice
This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

Bugs commiting, list of 'working' features

Discussion in 'Docs 2 Idea Review' started by PoweredDragon, Apr 30, 2017.

  1. P

    PoweredDragon Member

    Joined:
    Apr 16, 2017
    Messages:
    19
    Likes Received:
    2
    First of all - I'm not really up to date with "told" changes in docs 2, so I don't know if it already exists or had been already denied - I joined the forum just some days(max 2-3 weeks) and I didn't use to spend a lot of time there. Sorry!

    I thought of it for a while; it would be really great if we had it.
    There's, for example, expression. There should be, instead of mentioning it in the description, a list of events it can be used in. With events as well - a list of connected expressions.
    For example:
    On death
    <Description>
    This event supports these expressions:
    • victim
    • attacker/damaged
    • damage cause
    • final damage
    • don't really remember if there are others :V
    What would it give? Well; It will say if our syntax is ok when we wanna make condition or something; We wouldn't need to look for that on an expression list. I had such situation before - I was struggling to find any way to use 'location' hit by lightning and I got nothing. After that sb told me, that there isn't really a way to do that, if there's no entity there and I was so sad, but I wouldn't search docs for about 15 minutes to find anything; I would knew that!

    The second thing is tag "unworking", "bugged*".
    The first tag would be used, when the whole syntax of event/expression/etc. doesn't work, while the 2nd one would be used when some of listed supported expressions/events/etc. are not working or if it doesn't work with a specified addon :emoji_stuck_out_tongue: Again, easier life... And it would be found in the way of reports from community - fast and easy way; some reports give a clear situation, but it would have to be really, really well-described report - with versions, plugins and all this stuff (a special form to fill in?)

    What do you think men? Let's do that!

    EDIT:
    As it is similar, i don't make a new thread - also, if it goes about types, i'd add info "Loopable: yes/no", because not all types are usable (the same about commands maybe, because there are types either usable as argument or unusable :V

    EDIT:
    Cancelable would also be nice thing for events :emoji_grinning:

    @BaeFell - what do You think?
     
    #1 PoweredDragon, Apr 30, 2017
    Last edited: May 4, 2017
    • Like Like x 1
    • Agree Agree x 1
  2. ShaneBee

    Supporter +

    Joined:
    Sep 7, 2017
    Messages:
    1,414
    Likes Received:
    89
    I think event values have already been suggested. I don't know about cancellable. And bugged is mostly dependant on various factors, as server version, addon version, way of using it... the list goes on. Also, anything that returns multiple values is loopable.
     
  3. ShaneBee

    Supporter +

    Joined:
    Sep 7, 2017
    Messages:
    1,414
    Likes Received:
    89
    Well, when I read this:
    I'm pretty sure, that I explained everything you said.

    If it goes about loopable - not really everything and it is still helpful.
     
  4. ShaneBee

    Supporter +

    Joined:
    Sep 7, 2017
    Messages:
    1,414
    Likes Received:
    89
    +1
    Good idea!
     
  5. ShaneBee

    Supporter +

    Joined:
    Sep 7, 2017
    Messages:
    1,414
    Likes Received:
    89
    These are event-values. They've been added into Docs 2 and the Java API by @Tuke_Nuke detects them for the developer.

    This would probably be best between user and author, not on the docs. Admittedly, there are some features from Umbaska 2.0 that do not work, which could be marked as not working. However, I think for the general case, it's best for users to report to the addon developer and work with them.

    Those could both be added.
     
  6. ShaneBee

    Supporter +

    Joined:
    Sep 7, 2017
    Messages:
    1,414
    Likes Received:
    89
    I get it; that's what I usually do, but what, if author is not working on addon anymore? Or if the addon/Skript has a bug for a long time; maybe it would help (I'm not pushing myself on, but I can check such reports and add notes if needed :emoji_joy:). Also not every1 is really capable of contacting with authors due to lack of english-talks basics (I know such people, who are using Skript, while they can't actually talk with others (grammar :V). I heard of such men even more xD)
     
  7. ShaneBee

    Supporter +

    Joined:
    Sep 7, 2017
    Messages:
    1,414
    Likes Received:
    89
    It would probably come after the launch and with some consideration as to whether or not or will actually be needed.
     
Loading...