Posts by DrohtinDev

Concept - Part 4 "Creative & God Modes!" (Rising World Alpha) (Let's Play)
Arround minute 24:11 you can see some issue with the map. Is this a known bug or something new?

Also the pyramid seems to be in more than one chunk. So when you "zoom out" the building becomes partly invisible (I assum this is some kind of LOD). Are you planning to make a step between (between full model and nothing)? For sure such big objects are a problem. I think it could be better to put the LOD on the whole building. I know it would be hard to integrate that in your chunk system.

Is there a difference in walking on grass or on dirt? I am thinking about different speed (walking on plant dirt should be faster than walking through high grass).

Very impressing building, great job.
The lights at the second pic look awesome.
I am just wondering, why has the background tree this white looking color? Beside the tree are also some weird white looking spots.

love the small "tent" (shelter). Looks really smooth. Is the whole tent crafted or did you build it "by hand"?

Guys you are doing a great job with concept. The frequently updates are quiet nice. But sometimes it seams that you release staff a bit to soon (last release has 7 minor bugfixes). I think it is no problem during an early alpha access.
But I would recommend a nightly and a stable version for the future (maybe next year...). So everyone can choose which version he prefer.

Especially server are running with stable versions and do not update so often.

ok thats true. Maybe the check methode to proof if a key unlocks the door must be a bit better. A master key needs a generates key with a special format the it can open doors witch a vertain area of numbers.

That brings me some good point: Since master keys are freaking expensive in real world...you should do the same here
By the way...keycards (like in hotels) are compareable to keys...just another mesh...so maybe a good idea to implement them also (shouldn`t be that much work).

An idea about the key:

Just make a key generator tool to make keys by number. Save the number in the key. If you create a new key with the same number, it will open the same doors.
It is comparable to the keypad feature just that the code is fixed in the key. For each key made by the player save an entry in a list with the number of the key and a free editable text. So if a key get lost the player can use the list to make a new one with the same number.

So you also have to change the door. I would recommend a special "lookable door". If you build this door you also have to enter the number for the key (that the door knows what key fits). It is not 100% save but like in real world...if someone crack the code he will open the door...so see it as a feature (not a bug or weak implementation )

As long as the player do not user a "123" code the doors will be safe.

So just an idea to solve the "key-problem"

best video of them!

Sicher wäre das eine Lösung, würde jedoch die Spieler mit entsprechenden Rechner dem Spielerlebnis (Grafierlebnis) berauben!
Daher hatte ich eher im Sinn das man eventuell in die Richtung geht das man die Szene nur bis zu einem bestimmen konfigurierbaren Abstand reflektiert. Soll heißen Leute mit Powerrechner kriegen im Spiegel auch weit entfernte Objekte zu sehen und Spieler bei denen es grad so läuft kriegen quasi den Abstand 0 und damit gar keine Reflexion. Zumindest gibt es dann keine unnötige Einschränkung von Objekten und auch keine Performanceprobleme bei schlechten Rechner.

Mhh, die Objekte an sich sind sicher zu gebrauchen und machen das Häulse gemütlich. Aber vielleicht noch eine kleine Herausforderung für die Entwickler:

wie wäre es mit einem Spiegel

Quote from red51

sämtliche Objekte innerhalb eines Chunks werden zu einem Mesh zusammengebacken und haben quasi erstmal den gleichen Zustand wie das Terrain oder die Blöcke

Ja das Thema hatten wir ja schon mal. Ist auch aus Performance Sicht auf jeden Fall sinnvoll. Aber trotz das es nur ein Mesh ist, sind es doch noch verschiedenen Objekte oder verstehe ich das falsch. Was ich genau meiner ist, das wenn ich bspw. mit der Spitzhacke auf ein Objekt schlage wisst ihr durch Collision Point und die daraus resultierende Fläche ja auch auf welches Objekt ich gerade einschlage!
Das heisst im Endeffekt um das Problem mit schwebenden Dingen zu vermeiden muss jedes Objekt wissen ob ein anderes Objekt an ihm haengt bzw. auf ihm steht. Das muss beim platzieren jeweils bestimmt werden (wahrscheinlich Kollisionsabfrage).
Insofern ein Objekt zerstört oder entfernt wird, muss es alle an ihm hängenden Objekten bescheid geben. Wie die dann reagieren steht nochmal auf einem anderen Blatt (eventuell kurz in den Physik Space nehmen... ).

Ich denke auch nicht das das Thema auf der aktuellen Tagesordnung stehen muss, jedoch denke ich das es hier wichtig ist ein Konzept zu haben was einfach in die Architektur einzubauen ist (und man nicht 1000 Codestellen anfassen muss).

Quote from red51

Ja, das ist momentan in der Tat eine unschöne Lösung. Wir wollten es ursprünglich vermeiden, Objekticons anzuzeigen, aber ich denke da führt kein Weg dran vorbei.

Ich persönlich denke das Icons für alle möglichen Objekte sehr zeitaufwendig sind. Eventuell kann man mal versuchen eine Community gestützte Lösung zu etablieren. Sprich ihr schreibt einfach mal aus was ihr braucht und in welchem Format und Style und schaut einfach mal ob jemand Kreatives dabei ist der was beisteuert. Das ganze an ein kleines Belohnungssystem gekoppelt könnte erfolgsversprechend sein (Belohnungsidee: Blick hinter die Kulissen, NPC mit Name versehen, etc.)

Klingt nach einem recht lustigen Fehler das die Halterung das schwebt (sollte bei Postern u.Ä. wahrscheinlich auch so sein, werd ich heute Abend gleich mal testen).
Da ich gerade nicht spielen kann ist wohl auch eine Frage was passiert wenn ich den Steinboden unter einem Tisch weghacke?

Sollte Physics da nicht eigentlich den Job übernehmen und dafür sorgen das die Objekte dann runterfallen?

GLSL100? Really? Why are you doing this? Since JMonkey already need at least opengl 2.1 you can use GLSL120.

Anyway... as far as I know is this grafic card a little low with memory (just 256 MB, maybe plus 256 MB shared). You already mention that this could be a problem. But I think the system provides just 2 GB RAM (or is it 4GB?! ). That means it is not well to increase the shared memory since the game itself need also some space. I also think that so much shared memory slow down the game.
In my opinion: it could be tricky to find a configuration that works on this system. Maybe it will not work...
So I am really interested in the final solution of this problem

Hi,

I already had some compareable issues with a my shaders (not in concept). If I remember correct the problem was that I used GLSL130 language. If the system does not support this feature I got this error. As you can see above the system just supports GLSL120. Maybe this could be a reason?! I used an if statement to do something else if the system does not support GLSL130. This worked for me because the compiler just compiles what the system needs (and not the GLSL130 staff).

I would recommend to find out what shader is affected and check the code for language elements that are not supported in GLSL120.

Nice Feature! Looks much better!

How is the impact outiside of buildings? Or is it just enabled in building?

looks a bit like an IKEA dungeon

Quote from red51

Well... this is a very "specific" thing you're talking about.

I think the best way is some kind of repository for free available scripts. So players can create and publish scripts. If you have enough player there will be scripts for almost everthing.

Quote from red51

But remember that you won't see too much of the biomes in the next update

I know. I just though a bit about biomes and there are many possibilities. I just want to know if the idea of biomes is already clear or more a concept ( )

Do you think the game needs some loading time (like "entering new world, please wait") if the biomes switch really tight (e.g. from forest to grassland to tundra to poloar). I think you need a lot of textures and a lot of different meshs.
I recongnized the biome size is quiet big compare to the "chunk view distance". Is that the trick to avoid the loading of too many textures and different meshs?

I would like to know a bit more about the biome.

Do they have a fixed sizes and a fixed form (let's say a rectanlge)?
Is the vegetation in a biome fixed? I am talking about the kinds of plants that are alowed in the biome?
Are the animals (which are coming with one of the next releases) related to biomes?
Is the sort of biome fix? For example if I plant some trees in grassland (can I do this?) will it stay grassland or is it a forest? Or the other way around (so cut all tree and all gras, will it become a desert?)
If a game is already running on a server (with many changes on the map) and you add a new kind of biome ... what happen (does the game stay like it is without these new biome)?

ok that's all for now ...

I can go with that...so just something to think about (I know we are way of topic now )

I do not know your release cycle (build the jar, the assents, take it together, upload it, etc.) and how much time it take, but maybe you should think about feature driven release.
That means as soon as a feature is fully implemented you release it. I know this sounds very tough for you. But think about it...

(1) you still have the automatic update for the player (so they have no problem with many releases)
(2) new feature are much faster available
(3) fast feedback of single features
(4) player will play more often to see the new features

Maybe you can also think about a public feature list (to do list) and each player (just people who own the game) can vote in some way for features. You don't have to do this with each one but maybe in this way:
"Do you want feature A more oder feature B"
This could even work on your facebook page...