Posts by zfoxfire

    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.

    So Arctic and I were chatting about this on the side. When custom models come, we need to be able to support simple animations and that animation needs to be synced for all players in a multi-player environment. This will come into play for things like collision detection.


    The example we came up with are race cars on a track, driving through a hole below the windmill (also like mini golf). The windmill model has a static part and a rotational part. Both players are on a track and from their perspectives, the position and rotational speed of the windmill need to be updated for both players to help them adjust their speeds to avoid collision.


    Collision events need to be worked out as well. I know I'm probably jumping the gun here but I am curious at least what sort of limitations will be. The API methods are not yet published but at minimum I wanted to get this idea out to everyone so others can think about it as well. perhaps those with experience in other game APIs can chime in.


    Character model customization are another topic that we don't really know enough about. Ability to hot-swap body parts and visible armor parts on the fly will be necessary (this will enable his KanKolle stuff). Ofcourse external modeling work will need to be done by whoever writes a mod for this. But from the API perspective, I hope body components will be customizable. I for one want a fox head and tail and fur instead of human skin :)


    I'm assuming that additional character API methods will get released when the character models come out.

    Red mentioned one day about experiementing with spiders and that smaller than giant sized spiders might be possible. I'd imagine with any object could be scaled. My personal thoughts is that when character models come, we can have races finally. Dwarves will be smaller than Elves for example. We would need to be able to scale objects to fit our size. I envision stuff like tiny workshops ran by gnomes and gnomes riding on foxes and things like that.. And maybe even giant torches (not just as a random bug but intentional!). So yes, if scaling of all objects can be done via API then there should be massive spiders and snakes if you so desire ;-p

    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.


    You're now making me wish & desire for dinosaur skeleton displays from this dungeon update, something which may be causing Red51 to tear hair from his head.

    I'm sure its all going into that mysterious Book of Suggestions that Red51 keeps around his house somewhere. I imagine you and I have our own chapters in that one by now ^^ I always though it would be a fun easter egg to find such a book (or scroll) hidden in one of the jars underground. Afterall, there are supposed to be unique treasures to be found in the dungeons at some point. ^^

    ArcticKitsu,


    Well for me it was mostly excavating dinosaur bones, amber containing prehistoric flies with dino dna, gems and flint and rare items in jars are what I was thinking mostly. I think Red51 is going to implement smaller NPC animals at some points (spiders and snakes for example) but nothing really giant like Minecraft spiders. But I can totally get behind your idea of collecting bones to form a complete skeleton and making displays out of them.


    If you recall the huge texture and tree update that came before the biomes updates, the new objects were placed rather seamlessly into the existing world. I'd imagine that implementing dungeons and temples and wood shakes into the existing explored areas would not be a big deal as long as no construction objects are nearby where the new structure will be placed. So hopefully the conversion script can delete a cube of unmodified mountain interior and replace it with dungeons. :-D


    I hope those round objects are indeed scroll jars covered in spider webs. I hope that the bones will be new objects we can collect or harvest. We do need bones anyways in order to make some primitive crafting tools so this is definitely a step in the right direction towards all that stuff we've speculated about.

    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.

    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.

    The gps mod goes bottom center while the compass script goes bottom left, while the currency component of vornet goes bottom right. You probably just need to compare all three to see how text positioning is handled.