16:36:59 <prock> #startmeeting 0.3.0 postmotem 16:36:59 <fifer`> Meeting started Sun Jan 24 16:36:59 2010 UTC. The chair is prock. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:36:59 <fifer`> Useful Commands: #action #agreed #help #info #idea #link #topic. 16:37:24 <prock> alright here we go 16:37:38 <prock> Topics are listed here: http://wiki.fifengine.de/Meeting:2010/01/24 16:38:10 <vtchill> excellent you want to be the moderator prock? 16:38:40 <prock> yeah.. we'll start from the top down as listed in the meeting agenda 16:39:17 <prock> #topic License / Agreement paper 16:39:40 <prock> This topic was brought up the other day in #fife 16:39:47 <prock> vtchill do you want to take this one? 16:40:25 <vtchill> well the idea spawned from confusion about what licenses we currently operate under 16:41:03 <helios_> hi :) 16:41:09 <prock> welcome helios_ 16:41:19 <vtchill> i don't know that an agreement paper is needed, i have committed some things to boost for instance and they ask me if i am ok with their license header and they credit me in the source file 16:41:24 <vtchill> i think that is good enough personally 16:41:40 <prock> sounds reasonable 16:41:52 <vtchill> as long as we have our licenses clearly laid out on our source page and in any source we distribute i think thats the way to go 16:42:15 <chewie> one special situation popped up these days 16:42:34 <vtchill> now to extend this a little bit what do we do with files such as stuff coming from client projects 16:42:36 <chewie> CheeseSucker said that parts of the editor signal code is a direct copy of Djangos codebase 16:42:57 <chewie> Following our current policy we would just add there our license header as well 16:43:11 <chewie> But basically there is no work done from our side... 16:43:18 <vtchill> well what is their license? 16:43:21 <chewie> (if I understood that correct CheeseSucker ) 16:43:42 <vtchill> usually you need to ask permission to copy their code into your project 16:44:04 <CheeseSucker> http://fife.trac.cvsdude.com/engine/browser/trunk/tools/editor/scripts/events/signal.py 16:44:11 <vtchill> depending of course on their license 16:44:30 <prock> http://code.djangoproject.com/browser/django/trunk/LICENSE 16:45:20 <prock> sounds like we need to add the copywrite notice 16:45:20 <CheeseSucker> http://wiki.fifengine.de/Python_coding_standards#License 16:45:21 <vtchill> yep so we need their copyright on our file 16:45:31 <prock> copyright even 16:45:34 <CheeseSucker> * If you directly copy and paste code from another project the original copyright header needs to stay in place! Don't add a FIFE header to the file in this case. 16:45:36 <CheeseSucker> * If you used portions of code from other projects and integrated it into project files, add the FIFE header at the top of the file but add an additional remark after it that states the origin of the copied code parts. 16:45:38 <CheeseSucker> * You can use this example as a template in this case: 16:46:05 <CheeseSucker> that's what our coding standards say about the issue 16:46:09 <vtchill> ok thats good cheese 16:46:44 <prock> so basically we should remove the FIFE header and add the Django copyright notice 16:46:51 <vtchill> yes 16:47:08 <prock> what files does this affect? 16:47:17 <CheeseSucker> signal.py and saferef.py 16:47:18 <vtchill> i know signals.py 16:47:18 <prock> signal.py and one other 16:47:20 <prock> okay 16:47:47 <vtchill> also what should we do for files in the fife repository that came from a client application, such as the editor plugins 16:48:09 <chewie> well.. 16:48:10 <prock> #agreed we should remove the FIFE header from signals.py and saferef.py and add the Django copyright notice found here: http://code.djangoproject.com/browser/django/trunk/LICENSE 16:48:23 <prock> one more thing.... who will be responsible for doing this? 16:48:41 <CheeseSucker> I can do it 16:48:49 <chewie> I'd say fife ships some generic plugins - and in the long run we should collect additional plugins somewhere else 16:48:51 <CheeseSucker> It's only two minutes of jobs 16:49:13 <vtchill> i guess we should take the same approach and put the copyright of the project even if from a client 16:49:14 <chewie> e.g. linking them on the homepage or something like that 16:49:16 <prock> #action CheeseSucker will remove the FIFE header from signals.py and saferef.py and add the django copyright 16:49:30 <vtchill> well if a plugin can be used across clients it would be nice if clients would contribute it back to fife 16:49:39 <chewie> yes 16:49:41 <vtchill> so we can maintain it 16:49:49 <prock> if they contribute it back to fife it becomes FIFE's code 16:49:57 <chewie> in that case we would put the lgpl header ? 16:50:02 <chewie> yep 16:50:08 <vtchill> yes but there should still be a credit given, but have the fife header 16:50:11 <prock> but we could also put a notice of who contributed it 16:50:21 <chewie> good enough I'd say 16:50:51 <vtchill> and the clients don't have to contribute it back if they are not comfortable with the license 16:51:26 <prock> #agreed any client code contributed back to fife should have the FIFE header and also credit given to the contributor 16:52:09 <prock> okay I think that basically covers everything for that topic 16:52:11 <vtchill> ok i think that is it for that topic 16:52:17 <chewie> yip 16:52:28 <prock> #topic recap FIFE 0.3.0 release 16:53:07 <vtchill> well to start this topic a big thanks to prock for heading it up and making sure things got done 16:53:16 <prock> no problem at all 16:53:19 <prock> :D 16:53:25 * chewie applauds 16:53:27 <prock> thanks for your support also 16:53:30 <CheeseSucker> yes, you got us to the finish line =) 16:53:43 <prock> As it was the first release ever there were a few problems 16:53:43 <vtchill> hehe mile 1... of a marathon is more like it 16:54:19 <vtchill> but anyhow i think a lot of things went right, mainly we stayed focused and didn't let things creep in pushing the release out 16:54:41 <prock> so I would like to apologize for missing a few things. First I should have spent a little more time filling out the CHANGES file (thanks CheeseSucker for doing that) 16:55:04 <prock> and of course the whole win32 scons building issues 16:55:22 <prock> did I miss anything? 16:55:36 <chewie> I'd say those things had to come up - at least there wasn't a release for ages ... 16:55:48 <vtchill> having a well defined set of goals was a huge help and let us stay on our goal 16:56:10 <CheeseSucker> yep, also this release was delayed for far too long 16:56:24 <CheeseSucker> we should've had this release out for over half a year ago (at least) 16:56:31 <chewie> yep 16:56:49 <CheeseSucker> I think we should aim for more frequent releases in the future 16:56:49 <prock> vtchill: agreed 16:57:06 <prock> thats exactly what vtchill and I have been talking about 16:57:12 <chewie> Also we lack some progress documentation - as far as I got it you went through the trac changesets / tickets to spot them ? 16:57:27 <prock> we should probably fill you in on the plans we were talking about for 0.3.2 and 0.3.3 16:57:30 <prock> er 16:57:32 <vtchill> yes and i think we are heading in the right direction, the editor took a huge leap in aesthetics and usability and the build system is much easier to use and supports more targets for future fife expansion 16:57:34 <prock> 0.3.1 and 0.3.2 16:57:49 <vtchill> was going to save ethat topic for the future topic 16:58:05 <prock> k go ahead vtchill 16:58:14 <prock> lets try and stay on one topic 16:58:15 <prock> hehe 16:58:20 <chewie> ^^ 16:58:29 <vtchill> ok so have we noted all the open issues with 0.3.0 16:59:09 <chewie> perhaps we could add that parpg missed the release at all - but there is not much we can do about that 16:59:44 <vtchill> i talked with one of the developers today and gave him the run down about how to upgrade parpg and he said he would do it later this week 17:00:16 <vtchill> i also told him to stop by the fife channel if he has questions 17:00:29 <chewie> yes, I also posted at their forums as one of their devs had install problems 17:01:01 <vtchill> so the issues i know about are the problems building in debug mode in mingw for python clients 17:01:01 <prock> here is the list of open problem we indend on fixed for 0.3.1 --> http://fife.trac.cvsdude.com/engine/query?status=assigned&status=new&status=reopened&order=priority&col=id&col=summary&col=status&col=type&col=priority&col=milestone&col=component&milestone=0.3.1 17:01:01 <chewie> yip, so it's up to them to stay in touch with fife 17:01:47 <vtchill> unfortunately the link fails under mingw when building the debug version of fife python library 17:02:00 <vtchill> it affects not only mingw, but using code::blocks projects as well on win32 17:02:16 <prock> because we do not have the debug versions of the python libraries 17:02:28 <CheeseSucker> code::blocks uses the mingw compiler, doesn't it? 17:02:49 <vtchill> it doesn't really "use" anything anymore... it just calls the scons files which use the mingw compiler on win32 17:03:06 <vtchill> as opposed to msvc which doesn't use scons at all 17:04:38 <prock> I cant think of any other issues that aren't listed in the above link I posted 17:04:44 <CheeseSucker> how should we deal with progress documentation? 17:04:48 <vtchill> also although codeblocks is cross platform, the projects for fife don't really support linux builds at the moment, it was a little confusing on how to set that up when i was going through it 17:05:04 <vtchill> i haven't tested it though so its possible that it would work to build under linux, not 100% sure 17:05:22 <prock> perhaps a ticket should be made 17:05:37 <vtchill> hmm what did people have in mind for progress documentation? 17:06:10 <CheeseSucker> Some kind of documentation of what we have done, so we can easily fill in the changelog =P 17:06:22 <chewie> CheeseSucker, perhaps releasing more often would already help solving that issue 17:06:32 <CheeseSucker> probably 17:06:37 <vtchill> my fear is duplicating what is done by trac in some sort of user modified file would not work well 17:06:49 <chewie> So extracting all closed tickets from the milestone should cover the most important issues 17:07:00 <CheeseSucker> we could create a trac ticket for all tasks except minor ones 17:07:15 <vtchill> if we stick to what major projects do, a ticket for every commit, it should track quite well 17:07:19 <prock> basically thats teh best way to do it.. all changes should be documented with trac tickets. 17:07:27 <CheeseSucker> even typos? 17:07:35 <chewie> CheeseSucker, jep - so far features aren't trac tickets (as long as they don't have bugs) 17:07:43 <prock> no.. but you generally doing put typos in the change log 17:07:50 <vtchill> well does that warrant a spot in the changelog CheeseSucker ? 17:07:59 <CheeseSucker> yes, it does 17:08:07 <CheeseSucker> under the line: * Plus lots of minor bugfixes 17:08:12 <chewie> heh 17:08:18 <prock> lol 17:08:33 <vtchill> haha goal would be to eliminate that line from the changelog since it doesn't say much 17:09:17 <prock> so we agree... make trac tickets when you feel they are necessary and we will use them to track completed changes for the next release 17:09:32 <CheeseSucker> yep 17:09:42 <vtchill> and in case some are unaware as i was.. you can put for example [t:407] at the end of your commit line in subversion commit line to have it automatically comment on ticket 17:09:44 <chewie> we could add a "feature" component to trac 17:10:10 <chewie> mmh.. - that works? 17:10:21 <chewie> cool :) 17:10:21 <vtchill> yea prock and i have use it 17:10:38 <prock> #agreed make trac tickets when necessary and we will use them to track completed changes for next release 17:10:52 <chewie> How about branch merging etc.? 17:11:08 <prock> branch and merge should have a single ticket 17:11:09 <chewie> Should we create tickets therefore as well? 17:11:17 <chewie> oki 17:11:28 <vtchill> yes merging a feature or enhancement branch should be tracked by a ticket 17:11:29 <prock> you would close the ticket when you merge back into trunk 17:11:41 <prock> thats what we did for the build_system_rework branch 17:11:51 <chewie> so if e.g. helios_ starts a shader branch, he opens the branch, creates a ticket etc... 17:12:00 <vtchill> you only need tickets for things going into trunk... you can commit freely to a branch, but the merge back to trunk should be a ticket 17:12:32 <chewie> jip, sounds good 17:12:41 <prock> and try and keep track of your changes 17:12:45 <prock> in the ticket itself 17:13:13 <chewie> that's where "my tickets" comes in handy 17:13:52 <prock> #agreed for branching there should be one ticket that will be closed when the branch is merged back into trunk. All changes should be kept track of in that ticket. 17:14:13 <prock> okay next topic? 17:14:16 <vtchill> ok any other 0.3.0 comments before we move on 17:14:37 <chewie> not from my side 17:14:47 <CheeseSucker> nope 17:14:50 <prock> I believe CheeseSucker took care of the CHANGES file so we wont need to talk abou that 17:14:55 <vtchill> alright, lets do it 17:14:59 <prock> FIFE 0.3.1 17:15:06 <prock> #topic FIFE 0.3.1 17:15:27 <vtchill> so first proposed release date? 17:15:43 <vtchill> well i guess a little overview first... 17:15:58 <vtchill> 0.3.1 is intended to be a bug fix release for stability 17:16:07 <vtchill> no real new features or enhancements 17:16:37 <CheeseSucker> what is the status of phoku's optimization branch? 17:16:51 <chewie> unchanged 17:17:09 <prock> CheeseSucker: It has bugs... so as of right now we cannot merge 17:17:09 <chewie> phoku is MIA and there are 2 (?) visual bugs 17:17:28 <CheeseSucker> would his branch fit in a minor release? 17:17:29 <prock> and we have slated it for 0.3.2 17:17:32 <CheeseSucker> ok 17:17:39 <CheeseSucker> that answers the question =) 17:17:54 <prock> I hope we hear from phoku before then 17:17:59 <chewie> jip, me to 17:18:00 <prock> but it buys us some time 17:18:07 <CheeseSucker> there are a lot of bugs in the editor, but noone has created tickets for them 17:18:08 <vtchill> even if we don't i think we can handle the bugs 17:18:44 <vtchill> well CheeseSucker is that a volunteer? 17:18:45 <prock> vtchill: agreed 17:18:48 <CheeseSucker> So I will have to go over the editor and look for bugs and add them to trac 17:18:55 <chewie> CheeseSucker, jip - I guess the editor isn't used that often from UH / parpg 17:19:13 <CheeseSucker> UH doesn't use it, but I think parpg does 17:19:15 <vtchill> that is something we want to change, but we will address that later in another topic 17:19:21 <chewie> I know about some bugs as I'm writing plugins for it, but I was MIA, too ^^ 17:19:50 <chewie> vtchill, oki 17:19:56 <chewie> so - talking about the release date? 17:20:09 <vtchill> i was thinking march time frame 17:20:11 <CheeseSucker> march? 17:20:12 <prock> I would propose 3 months 17:20:25 <prock> seems we are all in agreement there 17:20:30 <chewie> jip, sounds better then "some weeks" 17:20:36 <prock> late march? 17:20:42 <vtchill> so we want to go end of march, around the 20th or so 17:20:45 <prock> say around the 20th 17:20:48 <vtchill> :) 17:21:04 <prock> sounds good to me 17:21:07 <CheeseSucker> around March 20th 20:31 GMT 17:21:10 <prock> lol 17:21:19 <chewie> hehe 17:21:54 <prock> #agreed FIFE 0.3.1 - tentative release date is March 20th, 2010 17:22:02 <vtchill> so any bugs that are not assigned or the owner is FIFE feel free to assign it to yourself and go after it 17:22:16 <chewie> I also think that some of the tickets aren't bugfixes at all.. 17:22:28 <vtchill> and you can click on Active tickets by milestone and that will separate them nicely 17:22:29 <chewie> like our pychan hide/show ticket ... 17:22:52 <prock> chewie: they dont ALL have to bug fixes.. :P 17:23:25 <prock> those are the tickets we chose to include in 0.3.1. 17:23:31 <prock> mostly bug fixes 17:23:34 <vtchill> we do need to be careful with the release though to not drastically change the interface or inner workings of a module 17:24:06 <prock> true.. the idea behind a minor release is to fix any bugs introduced in the major release 17:24:49 <chewie> jip, that's why I'd say #375 is a feature request 17:24:52 <prock> however in this case we decide to move some enhancements to a minor release 17:24:59 <prock> 0.3.2 17:25:18 <prock> basically these are all things we want to take care of before moving to 0.4.0 17:25:39 <prock> kindof a transition to the major.minor release schema 17:26:47 <prock> chewie: You can move it to 0.3.2 if you wish 17:27:30 <chewie> I'll have a look into it first - maybe our "hack" solution works 17:27:41 <vtchill> also if you find that a bug in 0.3.1 is starting to be a major change feel free to comment on the bug stating this, and we can talk about it as a group and decide what to do about it 17:27:46 <prock> I would prefer thre wasnt a hack fix though.. hehe 17:28:04 <chewie> well.. to me it's not a hack, it's a solution :> 17:28:19 <vtchill> but is it THE solution :-p 17:28:28 <chewie> hehe 17:28:46 <chewie> it's basically the solution I could offer - for everything else I'm lacking ideas for the implementation 17:28:53 <prock> but you are right chewie... we are changing the interface with that ticket.. perhaps we should move it to 0.4.0 17:29:24 <vtchill> i don't have a problem with that 17:29:24 <chewie> If there is any chance I'll discuss it with phoku 17:29:36 <prock> make sure to add your solution as a comment so you dont have to do all the research again 17:29:48 <vtchill> yes definitely comment on the bug 17:29:50 <chewie> I could imagine that he goes mad if I'm implementing that hack ^^ 17:29:58 <CheeseSucker> haha 17:30:21 <vtchill> well a hack can always be implemented properly in a later release that will include more drastic changes 17:30:43 <chewie> prock, yep, I attache the irc snippet to the ticket 17:30:54 <vtchill> so anything else on the 0.3.1 topic? 17:30:56 <prock> in any case... the changes CheeseSucker was talking about regarding the editor 17:31:08 <prock> where should those tickets go? 17:31:18 <CheeseSucker> what changes? 17:31:24 <prock> bugs 17:31:29 <chewie> there is a component for the editor... or what exactly do you mean? 17:31:37 <vtchill> i will leave that to CheeseSucker, but if they are truly bugs (defects) i say 0.3.1 for now until we have too many 17:31:41 <prock> do they go in 0.3.1, 0.3.2, or 0.4.0 17:31:52 <CheeseSucker> I would say minor releases 17:31:54 <chewie> ah, I see 17:32:02 <prock> if they are defects put them in 0.3.1... if they are enhacements put them in 0.4.0 17:32:20 <CheeseSucker> there are some tasks (like making the history manager pretty) that would probably go to 3.2 or 4.0 17:32:23 <prock> CheeseSucker: are you going to report them all? 17:32:33 <CheeseSucker> the ones I find 17:32:38 <vtchill> sounds good 17:32:40 <prock> okay 17:32:48 <vtchill> i will try and mess around with the editor some as well 17:33:43 <vtchill> next topic? 17:33:48 <CheeseSucker> has the components been renamed in trac? 17:33:52 <prock> #action CheeseSucker will report any bugs he finds in the editor and use his discretion as to which release to put them in 17:33:57 <CheeseSucker> AFAIK, the editor component was named clients/editor 17:34:01 <chewie> there is clients/editor 17:34:04 <chewie> yes 17:34:09 <prock> CheeseSucker: no they haven't 17:34:15 <chewie> but now it should be tools/editor I guess... 17:34:17 <CheeseSucker> yep 17:34:27 <prock> I'll do that 17:34:54 <chewie> fixed it 17:34:58 <prock> #action prock will rename the trac components corresponding to the editor and rio.. etc etc 17:35:06 <chewie> should I rename clients/rio as well? 17:35:11 <prock> lol 17:35:11 <chewie> heh 17:35:14 <prock> okay you do it then 17:35:14 <chewie> sorry 17:35:16 <chewie> :D 17:35:25 <vtchill> yes demos/rio 17:35:26 <CheeseSucker> hahaha 17:35:45 <prock> next topic... future FIFE development 17:36:00 <chewie> done 17:36:01 <prock> #topic Future FIFE development 17:36:13 <prock> We can probably talk for hours about this 17:36:20 <vtchill> well this is meant to just be high level 17:36:22 <prock> but I'd like to keep it relatively short 17:36:31 <chewie> Any major ideas behind that? 17:36:32 <vtchill> things we want to see and just to get ideas in peoples heads 17:36:35 <prock> I was telling vtchill about a dream I had 17:36:39 <prock> a vision 17:36:42 * chewie listens 17:36:51 <prock> about FIFE's future 17:37:24 <prock> FIFE should become truly (f)lexible 17:37:53 <prock> I can see it as a fully featured 2D engine... with a build in pysics and collision detection system 17:38:04 <prock> physics even 17:38:24 <prock> to make it suitable for all sorts of 2D games 17:38:51 <prock> thats all I got 17:38:52 <prock> lol 17:38:56 <vtchill> :) 17:39:01 <vtchill> so i will add some things i would like to see 17:39:43 <vtchill> (1) better pathing using something like navigation meshes with nice integration with the editor for creation 17:39:59 <vtchill> (2) particle engine to simulate effects such as fire, explosions, etc. 17:40:28 <prock> the particle engine is slated for 0.4.0 17:40:30 <prock> :D 17:40:46 <chewie> let me show a small video ... 17:41:03 <vtchill> (3) more flexible map saving/loading, i think this should be implemented like a fife engine plugin so that users can override this if they choose to, but this would allow for different languages to use fife 17:41:43 <prock> aye... right now we are tied to python because of the map loading.. and pychan for that matter 17:41:58 <prock> which brings me to another idea....... wait for it...... 17:42:12 <prock> get rid of guichan and write our own gui interface 17:42:21 <vtchill> thats a later topic! :){ 17:42:24 <chewie> -> http://www.youtube.com/watch?v=ut0SqBeAy1Q 17:42:43 <chewie> per pixel lighting :) 17:42:48 <helios_> :> 17:43:11 <vtchill> very nice looking effects there chewie 17:43:16 <chewie> So about the vision - that all sounds great :) 17:43:40 <vtchill> (4) clean up the coordinate system in fife and provide a nice easy to use api 17:43:41 <chewie> We @zero have some too... although they are "smaller" 17:43:47 <helios_> yep i like the idears too 17:43:55 <helios_> ideas 17:43:59 <chewie> (1) movie support 17:44:12 <chewie> (2) introducing basic lighting into trunk/ 17:44:23 <vtchill> that is on my list as well 17:44:46 <chewie> (3) improved pather that allows AI development 17:45:49 <chewie> physics and collisions would be very nice - as well as the particle engine 17:45:52 <CheeseSucker> I would like to see some samples that will be shipped with FIFE 17:46:04 <CheeseSucker> small snippets that shows how things can be done in FIFE 17:46:08 <vtchill> speaking of samples, i started a tutorials for fife 17:46:20 <CheeseSucker> f.example: 3D sounds, a basic platformer, board games, etc 17:46:22 <vtchill> i need to update it to the trunk 17:46:31 <chewie> a demo branch is definately needed CheeseSucker 17:46:46 <vtchill> the tutorials are meant to be short and to the point 17:46:52 <vtchill> such as here is how to control user input 17:47:02 <vtchill> here is how to mess with the camera and viewport 17:47:21 <vtchill> etc. 17:47:27 <CheeseSucker> do you have a link? 17:47:28 <chewie> vtchill, good idea - I also started a pychan tutorial a long time ago - maybe we can join forces there 17:47:35 <CheeseSucker> IIRC you had a website 17:47:52 <vtchill> http://code.google.com/p/fife-tutorials/ 17:48:04 <vtchill> its in c++ as well which is driving the need for a more flexible map loader/saver 17:48:33 <vtchill> i am hoping to have several tutorials each with a wiki page describing what the code is doing 17:49:55 <prock> I think I may help with some of the tutorials 17:50:07 <CheeseSucker> I need a password to checkout the tutorials? 17:50:12 <vtchill> absolutely 17:50:13 <vtchill> no 17:50:18 <vtchill> you can checkout anonymously 17:50:30 <prock> but for now I'd like to concentrate on getting 0.3.1 out and 0.3.2 17:50:42 <vtchill> Use this command to anonymously check out the latest project source code: 17:50:42 <vtchill> # Non-members may check out a read-only working copy anonymously over HTTP. 17:50:42 <vtchill> svn checkout http://fife-tutorials.googlecode.com/svn/trunk/ fife-tutorials-read-only 17:50:43 <prock> perhaps the tutorials can be released with 0.4.0 17:50:51 <CheeseSucker> failed: Could not authenticate to server: rejected Basic challenge (https://fife-tutorials.googlecode.com) 17:50:56 <vtchill> yes i a thinking 0.4.0 for tutorials 17:51:06 <CheeseSucker> ok 17:51:06 <vtchill> it won't work currently with fife CheeseSucker 17:51:39 <vtchill> also i was waiting till we completed the build system rework b/c i couldn't build fife properly for a static lib in linux 17:51:57 <prock> those are C++ tutorials 17:51:59 <vtchill> so currently on win32 and msvc support for the tutorials 17:52:03 <vtchill> yep 17:52:27 <chewie> We also have this thread here -> http://forums.fifengine.de/index.php?topic=73.msg1358#msg1358 17:52:29 <prock> also... I dont know if we mentioned this before... but we want to re-introduce the ability to use FIFE as a C++ library for C++ projects 17:52:51 <chewie> (Request for Tutorial) 17:53:31 <CheeseSucker> is there anything stopping this from being possible? 17:53:33 <chewie> prock, yes - I remember that one 17:53:36 <CheeseSucker> except the serializers? 17:53:51 <vtchill> well not anymore the build system now supports it 17:54:02 <vtchill> i wrote a c++ map loader for fife 17:54:06 <vtchill> its still in its own branch 17:54:49 <vtchill> but it works for loading a file saved from FIFEdit 17:55:52 <chewie> So, can we summarize the future of FIFE somehow? 17:56:13 <vtchill> a page on future fife features might be useful 17:56:26 <chewie> Tons of features and additional language support? 17:56:28 <CheeseSucker> General purpose 2D C++ game library? 17:56:30 <chewie> :> 17:56:57 <vtchill> haha 17:57:19 <vtchill> well we can slide down to the next topic which really goes hand and hand with a lot of these features 17:57:22 <chewie> And one question - are those visions pure dreams or are we able to achieve them? 17:57:36 <CheeseSucker> I think we should be able to achieve most of them at least 17:57:36 <vtchill> i think they are all achievable 17:58:00 <chewie> :) 17:58:10 <CheeseSucker> physics and particle engine are the ones that seems hardest 17:58:11 <prock> the problem with these dreams is we do not want to change the API that much as to make parpg, uh and zero mad at us 17:58:35 <vtchill> well at some point its going to happen 17:58:36 <chewie> We might want to listen to the other projects and generate some kind of roadmap as well 17:58:54 <CheeseSucker> UH would probably be angry if we turned FIFE into an engine for board games =P 17:59:01 <prock> so the short term goal is to make FIFE as it is very usable 17:59:15 <vtchill> we are pushing for stable releases so hard so we can change fife in the future and projects that don't want to updates can stay on a certain version 17:59:23 <chewie> From my point of view as zero programmer, FIFE still needs some love in order to let us a create games 17:59:35 <prock> vtchill: well put 18:00:28 <prock> the idea is to make FIFE as stable and useable as possible as it is right now... try and get a 1.0 release out there.. and start working on major features/re-writes 18:00:47 <vtchill> personally i would like to change the architecture of how fife stores objects and instances drastically, but i would certainly hold off on this until fife is a stable engine for those that like the features the way they are now 18:01:09 <chewie> mmh... it's not so much about likings I'd say... 18:01:39 <vtchill> well we certainly understand that a lot of code depends on the api fife has now, we don't want to break that 18:01:41 <chewie> If we e.g. rewrite the gui, there is a lot work destroyed for UH and Zero 18:01:59 <vtchill> but we want to evolve fife, but provide support for clients using past revisions 18:02:01 <prock> chewie: which is why we cant to that until the future 18:02:12 <prock> to = do 18:02:31 <chewie> so future visions = post 1.0? 18:02:38 <prock> exactly 18:02:45 <chewie> ah, now I get the idea :) 18:02:53 <vtchill> i am thinking we will have a fife 2.0 and that will be where all the magic happens 18:03:06 <vtchill> everything fife <= 1.99 is the old code with enhancements 18:03:10 <chewie> Okay, so Zero 2 then has physics and particle effects :o) 18:03:27 <vtchill> and possible a rewritten internal fife architecture and much different api 18:03:32 <vtchill> just to warn 18:03:55 <prock> maybe just a complete re-write... :P 18:03:59 <chewie> XD 18:04:13 <vtchill> the problem is clients started writing code to depend on fife before fife has really matured 18:04:13 <prock> we really have to sit down with all these enhancements and decide if they are feasible to implement in FIFE 1 18:04:15 <chewie> an irrlicht core with some additions? ^^ 18:04:33 <vtchill> hehe if we could support what irrlicht does that would be impressive 18:04:55 <prock> but I think thats about it 18:05:03 <prock> anywone else to add? 18:05:06 <prock> er 18:05:12 <chewie> vtchill, it´s not a problem - that´s why FIFE is where it is now :) 18:05:20 <chewie> Just remember: Make games, not engines :) 18:05:27 <prock> lol 18:05:27 <vtchill> i agree completely 18:05:45 <prock> anything else to add? I'll close the meeting if not 18:05:58 <vtchill> anything else on the meeting topics? 18:06:12 <chewie> mmh.. 18:06:20 <prock> nope.. looks like we touched on just about everything 18:06:23 <vtchill> just a quick note about FIFEdit 18:07:17 <vtchill> it needs to be fully featured, most other engines out there provide everything through the editor and the client then rights gameplay code only, they don't have to much with programatically doing things that the engine should really be able to handle up front 18:07:56 <vtchill> this goes with the idea of providing a nice standard game engine and toolset for clients 18:08:23 <chewie> mmh - is that even possible in terms of flexibility? 18:08:39 <vtchill> well other engines do it successfully 18:08:58 <CheeseSucker> examples? 18:09:01 <chewie> I only now genre-focused toolsets like e.g. rpgmaker 18:09:09 <vtchill> unity is a good one to look at 18:09:35 <vtchill> unreal engine is free and it provides a ton of features through the editor 18:09:36 <CheeseSucker> mass media fusion has a lot of impressive games, but they don't write any code at all 18:09:39 <chewie> the Löve engine is flexible as well, but needs a lot of programming IMO 18:09:44 <prock> vtchill: I think thats a little too restrictive 18:10:00 <CheeseSucker> unreal engine? 18:10:25 <prock> FIFE should be flexible and not limiting 18:10:50 <vtchill> its the one used by a lot of commercial companies for 3d games made by epic games 18:11:00 <vtchill> unreal tournament, gears of war, etc. 18:11:07 <vtchill> its got a nice editor along with the engine 18:11:08 <prock> I would define flexible being the ability for clients to extend/override the default behaviour of FIFE 18:11:10 <CheeseSucker> yep, I have made a couple of levels for UT2004 18:11:18 <CheeseSucker> but their editor needs a little love too =) 18:11:25 <CheeseSucker> (haven't tried the one for UE3) 18:11:38 <vtchill> well its not flawless, but it provides much tighter integration with the engine i think 18:11:52 <prock> Okay.. I'm going to end this meeting.. these are all topics we should perhaps start forum posts for 18:11:59 <vtchill> whats limiting about the way unity does things prock 18:12:14 <chewie> mmh.. maybe I lack the understanding right now - but if I compare UH and zero ... I couldn't imagine a basic client which would allow that 18:12:42 <vtchill> i dont see them as that much different really from the engines point of view 18:12:48 <prock> all in favor of ending the meeting and taking these discussions to the forums? or back in #fife? 18:12:56 <vtchill> sure 18:12:56 <CheeseSucker> yep 18:12:59 <prock> #endmeeting