[DONE] OD Windows binaries

[Danimal]

Yes, i think they should come with a basic weapon/shield thats is just for show (+0 to attack/defense) or better in case of elite version of some creatures and being able to declare it somewhere.

[hwoarangmy]

ok. Issue created
https://github.com/OpenDungeons/OpenDungeons/issues/285

[Bertram]

Why not, but IMHO, only special creatures, such as BigKnight should come with equipment. (To visually show the difference maybe?)
What do you think?

[hwoarangmy]

BigKnight should come with equipment. (To visually show the difference maybe?)

In fact, a knight without weapon seems a bit strange. And as Danimal said, we could create 0 damage weapons if needed to make such creatures look better...

[Bertram]

Ok, sounds fair... As long as it's just config, I'm fine with it.

[Danimal]

About the kobold not hitting the wall, its next iteration will have either longer arms or longer pickaxes along with normal speed

[Danimal]

yesterday i was playing around with materials, trying to get some normals working, but it was impossible, Why?
I saw older materials used this shader:

http://ogre3d.org/tikiwiki/tiki-index.p ... e=Cookbook

Its not included anymore?

[Bertram]

AFAIK, the normals are used through the real time shader system that does select the corresponding shaders depending on the renderer and drivers capabilities.
Plus, the cg program can't work, still AFAIK, since the cg parser and renderer isn't used anymore because of being obsolete and not provided under linux anyway.

This doesn't mean we can't use normals, but they have to declared in another way. I mean they have to be declared through the RTS system.

Oln has described a way to do it here:
https://github.com/OpenDungeons/OpenDungeons/issues/60
and gave a sample:
https://gist.github.com/oyvindln/f79922 ... t-material

That's the way to go IMHO.

[Danimal]

there seems to be ligths problems when that is applied to models, i also cant get both alpha and normals working... this is way out of my league, ill let the experimention to you guys

[Bertram]

New rolling release

(Date: 2014/11/29) - https://www.dropbox.com/s/ha8ojmksi5sjw ... 9.zip?dl=0

Changelog:

Game:
- New client/server game lobby! Now the server can configure Seats, player factions (Keeper/Heroes), Alliances and AI before playing a game. More swag for the same maps! (hwoarangmy)
- Start on rebalancing creatures (Danimal, Bertram)
--> Don't worry, BigKnights are not as powerful as hwoarangmy want them to be ;P
- Improved Keeper AI!! Now the AI will build any kind of rooms and handle conflicts in a much better way. ;> (hwoarangmy)
- New replay menu. You can now watch your previsou games. (hwoarangmy)
--> Note: This is more a dev feature so there is no movie slider to jump on a certain point of the game and such.
- Buttons have now tooltips. (Bertram, hwoarangmy)
- Added a quick-help window when in game. Simply push F1. (Bertram)
- Added the firs version of Keeper hand. You can also slap your creatures. Still basic, more to come about it. (hwoarangmy)

Creatures:
- Improved creatures path-finding handling, making them more efficient when searching tiles to dig, claim or enemies to fight. (Bertram, hwoarangmy)
- Allow creatures to spawn with equipment (hwoarangmy)
- Properly save the current HP when they are at maximum for creatures in the level files. (hwoarangmy)
- Permit workers to carry dead creatures and gold stacks found on the ground. (hwoarangmy)
- The cavehornet now has translucent wings. (Danimal)

Rooms/Traps:
- Fixed certain beds location on the dormitory room. (hwoarangmy)
- New better training dummy for the Training Hall (Danimal)
- Rolling boulder for the boulder trap (Danimal, hwoarangmy)
- New functional (and creepy) crypt room! For now it will spawn gnomes when bringing dead creatures to it. (An atrocity for Keepers) but one day... (Danimal, hwoarangmy)
--> The rooms also have some kind of inhabitants. (hwoarangmy)
- New Keeper portal model. (Danimal)
- Added support to make an entity translucent optionally and used this to show when the boulder trap is disabled. (Bertram)

Modding:
- New config file for room and traps specific values.

Misc:
- Dropped the use of pthread (oln)
- Updated doc, removed obsolete files, models and textures. (Danimal, Bertram)
- Foundation for the unit testing component. (oln)
This rolling release should one of the last if not the last before release and shall be used for thiner balancing.

Enjoy!

[hwoarangmy]

Cool ^^
It may be a good time to create the 0.4.9 branch so that new patches do not impact the current release. Because I guess balancing may take some time

[Akien]

It may be a good time to create the 0.4.9 branch so that new patches do not impact the current release. Because I guess balancing may take some time

I guess we can simply merge development into stable, and continue working normally towards 0.5.0 while pushing balancing and bug fixes both into stable and into development. There is a 5.0 branch currently, but it should probably be deleted (the name is wrong, it should be 0.5.0 IMO, and it doesn't contain anything that is not in development).

[hwoarangmy]

IMHO, when we do an official release, it is good to make a specific branch and do not update it anymore. It is good to check non regressions (if we see a bug, check which version it is present in).
Moreover, after we do an official release, if a major bug is found after some time, it would allow to make a patch for this specific release easily even if the develpment branch had many evolutions.

[Akien]

IMHO, when we do an official release, it is good to make a specific branch and do not update it anymore. It is good to check non regressions (if we see a bug, check which version it is present in).

For this git tags are more appropriate in my opinion. It's a frozen snapshot of the stable branch at the time of the 0.4.9 release (and will be used by packagers or curious users who want to compile the stable release).

Moreover, after we do an official release, if a major bug is found after some time, it would allow to make a patch for this specific release easily.

That's true, but how many stable releases do we want to support concurrently?

There are several git branching models, some more complicated than others. IMO it would be worth discussing it also with Bertram and oyvindln to choose the one that we like best (and that makes sense for a project with a small community like ours, we probably don't need something too far-fetched).

The current model with a stable and a development branch + tags for releases basically means that:
- we can push bug fixes to release N in the stable branch, and if need be release a N.1 bugfix version from the stable branch (with a N.1 git tag), and so on
- we work on the N+1 release in the development branch
- funky features or work for release > N+1 go into specific branches that are meant to be merged into development when they are mature enough or when the corresponding development cycle begins

So with this model we can support 0.4.9 while working on 0.5.0, and if need be release a 0.4.9.1 or 0.4.10 version using the stable branch.

Another nice model would be to drop the generic "stable" branch and to create versioned branches like 0.4 and 0.5. Note the use of only the first two digits, meaning that we consider the changes between the 0.4.x branch and the 0.5.x branch to be big enough to maintain both branches separately. I don't think the changes between 0.4.9 and 0.5.0 will be _that_ big, but as we discussed it previously, the 0.4.9 is mostly historical and doesn't really reflect the changes since 0.4.8.
For future 0.x.y versions though, we might try to increase the minor number x only when a gameplay or code-breaking milestone is reached (or for example when saved games are no longer compatible with x-1 releases), and increase the patch number y when doing minor releases.

On the other hand, I don't think we should create branches for every patch release that we do (i.e. a branch for 0.4.9, for 0.5.0, for 0.5.1 and so on). We probably won't backport enough relevant stuff to such branches, and having dead branches is a bad practice IMO, tags are better suited for that.

[Akien]

BTW I merged development into stable, though I made a mistake and used "git rebase" instead of "git merge", so we don't have the "Merge development into stable" commit that would have been relevant here. I'll use the proper command next time :-)

[Bertram]

Creating a specific branch is a good idea. I would simply create it as a child of the stable branch. (And I will ;]) The 0.5 branch was a temporary one and should be deleted.
As for branch names, I would name it 0.4 and not 0.4.9.
Why? Because the last number is IMHO for bug fixes only and shouldn't provide new big features. I would instead tag a specific commit with the 0.4.9 version in the 0.4 branch.
That said, this is all theory and I'd really like to hear what you think about it.
Best regards.

[Bertram]

That's true, but how many stable releases do we want to support concurrently?

I do think we shouldn't bother more than supporting the latest release. 0.4.9 is quite an exception as it is kinda the first "stable" version of our team and the first one on github.

And you're right, let's wait for hwoarangmy and oln thoughts about it, too.

[Bertram]

BTW I merged development into stable, though I made a mistake and used "git rebase" instead of "git merge", so we don't have the "Merge development into stable" commit that would have been relevant here. I'll use the proper command next time :-)

I, for one, don't care about having lerge commit in the history. So it's ok to me if you simply git pull from dev/push to stable. :)

I'll be on the changelog

[Bertram]

Changelog updated

[hwoarangmy]

I didn't know the tag system. It may be enough. You know better Git/GitHub than I do. I will let you decide the most suited way to handle the project.
I would just have some requirements:
- Whatever the development branch is, we should be able to patch at least the previous release (in case a critical bug is found) ie make a new release with only the critical bug patched whatever the current development branch state.
- We should keep a track of every release (so that we can check if we find a regression where it appeard first) ie we should be able to download the 0.4.9 version even if the current one is 5.1.7
- If possible, it would be nice to upload the binaries to make sure every version is playable even if the external tools used (such as ogre or boost) aren't compatible with the version (for example if the only ogre version available is 3.0)

[Danimal]

So many new additions , i cant believe how fast this has grown over the past year

[Bertram]

Ok, so if nobody says NO with the big voice. I'll delete the 0.5 branch, create the 0.4 one from stable and once released, we'll tag the 0.4.9 in there.
Github offers download links for the source tar.gz files + binary upload. I'll use that so oln will have a link to use when uploading it to sourceforge.

So many new additions , i cant believe how fast this has grown over the past year

What's left is some balancing touches until it feels rather right. I'd rather say we should make the game more fair, but making it "perfect" in term of balancing is not something we should try to achieve until we have every game features in. Let's try a few (even single player games) and do a few changes. Once we agree on them. I'd say let's release, IMHO.

Best regards,

[Akien]

I say YES with the Evil Keeper voice

[Danimal]

today i was finally able to test the new build, it feels really nice and fluid (balancement issues aside). The kobolds are more industrious now and work everywhere, and i really like that . And bouncing cannon balls
The only small issue i could see it that cross is used as a center spot instead of wall spot, and statues being too near to coffins; am i the only one that thinks that we should maybe increase the tiles overall size by 0.1 or 0.2?

[Bertram]

Hey,

The only small issue i could see it that cross is used as a center spot instead of wall spot, and statues being too near to coffins;

Ok, I'll open an issue about it.

am i the only one that thinks that we should maybe increase the tiles overall size by 0.1 or 0.2?

Or decrease the room models instead maybe?
I also think the starting view is a bit too high. (Since it's at the maximum possible height.)

What do you think?