FreeGameDev

Very nice Andrew

If you are having problems with any algorithms related to the AI let me know, then maybe I know of some good algorithms that will give big-O speedups - This is after all my field of work i.e. data structures and algorithms

I got a commit pushed which adds coloring to the tiles that are claimed so you can easily see what territory you control (and where your enemies control). The color looks alright now, but no alpha mash has been done for the tiles so the bulk of the tile turns your team color and only the little red cross in the middle remains roughly its natural color. It would be nice to have some discussion as to how we want to represent the team color on the claimed tiles. With this commit I think the coloring is now fully functional (or at least very close to complete).

-Buck

The way the team colors work now you have to change the same areas of the texture to a different color. If you want more variations then we need separate textures for the teams/factions. That could of course also be implemented if we want. I am not completely sure what variation you want?

I was not referring to making multiple textures, I just mean we need to figure out how the standard texture should look.

-Buck

Ahh ok I will think about it I should be connected to the design of the dungeon temple as the tiles generates mana for the keeper and channel it through to him via the dungeon temple.

Working on creature sounds, which i think i got working, but i have the issue that creatures seem to be unable to move anywhere (actually i think it's just the meshes that are not moved, as tiles are dug out if i try). The game also segfaults at various places after a while.
Is this an issue in the latest git, or is it something i've messed up?
(It also sometimes fails to start with

{l Code}: {l Select All Code}

An exception has occurred: OGRE EXCEPTION(4:ItemIdentityException): An object of type 'Entity' with name 'Level_-53_-88' already exists. in SceneManager::createMovableObject at /media/edisk1/opendungeons/ogre_src_v1-7-1/OgreMain/src/OgreSceneManager.cpp (line 6484)

Can't see what that would make this happen from what I did, but I don't know.

I have been working with some of the graphics systems lately and may have introduced a few bugs, this might be one of them. It is trying to create a mesh with the same name as one already loaded. I think this is because it was not properly deleted from some earlier event. I have run for a lot of turns and not encountered that so if you can find steps to reproduce it that would help.

-Buck

The exception seems to happen only the first time i start it with the debugger.
The creatures not moving properly happens every time.
Are you able to get on skype?

Okay, we sorted the issue.
Have now pushed the changes I did, dig and attack sounds are put in. Currently very basic with the same sound for all creatures and not synced with the animations.
Adding more will be simple when we have sounds for the different events.

For the next release I think we should try to get a particle effect system running, that would really spice the graphical look up. And the other thing should be the normal mapping

I have been doing a bit of code cleanup lately and will be pushing some of those changes to sourceforge in a little bit here. Basically I am going though and removing as much of the manual semaphore locking/unlocking in the code as I can. This should make it less likely to have bugs in the future, and may even fix some hidden bugs we have right now.

I also got the code working which sends the creatureAddDestination events working again of the multiplayer system. I will not be pushing those changes to sourceforge until after the next release is out so as not to introduce bugs into that code. I plan to do some more work on the multiplayer system in the next few days.

-Buck

Andrew could you add the keys Z and C to make the camera rotate right and left, respectively?

Should I make a ticket for it in the trac system?

There is a relevant ticket about this already http://sourceforge.net/apps/trac/opendungeons/ticket/45, which you can update.

Done, then we control the camera using q,w,e,a,s,d,z,c which is nice

Yeah, we should also allow zooming using ctrl-scrollwheel or similar.

Why ctrl? If I have a new application or a new game I intuitivly expect it to zoom if I scroll my mousewheel.

Or for what task is the mousewheel planned?

The mousewheel is used for cycling between picked up creatures currently. Though, we could change that to using ctrl-scroll insteadl and use normal scroll for zooming. (Which is very common)

I'm used to ctrl+wheel to zoom. (it is very annoying for me that in gpicview the mosuewheel alone zoom and do not scroll for instance)

Ideally, this should be configurable, though for now we should probably do a vote or something to decide on what to use.

It think we should just have config screen for chaning this, both ways of using the wheel could be prefered. Personally I prefer having camera control on qweasdzc and scrolling of picked up creatures on the mouse wheel.

oln {l Wrote}:Ideally, this should be configurable, though for now we should probably do a vote or something to decide on what to use.

yes configureable is best.

Configurable is best, yes. Default setting should be mousewheel-only zooming and ctrl-wheel list jumping however. This has a simple reason: Many modern mices (I have one) have "seamless" wheel scrolling and not the step scrolling anymore. This works great on scrolling websites and text and zooming in games, but if you need explicit steps (weapon change in Half-Life or creature scrolling in OD) it's not very good because only a small touch on the wheel already scrolls halfway through the list.

That's why I think the quantized list scrolling should include some other button that handles the scoll speed.

StefanP.MUC {l Wrote}:Configurable is best, yes. Default setting should be mousewheel-only zooming and ctrl-wheel list jumping however. This has a simple reason: Many modern mices (I have one) have "seamless" wheel scrolling and not the step scrolling anymore. This works great on scrolling websites and text and zooming in games, but if you need explicit steps (weapon change in Half-Life or creature scrolling in OD) it's not very good because only a small touch on the wheel already scrolls halfway through the list.

That's why I think the quantized list scrolling should include some other button that handles the scoll speed.

I disagree with that. I think a poll should be done to know what players prefer by default. (I'd for sure vote to ctrl for zooming)

QWEASDZXC is a problematic configuration, due to people who have Azerty (French) and Dvorak keyboards (I might be leaving out other keyboard configurations)

In Germany we have QWERTZU.

But to solve his problem, this maybe should be coupled to the multilang support. So that translators have the possibility to add keyboard default settings to their language. Or by some auto-detection of the keyboard layout.