Posts by LordFoobar

Quote from Minotorious

ok the null pointer exception probably happens because this line: Item item = chest.getItem(1); returns a null item and then the item.getName().equals("bandage") compares the name of a null value i.e. a null again with the word bandage

Yes. When comparing something in Java, you are better to compare a constant with a variable, or check if the variable has a value first. One of :

if (item.getName() != null && item.getName().equals("bandage")){

or better

if ("bandage".equals(item.getName()){

But in your case, since getName() may be the cause of your NPE, you must check for null, so

if (item != null && "bandage".equals(item.getName()){

Is it possible to see the source code for this plugin? I could try to reverse engineer the jar, but I'd appreciate sharing the source code so others can learn how you did it and even improve upon it (it is CC licensed after all).

The current implementation lacks an access state. Namely, plugins know when a chest is accessed (opened), but not when the chest is closed. Therefore, I propose extending this event with a simple flag

public class PlayerChestAccessEvent extends PlayerObjectEvent implements Cancellable {


    boolean cancelled;


    public PlayerChestAccessEvent(Player player, commons.objects.ObjectElement object) { }


    public PlayerChestAccessEvent(Player player, short objectid, byte variation, int cx, int cy, int cz, short px, short py, short pz, short rx, short ry, short rz, int info, byte status) { }


    public int getChestID() { }


    public boolean isChestOpen() { }


    public boolean isCancelled() {  }


    public void setCancelled(boolean cancel) { }
}

The new method isChestOpen() would return a boolean true or false whether the player opens or close the chest. Current script would need to check this flag to make sure that any logic is not executed twice, potentially breaking some internal state. I do not believe that an extra event is necessary, and the potential breaking change is a reasonable risk since it shouldn't affect too many plugins, and those can even benefit from this flag at the same time.

Rationale

There is no way to detect when a player close a chest.

Quote from Bogus

Hello Lord Foobar ;D

Nice to see you and a warm comback ;D

Thanks!

I have a lot of things to catch up with! I'm still pretty busy, but I will have some time to spare this winter (hopefully!). Meanwhile, @yahgiggle has been filling in for me quite nicely, True loyal gamer he is!

If I can help with plugins (Java) in any capacity, I will see to help.

Cheers!

I recently discovered a way to smelt more ore than I should, as evidenced by this screen capture, where all sulfur ingots were taken out from these two furnaces, from the same batch. I should have got 120 ingots (60 each), but got 140 instead. Yesterday, I got 152.

So, yeah, unless this is a known "feature", I'm all for it!

(Note: sorry for low res image... I just installed Manjaro and Shutter, and realized that it took screen caps using JPEG compression... )

Quote from Miwarre

A first announce to disclose that I am working on a Java plug-in for Area Protection and Management.

It is not a port, it is a complete rewrite from scratch. I am trying to go as much visual and GUI-ish as possible, so the progress is not very quick. A couple of screen shots to show some of the work so far.

There will be only ONE chat command, which will bring up this main plug-in menu (with clickable items):

[...]

The New Area command opens the area selection tool to create the new area; details about the area being created (centre location and sizes along the two coordinates) are displayed in real time in the info panel:

[...]

The idea is to be backward compatible with the existing areas, if possible, but this plug-in will allow to set the permissions of each area individually.

Stay tuned!

Display More

This is awesome! If you want, I could add you to the Github organization, and this would allow others to create issues (improvements, suggestions, bugs, etc.) and collaborate on the code.

Every programmer understand this :

Quote

Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning.

--Rick Cook, The Wizardry Compiled

... testing games is a tedious task

Quote from zfoxfire

Did anyone just get a 12 MB update for rising world? I see no announcements and I've been getting a lot of 0 byte updates for random games which I think is just a Steam bug. I dont see any anouncements on here however.

Uhh.. nevermind. I still have version 0.6.5.1. I'm pretty sure that's the current version.

Yeah, @red51 will most likely announce any update before it is actually pushed, to make sure those with a server can update, too!

Quote from Benjaminn

Almost 1 month later and still no water update, what a game.

Quote from Trillnar

It has actually been 4 months since the last major update of any consequence. The last one being the biomes released last Christmas. With only 1 person doing most of the coding, it is going to take a very long time before the goals are reached . You will find that a lot of the early access games on Steam are only written by one or 2 people . Blockscape, stars one , synthetic world , and kingdoms to name a few. I do not know why water is taking so long but that is the way it is going to be. We just have to wait and see what happens. Unless red gets help, there will be a very long wait for a lot of the stuff that is mentioned in the roadmap. One person can only do so much. We are all going to just have to wait patiently.

If you missed my post about why updates sometimes take longer than in other games, here it is. This is not an extensive post and I didn't go into the complexities of game development, and I encourage you to do your own research instead of claiming absolute knowledge or complaining about things on something you clearly don't grasp. In a world of fast food, fast play, fast freakin' everything, one loses perspective on the complexities that this world offer all around; some people's jobs is to make easy something that is diametrically opposite from it, be grateful for that. Professional athletes and artists becomes who they are with dedication, patience and time, and such is the same with game development. Read the comments on the games that have "mixed" opinions on Steam, and you'll see that the argument of "devs not listening to the players" and "some updates are breaking things" is common. Sometimes, these argument are legit. Sometimes, they are just coming from whining, self-righteous gamers. Don't be like the latter. It is far better to handle discontent than frustrations from one's user base. Think about it.

Quote from zfoxfire

Just a reminder, for anyone who can't wait any longer to take a dive in Rising World, there is a very special secret lake hidden in the game (probably left in there for testing purposes). To find it, simply switch on creative mode and mine straight down to about -800. You'll find it after passing through the glowing red rock.

Hop right in!

LOL

it's actually true. There is water in the game already. The red rock is only to dissuade you.

I think you misunderstood Or I perhaps should have given some precision; the link was mostly about the NASA research, which stipulates that a fall may be fatal at ~17.5 m/s vertically (see page 36, or Figure 10 of the PDF) I had included a link to the StackExchange question to cite my source of finding, and because despite the obvious errors (as you pointed out), some answers and comments are still pertinent.

For convenience, here is a direct link to the PDF.

Quote from Jakemo

So i'm guessing shallow water will give you more damage than deep water? and REALLY deep water probably not much damage at all? Or is that also going to depend on fall height?

Just thought... http://outdoors.stackexchange.…o-fall-for-it-to-be-fatal

Quote from SilverSatin

*snip*
Since we will be able to swim in water i assume we might be getting an oxygen-meter show up on the HUD and a new cause of death (drowning).
How about 1-step further to make RW different than most other games like body heat ->> hypothermia when swimming in cold biomes.
I mean we've got radiators.... It would be cool... also the campfire could radiate heat for after a cold swim!
or is it too much ?

I think this is a very good idea. Body heat (or the lack of) could gradually slow the player's movement. Dying from hypothermia could use the same animation as sleeping. For example, as your body head is reduced, the player's max movement (ie. running speed) is gradually reduced, until it is equal to walking speed, at which point the vision starts to get darker.

Under water, suffocating could start with blurry vision (instead of slowing down), and then having vision fading to black (i.e. sleeping animation).

This would add some realism in the game instead of "hurting" as in many other games.

Wonderful!!

Quote from shortybsd

Sad decision, LUA is fast and does not need to be compiled for on the fly coding. To be honest I'm not a big fan of Java, although good games came out of it. With LUA I can implement something super quick and makes debugging super easy. With Java it will be a nightmare as well as a memory hog. I really hope you guys thought more of this before making a final decision.

... you do know that Rising World is for the most part Java, right? And while you are right about Lua allowing to build something quick and dirty, you still need to restart the entire game every time you make a change in your script as well.

And, for the sake of arguing, on one hand, with Java one could test their script in a mocking environment before launching the game, instead of starting and stopping the game a dozen times to find and fix issues. On the other hand, unless your Java project is requiring a few dozen sources and third party projects, etc. javac is quite acceptable. As for memory, you are picking your arguments at weird places, as the Lua-to-Java bridge (or any Lua-to-native bridge) requires a lot.... A LOT!! of wrappers and thus creates many memory buffers during a script's execution. While these buffers are cleaned and garbage collected and create very few memory leaks, you never have direct access to anything, and the abstraction layer is really a waste of CPU time.

Having an ease to edit something is usually in opposition with the end result (i.e. performance). And, in the end, the point of a script is to be executed, not edited

Now, I am not part of this decision, even though I have had a voice (that had more or less weight in the equation); but I not only support the migration, I believe it has long term benefits to the game on various and many aspects. Far more than continuing supporting a Lua API (which is nothing but limiting in Rising World). There is a reason why Minecraft have so many powerful game mods and why it works.... it uses Java as well. Not Lua. Just some food for thought.

By the way, the website is up now

Quote from yahgiggle

i know of a another user who built a minecraft type game they had a go at making it round but ran in to all sorts of problems with voxels not lining up they ended up scripping that idea and went with a box type of shape

Of course you can't align squares in a round shape.... regardless how big your world is. My point is that, if you picture a world as a rectangle (because a world is always slightly wider than high.. read about physics... enough said) with a large enough area; a world can be big enough as to appear flat, and walking and wrapping around the map will be seamless. If you've ever played old school FF, for example, they have this concept of a wrap-around world in the game.

Of course, you can't really map that sort of map unto a sphere, for example displaying the voxel world from space, as this would imply a non-rectangle world, which would be messy... real messy, or distord the world parts around the poles to make them fit. Ugly.

Quote from zfoxfire

I personally think that wrap around world would be very playable and better than minecraft infinite. Or atleast an option for this would be cool. I know the idea of a round world was discussed once too and i personally like this best of all as an option.

It is also my opinion. Granted, the world can be large... just as you'd expected from a world (ie. planet) where you can't just walk half an hour and loop back to your original position it has to be big enough to feel "infinite". I supposed that, given this and the future water, the concept of continents (and islands...) could emerge also.

A pretty nice idea could also imply having different world configurations; when creating a world, setting the world's size would impact it's gravity (the bigger the world, the stronger gravity value)... with a limit, of course! Given that the current measures is 1 block = 0.5 meters, a earth-sized world of 40,000 km would give 80,000 blocks, or about 5000 world parts "wide" (i.e. before wrapping around) with a gravity of 9.81 m/s² .

Having different texture packs, different skyboxes and the aforementioned settings, this could be pretty sweet! And biomes could simply be geo-markers to know where we are in the world Also, with that, a world map could easily be generated, browsable, and searchable... with a proper GPS system even.

Just a thought

When you say "infinite", do you mean that the world will "wrap around"?

Good question! I am surprised that this wasn't raised before I think most of the ores are defined, but not coal.