Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Crunch]

If there's room for another 3D modeler, I'd be happy to help out.  I'm fairly new to DF, but I do have some experience turning small 2D art into 3D art...

[Skeggox]

Any help is more than welcome, Crunch!

Obsidian's philosophy is that absolutely anyone can contribute anything.

To that end I've chosen to use OpenSceneGraph to render the geometry and models. That means there is a decent composer called OSGEdit(http://osgedit.sourceforge.net/) that you can use to import models and play around with. If you can make it in OSGEdit, Obsidian will render it.

Currently, opsneakie and Djohaal are our modellers/render experts, and GFXiNXS our artist. Contact them (cc me) and lets organize what models and textures we'll need for starting out.

[orbatos]

Is there a centralized location of needed objectives? What I mean are lists of models, textures, Obsidian modules, etc.

This would make it easier to contribute as people would know what is already available versus partially complete or entirely missing components.

[Skeggox]

Alas, not yet.

I'm spending practically all of my spare time on just getting Obsidian to a beta release state.

I'm hoping someone will volunteer to set up and run such a central repository?

There is a bare-bone wiki landing page for Obsidian (http://df.magmawiki.com/index.php/Utility:Obsidian) that would make an excellent starting point. Just add some pages for models, textures, etc. and then we can use the discussion pages to coordinate what goes on the lists.

[Daenyth]

Getting set up on github is very very easy. I can help you out if you want

[Skeggox]

Hrmm. Can we use github to store the source art, as well as the art assets then? Even if they get large? What are the file size and bandwidth limits for a project on GitHub?

If that is workable, what would you need from me to setup a repository for Obsidian on github?

I'm using Git locally (I'm fairly newb with it - been using Perforce for a while so the learning curve is interesting).
Eventually I can push the source with history to github once I'm ready to release it. Until then we can use it to push binary releases and models, textures, logos, etc.

[Daenyth]

Large binary assets are one of the things that git is weaker at, but I'm sure we can find some way around it, perhaps hosting them separately, though it's certainly possible to include them

Size limits: http://github.com/plans

Why don’t I see any disk space limits?
GitHub does not have any hard storage limits. We have soft limits for each plan to prevent abuse. We find almost everyone uses a small fraction of this limit. If you find yourself needing more disk space for a legitimate use, email support@github.com.

The soft limit for the free level is 0.3gb I believe.

[Skeggox]

Ah, okay, I see.

Hrmm. Right - I think I'll use http://dffd.wimbli.com/ for binary releases of the tool and source art packs.

Art candidates (models, textures, etc., both source and compiled) will be hosted by the contributor until they are accepted into an art pack, in which case they will be packaged and published into the above-mentioned DF repository.

Links to art candidates will be posted on the wiki Art page that I've just set up (http://df.magmawiki.com/index.php/Utility:Obsidian/Art).

I'll use GitHub for source code only. I'll take a look at creating a repository when I get some time.

[James.Denholm]

Just to offer a different viewpoint - Most of the Dwarf Fortress utilities that I've seen (Stonesense, Dwarf Therapist) use Google Code as a host, which works with Subversion and Mercurial... whatever the heck Mercurial is.

So, yeah, it works with Subversion. Which I would argue as being the option to go with, because I'm unaware how Git works, and therefore is must be evil and you should avoid it like the plague.

[huhu]

Git is pretty simple, and comes with a very good web interface. It has about a billion different, sometimes-tough-to-decipher error messages, which happen when you're trying to execute a command that wouldn't do what you expected. You can override its complaints if you really want to, but also suffer the consequences. Anyway, it's just a code repository. Two flavors of tea are still tea both.

[Skeggox]

I chose the Git because it is a VCS I haven't tried yet, and it was next on my list of things-to-learn (being my first distributed VCS) . I've whipped Subversion already, but Mercurial is even less well known then Git at this point, at least to me.

[Cruxador]

Git is pretty simple, and comes with a very good web interface. It has about a billion different, sometimes-tough-to-decipher error messages, which happen when you're trying to execute a command that wouldn't do what you expected. You can override its complaints if you really want to, but also suffer the consequences. Anyway, it's just a code repository. Two flavors of tea are still tea both.

Not if one of them is actually an herbal tea.

[orbatos]

"Tea" as colloquially used in the US is too vague for this sort of comparison, perhaps the relative toxicity and flavor of indonesian (Cassia) versus ceylon cinnamon might be more appropriate. You could probably make a broader case for a comparison of VCS in general based merely on the digestibility of the Lauraceae family.

I like the potential concept here where Dwarf Fortress content becomes abstracted into a data set that can be interpreted in a variety of ways, so I wonder if there is any possibility for a similarly modular interface system.

[MP2E]

I chose the Git because it is a VCS I haven't tried yet, and it was next on my list of things-to-learn (being my first distributed VCS) . I've whipped Subversion already, but Mercurial is even less well known then Git at this point, at least to me.

I commend you sir, git is absolutely fantastic and my favorite DVCS by far(mercurial is pretty cool too, but git is just that much better). As for github, I would recommend using that for hosting. The 300 MB repository size limit is only imposed at first to make sure you don't take advantage of GitHub in a malicious way. All you have to do is email support after you make an account, and they will be more than happy to give you more space for free! However one thing I would NOT suggest, do not include binaries in the git repository, in git, every bit of data that has ever been in a commit is included when a person goes to clone the repository. This is nice generally, because the objects are all compared to each other and only the differences are stored, then heavily compressed. However with a binary the delta compression does not work nearly as well. Having one or two tiny binaries is fine, but you have to remember, EVERY TIME the executable is changed, or even if it is removed, if it has at one time been included in a commit that data must be downloaded for every user that clones your repository(unless they only clone 1 commit, svn style).

By the way, I can help with some stuff. Whether it be git advise, helping port to linux, or whatnot.

[Skeggox]

Progress Report

The save part of the Cell engine is now finished to alpha quality - it can serialize out any data structure defined in the cell definition file to XML. It implements cons hashing of instances, with a simple run length encoding of the actual map cell array. This optimizes the in-memory and on-disk representation for size, since I want Obsidian to handle very large megaprojects without borging the computer's memory. This trades off against speed a bit, but currently the cell engine takes about 12 seconds to save a deep 2x2 fortress, with DF suspended only for the first 4-5. That seems reasonable so far for an unoptimized debug build...

As a nice side effect, the XML file is also pretty darn compact now. A 2x2 embark with 180 z-levels is saved as just over 300kb of text XML. I might not even need a compressed binary serializer... argh, who am I kidding? This is DF - someone is probably already itching to throw a 15x15 embark with 500 z-levels into the front of the Cell Engine just to watch the pretty flames and shrapnel coming out of the back of it. 

Ahem. The cell engine currently reads from DF and saves to file the following:
1 ) Tile types
2 ) Materials
3 ) Global Features (DF only has Underworld for now, AFAIK)
4 ) Local Features (Adamantium tubes, pits, stairways, river sources/sinks, etc.)
5 ) Veins
6 ) Stone Layers
7 ) Constructions
8 ) Settlement info*

Items and critters will eventually be added as well - but they are lower priority for now.

Next up: With the engine settling down to a somewhat stable architecture I'm going to finish the Lua bindings - so that you can query/manipulate all fortress data from inside of a Lua script.

After that I'll be grabbing the latest DFHack and updating the Cell engine to use it, i.e. get some support for 31.06+.

Once all that is done I will release a beta Lua module of the Cell Engine for anyone that wants to dump their fortresses to XML and play with them a bit in Lua. ETA is expected to be 2-3 weeks (we're entering finalling, so my days are going to be hectic for a bit)

Skeggox

* The code is written, but my version of DFHack doesn't implement it so I can't test it properly yet