RWSE (Rising World Script Extender)API

A new update is now available, introducing seasons and more!
Latest hotfix: 0.8.0.1 (2024-12-20)

    Before I jump into this please read my statement first:


    I do not wish to step on anyone's toes nor do I wish to cause conflict between persons or offend the great work of @red51 . He has done an amazing job with this game and I believe we as a community can come together and assist by creating a RWSE: API that will allow mods, new textures, class files and a scripts-config. Only if we can work together without stepping on anyone's toes can this be accomplished. When I began playing Minecraft Forge which is a similar API was created that allowed the first of many mods to work with one another without disrupting the vanilla folders at all. Lua has this same compatibility as Java with the exception that it could run more smoothly. If anyone feels distressed or alarmed at this post please do not be afraid to voice your opinion as it is not created for controversy but as a step towards a brighter future for Rising World. With that being said let's get started.



    In the RS Example 1.jpg you can see there are various folders one of which is "Scripts" which is what I wish to bring up today. Now suppose we created together a script-extender named [RWSE (version number)] and added to the scripts folder and hit play. It would generate other folders with their said components much like RS Example 2. the script-extensions otherwise known as the mods folder would consist of a collection of scripts (mods) written in Lua that can now run simultaneously together. The "Options" as to which I added would essentially be the extension program itself which would allow the script-extensions (mods) to run.


    The "script-config" would allow you to change the configurations of the scripts if you needed to make changes to the script-extensions/mods. When you look at (example 1) you see scripts is basically already the mods folder in general. When you create a script to work with the game you simply ad it and click play and it works just fine. When you start stacking scripts (mods) sometimes you might encounter errors because of a configuration error. This is where the RWSE comes into play it organizes your scripts adds a script-config folder for you to easily go in and make changes much like you would in a Minecraft configuration file.


    What will RSWE look like? Let's look at Forge exhibit 1: In here we see various file of different types and names but one sticks out above them all "Paulscode." What is Paulscode and how does it relate to a script extender? Paulscode is in itself a script extension created for Minecraft to allow mods or in our case additional scripts to run together, hence MCP. Lua and Java are almost completely identical programs. If the mod "Computercraft" was rewritten and added into the new scripts/mods folder with RWSE it would work. So what am I getting to? Didn't @red51 already say he was working on this? Yes he did say he was working on it and the game updates as well. If we (as in the script writers) came together as a modding community with @red51 's blessing and created the RWSE as a superficial scripting api that would install itself we would be providing a great assist with the developers.


    I honestly don't know how to write scripts or mods for that matter, but I do understand how it's all put together. So I ask the developers at this point: Can we please create a superficial temporary modding script that will in no way harm the content of your game? It will install itself in the scripts folder and create a multi-thread that will allow more sophisticated scripts to run?

    I have never played Minecraft (yes, I didn't, believe or not...), so what might be obvious to you, perhaps it isn't to me. In particular I have not understood:


    *1*) What this Extender would do and what kind of "configuration" it is supposed to allow. I can speculate that it might:


    1a) allow to turn on / off individual scripts, which would SURELY be useful, but I would expect the RW own script framework to have this functionality built-in


    1b) change some kind of settings / parameters passed to the scripts by the 'official' API. This would seem quick a disputable hack to me and, assuming is it possible at all without hooking very deeply in the core code, it is likely to raise conflicts and/or to increase the load on user support (the dev team is small and has already a lot to do).


    *2*) Which kinds of problems your proposal aims to overcome.


    2a) "When you start stacking scripts (mods) sometimes you might encounter errors because of a configuration error." As far as I can tell from my own experience and from forum posts, errors are encountered not because of some system-wide configuration error, but because this or that script has not been installed properly.


    2b) Allow a better interaction between different scripts. This also would be useful and I already hit use cases for this, but I suspect it can hardly been provided by a middle-ware, if the base API does not support it in the first place.


    2c) Provide some general routines to be used as 'building blocks' by other scripts. Also potentially useful, but the same observations as in 2b) also apply.


    So, I suspect there is something important hidden here, but I am not able to see it. Can you elaborate a little?

    Perhaps if I explain it this way when you play Minecraft without any mods you're essentially looking at a bundled game. If you want to mod it you go to forge.net/downloads and download the appropriate version that matches the version of Minecraft you want to play. On here think of it as the Beta's you can opt in to play instead of using fuel for example you can go back and play an earlier version without updating your world.


    1) You run the forge installer using the right-click/scroll/java(tm)binary
    1A) To install RWSE you would run it as a stand-alone script in the scripts folder.
    2) Forge installs all the necessary files and MCP
    2A) RWSE would install as soon as you click play. What it would do is install all the necessary files & libraries it would need into the common/scripts folder
    3) Minecraft now has a mods, config, libraries,and additionals that will allow the game to run.
    3A) RWSE now has a folder named script-extensions which in this case is renamed as mods. Here is where you place your multi-threaded scripts in their own retrospectively named folders such as Computercraft for example. These multi-threads are your mods compacted to run when you press play with the help of RWSE. each multi-thread has it's own subfolders containing the textures, animations, objects etc..


    What I'm trying to say here is the scripts folder is essentially a mods folder within itself. You add GPS, Compass or whatever and it runs.
    Lua can run on multi-threads the same exact way as Java. So in regards to a script-extension based API being integrated into the scripts folder you can rewrite any and all Minecraft mods to be compatible with Rising World in itself without disrupting the vanilla features. Instead with your now created muit-thread mods you can add to the game without harming the vanilla content.

    While I don't know that much about LUA, I'm guessing its not as powerful as Java is. Even if both languages support multi-threading its possible that Java just does things much better. The best LUA scripts I've seen in Rising World simply write text to the screen, make database calls, and adding some extra comands to the chat window. That stuff is cool but the kind of mods we see in Minecraft completely modify or add assets to the game. Can we really write really complex stuff like that with LUA? I know its possible with java via class extension but how does LUA handle this? All the mods in Minecraft are written in Java to my knowledge and many of the Minecraft mods are very impressive. There was a thread on here where the announcement of switching to Java was made. I can't find it anymore. I'm sure there are lots of factors that came up in the decision to switch and I doubt Red would change his mind now, especially after all the time he was been putting in the past few months getting this new API ready.


    Regarding the script extension, from what I've looked into it, it seems to be just another API to extend the vanilla API. The problem is that at this point, we do not know what the new API looks like. The first release coming will have only a limited set of functionality. New methods will be added over time. So to talk about an extended API seems to be jumping the gun somewhat. Red also mentioned that he wanted to make Rising World mod friendly so I doubt if there will be a reasonable need for API methods that Red specifically did not approve of but again, its too early to tell. The other problem is that in making an extended API, the Rising World game code needs to be decompiled and tedious efforts need to be made to figure out which classes do what. At that point, simply extend the class and add your new methods to your new class. That can be done but its time consuming unless you have a lot of developers working on decompiling the code and poking around at it. The other problem I see is that the game is still in early access. I just can't imagine seeing any Minecraft levels of modding happening to a game still in alpha. Each time an update occurs there is a high risk of the extended API breaking because I imagine all the class names will now be renamed due to obfuscation (I haven't verified this personally but it makes sense). So now, time has to be invested in fixing the extended API to be compatible with the new obfuscated names in each build AND discover new features. With new release builds happening once a month, that means the extended API breaks each month and possibly by the time the changes are worked out, a new release build might be just around the corner. It just seems like a lot of wasted time.


    So in sum, it might be easier to just have a request stream of new API methods that Red and team can implement if approved. The development life cycle is drastically different between Rising World and Minecraft. Minecraft builds are worked in parallel so it probably makes it easier for modders to get started working on API updates. Mojank has a team and developers have to coordinate code changes, follow processed, and a build pipeline has to be in place to validate integration of all changes. Again, obfuscation is also an issue. Maybe its not so much in Minecraft. Mojang might make it less complicated intentionally to give modders an easier time. I still have to spend some time decompiling Minecraft to see how they do it.. But Minecraft has a build pipeline and development processes. Rising World is written primarily by one person so things are greatly simplified. The build process for Minecraft could be designed in such a way to make it easier for the modding community to to work with beta builds to get their extended APIs ready to go by the time the beta becomes an official release. When Rising World code becomes more stable and in beta then maybe this will change too. At this point, I just cannot imagine any proper development lifecycle or build pipeline being enforced. When its not longer just Red51 and beomes a development team then better coordination between devs and modder will likely be possible. For now, I think the idea of an extended API is seriously jumping the gun by about a year.


    I'd seriously like to hear from any actual mod writers from the Minecraft community chime in with what their experiences are working with API extension development and how hard it is to keep up with even the beta build changes of Minecraft.

    Most of the parameters for the game are stored in database files which are game assets. All recipes are stored this way as well. If the new framework gives us easy tools to to override default values then we could easily write a tiny mod to alter the drop rate of saplings from trees or altering the growth time. Adding new menu screens would be a great way to give the player the option to override these values without digging into the game files which would go over the head of most casual players.


    But in your response #2 is the bottom line that I think we all have to keep in mind. We dont yet know what the new API looks like so we wont know what problems we need to overcome. We certainly know what problems are in the LUA API but that's on its way out so largely irrelevant. The amount of modding done already via LUA is (from my perspective) not complex enough to consider conversion to be that much of a headache. I think Red was smart it making this tough call earlier than later to change the API.


    So yes "Which kinds of problems your proposal aims to overcome" is the core question to ask. I see managers and developers fail in their projects because they don't ask this question up front. They want to change things just for the sake of it without giving good reason why.

    Quote from zfoxfire

    Most of the parameters for the game are stored in database files which are game assets. All recipes are stored this way as well. If the new framework gives us easy tools to to override default values then we could easily write a tiny mod to alter the drop rate of saplings from trees or altering the growth time.

    I didn't investigate these specific points myself and you may easily be true. Granting access to the game data bases is potentially very dangerous (I saw access to the world data base is announced in the new API post and I assume the dev team knows very well what they are doing; I would be more than a little scared...). Also, default value changes may require world reload or even programme restart, who knows. We shall see...

    Quote


    So yes "Which kinds of problems your proposal aims to overcome" is the core question to ask. I see managers and developers fail in their projects because they don't ask this question up front. They want to change things just for the sake of it without giving good reason why.

    Glad you agree! I forgot who, but someone said: "Finding the right questions is more important than finding the right answers" And I would add: "sometime, even more important than finding any answer at all!". :S

    Quote from Miwarre

    I didn't investigate these specific points myself and you may easily be true. Granting access to the game data bases is potentially very dangerous (I saw access to the world data base is announced in the new API post and I assume the dev team knows very well what they are doing; I would be more than a little scared...). Also, default value changes may require world reload or even programme restart, who knows. We shall see...

    Glad you agree! I forgot who, but someone said: "Finding the right questions is more important than finding the right answers" And I would add: "sometime, even more important than finding any answer at all!". :S


    I looked briefly at the old API and there are functions already which allow you to access the database. I'm not sure exactly what it all does since there is no documentation so I never bothered learning it. The fact that documentation will be auto generated with the new API is going to be so awesome! The announcement you're referring to states "full access to the world database". I assume there would have to be some important restrictions to prevent serious damage to occur. However, I guess any bad person could write a mod to drop the world database. Hopefully safeguards will be in place to prevent serious damage to occur. I assume its going to mostly mean that we can write mods now to generate our own custom structures in game without having to place them manually. Perhaps convert some minecraft builds to Rising World :-D


    I've seen plenty of developers and managers make the mistake of not clearly identifying the problem they wish to solve before deciding to just arbitrarily change stuff. There's a reason why in modern development lifecycles, most of the time is spent planning what to do.

    I think it's kind of strange that the same day I was thinking about this and writing this up that the new API was announced for drop. After reading all the details I say yep that's the RW -Forge we've been waiting for and my idea of an RWSE just went...Bloink like a penny in the storm drain. Now there's the modding API we've been waiting for. Time to make some noise on Curse. :)8)

    i mean, if the API is good and Red is willing to add specific features as the demand arises then I think we should be ok. LUA could have been made into a modding API but Java is just far more powerful and efficient and then there is ease of documentation generation. There really is not much reason to hold onto Lua. Using Lua in the first place was designed to be a simple solution but it just turned into technical debt.

    Quote from Miwarre

    Or we could start making mods...

    I will gladly leave the creation of mods to the coders. What I meant earlier was contacting the mod devs, and staff over at Curse. These guys really know what they are doing. When the new API is released they will look into it. A few modders from Curse and the Minecraft Forums are interested in this new API and how much flexibility it can add for modding. The decision for rewriting their mods much like Team CoFH and several others say it's not likely to add technical mods until some type of energy is added to the game. Personally I have no problem with anyone making mods, in fact I encourage it. @Chrisx84 I am willing to bet would be among the first to make a windmill move of it's own accord using the animations added by this new API. @Miwarre I can see enhancing her GPS mod to do a multitude of things, maybe add beacons through use of animations and other technical aspects. No longer will you need to get lost if a beacon from 10,000 blocks away can display your home coords in the distance. Portals can be enhanced to take you to a flat dimension basically stitching 2 separate worlds. One for Mining, and one for building, having fun and enjoying the game. I messaged the makers of Buildcraft and they said the same thing as TeamCoFH the game needs a power source before they can start on anything. I for one am really looking forward to trying out everyone's mods. I'll even do show casings on them :)

    Quote from ArcaneDesmond

    I will gladly leave the creation of mods to the coders. What I meant earlier was contacting the mod devs, and staff over at Curse. These guys really know what they are doing. When the new API is released they will look into it. A few modders from Curse and the Minecraft Forums are interested in this new API and how much flexibility it can add for modding. The decision for rewriting their mods much like Team CoFH and several others say it's not likely to add technical mods until some type of energy is added to the game. Personally I have no problem with anyone making mods, in fact I encourage it. @Chrisx84 I am willing to bet would be among the first to make a windmill move of it's own accord using the animations added by this new API. @Miwarre I can see enhancing her GPS mod to do a multitude of things, maybe add beacons through use of animations and other technical aspects. No longer will you need to get lost if a beacon from 10,000 blocks away can display your home coords in the distance. Portals can be enhanced to take you to a flat dimension basically stitching 2 separate worlds. One for Mining, and one for building, having fun and enjoying the game. I messaged the makers of Buildcraft and they said the same thing as TeamCoFH the game needs a power source before they can start on anything. I for one am really looking forward to trying out everyone's mods. I'll even do show casings on them :)

    thnx for thinking i can make a windmill move but im actually leaving all the movement to someone else who dares to take the challenge. im just looking forward to being able to copy and paste blocks with world edit like we can do in minecraft with their world edit system.

    From What Red said in the post link below, animations of models with bone systems will not be possible yet however simple animations are possible. He did specifically say that a windmill would be possible. Perhaps the stationary and moving part would be two different models. The rotational part is just instructed to rotate around itself. This could open the door to someone writing mods to create gears and pulleys. But I'd rather stick to code than modeling.


    Upcoming: Dungeons and Plugin API


    The Compass and GPS I'd love to see replaced by something like the compass from 7 days to die: http://www.liquidbuzz.com/files/7d2d/miGUI/compass.png


    Red did say it would be possible to add drawings to the HUD. I hope it will be possible to query both land height and texture at each block position (each chunk is 64x64 blocks I think) and generate a map. If we can query textures surrounding us at player height then underground maps will be possible too.. OOOOh the possibilities!!!!
    I think a map is suposed to be coming to vanilla Rising World but I'd rather see Red focus on core features and API expansion.

Participate now!

Don’t have an account yet? Create a new account now and be part of our community!

Create Account Login