Posts by sapier

Thanks for telling I was wondering if the two differrent terrain id's really are the same, now it's clear they are not. I'd appreciate to have a way to get some terrain type. It'd be great if for terrains there was something like for other things where you could obtain the expected result when breaking too.

btw I guess I've found another bug

Issue 2)

PlayerPickupItemEvent

If you catch a pickup event from a furnace and modify the furnace content using the lower code it seems to cause a crash when you do this a second time. No idea why it seems to work the first time.

In my case I used this code to simulate some sort of material loss due to lack of skill.

And to make it clear it not only throws an exception it completely crashes the game

                event.setCancelled(true);           

                WorldItem[] furnaceItems = furnace.getItems();

                if (furnaceItems != null)
                {
                    int index = 0;
                    for (WorldItem furnaceItem : furnaceItems)
                    {
                        //If item is not null, destroy it
                        if ((furnaceItem != null) &&  (furnaceItem == item)) {
                            furnaceItem.destroy(false);
                            furnaceItems[index] = null;
                        }
                        index ++;
                    }
                    furnace.setItems(furnaceItems);
                }

This is one of the crashdumps, doesn't look very helpfull to me but maybe you can see more in it than I am.

          Caught fatal signal - signo:11 code:1 errno:0 addr:0x9c487318
Obtained 14 stack frames.
#0  0x007f4c7cd83dfa in PlayerMain(int, char**)
#1  0x007f4c7cd7bd47 in (Unknown)
#2  0x007f4b12558b66 in PosixSignals::chained_handler(int, siginfo*, void*) [clone .part.0]
#3  0x007f4b125595fe in JVM_handle_linux_signal
#4  0x007f4c7be5b050 in __sigaction
#5  0x007f4b121425ad in jni_GetLongField
#6  0x007f4bed50c3bd in bool __gnu_cxx::operator==<wchar_t const*, std::__cxx11::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> > >(__gnu_cxx::__normal_iterator<wchar_t const*, std::__cxx11::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> > > const&, __gnu_cxx::__normal_iterator<wchar_t const*, std::__cxx11::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> > > const&)
#7  0x007f4bee106481 in bool __gnu_cxx::operator==<wchar_t const*, std::__cxx11::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> > >(__gnu_cxx::__normal_iterator<wchar_t const*, std::__cxx11::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> > > const&, __gnu_cxx::__normal_iterator<wchar_t const*, std::__cxx11::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> > > const&)
#8  0x007f4beb825813 in _fini
#9  0x007f49b828476d in (Unknown)
#10 0x007f49b827cc56 in (Unknown)
#11 0x007f49b827cc56 in (Unknown)
#12 0x007f49b827cc56 in (Unknown)
#13 0x007f49b1125814 in (Unknown)

Maybe I mussed it but there doesn't seem to be a bug report thread by now.

I'm gonna use this thread to report bugs (and things I consider to be bugs) in the API version 0.7.5.2.

Issue 1)

PlayerHitTerrainEvent

ChunkPart chunkpart = net.risingworld.api.World.getChunkPart(evt.getChunkPositionX(), evt.getChunkPositionY(), evt.getChunkPositionZ());
int terrainID = chunkpart.getTerrainID(evt.getBlockPositionX(), evt.getBlockPositionY(), evt.getBlockPositionZ());
TerrainMaterialType materialtype = Plants.TerrainMaterialType.get(terrainID);

I'd expect this code to return the materialtype of the terrain being hit yet it doesn't work as expected.

e.g. if you hit grassland, gravel or sand terrains it's completely fine, yet if you hit bare soil it does return "water"

Don't get me wrong I am fully aware this isn't completed yet thus a lot of things are subject to change. I just had the assumption that while stuff isn't complete still is built in way that it might hint towards the direction the deveopler is planing the stuff to go.

I guess no one would design stuff in a way contrary what is planned to be added knowingly. Granted there are the cases where assumptions turn to be wrong later or the direction changes because an idea looking great turns out to be not that great later.

Based on those assumptions I got curious because the tree log style and crafting and block scheme didn't suite together very well ... at least to me

So for now to me it seems the direction is that at some point in future you will need the corresponding wood type to create the building blocks yet there most likely will be some generic changes required to make that possible, so it's not very likely to be there soon.

btw I personally wouldn't care if there's a way to travel in EA. I guess most ppl wouldn't if there's a creative mode ... well and there's the portals plugin too so I have a feeling there are enough ppl out there "fixing" the shortcomings of it until they are done in game

Quote from Avanar

Well, isn´t that obvious?

Well just looking at the game itself it might seem to be obvious. Yet I did look at the plugin API a little bit. Asuming the API is somehow representing the game strukture the "blocks" and recipes don't really hint towards that. Granted it is always possible that part of the api was just a "quick & dirty" hack to get it going. Which could very much be true as the API doesn't have a way to define recips from there. Guess once that feature would be implemented a cleanup in this area of the API is mandatory.

Quote from Avanar

It would be a bit annoying for survival players

I don't really get that point, isn't it common in other games to just have a "creative mode" for those who just want to do building?

I wonder why there are different logs in this game.

Agreed I'm in early game, but for now I haven't seen any difference in them. All the building blocks take arbitrary types of wood you don't even have to have certain wood for certain textures.

I guess it's due to something planed later but I couln't find the goal where it is heading right now.

Does anyone know what the plan behind this is?

Thanks

I somehow found a way to provide notifications without the support of the new version api have a look at the code of my RisingSkills plugin if you're interested in what is possible by now.

While furnaces aren't really implemented in the API they do put quite some information to the logfile. Interestingly this information seems to be enough to do a rudimentary smelting skill.

Yeah I know this is a extremely ugly hack ... but it does what it should do

In the long run it would be nice if the furnace meta object did get some internal storage which holds the information about the items linked to the slots as well as the information which player did place it.

I'd suggest to attach an inventory to the furnace but this wouldn't be able to hold the information about who placed it (at least for what I know by now)

Additionally events helpfull for furnaces might something like:

FurnaceOutOfFuel

FurnaceOreSmeltingComplete

I was looking at how furnaces work in the new version and well, the amount of event's created by furnaces in the new plugin api is quite small ... at least as far as I know.

So I have a feeling it's gonna take at least another update of the plugin api to be able to write something like this plugin for the new version.

Quote from red51

Basically you can do that, but if you cache the item and use it at a later stage, make sure the item is still valid then (i.e. make sure the item hasn't been removed or disposed in the meantime). To do that, you can call item.isValid()

hmmm I guess the "empty" item i had was invalid. what about rising an exception if someone calls a function if an invalid item? getTypeID()

Quote from red51

but a generic addItem() method which simply takes a String would definitely simplify this (you'll only need to pass recipe.name

I guess that's a good idea but when trying to add clothing or construction i realized there's stuff like color or texture required too. I was to lazy to check but I have a feeling I would have to read that one from the item in the event and then use it later.

Maybe instead of using the name, the onPlayerCraftItemEvent could get something like an extended recipe which contains not only the recipe definition but also all those additional parameters. If this full definition was a pure java object and could be arbitrarily stored it could be used at any time to create that object.

Additionally the parameters could be modified too before really creating it.

first of all thanks for your patience

seems like my memory tricked me for the last point if (item instanceof Item.ObjectItem object) doesn't return true for lumber so you can ignore that point.

I've found out a few things in between.

1) you cant save the item provided in the event. start a timer and get the item back in the timer callback. While the object stored is still an item it seems to be empty at that point in time.

I can only guess but I assume that I did my checks on that empty item last time what caused me think that lumber is an object item too.

I guess I finaly found a solution, the last missing piece to the puzzle was not using the id from the item in the event but geting the ObjectDefiniton from the recipe name and use that one for addObject

        System.out.println("craftingFinished: id=" + id + " variant=" + variant);

        if (item != null)
        {
            boolean isConstructionItem = (item instanceof Item.ConstructionItem);
            boolean isObjectItem = (item instanceof Item.ObjectItem);
            boolean isClothingItem = (item instanceof Item.ClothingItem);
            boolean isBlueprintItem = (item instanceof Item.BlueprintItem);
            System.out.println("craftingFinished:" + recipe.name + " ID(" + item.getTypeID() + "):" +
                    " isConstructionItem=" + isConstructionItem +
                    " isObjectItem=" + isObjectItem +
                    " isClothingItem=" + isClothingItem +
                    " isBlueprintItem=" + isBlueprintItem );
        }
        else {
            System.out.println("craftingFinished: item as lost");
        }

        boolean isConstructionRecipe = (recipe.type == RecipeType.Construction);
        boolean isObjectRecipe = (recipe.type == RecipeType.Object);
        boolean isClothingRecipe = (recipe.type == RecipeType.Clothing);
        boolean isBlockRecipe = (recipe.type == RecipeType.Block);

        System.out.println("craftingFinished:" + recipe.name + " ID(" + recipe.itemDef.id + "):" +
                " isConstructionRecipe=" + isConstructionRecipe +
                " isObjectRecipe=" + isObjectRecipe +
                " isClothingRecipe=" + isClothingRecipe +
                " isBlockRecipe=" + isBlockRecipe);

        if (isConstructionRecipe) {

        }
        else if (isObjectRecipe) {
            ObjectDefinition objdef = Definitions.getObjectDefinition(recipe.name);
            player.getInventory().addObjectItem(objdef.id, variant, 1);
        }
        else if (isClothingRecipe) {

        }
        else if (isBlockRecipe)
        {

        }
        else {
            player.getInventory().addItem(id, variant, 1);
        }

While I do understand that this is a result from how the data is structured in the game, IMHO for the api this is WAY to complicated

Hello,

thanks for your support I'm a little bit confused, the part wich is troubling me is not the side to find the item or recipe, my trouble is the other side. The place where the item goes to the players inventory.

if (item instanceof Item.ObjectItem object)

does tell true for both a workbench as well as for lumber.

yet I can add lumber by calling

player.getInventory().addItem(item.getTypeID(), item.getVariant(), 1);

but this doesn't work for workbenches as red51 mentioned this just adds an objectkit.

to be honest I could create my own lookuptable where I write the function to use to all the recipe/itemnames but that's something I'm really really reluctant to do

I'm quite sure I'm missing something.

To be honest I completely forgot about the item element in the event so I gave it a try. I gave my idea about the object and item definitions a try too.

Sadly neither of them did work for common and different reasons

first, there's no object definition for a primitive workbench but a item definition so using this as criteria to choose between addItem and addObjectItem doesn't work.

That directly results in an issue with the solution james1bow suggested too because the item in the event is an ObjectItem in both cases too so there's no hint for what to use by using the item type either.

on the way I discovered a further issue, how to add a blueprint item to the inventory? ... well without the other issue solved that'd be just a question for curiosity

Hmmmm I had a feeling it was something like that. To be honest if it was just about a single item it would be fine to just look it up in the definitions db once.

Yet that's not that much helpfull in my case as I want to create a generic wrapper which basicaly replaces the in game crafting. You might ask why I'd like to do that, to me the instantaneous crafting just doesn't feel right so I tried to create a short delay by aborting the original craft, start a timer, fill a progress bar and once a certain time has passed add the craft result to the player inventory ;-).

Adding a custom list of crafts to the mod would work but is way to error prone to be a real solution so was hoping to get all information required to do so from the recipe.

If I did understand upper text correct it might be possible to distinguish between items and object by using the getItemDefinition and getObjectInfoDefinition functions on the recipe output name ... I'm gonna give it a try.

thanx for explaining

Hello,

I'm trying to create a crafting wrapper which introduces some delay when crafting stuff.

It's working quite fine by now yet I do have an issue.

In order to add something to the inventory you need to know which function to call. There is:

addClothingItem

addConstructionItem

addItem

addObjectItem

addItem for example works fine for lumber but it fails when trying to add a primitive workbench

For now I didn't find a hint in the itemdefiniton which of the functions to use either ... not sure if i missed it.

nevertheless. instead of having all those functions up there wouldn't it be way more easy to have a generic function which just takes the itemdef and an amount?

genial .... endlich nicht mehr alle verschiedenen werte und type per printf ins log schreiben

SetDamage method would be helpfull in PlayerHitTerrainEvent too

Quote from paulevs

In that case it should be simple - you can cancel the event and then damage plant manually, for example you can use getDamage and multiply it on level (or any other system that you will implement). Event itself don't provide you the plant object, but it provides you getGlobalID method, so you can get this object from the world with getObject method and apply custom damage to it with setStrength. That should work fine (probably)

I gave it a try so others don't have to do too. Using following Code when the event was a PlayerHitVegetationEvent:

ObjectElement gameobject = net.risingworld.api.World.getObject(event.getGlobalID(), event.getChunkPositionX(), event.getChunkPositionY(), event.getChunkPositionZ());

sadly "gameobject" is null in this case so it doesn't really work that way ...

actually I did do that not ro modify the damage (which is already possible by now) but to get the current strength of an object which is not available in the event.

Update: forgot to mention i did hit a tree to verify that code

Update2:

LOL ... adding last comment made me thing about it once again ... as ai was hitting a tree obviously the right thing to do is

Plant gameobject = net.risingworld.api.World.getPlant(event.getGlobalID(), event.getChunkPositionX(), event.getChunkPositionY(), event.getChunkPositionZ());

if you do it that way it's gonna work.

btw due to how rising world works some things like "boulders" and "rocks" are most likely considered as plant too.

Herbalism doesn't make sense right now as there are no gatherable herbs ... and there's no way to change the plantdefs from api right now.

Update 0.0.1 now supporting mining is uploaded.

Sadly for mining there's a lot of limitations due to the lack of functionality in API.

I've written them to the Issues part of the README.md file if you're interested but I don't wanna address them yet I intend to collect more and make a usefull suggestion on how to fix those at a later time.

Thanks there's still a lot of stuff to be done and pieces missing. Imho the amount of different tool tiers is a little bit on the low side.

Next update will most likely contain Mining support.