Current state of GAE?

[titi]

Whats the current state of GAE?

Is there soon any hope of a version that
- has all glest 3.2.2 features included
- has any kind of working multiplayer support?
- is really stable( regarding at least the glest 3.2.2 features ) or on the way to get a stable version? ( Probably in its own branch a branch with some kind of "feature freeze" )
If there is anything like this in the pipe, please give us some official alpha or beta versions that we can test ( not only svn access )!

If a stable GAE release like this is not really possible yet, maybe you can give us an improved version of glest 3.2.2?
With all the upcoming and released mods the current glest really has a big problem with its way of loading. It loads all the factions in a techtree, used or not. So maybe you can give us such a patched 3.2.2 Version now if you need more time to create a first stable GAE.
I think all the glest modders would be really really happy to get something new official and stable whats better then 3.2.2 .
We (the modders/content creators) really need one official version that we can base on, please give it to us!

[silnarm]

If a stable GAE release like this is not really possible yet, maybe you can give us an improved version of glest 3.2.2?

A stable GAE with reliable networking is probably some way off, unfortunate perhaps, but that's life

I've submitted a patch on the Glest sourceforge tracker to only load the factions used in a game, it's very small and perfectly 'safe'.  If Martiño doesn't want to release a patched version himself, I can build a windoze executable.

[wciow]

I was hoping that someone would build the latest "windoze" version with the new LUA areas code so that I could test it 

[hailstone]

Already done https://forum.megaglest.org/index.php?topic=4508.msg28145#msg28145

If you find any bugs post them to http://sourceforge.net/tracker/?group_id=241094&atid=1114827 until Daniel gets his server up again.

[silnarm]

Already done https://forum.megaglest.org/index.php?topic=4508.msg28145#msg28145

If you find any bugs post them to http://sourceforge.net/tracker/?group_id=241094&atid=1114827 until Daniel gets his server up again.

Actually, that doesn't have the new Lua stuff... A new minor release is probably called for.

[hailstone]

We really need a changelog and roadmap. 

The last part still holds though.

[daniel.santos]

Yea, I still think the networking is the most important part.  If you want a rough date for this, I'm hoping we can have it ready in January.  Also, I'm hoping we can get all of Silnarm's pathfinder stuff and maybe some minor AI tweaks in as well.

Hailstone, Silnarm: Maybe we can have a real meeting next weekend and work out a roadmap?  Maybe we can start discussing the items.  Here's what I can think of off the top of my head:

• Networking rewrite
• No more slutty singletons (being done in network rewrite)
• Core class refactoring (Program, ConsoleProgram, GuiProgram -- also being done in network rewrite)
• Pathfinder enhancements
• AI enhancements
• Rendering performance enhancements
• GUI implementation -- make GAE fully skinnable and all UIs defined in XML (or similar) files.
• Lua extensions (fully Lua-ization of engine & GUI)
• Lua-ization of skill & command types
• Entity/Object refactoring -- this is part of the path to full physics (a.k.a., tossables), doodads/"whats-its", enhanced projectiles (more trajectories and possibly line of sight restrictions), everything being able to have a particle system(s).  This is also part of the path to FPM Monks being able to have an "<Insert Deity's Name>'s Grace" skill that creates a static field with a visual effects and an emanation, but not an actual unit.  In essence, there will be a new base class for all attack objects (currently AttackParticleSystem), units, whats-its, triggers and other various odd entities (like the FPM Monk's ability).
• Simple wind & swayable objects (bushes, trees, grass, etc.).  Particles will be affected by per-cell or per-area wind drag.
• Ripping out abstraction layers in shared_lib that we know we'll never use.
• Locally stored resources and skills to replenish any of them.  This may also entail converting HPs and EPs to locally stored resources.  (this is mostly completed in the old 0.3 branch)
• Entities need the ability to alter ambient light in the area around them instead of just specular
• Garrisoning and walkable walls

What else?

EDIT:  Oh wait...

• Skeletal animations and support for other model formats (maybe the .blend format?)
• Replacing current jam-based build system with pure GNU autotools.
• Move tinyxml to a sub-project of it's own because it requires RTTI (we can compile it into a static library like shared_lib and then link to it).  Also, Gentoo removed the tinyxml package and is no longer supporting it -- those bastards!  If expat is tinier than tinyxml, then we can consider using that instead since tinyxml isn't supported.  Otherwise, we'll just maintain it ourselves.  
• Remember non-allied buildings and store them (in the team's annotated map?) and display them as in the state we last saw them.  So if a building was damaged, it will continue to appear damaged until we visit it again, even if it is repaired.  If a building goes away, we will continue to see it until we visit it again and discover that it's gone.  Ditto for buildings being built.
• proper AI for dealing with enemy walls
• Hailstone's Describable framework?  The more I run into this code (skill & command types) the more I like the idea.

[titi]

Why do you make/plan all this new stuff in one new release? No offense here, but I personally think that it will end up in a big bugparade.
Why don't you do the things step by step? OK Multiplayer rewrite is a big thing that will change a lot, but all the other stuff can be made step by step and release by release. This would give you feedback on errors and would help you to get something stable. But up to now, we didn't see any kind of real GAE release, only some kind of daily builds which were made when the things looked like a bit more stable.

With "release" I'm talking about the classical thing:
1- feature freeze
2- alpha version ( if needed some more alphas )
3- a beta version when you think its all working
4- release

Currently a lot of stuff already is in GAE, so I think its really really time to make this kind of release! Even without a working multiplayer its needed to bring the currently made changes to a productive state. But probably the multiplayer development already made so many changes that you can't release right now, but "feature freeze" should really be done now.

All this is only my personal opinion! I'm very happy that you guys are working on GAE and there are so many things that really look good and promising.

[daniel.santos]

Hush titi! I'm not talking to you! 

Seriously, this isn't what's planned for one release!  We need to make a roadmap of the things we want to do and have hailstone push Silnarm and myself around and get us to follow his lead and give you guys stable releases.  These are the features we need to implement.  Do we need it immediately?  No, but we need to plan them if they are going to get done.

I sorta thought that 0.2.12a was semi-stable, but I've seen a lot of bug reports too.  I'll let hailstone answer all that planning/release stuff.

[silnarm]

hehe... Yes, relax titi We wont be doing all that before we get what we've got (and hopefully some things we will soon have) all working and bug-free.

Ok, I'm gonna handle a few specifics (out-of-order)

'slutty singletons'
I object to this derision! non-singletons can be just as slutty, they're just less discrete about it they have a pimp (their 'owner') who passes them about to whichever object wants them.

On a serious note, I have steadily been removing the path finder's reliance on the game/world being a singleton, and even trying to remove init() functions.  Some things should still be singletons though, graphics and sound renderers, config, logger, maybe a couple of others... but yeah, writing code that was relying on Game being a singleton was a silly move.

pathfinder
Ok, so I think this should be two points, 'Hierarchical' is needed to get reliable paths quickly, I should have finished this ages ago, but kept going off on tangents... anyway, as can be seen elsewhere, this is now my priority, and should be done shortly. 'Cooperative' is another kettle of fish, and frankly, can wait.

Networking rewrite
While it's not exactly my cup of tea, obviously I would be able to assist here, and once I'm done with the hierarchical A*, that's just what I'll be doing While my own interests are in making a better single player experience (AI, campaigns) multiplayer is a big deal, and without stable multiplayer, we're probably not going to get much of a user base...

tinyxml
Are you sure about this? I have tinyxml built into shared lib, on windoze I have RTTI switched off for both game and shared_lib... a find 'dynamic_cast' or 'typeid' gets no matches in tinyxml.cpp or tinyxmlparser.cpp.

GUI
This is another one that we should try to get on top of sooner rather than later, obviously a lot of other stuff may/will rely on it.

I'd like to go through some of the other things and break them up in to sub-tasks, some of them kind of overlap as is anyway.  But a forum post is probably not the ideal place for that, I'll start spamming the tracker as time allows

So I think getting the pathfinder and networking done should be the biggest priorities, then titi can have a 'feature freeze' and hopefully we can find some stability soon there after.

[titi]

ok relaxing   

[daniel.santos]

tinyxml
Are you sure about this? I have tinyxml built into shared lib, on windoze I have RTTI switched off for both game and shared_lib... a find 'dynamic_cast' or 'typeid' gets no matches in tinyxml.cpp or tinyxmlparser.cpp.

Weird, you're right.  Well, I broke something on my system again and I can't run automake (I appear to have broken perl this time) so I can't test the gcc -fno-rtti flag again, but I did have it commented out in the Jamrules file.

So I think getting the pathfinder and networking done should be the biggest priorities, then titi can have a 'feature freeze' and hopefully we can find some stability soon there after.

ok, so networking & pathfinder and then feature freeze.  We'll start 0.3 with the GUI changes and I can pull my crap back out of the old 0.3 branch and we'll start screwing it up from there.   So where's this issue tracker?  The one in sourceforge?  So here's my 0.3 list then:

• GUI Fun
• Lua-ization of internal game objects
• refactoring "Game Objects" -- all derived from a single base class, particle systems for everybody, enhanced ranged attack trajectories and properties (collisions), "incorporeal" (i.e., not selectable) entities like time the FPM Monk's thing, etc.
• whatever de-singleton-ization that wasn't finished before
• chop up shared_lib (remove unneeded abstraction)?
• Maybe some stuff from the old GAE 0.3 planning thread
• Conversion of "repair" skill to "replenish" (already done in old 0.3)
• whatever else

[John.d.h]

I remember someone (I think it was Daniel) saying that <effects> could be added to the repair skill, but I wasn't sure if you meant that was already implemented or just planned, so is that doable at the moment?  If so, do the tags have a specific placement in the skill?  The GAE guide doesn't say anything about it.

[daniel.santos]

Oh, thanks John, that's a pretty important item.  Yea, adding an effect to the repair/replenish skill and maybe even to any skill, with skills not involving a target allowing only self for the effect target.  But also is the "cast spell" skill which does nothing but add an effect to a target.  This later especially has associated AI requirements, which the AI-related flags were intended to address.

[hailstone]

What features are missing from Glest 3.2.2?
I can only think of multiplayer, some Windows specific error logging, and auto test (I enabled this yesterday - the code was there but needed a config option).

[silnarm]

What features are missing from Glest 3.2.2?
I can only think of multiplayer, some Windows specific error logging, and auto test (I enabled this yesterday - the code was there but needed a config option).

I think we should have got everything, except multiplayer... I'll be whipping up a 'never ending scenario' to replace the auto-test with at some stage, might as well make it a stress test :-)

[softcoder]

Good evening gentlemen. Would it be worth me trying to get multiplayer to perform better in the 3.2.2 codebase or is there something I can look at in the GAE codebase? If the GAE codebase is the way to go.. where can I get info on getting the code and building it (in Linux of course).

I've got two modellers here in the family (Elimnator and Tiger) so we could help out where it makes sense.

Thanks

[silnarm]

Hi softcoder,

 By all accounts 'mainline' Glest development has ceased, we have a few issues to resolve with GAE to get it use-able and stable, networking and rendering being the things that most need attention atm.  Daniel has been working on the networking, and as best I know is a complete departure from how it was/is done in mainline Glest... There are various discussions about different parts of it in various threads here, not very well organised I'll leave it for him to enlighten you on the details or point you toward them.

Are you interested in networking mainly? or pretty much anything?

I posted some renderer related tasks a while back,
https://forum.megaglest.org/index.php?topic=4628.0

There are a bunch a game mechanics related things that also need doing... you'll have to forgive us though, Daniels server (and therefore our main tracker) is down atm, and we aren't all that well organised right now in any case!

Source can be obtained through soureforge,
http://sourceforge.net/projects/glestae/
trunk, and 0.2.12 and network branches should be 'safe' for linux, I've been working in the pathfinder branch and that is unlikely to compile under linux atm...

If you could let us know where your interests lie, there would almost certainly be something you could work on

[softcoder]

What i'd like to do is really get the networking (multiplayer) stuff working well. I had looked at the old code in Oct 2008 and tried some things to improve performance (and made some progress).. but I got snagged by the whole "world, Graphics frames synch with network packets" problem. That was a bad design since a slow network, or more multi-players would eventually make it completely unusable (as can be seen when you try 4 players).

We have a large family network here and would like to see glest playable by the whole family if possible (up to 8 players). While that many may not be possible in the near future (due to other issues like map size... etc...) I would like to get at least 4 player working well. In general I could work on any area that really needs it to assist getting a rock solid release to give more time for the other (shall we say... lofty) ideas mentioned on a todo list.

I'll snag the source and try to compile today.

[softcoder]

Ok I have downloaded the source code from sourceforge and compiled fine in Ubuntu 9.10 but...

but where is the actual source repository and what branch is the right one to work with? I assume we're using SVN here?

Thanks

[softcoder]

Ok so I found the link on sourceforge (http://sourceforge.net/projects/glestae/develop) but a few things to note:

a) this checks out all the branches.. each branch has a copy of the "data" which is large. Probably a good idea to have the "data" in a separate module from the main source?

b) is there a specific forum / place where dev's only can discuss dev items? A place to co-ordinate what everyone is working on and share ideas / problems etc?

[silnarm]

Ok I have downloaded the source code from sourceforge and compiled fine in Ubuntu 9.10 but...

but where is the actual source repository and what branch is the right one to work with? I assume we're using SVN here?

Thanks

SVN root is https://glestae.svn.sourceforge.net/svnroot/glestae
As to which branch to work with, Daniel has been working on his network rewrite in the 'network' branch, but I'm not sure on the current status of that.  That's probably the best place to start looking though, to get familiar with what he's done.  As I mentioned, there are probably some useful threads around here regarding it, but there was a lot a refactoring going on to, so some of the threads may not appear to be about multiplayer.

Daniel? links to pretty pictures?

Ok so I found the link on sourceforge (http://sourceforge.net/projects/glestae/develop) but a few things to note:

a) this checks out all the branches.. each branch has a copy of the "data" which is large. Probably a good idea to have the "data" in a separate module from the main source?

b) is there a specific forum / place where dev's only can discuss dev items? A place to co-ordinate what everyone is working on and share ideas / problems etc?

a) Yeah, one data dir was how it was set-up, we're migrating the data to all branches, so the idea is to checkout just a branch/tag (say, svn co https://glestae.svn.sourceforge.net/svnroot/glestae/branches/network for example) and then use 'svn switch' to jump around without downloading all the data again.

b) We have a mailing list which doesn't get used much, I believe we're all subscribed
http://sourceforge.net/mailarchive/forum.php?forum_name=glestae-devel

[Yggdrasil]

Skeletal animations and support for other model formats (maybe the .blend format?)

This would be much of work and i don't see the benefit of supporting more formats. Just convert.

Replacing current jam-based build system with pure GNU autotools.

Huh? Why that? Autotools isn't fun to maintain and again: What's the gain of changing to autotools?
I could provide cmake buildfiles i made some days ago just to get familiar with cmake. cmake has the ability to generate native build files, e.g. Makefiles on Unix, Visual Studio Projects on Windows, ...
With the extension cpack one can create install packages for different systems (DEB, RPM, Installer for Windows). There's also ctest for testing stuff.
I got it to build on Linux, Visual Studio had some errors. And i only tried creating deb-packages, which would need some more patching to work fine (using ~/.glest (there's a homedir patch in gentoo for glest), setting a data root (they use a shell script as workaround)).
I could polish it up if you're interested. It's not so important because jam works atm and other things need more attention.

[-Archmage-]

Because a .blend file will hold the anims, so people who didn't make the model an EASILY change any anim they want to, when you import a G3D you have to make an armature and re animate it.

[titi]

.blend is an internal format for blender! Its not something only made for models. Even complete games can be in it! So .blend is really no option.
We should really stay with g3d for now, there is no big benefit I can see for now.