OpenDungeons TODO

[paul424]

Also, something it wrong , the possescreature cmd does no longer work ...

{l Code}: {l Select All Code}

 
       // Pick the creature up and put it in our hand
        if(inputManager->mExpectCreatureClick)
        {
            progressMode(ModeManager::FPP);
            const string& tmp_name =  (itr->movable->getName());
            std::cerr << tmp_name.substr(9, tmp_name.size()) << std::endl;
            cm->setFPPCamera(mGameMap->getCreature(tmp_name.substr(9, tmp_name.size())));
            cm->setActiveCameraNode("FPP");
            cm->setActiveCamera("FPP");

            inputManager->mExpectCreatureClick = false;
        }

Have you modified something in here ?

[Bertram]

Broken since before I touched the game mode input logic, as for me.

I don't know whether it is related to the Ogre or CEGui transition. I disabled the same call in the editor mode btw.

[Bertram]

@Paul, Could you open a new thread about config files format and the map data format?
We need to start the specifications from the ground up to make sure we all agree about what to.
This will prevent you from losing time coding something that might end undesired or not giving the needed functionalities.

Thanks and best regards,

[Danimal]

Bertram, could you add skorpios lizarman on next build?

[Bertram]

Sure, and a new in-game GUI? (I'll add the lizardman, the dwarf and maybe the hornet in the spawn pool so we can have a look at them, if I can fix them first. :])

[Danimal]

thanks, the new models deserve the exposure (i love the tiger-ish lizardman) and if you can fix the spawn pool we can finally give the player an empty dungeon from which to build up

[Bertram]

Hi,

I do think the player can already start with no creatures in his/her team. It's a matter of removing all the creature listed for the green player, atm.
Should I try that?

Btw, I pushed the new GUI and my latest patches. (And I'm still on the map loading code atm.)

[Danimal]

it would be great to just start with just your dungeon heart in an empty small cave and dig everything else until you can take on some enemy mini-fortress; and remove the creature showcase from the north. Just save the old test map somewhere since it can still be uyseful.

[Bertram]

I think we want the same thing: a true first playable map.

I'm working on the map loading code and the gui especially for that. So that you could edit some map and then load it to play it, and then share it back.
We can always keep the test level for reference of course, but I clearly see your point.

[Danimal]

I think we want the same thing: a true first playable map.

Absolutely, i can even think of a few that could be easily done with what little we have.

[Bertram]

Hi again,

Ok, I added the lizardman, the cave hornet and the new dwarf in the test level locally.
I also figured out how to make translucent wings for the hornet:

cavehornet2.png (128.25 KiB) Viewed 13643 times

I must also apologize since I was wrongly thinking the specular and diffuse textures were applied. This is false, they aren't but the corresponding color values from the general script are, which misled me.

I'll have a look at that and in the meanwhile, I'll upload what I have done so far.

Best regards,

[Danimal]

Cool! i want a download of that asap!

[Bertram]

Cool! i want a download of that asap!

You're starting to act evilishly, My Lord.

All that is pushed on SVN, btw.

[Bertram]

Hi again

Nice news, while working on the map loading code, I got to learn enough of the mechanisms of the map tile, and ended up working on this:
https://github.com/Bertram25/OpenDungeo ... 0ba9bb333f

Now workers will be able to claim walls and turn them into claimed ones.
Claimed walls won't be diggable anymore by opponents, but will still be by your team.

I also removed the tile color spreading effect as it seemed like a bug to me. We shouldn't add such obscure mechanisms, without linking them
to a skill or something clear for the player.

I also cleaned up a few things along the way.

- Started cleaning up the map loading code:
https://github.com/Bertram25/OpenDungeo ... 92f57b8946

- Removed dead code.
- Made map memory initialization set the map size also.
- Moved the map size parameter loading next to tiles.
- Made use of standard tile variable when adding a tile instead of a pointer, since it was mem leaking.
- Merged a few redundant functions.
- Fixed a typo that made non-square-shaped map impossible to load.
- Forgot to tell in commit message: Added missing map size parameters in map writing code.

NOTE: You'll need to apply that change as well to be able to test:
https://github.com/Bertram25/OpenDungeo ... 4e9998e391

Enjoy!

Please, review!
EDIT: I'll remove the ogre.cfg changes from the patch.

[Danimal]

Amazing upgrade Bertram, in your opinion, how is the actual state of the code? how many vital functions are missing or faulty? is feasible to start adding gameplay related element in the near future or will it have to wait ?; and lastly what is your current TODO list (god, i sound like a bossy foreman)

[paul424]

Well , I don't know whether it's diffrence between various API conventions of SFML , but I get lots of errors of type 'no method member named FooBar' while fooBar ( camel notation ) is valid and compiles .... So far this was the case for SFML methods in CreatureSound and MusicPlayer ...

[Bertram]

Hi paul,

Well , I don't know whether it's diffrence between various API conventions of SFML , but I get lots of errors of type 'no method member named FooBar' while fooBar ( camel notation ) is valid and compiles .... So far this was the case for SFML methods in CreatureSound and MusicPlayer ...

Like that I'm not sure, but the FooBar -> fooBar camelcase change is a change that was done during the SFML 1.x -> 2.x transition on certain functions.
Plus, I know there has been some fiddling with fixes to the FindSFML.cmake module by Nido and reverts from you a few times, so I don't know anymore in which state this module now is. This might be one cause.

So I'd say:
- Check you CMakeCache.txt file to see whether you're actually using SFML 2.x lib/headers exclusively.
- Check the FindSFML.cmake module to see whether you've got the latest one. (The version capable to check the SFML version) and ask Nido in that case?

I hope this will help you.

[Bertram]

Hi Danimal,

Amazing upgrade Bertram, in your opinion, how is the actual state of the code? how many vital functions are missing or faulty? is feasible to start adding gameplay related element in the near future or will it have to wait ?; and lastly what is your current TODO list (god, i sound like a bossy foreman)

Thanks. I just hope some devs will be ok for me to push that, since I base my next stuff onto this.

The current state of the code is still not good looking, even if the code is working after all. The most surprising thing is the tangle of several key functions that make the game management really uneasy to follow, and overall, I'm working on this. There are also incomplete constructors/destructors that are making memory leak, or on the other hand a few redundant functions that don't help either.

Note that I don't blame anyone in particular, while I can't ignore facts. I hope nobody gets hurt by my changes or comments. I simply do think they are necessary. But I'm open for comments too, of course..

The key points on my TODO list are:
- Discover the last features code, simplifying things along the way, filling missing constructors/destructors, fixing small design mistakes along the way.
- Simplification of the map loading code, and map memory management.
- Making the app able to unload correctly a map, and permit to load several ones without crashing.
- Fix or at least reduce the app quit crash causes.

Once I'm mostly done with those problems that aren't that big but really hurting the understanding of what's going on, and somewhat leading to even more errors when adding stuff, I think we will be able to move on.

Also, out of fanciness, I'd like to add those things:
- Simplify a bit the current map format:
-- Without any big revolution here, I'd like to remove the need to specify the number of things you're going to declare.
E.g.:

{l Code}: {l Select All Code}

160000 # Num of tiles next to this line
Tile ...
Tile ...

to this, for instance:

{l Code}: {l Select All Code}

[Tiles]
Tile ...
Tile ...
[/Tiles]

-- Move the creature definition in a separate file.
- Improve the Editor:
-- Addition/removal of creatures.
-- Addition/Removal of rooms.
-- Basic save support.

The patch I've made about claimed walls is a prerequisite for actual rooms support:
I do no know what you exactly want to do about this, but IMHO, room tiles should be put only on claimed ground tiles surrounded by claimed wall tiles. This means that to be able to place a room tile, the tile should be made of ground, be claimed, be next at least one same team claimed wall tile, or a tile of the same room type. Am I correct?

About the other next features I think we could be able to add first, I think we can add custom spawn pool support (but maybe once the creature definition is in another file to make things clearer), biomes support (since it's about texture swapping if I got it well), and support for creature that can dig, but aren't workers.

Feel free to comment.

[paul424]

Well I suppose it has little to do with the state of Cmake scripts on other branches.
Your repo/branch should deliver them all.
BTW I just restored NIDO orginal script to the development branch ( sorry Nido) .
So what I believe the OD development branch has the most general CMAKE scripts to build various OD code ...
But I have little patiance to copy over those scripts from one version to the other knowing I can accidently overwrite something ....

[Danimal]

I dont think you should check for a wall when creating rooms, that would limit too much room creation, since if you are located inside a water island with no walls you cant lie a guard room for example or make a no walls dungeon

[Bertram]

BTW I just restored NIDO orginal script to the development branch ( sorry Nido) .
So what I believe the OD development branch has the most general CMAKE scripts to build various OD code ...

Thanks for making sure the script is the latest again.

I believe you're correct about the development branch being the most up to date.

Well I suppose it has little to do with the state of Cmake scripts on other branches.

Now, I don't know why you're speaking about the other branches, but if you're wanting to work on one, you will need to resync it with development anyway, I guess.

[Bertram]

I dont think you should check for a wall when creating rooms, that would limit too much room creation, since if you are located inside a water island with no walls you cant lie a guard room for example or make a no walls dungeon

Ah ok. Btw, note that I was speaking exclusively about in-game rules, nothing related to the editor. (Just in case)

I'm not sure at all about the rules you want to apply to create proper rooms (maybe there are none more than the current in-game ones?)
or maybe different rooms will have different rules?
(I can already tell the bridge room will be specially handled, for instance.)

Could you give me a bit of input about that?

[Danimal]

its easy, bridge needs water and lava to be placed upon; all the others just need a claimed tile of your colour, in the original dk having walls made them more productive and easier to defend (putting doors and traps) so excavating square caves was encouraged, but walls werent a need, you could create a masive one cave dungeon with no walls at all, and full of rooms that bordered with each other.

[Bertram]

Cool, this means no further work needs to be done atm on that.

[paul424]

Building CXX object CMakeFiles/OpenDungeons.bin.dir/source/CreatureSound.cpp.o
/usr/bin/g++ --std=c++11 -O3 -DNDEBUG -I/home/tom/Opendungeons/opendungeons/source -I/home/tom/Opendungeons/opendungeons/dependencies -I/home/tom/Opendungeons/opendungeons/dependencies/tinygettext -I/home/tom/Opendungeons/opendungeons/dependencies/tinyxml2 -I/home/tom/Opendungeons/opendungeons/dependencies/angelscript/angelscript/include -I/home/tom/Opendungeons/opendungeons/dependencies/angelscript/angelscript/source -I/home/tom/Opendungeons/opendungeons/dependencies/angelscript/add_on/scriptarray -I/home/tom/Opendungeons/opendungeons/dependencies/angelscript/add_on/scriptbuilder -I/home/tom/Opendungeons/opendungeons/dependencies/angelscript/add_on/scripthelper -I/home/tom/Opendungeons/opendungeons/dependencies/angelscript/add_on/scriptstdstring -I/usr/include/cegui-0 -I/usr/include/SFML -I/usr/include/OGRE -I/usr/include/AL -I/usr/include/OIS -o CMakeFiles/OpenDungeons.bin.dir/source/CreatureSound.cpp.o -c /home/tom/Opendungeons/opendungeons/source/CreatureSound.cpp

The -I points to proper include dir. (As pointed out with cmake-gui ) . I checked out the version of SFML there , it's "2.1" .
How it is all possible ?!
The only possibilty is that somewhere in caches there are stored compiled include headers ...
Could you just make your CMake script system identical as on development ?
EDIT:
Ohh dude , you are negatiting yourself , if there was such a transistion as

Like that I'm not sure, but the FooBar -> fooBar camelcase change is a change that was done during the SFML 1.x -> 2.x transition on certain functions.

Than calling methods as Play(), Stop() etc. would require SFML 1.x not 2.x as you claim .
Don't see a reason you don't try using newest SFML. The way you could try is merging development branch into your bertramXXX/development I think ....
Well one library version switch is bearable but in the long run we could go into dozens of lib combinations for each fork ... so why not stop now ?