Informacje Informator - Bukkit 1.1

Dyskusja w 'Nieaktualne Pluginy' rozpoczęta przez użytkownika Oskar13, Lut 24, 2012.

?

Rozwijać plugin?

  1. tak

    8 głos(ów)
    80.0%
  2. nie!

    2 głos(ów)
    20.0%
Status tematu:
Brak możliwości dodawania odpowiedzi.
  1. Oskar13
    Offline

    Oskar13 Nowicjusz

    Wiadomości:
    11
    Polubienia:
    0
    Punkty:
    1
    Informator
    Witam, mam do zaprezentowania autorski plugin o nazwie "Informator", jest on prosty lecz za razem bardzo przydatny. Polega on na wypisywaniu informacji po wytypowaniu wcześniej ustalonej komendy. Wszystko opiszę w tym temacie. Zapraszam!
    Komendy:​
    /info - cała pomoc i wszystkie komendy.​
    /info reload - reload pluginu, pokazuję się tylko gdy mamy odpowiednie permission.​
    /info lista - lista wszystkich komend.​
    /info [komenda] - użycie.​
    /info info - Informacje o autorze.​
    Permissions:​
    informator.admin - Funkcje administracyjne pluginu, w tym przypadku tylko "reload".​
    (lub OP)​
    Przykładowe zastosowanie:​
    Duży serwer RP, z wieloma nowymi funkcjami. Brak administracji online. Gracz nie wie od czego ma zacząć i gdzie pierwsze zamoczyć palce. Z pomocą przychodzi ten plugin, dzięki niemu będziemy mogli ustawić dowolną komendę i dowolny opis jej.​
    Config pluginu:​
    Kod (text):
    1. # Stworzone przez Oskar13!!
    2. Komenda: testowa
    3. wiadomosc: '&4TestNadTestem'
    4. Komenda1: ''
    5. wiadomosc1: ''
    6. Komenda2: ''
    7. wiadomosc2: ''
    8. Komenda3: ''
    9. wiadomosc3: ''
    10. Komenda4: ''
    11. wiadomosc4: ''
    12. Komenda5: ''
    13. wiadomosc5: ''
    14. Komenda6: ''
    15. wiadomosc6: ''
    16. Komenda7: ''
    17. wiadomosc7: ''
    18. Komenda8: ''
    19. wiadomosc8: ''
    20. Komenda9: ''
    21. wiadomosc9: ''
    22. Komenda10: ''
    23. wiadomosc10: ''
    24. super-komnedy: 'false'
    25.  
    Dodatkowe informacje:​
    Komend orginalnie jest 5, lecz jeżeli zmienimy wartość "super-komendy" na true, i po relogu serwera, w naszym configu aktywują się kolejne 5 komend, łącznie 10.​
    Użycie:​
    Przykładowo​
    Komneda7: trole #trole to komenda, czyli /info trole​
    wiadomosc7: 'Trolle w naszej krainie sa bardzo niebezpieczne, uwazaj na nie!' # treść zwracana.​
    Download
    Plugin:
    Kod (text):
    1. http://superupload.eu/?link=ecm8Q.c
    UWAGA: Jak na razie BRAK polskich znaków!
    Do administracji:​
    Chciał bym zostać developerem bukkit.pl. Jestem aktywnym człowiekiem, mam aktualnie projekt minecrafta który jest w trakcie realizacji, głównie zajmuje się pisaniem stron internetowych i programów dziennego użytku. Mój projekt w minecraftcie będzie opierał się tylko o autorskie mody.​
     
  2. Dominos
    Offline

    Dominos Nowicjusz

    Wiadomości:
    4
    Polubienia:
    0
    Punkty:
    1
    Witam a mógłbyś dodać jeszcze opcje żeby automatycznie się wyświetlało np co 5 min.
     
  3. Rutr
    Offline

    Rutr Użytkownik

    Wiadomości:
    56
    Polubienia:
    26
    Punkty:
    28
    Od tego jest plugin np: AutoMessage

    A co do pluginu:
    Powinieneś zrobić czytanie listy tych 'komend' dynamicznie, czyli nie że z góry masz podaną ilość tak jak to masz, tylko ile podasz tyle wczyta. Najlepiej to zrobić o takie strukturze:
    Kod (text):
    1. komendy:
    2.     <nazwa komendy>: 'Info wyświetlane'
    3.     <nazwa komendy2>: 'Info wyświetlane2'
    Przydało by się jak byś udostępnił źródło.
    Zakładam że do wczytania konfiguracji użyłeś org.bukkit.configuration.file.YamlConfiguration
    keye jakie zdefinowano możesz sprawdzić:

     
  4. Oskar13
    Offline

    Oskar13 Nowicjusz

    Wiadomości:
    11
    Polubienia:
    0
    Punkty:
    1
    Źle zakładasz, w bukkicie funkcja getConfig() jest wbudowana. Wystarczy ją wywołać i config się nam utworzy. A co dynamicznej listy . Jeżeli to wykonam to i tak każda komenda musi zaczynać się od /info costam Ponieważ w przeciwnym razie administrator serwera będzie zmuszony do edytowania pliku plugin.yml a tego bym nie chciał.
     
  5. Rutr
    Offline

    Rutr Użytkownik

    Wiadomości:
    56
    Polubienia:
    26
    Punkty:
    28
    wcale nie!
    którego bukkita używasz jako biblioteki?
    Nie ma takiej funkcji, bukkit jest w javie więc to się nazywa metody, a metody są w klasach, więc jak podajesz nazwę metody to w jakiej klasie.
    Wyżej wymienione przeze mnie klasy też są wbudowane, są nowsze i bardziej efektywne.

    A co do komend to chodzi mi o to żeby wywołanie było tak samo, ale lista żeby była dynamiczna. niech bedzie to /info <komenda>
    tylko niech czyta tyle komend ile administrator poda a nie ten co plugin pisze!

    A co do własnych komend na serwie:
    Komendy można rejestrować metodą w trakcie działania pluginu, i w tedy admin serwera nic nie musi zmieniać w plugin.yml

    np CommandHelper od dawna rejestruje komendy, w czasie działania serwera możemy zrobić własne makro a potem ten plugin przeładować i już nam dziłają nowe komendy.
     
  6. Wert
    Offline

    Wert Znany

    Wiadomości:
    1,453
    Polubienia:
    554
    Punkty:
    268
    Skopiowałem żeby na naszym bukkicie się pojawiło coś nowego:D

    Introduction to the New Configuration



    The Configuration API is a set of tools to help developers quickly load and emit configurations files that are human readable and editable. Currently however, the system only supports the YAML Schema for configuration files. However, with the API, new formats can be added, as the overall API is meant to be schema agnostic.
    For those of you who are already developing, you may have been surprised at the deprecation of the org.bukkit.util.Configuration package, but fear not for it has been replaced with something is more powerful! You may be asking yourself: How do I use the new API? For those who are new to Bukkit Plugin Development, you may be asking yourself: How do you get started with creating configuration files?
    This introduction assumes you have some knowledge about Java, programming Bukkit plugins, and Object-oriented programming.


    The Configuration Object

    Your plugin extend JavaPlugin, doing so, you inherited methods and fields from JavaPlugin. The inherited method, getConfig() returns an object of typeorg.bukkit.configuration.file.FileConfiguration. This is the object that represents config.yml inside your plugin's data folder.
    For the first time getConfig() is invoked in your plugin, this is the point that config.yml is loaded from disk, and default values loaded from your jar. From that point on, getConfig() will return the FileConfiguration object that is in memory. All operations are performed on this object, and does not reflect changes to the file on the disk after loading. If config.yml does not exist in your data folder, it is equivalent to an empty config.yml, and will load an empty FileConfiguration.
    [​IMG] Warning: if you assign the returned object from getConfig() DO NOT assign it to a static field
    [​IMG] Warning: if you do the above, assign getConfig() to the variable AGAIN after a reloadConfig
    [​IMG] Note: it is better to just use getConfig() instead of storing it
    Default Values

    Default values for your config.yml should be provided for the user of your plugin. If the config file in your plugin's data directory does not exist, is empty, or is missing keys, it will load the missing keys and values from your jar. Defaults should be provided in a YAML file that has the exact same structure as you intend config.yml to have. The file must be namedconfig.yml and be placed in the same directory as your plugin.yml. If you want to copy and overwrite the defaults into the plugin's data folder, you will need to invoke thesaveDefaultConfig() method of JavaPlugin. If you do not wish to overwrite the existing files, you set the copyDefualts option to true
    If you are using dynamic values for defaults, defaults can be added to the configuration within code with addDefault(String, Object) and addDefaults(Map<String,Object>) methods.
    In certain cases if you wish to append new defaults to an existing config.yml you can set the option copyDefaults to true
    getConfig().options().copyDefaults(true)
    Getting Values

    Reading values from the configuration involves invoking one of the many getter methods. A complete list of getters can be found here. Some of the commonly used getter methods are as follows
    • getBoolean(String)
    • getInt(String)
    • getString(String)
    • getList(String)
    • getStringList(String)
    Keys

    The retrieval of keys being not values behaves differently from the other get methods. Invoking the method returns the set of keys for the current FileConfigurationSection. To get the section you will have to invoke getConfigurationSection(String) before invoking getKeys(boolean). The boolean value determines if the returned set is recursive, if true it will return the keys of the given section and their children keys, if false will only return keys of the given section.
    • getKeys(boolean)
    [​IMG] Note: This now returns a Set of Strings
    Setting Values

    Writing values involves invoking the set(String, Object) method on an instance of Configuration. Unlike the different get methods that FileConfiguration has, there is only one set method. Not all objects can be set, only primitive types, String, Lists, and types that implement ConfigurationSerializable, such as Vector and ItemStack, can be set. To erase a value supply null as a parameter. All changes made by set will only affect the copy of the configuration in memory, and will not persist beyond restarting the server until the configuration is saved. Following are some example uses:
    // setting a boolean value
    this.getConfig().set("path.to.boolean", true);
    // setting a String
    String string = "Hello World!";
    this.getConfig().set("path.to.string", stringValue);
    // Setting a List of Strings
    // The List of Strings is first defined in this array
    String[] listOfStrings = {"Hello World", "Welcome to Bukkit", "Have a Good Day!"};
    this.getConfig().set("path.to.list", Arrays.asList(listOfStrings);
    // Setting a vector
    // event is assumed to be an existing event inside an "onEvent" method.
    Vector vector = event.getPlayer().getLocation().toVector();
    this.getConfig().set("path.to.vector", vector);
    // Erasing a value
    this.getConfig().set("path.to.value", null);

    HashMaps

    If you wish to set a HashMap, you will instead need to create a ConfigurationSection. You can only save a HashMap where the key is a string the the value is something that is already ConfigurationSerializable.
    createSection (String path, Map< String, Object > map)
    Saving the File

    If make any changes to the FileConfiguration with set methods, or mutate any Lists, you will need to save the changes to disk if you wish to keep these changes after the plugin is disabled. To save the file to disk invoke the saveConfig method for your plugin, it will overwrite the file already there.
    this.saveConfig();
    Reloading from Disk

    If you suspect that users have made changes to the config.yml in the data folder, those changes are not reflected in memory. Invoke the reloadConfig() method of your plugin to load from the disk again. It will destroy all changes in memory.
    this.reloadConfig();
    Advance Topics

    The Following are some more advance topics, these are meant for more advanced plugins. If you only require the default config.yml, creating custom methods for reading and saving it is overkill.
    Options

    Every FileConfiguration instance is associated with a FileConfigurationOptions object. The FileConfigurationOptions object controls the behavior of the FileConfiguration it is associated with. FileConfiguration's options() method returns the FileConfigurationOption's responsible for it. With it you can check and set each option. There are currently four options. Be aware that the methods are overloaded, for example copyDefaults() which returns a boolean and copyDefaults(boolean) which returns it self, but has a side effect which changes the state.
    CopyDefaults

    The copyCefault's option changes the behavior of Configuration's save method. By default, the defaults of the configuration will not be written to the target save file. If set to true, it will write out the default values, to the target file. However, once written, you will not be able to tell the difference between a default and a value from the configuration.
    PathSeperator

    PathSeperator changes the character that is used to separate the different levels of the configuration. By default it is the "." (period) but it can be changed to any char.
    Header

    Header is the comment block at the top of a YAML file, it is applied to the save output. The header is the only comment that Configuration API knows how to copy.
    CopyHeader

    If CopyHeader() returns true then the header will be copied on save, from the default source.
    Methods for Getting, Reloading, and Saving Custom Configurations

    If you require additional YAML files, for storing configuration information or persisting additional game information you will need to write your own methods for accessing the additional configuration files. Modeled after JavaPlugin methods, the following is an example how to write your own methods to read and save to custom configuration files. Since these config files belong to your plugin, you can put this method in your main class so that you can have the same access as you have with config.yml. You will have to write a set of these methods for each YAML file. The advantage here, is that you can use each set in the same manner as the provided methods for the default config.yml.

    First you will need to declare two fields and initialize them for the custom configuration. One to hold the FileConfiguration and one to hold the File. The File Object represents the file on the disk, and the FileConfiguration represents the contents of the configuration.
    private FileConfiguration customConfig = null;
    private File customConfigurationFile = null;

    Then, write the method that is responsible for loading the config from disk. It will load the file, and search the jar for a default customConfig.yml.
    public void reloadCustomConfig() {
    if (customConfigFile == null) {
    customConfigFile = new File(getDataFolder(), "customConfig.yml");
    }
    customConfig = YamlConfiguration.loadConfiguration(customConfigFile);
    // Look for defaults in the jar
    InputStream defConfigStream = getResource("customConfig.yml");
    if (defConfigStream != null) {
    YamlConfiguration defConfig = YamlConfiguration.loadConfiguration(defConfigStream);
    customConfig.setDefaults(defConfig);
    }
    }

    Next, you need to write the getter method. Check if customConfig is null, if it is load from disk.
    public FileConfiguration getCustomConfig() {
    if (customConfig == null) {
    reloadCustomConfig();
    }
    return customConfig;
    }

    Finally, write the save method, which saves changes and overwrites the file on disk.
    public void saveCustomConfig() {
    if (customConfig == null || customConfigFile == null) {
    return;
    }
    try {
    customConfig.save(customConfigFile);
    } catch (IOException ex) {
    Logger.getLogger(JavaPlugin.class.getName()).log(Level.SEVERE, "Could not save config to " + customConfigFile, ex);
    }
    }

    After adding these methods to your plugin's main class, you can use them in the same way as the inherited getConfig(), reloadConfig(), and saveConfig() methods.
    Serializing and Deserializing Objects

    Any objects you want to serialize must implement the ConfigurationSerializable Interface. Serializing objects, allows a developer to quickly store game information and facilitate easy loading. It greatly simplifies tasks such as storing a Location in YAML, a developer can serialize a wrapper class, which provide methods to retrieve a Location.

    In addition to implementing the interface You must implement one of the following:
    • A constructor that accepts a single Map.
    • A static method "deserialize" that accepts a single Mapand returns the class.
    • A static method "valueOf" that accepts a single Map and returns the class.
    You must also register the class with ConfigurationSerialization before it attempts to deserialize any objects. This statement can be placed in a static initializer block in your main class.
    ConfigurationSerialization.registerClass(Class<? extends ConfigurationSerializable> clazz)

    [​IMG] Note: a nested ConfigurationSerializable object is returned as type Map and needed to be casted as such and given to one of the deserialization methods when the parent class is being deserialized
    Aliases

    You can provide an alias to your class so that it does not serialize with the fully qualified name of your class. You provide the alias with the SerializeAs annotation to the class implementing ConfigurationSerializable.
    @SerilizeAs(String alias)
    When registering a class with an alias, the alias must be provided on registration.
    ConfigurationSerialization.registerClass(Class<? extends ConfigurationSerializable> clazz, String alias)
    Example Use

    Below is the an example plugin that uses the new Configuration API to store messages to be displayed as an MOTD as players join, and for the player to retrieve the rules on command. It does not follow proper style and plugin layout as it was made to fit within 50 lines.
    import java.util.*;
    import org.bukkit.command.*;
    import org.bukkit.event.player.PlayerJoinEvent;
    import org.bukkit.plugin.java.JavaPlugin;
    import org.bukkit.configuration.file.FileConfiguration;
    import org.bukkit.event.*;
    public class SimpleMOTD extends JavaPlugin {
    public void onDisable() {
    System.out.println(this.toString() + " disabled");
    }
    public void onEnable() {
    getServer().getPluginManager().registerEvents(new Listener() {
    @EventHandler
    public playerJoin(PlayerJoinEvent evt) {
    event.getPlayer().sendMessage(getConfig().getString("message"));
    }
    }, this);
    this.getCommand("rules").setExecutor(new CommandExecutor() {
    public boolean onCommand(CommandSender sender, Command command, String label, String[] args) {
    List<String> rules = (List<String>)(List<?>)getConfig().getList("rules");
    Iterator<String> iter = rules.iterator();
    while (iter.hasNext()) {
    sender.sendMessage(iter.next());
    }
    return true;
    }
    });
    this.getConfig().options().copyDefaults(true);
    saveConfig();
    System.out.println(this.toString() + " enabled");
    }
    }
    The default config.yml
    # default config.yml message: Hello World and Welcome! :) rules: - Play Nice
    - Respect others
     
  7. Oskar13
    Offline

    Oskar13 Nowicjusz

    Wiadomości:
    11
    Polubienia:
    0
    Punkty:
    1
    Chłopie jak masz tutaj się ze mną kłócić to lepiej się nie wypowiadaj w tym temacie. Taka właśnie jest Polska moi drodzy. Wiem raczej lepiej jakiej funkcji użyłem. I raczej nie ma różnicy żadnej między wydajnością, ponieważ to właśnie NIE JEST METODA tylko funkcja publiczna. Dlaczego nie ma różnicy? Ponieważ przy takich wielkościach plików nie ma wydajności. To jest to samo co podałeś tylko inna nazwa pliku. A co do twojego commandhelpera, on wcale nie dodaje żadnych komend do plugin.yml, tylko przyznaje je dynamicznie do tablicy wielowymiarowej wbudowanej w siebie. I jak zauważyłeś komenda /help. Bardzo proszę Cię nie spam mi tu już. Przyjąłem Twoją sugestie dotyczącą tych komend, więc ją zrealizuje. Będziesz sobie pisał własne wtyczki to będziesz w nich używał czegokolwiek tam chcesz, możesz nawet załączniki c# tak wpakować nie mam nic do tego :) Pozdrowienia. I ponawiam moją prośbę.
     
  8. Rutr
    Offline

    Rutr Użytkownik

    Wiadomości:
    56
    Polubienia:
    26
    Punkty:
    28
    ?
    Przecież nikt tu się z tobą nie kłóci! To jest forum dyskusyjne więc kulturalnie rozmawiamy.

    W javie nie ma funkcji! Są metody, każda metoda musi być w jakiejś klasie a te z kolei w pakietach. wraz za javą są tysiące klas(biblioteka). metody przed którymi nie musisz podać obiektu/klasy to są metody tej samej klasy, lub klasy bazowej.

    metoda getConfig() znajduje się w klasie:
    Kod (text):
    1. org.bukkit.plugin.java.JavaPlugin
    klasa główna każdego pluginu musi z niej dziedziczyć.

    a co ze źródełkiem? :)
     
  9. Oskar13
    Offline

    Oskar13 Nowicjusz

    Wiadomości:
    11
    Polubienia:
    0
    Punkty:
    1
    Źródło kodu jest tak dziadowe że wstydzie się go udostępniać :p Nie tak na serio, założę konto na githubie. Napisze plugin od nowa tym razem z pętlą while i wykorzystam Twoją sugestie. Wtedy dam źródło. No może i masz racje ale raczej metody a funkcje to to samo, są zdefiniowane przez nas, mają ten sam cel, mogą być różne, tylko nazwą się mylą :) Nie łap mnie za słówka :] Przy okazji piszesz w javie? Szukam osoby chętnej do projektu.
     
  10. Marcin Majewski
    Offline

    Marcin Majewski Użytkownik

    Wiadomości:
    64
    Polubienia:
    31
    Punkty:
    28
    Spotkało się dwóch pro elo programistów. Dajcie przeczytać a wyciągnę wnioski z waszej kłótni.
     
  11. Rutr
    Offline

    Rutr Użytkownik

    Wiadomości:
    56
    Polubienia:
    26
    Punkty:
    28
    @marcin
    najpierw się czyta potem komentuje! ;p
    my się nie kłócimy tylko dyskutujemy!
    A źródełko zawsze możesz dać to ci pomogę.
     
  12. Oskar13
    Offline

    Oskar13 Nowicjusz

    Wiadomości:
    11
    Polubienia:
    0
    Punkty:
    1
    Pan Marcinek wywalił mój komentarz z tym że niby developer a nie oddał żadnego pluginu swojego. Rutr ja pisze raczej mody, więc chodzi mi o osobę to projektu serwera chętną :p
     
  13. Rutr
    Offline

    Rutr Użytkownik

    Wiadomości:
    56
    Polubienia:
    26
    Punkty:
    28
    heh
    ja jestem programistą więc na serwie murzynił nie będę. ;p
    a mam swój serwer z jakimś gościem
     
Status tematu:
Brak możliwości dodawania odpowiedzi.