Posts by zfoxfire

    Hi Miwarre,


    Good idea to branch this off the other discussion. This really is a subject on its own. I was thinking of a plugin manager in terms of handling installing and distribution but a plugin manager should also offer a way to enable/disable a plugin. I'm almost positive this has not been brought up before so kudos to you :)


    I'm sure Red51 already have implemented some kind of process manager to handle the plugins, each plugin would have to be threaded already. So maybe it would be possible to load/unload a plugin while game is running. This might add to complexities to us as plugin developers but it would be an excellent feature. I'd love to hear Red51 chime in on this. I'll nudge him right now on addressing this. I know he's been discussing internally yesterday about the finalized form of plugin implementation and many of our concerns we also brought up (e.g subfolders) did come up. He should be making an official announcement soon so I'll give him a heads up :)

    Thanks Arcane,


    I'm glad that no pot stirring was intended. I hope some of our discussions cleared up some confusion. It's a shame that events played out the way they did and it's probably best to just move on. I still do hope Chris comes back and we can all work together and make some cool new stuff. Chris is a talented programmer and we need that kind of tallent in the community for when we have to start converting the old lua scripts into java.

    @diegomarino80gongo
    Thats pretty much the bottom line here. For people like me we can accept the update frequency as "the way it is". Some others cannot and complain abouy lack of updates here or through Steam reviews.


    The game is coming along just fine. Not everyone will agree but there are more positive reviews than negative ones.

    Arcane,


    I doubt if Chris will respond and Vornet is unavailable on github anymore last I checked. Someone will have to write up a new economy script for the java API. Once Lua is dropped, Vornet will no longer work. However if someone is still running it on their server then it could be rewritten for Java.

    the game is developing just fine all things considered. Some of the extra delays are likely Red ensuring that the updates dont cause any technical dept later down the road.


    It's funny that you mention a peaceful feeling. I think we have all coe to expect that as that is the way its been. However.... monsters are coming as well are hostile humans. The mood and feel will change but hopefully we will have options to control what we want so it can stay the same for those of us who want it. I'm personally looking forward to all the upcoming changes and I think we are definately heading in the right direction.


    I understand what you mean by things being static. Even the animals are the same. The animal AI was reworked recently to support whatever dungeon monsters we get. Hopefully the new AI allows for respawning and herd mentality for animals. It would add a new dynamic to the game. Red has a long-term vision of what this game will become but the bottom line is there is only so much that can be done at a time.


    This is why I am more excited about the API than any other update because it will allow us to start customizing the game in a way that wasnt possible. For example, the level up server will be able to auto level up the players now which was not possible in the old api.


    There was another comment where Red confirmed a way to play built in sound effects. This will let us randomize natural sounds which will make the game less static.


    I've shelved this game a few times since I've bought it but thats ok. Even when not playing, I lmenjoy being a part of the community and influencing the development. I enjoy playing whenever there's an update and see all the changes. The API is whats really going to keep my interest for a while but dungeons just sound so much fun.

    I do agree with you that it adds to complexity. So I guess at this point it all boils down to whether or not Red51 wants to allow the game to support drop in zip files which would expand and let you modify the contents anyway you want. I do not like that approach personally but I don't know specifically what the harm would be to support that approach in addition to what I propose.

    Arcane,
    I did a bit more research into Forge and confirmed my suspicions. Forge is a hack. It modifies the original jars. Therefore, yes it needs a standalone installer. If anyone wants to come up with hacks for Rising World then I highly doubt they will be supported by the JIW team.
    The API provided to us requires writing normal java applications. They interact with the game using the official API. We are referring to them as mods bit they modify the game through an officially supported means. No installing or hacking necessary :)



    Miwarre,


    If we get a subdirectory dedicated to the plugin, you could essentialy write a class to handle the configuration file. It would contain a method to generate a config file off of a template inside the jar. The config file is placed inside the folder and can have as many comments as you want. The class would also need methods in it to check the file for proper syntax, handling errors, and your standard get/set methods for managing the values. If you want to have external variables the i suppose it would make more sense to only read off the external file but its largely up to you how to handle it. I would program default values in the code regardless so incase a user comments out a line, it won't cause an undefined variable error.

    @red51 I would imagine we would need a methid to list the sound effects available in game before we can set up event handlers. As I recall, before you guys switched to fmod, there were a lot of unused sound effects. If all of these are all converted into the new bank files then it would be nice to set something up so that water sounds play near user-placed streams. Maybe random gusts of winds and whatnot. That would really add to the realism to our custom worlds :)

    Neverwinter has a 3rd person perspective. Pretty sure we are going to get that after the player models are replaced. A skill tree and some kind of age progression/recipe unlocking system has been discussed but no details have been finalized AFAIK.


    For raiding purposes, we probably need a land claim block that can be owned by a group and can be picked up by an opposing team. I personally am not into PvP but definately feel it is a good idea to offer such items. At present, PvP mode only allows friendly fire.


    We are getting some ranged weapons and armor along with the player models so I'd imagine PvP might be more interesting than just clobbing people with morning stars! I also have made a suggestion to add the ability to block or parry while using melee weapons as some here are interested in medeival combat simulators as well. :)

    Thanks Nick,


    The API will hopefully open the doors to a good modding community, perhaps we can spread some interest amongst Minecraft modders eventually. I'd hope that the API will expand enough so that we don't have to go the route of Forge.

    You found an island in the middle of a lake? That's rare. How lucky you are! :)
    Wurm seems like an awesome game and I want to pick it up one of these days. At some point later on down the road we will be seeing more advanced player models, customization of character and clothing, and buff/debuffs. Maybe even skill leveling too. Some of what I saw in WURM I felt should work its way into Rising World but we need a ballance between fun and grinding. WURM seems like a game you really really really have to grind in.

    Indeed! But it only works for assets distributed together with the .jar and which do not change over time, it does not work for assets which do change over time or are added at user side.

    [/quote]
    If your assets distributed change over time, you need to bump your version number whenever you release a change to your code or assets. If you want to have multiple variations of your distribution with the same variation then you can give each package a different name variation. The idea of an optional subfolder is to allow users to add to the mod content to override whats in the mod, for example if they choose to use a different elevator model. Essentially the jar works as its told to internally unless folder container configuration info. The jar just contains the default configuration


    [quote='Miwarre','https://forum.rising-world.net/index.php/Thread/4806-Zip-vs-Jars-Plugin-nameing-conventions-upgrades-and
    Oh no! Nobody reads instructions (except you, me and some other on this forum, of course... :whistling: ), Windows users never pay attention to file/directory name case, everybody can make mistake... The less steps are required by the user and the most obvious each operation is, the smaller the probability of errors and problems. The simpler, the better; and "one plug-in, one directory" is hard to beat as simplicity and understandability.
    [/quote]
    I think its reasonable to expect that if the person using the mod just wants to use it out of the box then they can just install it. The directory creation and whatnot should not be done unless the player actually wants to mod it like you said with extra elevator models. That person is going to have to read instuctions otherwise. Or you can design the elevator mod with a gui that will allow the player to browse to a 3d model on their hard drive and then the mod will update the config file and subdirectory by itself. If you design software to be user friendly then the instructions should not be too complicated or in many cases the process intuitive. Most of the minecraft mods' I've seen are NOT drop-in friendly so I hope that with Rising World we get a chance to do modding better and smarter :)



    (incidentally, the requirement you seem to propose of .jar file name matching sub-directory name is another thing which can easily go wrong).


    Depends on how Red51 implements the plugin installation process. Perhaps when RW boots up, it scans the plugins and automatically creates the subfolders based on the jar names. Its up to the jar to use the folder space as it needs but it could definately be optional. This would remove any requirement for a player to be renaming folders properly. We have to view installing mods almost like operating a toaster appliance. You buy the think and plug it in and it just works.



    B) Maven & NetBeans: I have never used either, as I'm in the Eclipse / Ant congregation


    Maven is a much smarter built tool than Ant. In ant, steps are defined manually. In maven for the most part just define the jars and their version numbers you want to include and Maven does the rest. There's much less configuration necessary and I'd imagine that Netbeans or Eclipse will do most of that work for you. Incidentally, Ant is used by default in Netbeans as well. if you swith to a maven java project then it changes.



    How the repository backing this list is organised, whether some quality control is assured or whether some requirements are made to appear in this list (and which ones), I believe are questions better left to the dev team to decide, according to the general application structure, dev resources and priorities, whether Steam (and Steam Workshop, in case) make requirements or assumptions and so on.


    i agree that its ultimately up to the JIW team how to manage all this, Perhaps the modder community can manage something like what I'm suggesting seperately. Its just an idea. The convenience of having it part of rising-world.net would mainly be to give all users access without having to register on a standalone site. However, for the API it should be easy for us to get to. Most likely the API will be bundled directly with all future releases so using maven to access the API will be not-necessary. In that case the maven repository idea would be more of a community effort to distribute mods.



    C2: From the plug-in developer perspective, a general repo for plug-in source code dev would surely be nice to have.
    *) This can be as simple as a public github repo (which are free) or more structured (I don't think github public repos allows to restrict access to individual sub-directories).


    The problem with putting everyting on github is I imagine we would have lots of mods in the works. That cannot be put under a single git repository. Subversion approach puts all projects under one repo. Git is one repo per project. A git server dedicated to the entire community (whether it be paid for by the community or by JIW) could be more cost effective. Each mod writer has their own repo or repos. And they can control write accesss to their repo



    Yes very quite similar. Whenever Forge is installed in Minecraft it generates a folder called mods and in addition to all the libraries and functions it requires to launch the game. It also adds various other folders for screenshots,texture packs etc.. Right now Rising World is in it's infancy and to create a mod loader for it without the full source code in Java yet is just going to become a nightmare. Example: Right now the RW directory seems organized but once you start adding new libraries and mod folders you need a place for these to go without creating a disaster in the plugins folder. The plugins is a mods folder in itself external from that you would need another folder for additional libraries that connect to both the launcher and game itself otherwise the game won't run. Instead it's going to continually crash. This is why Forge creates it's own sub-directory and folders for which the game can launch.


    A properly packaged jar file will have all its depdenencies included inside he jar. This is the purpose of the Maven build tool.
    So if you want to build a bundle plugin that contains multiple unique plugins written seperately, you'd still be distributing one jar which is a consolidation and repackaging of all the other plugins.


    When a jar is executed by JVM, it does not extract itself. the JVM loads what it needs from within the jar so no mess should be made.


    I took a look at feed the beast and direwolf. Looks like their idea of a bundle is a zip file containing folders containing jars. I guess I don't understand well enough how plugins work in Minecraft but it looks extremely sloppy. If Minecraft is written in Java as the plugins are, then there should not be a mess of folders


    [quote='ArcaneDesmond','https://forum.rising-world.net/index.php/Thread/4806-Zip-vs-Jars-Plugin-nameing-conventions-upgrades-and-Maven-repositories/?postID=38625#post38625']
    Think of it like http://www.feed-the-beast.com Maven would need to have an independent launcher or a dependency written into the game code eta "Paulscode" and added to the games source-code for this to work properly. Don't get me wrong Maven sounds like a great idea and one that we could all use as we rock back and forth on the edge of our seats in excitement for real mods to enter the game. If I'm misunderstanding Maven or what you mean by this then I am sorry.
    [/quote]
    Could you help me understand what a launcher is? I have a feeling that the way plugins work in Minecraft is the result of how the game was hacked and modded in the first place. it worked but it is not clean. Red51 is wanting to make modding easy and support as much as the mod community desires. I get the feeling that he wants to follow all the normal jar packaging standards which should help us write clean and simply packaged mods. No hacky stuff!


    Maven is a standard building tool used by software developers around the world. This is what we use at work to bundle our applications. Our applications are deployed into our Maven repository and pushed into production into our Fuse Fabric which grabs our jar files and makes them active on our application servers.... No messy file structures.. Just a bunch of jars.