OD - Ordered TODO list thread

[Bertram]

Hi everyone,

This is a topic about what is to be done atm for OD.
Feel free to comment.

EDIT: TODO moved to: http://opendungeons.sourceforge.net/wik ... _todo-list

Have fun!

[Elvano]

Forum:

• Delete old useless threads
• Get rid of outdated information
• Replace old topics by new ones (or fuse important info)
• Fuse duplicate threads

This forum is getting too stuffed and user-unfriendly D;

[Akien]

Forum:

• Delete old useless threads

s/Delete/Archive/ IMO. There are always valuable bits and pieces that could be used later or referenced (though I didn't check, I'm just speaking generally about deleting old threads).

[Skorpio]

Forum:

• Delete old useless threads
• Get rid of outdated information
• Replace old topics by new ones (or fuse important info)
• Fuse duplicate threads

This forum is getting too stuffed and user-unfriendly D;

I'm against this. Who would decide which thread is useless and needs to be deleted? Something that seems useless to one person might be useful for someone else. I wouldn't mind closing old threads, though.

[Bertram]

Hi,

I added Elvano's proposal and added task assignment I'm sure of, and proposal for some other ones.

@Skorpio, Elvano: Just tell me what to put there once you got an agreement.

Later, I guess this very thread should move to the website, where it belongs more. What do you think?

[Bertram]

Also, I know some of you guys will find naive that I'm using a thread to create an issue list, while this would belong more to a tracker.
While I agree that we should move issues to a tracker, we should still have priority and people following them when doing the tasks.

That being said, I noticed that there is a issue tracker here:
http://sourceforge.net/apps/trac/opendungeons/report/1

Is it the official one? I mean, can I have access there and start adding/completing issues info?

Best regards,

[Elvano]

If it is an "official" one it might as well be cleared first and re-add only the issues that still stand. It hasn't been used for almost 3 years.

[charlie]

Regarding the forums, we [the FGD management] long wanted a simpler structure for OD. We could archive the majority into an 'archive' subcategory and simplify the structure down to Development and General (with perhaps a 'Graphics & Media' category too).

[Bertram]

@Charlie: If you can easily set what's belong into the archive sub-category, please do so. People will be able to complain if some threads have to be moved back, anyway.
Otherwise, nothing will be done as no one will want to take responsibility for such a sensible thing.

[Bertram]

I've refreshed the issue list in the tracker. Certain issues were actually fixed.
I've also added my own issues there. Feel free to add your own ones if it's a bug, but only add a feature request if you are ready to work on it.

Thanks!

[nido]

- Once done, remove non-working MingW support. Nido?
- Then, have a look at supporting dependencies/ as system-wide ones using CMake parameters. (default to system deps) Nido?
- If we decide to keep AS, add support to use AS as a lib or not, using a cmake parameter (default to use it as a lib.)

accepted

- Decide whether we keep Angel Script (AS) or not. Pending on Nido's agreement (2014.03.19).

For the forseable future, accepted. Unless we explicitly consider angelscript unfit at some point in the future, accepted indefinitely.

- Decide whether you want a windows zip, or an installer. Everyone?

cmake can create msi files.



Also, can we sticky this todo and/or unsticky the one with the last reply in 2012?

[Bertram]

Hi nido,

Thanks for your help!

For the forseable future, accepted. Unless we explicitly consider angelscript unfit at some point in the future, accepted indefinitely.

Ok, first post updated.

cmake can create msi files.

That's also a solution, but does it work atm?

Also, can we sticky this todo and/or unsticky the one with the last reply in 2012?

I can't do that myself unfortunately. Maybe an admin?

[Bertram]

Hi again,

I've got patches awaiting review:
- A few editor's cleanup and improvements:
http://sourceforge.net/p/opendungeons/g ... afd18c40f/

- Made music handled by each game mode and a few related additions:
http://sourceforge.net/p/opendungeons/g ... c3b5e7f70/

- Fixed Lava display in game:
http://sourceforge.net/p/opendungeons/g ... d8a76c681/

- Simplified the implementation of the (Battle)Field class. Once this commit will be reviewed, I'll also rename the corresponding cpp/h files:
http://sourceforge.net/p/opendungeons/g ... 156a689c6/

- Moved the server to its own namespace. Once this commit will be reviewed, I'll also rename the corresponding cpp/h files:
http://sourceforge.net/p/opendungeons/g ... 328260bfb/

Thanks in advance!

[Danimal]

Good additions; So does it means the game will be able to change the music automatically based on situation? Ex: relaxed one for exploration or digging, or noisy one each time a battle breaks up.

[Bertram]

For now I only made something that I considered logical: Make each game mode handle music on its own. And remove the music in the editor as it was annoying when trying stuff there.

Now, your idea looks cool, but I also wondered whether having the music played configurable in the level a map data is desired?
Those two idea are rather mutual-exclusive, though. (Except if you define a normal music and a music for battle times.)

Anyway, what currently lacking in the music player is:
- Change music tracks handling from integer index to a string based array.
- Add fade in/fade out and cross-fading support.

Best regards,

[Danimal]

Yes, kind of, so music could vary from biome to biome; we would use a jungle like for the jungle biome and a calm one for the underground biome.

[Bertram]

Cool, I added that to the first post.

[Bertram]

Please, review my patches or I'm going to get stuck for what's next. Thanks in advance.

[paul424]

It's ok , except please add #include <string> in the Filed.h header file.
Seems you delete subdirs with code which ain't >>source<<.
In those separate dirs I keept main.cpp , test scripts etc to see how the created component is going to work.
So if in future we would like to fix HermiteCatmullSpline code or Quadtrees I would recommend to start working with those simple demos ... if you remove them , you have to rewrite the scripts yourself ...
The same is with Pipes ... I want to put separte example program , but don't want to have it delted ...

[Bertram]

Hi Paul,

It's ok , except please add #include <string> in the Filed.h header file.

Ok, I'll push that afterward with the requested fix. thanks for the review.

Seems you delete subdirs with code which ain't >>source<<.
In those separate dirs I keept main.cpp , test scripts etc to see how the created component is going to work.
So if in future we would like to fix HermiteCatmullSpline code or Quadtrees I would recommend to start working with those simple demos ... if you remove them , you have to rewrite the scripts yourself ...
The same is with Pipes ... I want to put separte example program , but don't want to have it delted ...

I didn't remove them, I put them in the devel_tools/ sub-folder to make the root folder less cluttered.

I'll also remove the XML/ folder after moving it to SVN, but we'll need to seriously redo that from the ground up.

While I'm on it, there:
http://sourceforge.net/p/opendungeons/g ... fea46961d/

{l Code}: {l Select All Code}

+       if( nodes[UR]->isEmptyLeaf() && nodes[UL]->isEmptyLeaf() && nodes[BR]->isEmptyLeaf() && nodes[BL]->isEmptyLeaf()  ){
+      delete [] nodes;
+      nodes = NULL;
+       }

There, you added spaces in brackets and you broke the indentation. It seems you also added useless spaces. Please, try to avoid that in the next commits.

Best regards,

[Bertram]

Hi again,

I have two questions:

- The files source/FixedPrecision.h/cpp seem to be useless atm.
What were they going to be used for?
If it happens they have none, I don't see why we should keep them.

- The source/Render_Request contains duplicate and outdated split render request code from the RenderManager.cpp file.
There is no point in keeping that as it is useless and confusing.
If the goal was to split the code into pieces, well, better start from scratch and do it in a better way, IMO.

So, without strong point against, I'm for removing that dead code. Anyone?

Best regards,

[paul424]

1) Well that was to simplify the Culing algorithm for tiles ( the fixed precision arithmetic is done impliciltly on int's ) IF someone could implement that FixedPrecission class and rewrite the CullingManager to use it .
2) No idea ... split ? Ahh you should have deduced yourself ... I wanted to have separate class for each RenderRequest.

[Bertram]

Hi Paul,

1) Well that was to simplify the Culing algorithm for tiles ( the fixed precision arithmetic is done impliciltly on int's ) IF someone could implement that FixedPrecission class and rewrite the CullingManager to use it .

Ah, I see, thanks. The fixed precision might be unneeded though, as we could simply cut one tile wider than necessary from what I understood and have the same result.
But ok, let's move on with that point later as there is more urgent.

I'll turn the culling manager into a component of the camera manager, though, since it is only used by that class.
Plus, I'll need to do that to remove some useless complexity in the camera manager initialization.

2) No idea ... split ? Ahh you should have deduced yourself ... I wanted to have separate class for each RenderRequest.

I guess I deduced right then. My point is that each duplicated pieces you've put in the sub-folder is more or less outdated/non-functional, so the work should be redone anyway.
I'll remove them to prevent maintaining dead code uselessly. That task will have to be done for good at once before being pushed in development to avoid
producing just duplicate dead code.

Best regards,

[Bertram]

All right, every patches pushed. + Field and Functions.cpp/h renamed .

I also removed the XML/ folder from the code source and commented the CG plugin in the corresponding files.

[Bertram]

Hi again,

New patches for review:
- Cleanups:
https://github.com/Bertram25/OpenDungeo ... b58f306397
https://github.com/Bertram25/OpenDungeo ... 1434ddb065

- Something more interesting:
https://github.com/Bertram25/OpenDungeo ... aad8e037fa
--> Made each application modes set up itself the camera starting position and removed the need to hardcode the map size in the game map constructor.
As a result, the starting camera position in game mode will start at your temple position (the room spawning Kobold workers.).
--> If there is no temple, for now, a default value is applied. Maybe we'd want to add start pos parameters in the map for each player?
--> The starting position in the Editor mode is still the map center. (Here: 200, 200)
I also turned the culling manager into a component of the camera manager, and move the camera initialization into the camera manager class at its much more logical that way.

!! While doing it, I realized that at load/save time, the creature/room/tile position are stored relatively to the map center. But during the game, the entities coords are absolute. The (0,0) position being bottom-left.
I'll will be working next at changing the saved/loaded entities coordinates back into absolute ones since it will make things much easier to follow.

Best regards,