search

Nanoware / Terasology

Terasology is an open source project started by Benjamin "begla" Glatzel to research procedural terrain generation and efficient rendering techniques in Java using the LWJGL. The engine uses a block-based voxel-like approach as seen in Minecraft. After proving itself as a solid tech demo begla was joined at first by Anton "small-jeeper" Kireev and Rasmus "Cervator" Praestholm and a full-fledged game concept was born. Our goal is a game that pays ample tribute to Minecraft in initial look and origin, but stakes out its own niche by adopting the NPC-helper and caretaker feel from such games as Dwarf Fortress and Dungeon Keeper, while striving for added depth and sophistication in the foundation systems akin to DF.
http://terasology.org/
Apache License 2.0
4 stars 1 forks source link

Several small changes for eclipse setup #58

Closed msteiger closed 11 years ago

msteiger commented 11 years ago

I changed a few minor this to get Terasology working in eclipse. It is not yet complete.

I'm not sure why github also displays older changes in the diff view. I merged your changes with fast-forward, so nothing was changed, really.

Cervator commented 11 years ago

Looks good to me - nice :-)

I'm not actually testing in Eclipse, but it behaves as expected elsewhere and the changes look good. You'd be a better judge for Eclipse setup if you're trying to use it!

The reason other commits are tagging along is because the Nanoware branches aren't kept in sync with MovingBlocks after I applied the final version of the restructure there. We can test anything big here (mainly validating Jenkins) but PRs should probably all be aimed at MovingBlocks develop and rebased on its HEAD

I keep separate local workspaces for Nanoware and MovingBlocks to stay sane. Branch / fork / rebase madness can get kinda crazy :-)

msteiger commented 11 years ago

Ok, I see the problem. I should not have merged the original MB/TS branch in the first place. How do we proceed here?

Cervator commented 11 years ago

My usual recommendation goes:

1) Clone MovingBlocks/Terasology into a new workspace 2) Manually copy the few files you've changed from your Nanoware workspace into the MovingBlocks one 3) Add a remote reference to your personal fork 4) Push to a topic branch' on your fork 5) Set a PR from there to MovingBlocks/Terasology's develop branch :-)

Really you can just use the MovingBlocks workspace and never need a Nanoware one. If whatever change may justify testing under Nanoware (for Jenkins) you simply direct a PR there instead. I'll clean up the branches real quick and that way your PRs would simply include any missed commits from MB naturally. Part of why this PR went funny is that the branches have diverged

msteiger commented 11 years ago

Done! Moved to Movingblocks/Terasology ..