Project Recovery

[lgromanowski]

I just sent Nico an email, asking him about the state of his involvement in the project. I suggest we give him a couple of days to come up with a reply.

If we don't hear from him or the answer is negative, we should try to move the project forward on our own. I have prepared a plan of action for this scenario. More details later.

Good work. I'm looking forward to next year, and progress on OpenMW!

I come back to see how the project is coming along and then I see no progress. We need some sort of motivation here.... I wish I could help, but I'm still stuck in hs. Idk anything about coding... and I'm guessing that's what you guys need. I had high hopes for this, I mean what mw player does't want a decent remake because of bethsoft's lousy bug-fest of an engine? I hope things turn out for the better, and nico responds to your letter. Merry Christmas everybody, see you in 2011

I come back to see how the project is coming along and then I see no progress. We need some sort of motivation here....

I sent Nico a PM the other week, now Zini emailed him.

Motivation is probably the last part of the whole equation. Let's see what happens, hear what zini has to say, and we'll talk more about it then.

I can't really continue the wiki stuff I wanted to do until I have something to say about the current changes that are good to go.

I'm a pretty good programmer, at least when it comes to C#. But my C++ knowledge is pretty damn lacking so I don't even know where to start when it comes to OpenMW.
Would love to help but looking through the code just leaves me confused, I spent an hour or so just digging through it and as of yet I have not a single clue how any of it works.

With several communication attempts failed, I think we can safely assume, that Nico is gone (at least for now). Therefore we will have to move forward on our own. Here is what I propose:

1. Plug the holes, that Nico left

Nico was providing considerable code contributions and also he was the only person with knowledge about the internal workings of certain parts of OpenMW. It is unfortunate, that we don't have these resources anymore, but our regular developer pool should be able to handle it (albeit a bit slower). No immediate action is required here.

I am willing to take over the code management (merging, pull-requests and such). I will also get involved into the higher level design decisions (which I did for the apps/openmw part all along).

This leaves us with the following open positions:

1a. A PR guy (or gal)

Sir_herrbatka's update posts in the announcement forum work nicely. But we also have to maintain a presence outside of our own site. I am thinking mostly of Ohloh and Freshmeat. OpenMW is registered with both sites, but the information there is hopelessly outdated. To a random coder who comes across our entry the project would look dead. Since these sites are potential source of new developers we can't continue this way.
Also some PR might be required at other sites (Morrowind-related) at some point. We will have to discuss this in more details.

Qualification: No coding skills required, obviously. Decent grasp of the English language and the ability to follow the project's progress. I am willing to proofread all the material, but it should be in a state where at most minor corrections are needed. If everything has to be reviewed and rewritten multiple times, this is not going to fly.

1b. A release manager

The release manager would need to keep track of who is supposed to compile for what platform (this includes pinging those persons occasional, if they are inactive for a long period of time).

Once we decide we are ready for a new release, the following would happen:
- I poke the release manager
- the release manager pokes all the building/packaging people
- the building/packaging people send there packages to the release manager (via email or whatever is convenient)
- once all packages are done, the release manager uploads them to a central location (to be determined, but I am favouring github)
- the release manager writes an announcement in the announcement section

Qualifications: The ability to follow the project's progress. Coding-skills are not needed. It would be convenient, if the release manager also does the building/packaging for one or more platform, but it is not required.

Both positions don't require a huge amount of time, but they do require persistence. PR updates and releases should happen timely, once we decided that they are in order.
Also it would be perfectly okay for one person to take both jobs.

It is of uttermost importance, that we can fill both positions, if this project is supposed to go anywhere.

2. Forum

I will PM Lordrea and ask him to give Sir_herrbatka and me moderator rights (plus whatever posting rights are needed for the new positions mentioned above). The forum starts to look a bit chaotic in some places and it would be beneficial, if we had someone who could split off-topic discussions into separate threads.

3. github

We declare, that my fork is the primary repository from now on. That will require some wiki changes and some changes to the Ohloh and Freshmeat entries. Also people with existing local repository might want to redirect their upstream remote to my repository.

4. Roadmap

The roadmap in its current state doesn't work very well. Coders usually pick whatever they are interested in, no matter if it is in the current milestone or not.
Because of the recent project downtime and the lack of a finished terrain implementation we have to rewrite the roadmap anyway. Since we are already at it, I propose we change it completely:

- We have one (current( milestone, which contains the tasks people currently working on and tasks we have commitments for.

- We have a suggestion list of tasks, we would like to get into the current milestone

- The rest of the tasks is collapsed into a single categorized list. I will extend this list until it (at least semi-completely) contains all tasks required for 1.0.

People then can pick tasks from the categorized list. If we see that their work is getting somewhere, we move the tasks to the current milestone.

5. Code

I will start to review all non-merged branches and merge them where applicable.

6. Branching

I will post some guidelines, that will make the handling of branches a bit more ordered, so we don't end up again in a situation as chaotic as now.

7. Release

Once we have the repositories sorted out, we will look at the code again and decide about a release. We may want to find closure for some of the actively developed features first.

8. Post-release PR

After the release, once we have some momentum going again, we ask Star to make us another promo-video. This could be posted to some Morrowind-related sites. We had a discussion a while ago about early PR targeted at non-coders. While I partially agree with the outcome, I also think we shouldn't disappear completely from the MW player's radar. Occasionally making some noise is a good idea.


Comments? Agreement? Objections? Volunteers?

We would need this changes anyway.

The most important thing for now is 0.09 (codename whatever, let it be "Balmora"). It seems that we just need to do it and then start to organize again (one way or another).

So it seems that 0.09 is out in last days of 2010.

Unless Sir_herrbatka wants to do it (his previous hard word I think makes him more deserving) I could volunteer to do PR stuff. While haven't been the most vocal person on this project, I've been following every mailing list post and forum post for a long time. English is my first language, and I have experience as a webmaster and forum mod. Again, unless Sir_herrbatka wants to do it, I'm officially volunteering for PR guy.

great, I will be just a moderator and announcer on our little but still growing up forum.

I don't feel comfortable with english anyway. Engrish PR is not very effective.

Anyway; freshmeat, ohloh (lol) and ModDB are in need of update.

Looks okay, Zini. I'm not very far into software engineering (Software craftsmanship), so I have to trust that the system you have set up works well enough for a casual community of contributors ranging from CS Student to Guru.

I also volunteer for mod - I used to admin a large community back in EQ.
You could always use a few, and I'm on checking here often enough.

However, since we've arrived at this point, I probably should speak my mind about the situation, because I think we have a chicken or egg problem with contribution. I want to describe and outline some problems I think should be resolved or discussed.

1. The Project to others:
I definitely still think that, in order to gain any momentum (again, they won't come if you don't have them), this project - and everyone involved - will have to be organized, friendly, and work hard to make sure they can work with others.

There is nothing more important that having a friendly and helpful environment. Stress, real life, all those problems are things we all share, but they don't belong in a community setting where people are volunteering their time to help build something.

Under Zini's plan, we'll have a structured team, and for that to be successful we'll have to build teamwork and accept conflict and construct better solutions to problems at all levels. Bad personal behavior is simply unacceptable, here. It is such a turnoff that I think it is the number one threat to openMW. Otherwise, the project will be just a thing worked on by two people. The MW community can file it right along with the other two MW projects and the numerous attempts to resurrect Tribes.

2. Spaghetti:
We've had a few complaints already that the code is difficult to read and understand. I can recall looking at the 0.08 release and having a hard time understanding how everything is organized, what all the large functions with many arguments actually did and what function they served. While many can "figure it out" - that phrase wins no friends. It just doesn't. It should never be said, and a few hours of putting comments in can save days and weeks for everyone. No one should have to sit and stare at it.

The project, top to bottom, needs well-commented code and excellent online documentation. The deoxygen stuff is great, feels like browsing php.net or Sun's java documentation (or even MSDN's XNA and C# stuff), and we need to find that stuff and make use of it. All classes should be easy to read and all functions documented to pick up on MSVC or Eclipse (unnngh CDT so bad) Code Insight features and the like.

Yes, we should make things easy for others.

3. The Windows build

The business of successfully building, compiling, and running on windows is still shrouded in mystery to me. Libraries missing, libraries not linked up correctly, library installation packages that we need just not working, setting environment variables here but not there, needing to build libraries myself; It's really discouraging, a lot of work, and a total turnoff. We can't let this go on if we want people testing and coding. We can't just say, "oh well, switch to Linux" or just hand everyone a mountain of stuff and tell them to "figure it out". "Figure it out" should be banned.

I should be able to download a list of things, install them, and compile and run my own OpenMW on either platform.

The windows build looks like it has no love.
----

These are the big three things from my on view. It's great that we're going to try to get things rolling again, but if we can't manifest a list of good reasons why anyone should contribute to this project, then the project won't be going anywhere.

The windows build looks like it has no love.

No manpower - no love

... and we need all the love that we can get

Well this problem was touched by lordrea. "Linux only" is a trap that we just must avoid for the sake of this project.

Looks like we all agree to my plan. I have seen several contributor online today, who didn't post anything. I'll interpret that as agreement too.

We have one position filled. That is good. The other position is still open, which is not so good. Hopefully someone is stepping up soon.

Assuming we find a release manager (and still have people who do the actual building/packaging), I will start working in a day or two. A release this year is pretty much out of question, even if we find a release manager today. Just too much work (especially #4 and #5 in the original posting).

A few additions to the plan:

- The Priority column in the roadmap doesn't make much sense with the proposed changes. Maybe we should replace it with a Difficulty column. This change will allow less experienced people to pick up easier tasks more quickly.

- I didn't mention it in my original post, but code management includes handling the doxygen uploads. I will update the documentation once I am done with merging.

- I have a dormant Twitter account lying around, that I am using passively as a newsfeed. If there is enough interest, I could start positing real time updates about what I am doing OpenMW-wise.

Well this problem was touched by lordrea. "Linux only" is a trap that we just must avoid for the sake of this project.

One of the better ways to handle this would be to get the build system set up so the project can be cross-compiled. Actually, a CMake project is cross-compilable by default, unless it does something to break it. Any Linux user can install a cross-compiler and do a Windows build without needing a Windows machine. Can even test it under Wine. OSX support will be a bit harder, though.. it's very difficult to build for OSX on a non-OSX machine.

Zini,
I think it is good that the project is getting back on track. When will the next roadmap be up?


Another good place to advertise OpenMW would be Bethesda's Morrowind Modding forum.

What all needs to be done with the Windows build? I develop in windows.

When will the next roadmap be up?

After we got the next release out. Maybe next week if everything works out and we actually have the people to do the release.

What all needs to be done with the Windows build?

Building and packaging it into a zip file or something. With all required DLLs. I think the last Windows release was missing one.

When will the next roadmap be up?

After we got the next release out. Maybe next week if everything works out and we actually have the people to do the release.

What all needs to be done with the Windows build?

Building and packaging it into a zip file or something. With all required DLLs. I think the last Windows release was missing one.

Oh, I thought we were going to scrap that roadmap and make a new one.

So will the work I did on NPCs be in the next release?

Oh, I thought we were going to scrap that roadmap and make a new one.

Little point in making a new roadmap for the upcoming release when the upcoming release is supposed to happen next week.

So will the work I did on NPCs be in the next release?

Will have to review and try it first. But I see no reason not to include it.

Wee! This is exciting!

Zini, resurrecting your twitter would be fantastic, I've spent today at work mulling over some other ideas too. I'll get to work solidifying these things and then run them by the community and then get them in the air!

I will volunteer(whether you need more than one is up to you) for PR
-i could setup a moddb page if that might help get some flow and manage that. give updates/screenshots and make some videos for it.

i have website coding skills
i have some java programming skills
i have some C# programming skills(same bloody syntax)
i can moderate forums if need be.
i can google stuff.

i can help with Linux side of getting an environment setup (i wrote the requirements on the wiki)

sir_herrbatka if you need help with English, contact me in a pm here (i will give you my email)
and before you post anything to the site i can run through it and remove unnecessary comments, check grammar etc and then post the fix back to you.
its no skin off my teeth and its a way i can help, cause i can't program that well (yet and certainly not with C++)

Im all for progress. so you got my back.




edit: there is already an openmw moddb page, i have submitted an application to join the company 'openmw' hopefully that will give me access to update Moddb. (last update was august).

tombofsoldier i think is the contact for it, so it would be very much appreciated if it were accepted, thanks.

alias is pchan3 for moddb

@hircine
You would be more effective by just working on your own

@Star
I don't want to suggest anything (this is just random idea) but you could be this relase manager - at least you can help a little to brave windows builder. There is nothing to moderate on the forum right now so you can just concetrate on this.

@Hircine: I think raevol already took the PR job. Now we have two people for PR and none for release. Maybe you could sort that out between the two of you?
If you want to take over the job of Linux packaging, that would be welcome too (for now we just put everything in an archive, but investigating CPack and going .deb is certainly still on the list).

btw. here is the link for my twitter account http://twitter.com/#!/marczinnschlag

i could try to make a deb package, if i succeed will let ya know
(gotta install my linux HDD. was removed since new case/gfx card.)

sent an email to tomb to get access to moddb.

I assume you guys will sort the release stuff out on your own, so that when I yell RELEASE in a couple of days people will get into action and sort things out on their own (I will still be here to assist).

Okay. #1 is down. Onto #2. Will send a PM. For now I will only ask for moderator rights for Sir_herrbatka and me. What ever announcements come from PR and the release manager can go through Sir_herrbatka, since he is doing all the posting in the announcement forum anyway.

Edit: @Star: Thanks for the offer regarding moderation, but we don't really no anymore people here.

@Star
I don't want to suggest anything (this is just random idea) but you could be this relase manager - at least you can help a little to brave windows builder. There is nothing to moderate on the forum right now so you can just concetrate on this.

Well, while I'm not afraid to accept new responsibilities, if I would have this position, especially as a programming neophyte trudging through a Computer Science degree, I would be responsible for directing and working with people much more skilled and experienced than I when it comes to coding and managing a product. If you guys are willing to accept my lack of experience in software to trade off for my other skills, then I'll accept the position of windows build manager.

As zini outlined:

The release manager would need to keep track of who is supposed to compile for what platform (this includes pinging those persons occasional, if they are inactive for a long period of time).

Once we decide we are ready for a new release, the following would happen:
- I poke the release manager
- the release manager pokes all the building/packaging people
- the building/packaging people send there packages to the release manager (via email or whatever is convenient)
- once all packages are done, the release manager uploads them to a central location (to be determined, but I am favouring github)
- the release manager writes an announcement in the announcement section

Qualifications: The ability to follow the project's progress. Coding-skills are not needed. It would be convenient, if the release manager also does the building/packaging for one or more platform, but it is not required.

These are things I can certainly do, and thinking a bit - it probably would be fine for most users this way - if *I* can get it built, compiled, and running, we're in good shape.

We currently have a "Donate!" link on the front of our wiki. I guess the money would go to Nico, which does not sound right. Unless anyone objects, I would like to remove this link.

I think I managed to redirect all wiki references from Nico's git repository to mine. But it is possible, that I missed some. If you see anything, please fix it.

People who have already forked can keep their old fork. But people forking now should better fork from my repository.

Also, if you have a local repository, you might want to redirect your upstream remote from Nico's to mine (just delete the remote and recreate it; I don't think git has a rename function for remotes).

#3 down too. Onwards to #4. This will take a bit longer.

I think I managed to redirect all wiki references from Nico's git repository to mine. But it is possible, that I missed some. If you see anything, please fix it.

People who have already forked can keep their old fork. But people forking now should better fork from my repository.

Also, if you have a local repository, you might want to redirect your upstream remote from Nico's to mine (just delete the remote and recreate it; I don't think git has a rename function for remotes).

#3 down too. Onwards to #4. This will take a bit longer.

Before today, I've been getting "not a valid repo" messages when I try to pull from anyone. I'm not sure if the command is correct. The command should be "git fetch zini" or "git pull zini" (I know one command combines two of them, evades me atm. I definitely have you set as a remote, though.

If you can, update the github faq instructions we have on the wiki so it's all cleared up about how to pull from you.

I am not really sure what FAQ you are referring to.

Even though using "upstream" as a remote name is preferable now, "git fetch zini" should still work, if the remote has been set up correctly and if it is not, than this is a user error.

I am not really sure what FAQ you are referring to.

This one:
http://openmw.org/wiki/index.php?title=GitHub_FAQ

Even though using "upstream" as a remote name is preferable now, "git fetch zini" should still work, if the remote has been set up correctly and if it is not, than this is a user error.

Hmmm...Used the instructions you gave to someone else, lemme try again.

Code: Select all

git fetch zini
Remote error:
could not find repository zinnschlag/openmw

Hmmm...I suppose I could set up a new one with a different name.

Just to check, adding the remote should be as so:

Code: Select all

git remote add NAME git://github.com/zinnschlag/openmw.git

Oops. I missed that one. Should be fixed now.

Updated the roadmap. #4 down (#2 still pending). Won't be able to get to #5 today.

Well, thinking on everything going on - I'll throw my hat in for Windows Release manager.

Hi guys,

I have been following this project for the past few months and I am very excited about this project, mainly because Morrowind will be running native on Linux for the first time.

I have provided coverage of the project on Ubuntu Gamer and did a interview with Nico in Full Circle Magazine, all efforts to promote the project.

I am now keen to help the project out to get and volunteer to help where ever I can.

I am not a coder, but my main skills to running a team, or helping out where I can. I can maintain websites, forums and wikis and in community work.

My main experience with an open source project is 3 years experience in running and starting up a project which went quite. Gfire project is a Xfire plugin for Pidgin, allowing users to connect to Xfire using Pidgin. The project went quite in 2006, and in 2007 myself and a coder started the project up again. I created a new website, active IRC channel (with meetings), forums, wiki and fast growing community. I basically did everything but code. I left the project earlier this year, since it was at a state where it was a growing project. In my time I was the release manager for 9 releases. http://gfireproject.org/

Not sure how much use I would be, but please let me know

@chewit: You sound like the ideal candidate for the position of Release Manager.

@chewit: You sound like the ideal candidate for the position of Release Manager.

Yeh,thats sound fine. Whats the next step? Contact details? Roles you want me to do now?

Well, we are pretty close to a new release. Make sure you know whom to poke about building. For now only Windows binary and Linux source release, but we should look into expanding that for future releases.

We also have to decide about where to upload the release. I suggest github. I am not 100% sure, but I think if I add you as a colaborator to my OpenMW reposiroty, you should be able to upload to it. You need to have a (free) github account for that though.
I will PM Lordrea about giving you positing rights in the announcement forum. I haven't received yet a reply for my first PM though. If don't get the positing rights in time, you can run everything through Sir_herrbatka who is online on daily basis and has the required rights.

Well, we are pretty close to a new release. Make sure you know whom to poke about building. For now only Windows binary and Linux source release, but we should look into expanding that for future releases.

We also have to decide about where to upload the release. I suggest github. I am not 100% sure, but I think if I add you as a colaborator to my OpenMW reposiroty, you should be able to upload to it. You need to have a (free) github account for that though.
I will PM Lordrea about giving you positing rights in the announcement forum. I haven't received yet a reply for my first PM though. If don't get the positing rights in time, you can run everything through Sir_herrbatka who is online on daily basis and has the required rights.

I have created a GitHub account under the username of chewit.

Added.

I have posted another article on Ubuntu Gamer trying to get some new developers to help out on OpenMW.

http://www.ubuntugamer.com/2010/12/open ... evelopers/

Ubuntu Gamer receives 10,000+ traffic each day and has 1500 followers on Facebook and Twitter, so hopefully we will get a few new developers

Okay, here are the merge results:

amos-branch (class selection): Needed some fixing, but is in now. Unfortunately in a very unfinished state. I added another roadmap entry for finishing it up.

jhooks-branch (music player and NPC rendering): Is in now. But we need to work a bit more on it, before we can have a release.

jpn-branch (some GUI cleanup and first part of NPC dialogue window implementation): Is in now.

Mach1723-branch (accessing files outside of a bsa archive): Not merging. The feature is incomplete. Unfortunately Mach picked the less important case. That by itself is not a reason for exclusion, but we also have serious performance problems. Not ready yet, but may serve as base, if someone else wants to pick up the task.

Athile and apreiml-branches: Not merging. These are simply too old and quite a bit of the work done in these branches has been already done elsewhere. Sorry.

Okay. #5 down. on to #6:

I suggest the following branching policy:

1. Developers, who want to work on a feature, are required to make a topic branch with a short easily identifiable name.

2. You are encouraged to merge the upstream master branch (from the zinnschlag repository, not the korslund) into your branch occasionally and once before the pull request. This is not required though.

3. While you are working on a topic branch, push your changes to github often. We want to see, what is going on. As a guideline one push at the end of a successful OpenMW-workday is a good idea.

4. Only one topic per topic branch please. New topic branches should always branch of from upstream master (unless they rely on another topic branch)

5. Once you think your work is ready, send a pull request (to the upstream account). You may want to talk about it in the forum first, if you are not sure if it is ready.

6. We generally don't accept patches or other kind of code contributions. We may make exceptions for a highly valuable piece of code, but the strongly preferred method is through github.


I hope these rules are acceptable to you all. Feel free to discuss. If we can agree on them, it would be helpful, if somebody can wikify them.

im in the process of building and packaging OpenMW for Linux (the build as of 2 days ago/korsland).
where should i upload it? (if it goes well that is)


on another note, flooding is bad mkay. losing internet is just as bad.
a whole 24 hours without it sucks. especially when you were in teh middle of getting packages to compile stuff. had everything except g++ installed.

im in the process of building and packaging OpenMW for Linux (the build as of 2 days ago/korsland).
where should i upload it? (if it goes well that is)

The version you mentioned isn't ready for release, so there is little point in uploading it. But it is good, that you have sorted out the packaging for Linux. We should be able to have a release in a couple of days (depending on how fast jhooks and me can get the remaining kinks out of his NPC rendering code). chewit will poke you, when we are ready and he will also collect the finished packages.

i compiled fine, got a binary. but any attempts at making a .deb package has failed miserably.

i think i need a install target apart of cmake for cpack to work.

http://www.vtk.org/Wiki/CMake:Packaging_With_CPack

who knows how to work with cmake commands let me know.

i tried non cpack/cmake methods and came up short.

To be fair, it's been less than a week since this topic (and assumed contact) was attempted. Hell, it took me a couple of days to check my inbox as well.

Just the same, granting Zini and sir_herrbatka global moderator rights, and chewit topic creation rights in the announcement forum.

Any other web/wiki/forum/etc-related discussion should be directed to the "Discuss the Site" subforum as opposed to as a reply to this post. It's what I'll be checking through the busy holiday season.

Hope to see things get back on track. Keep up all the good work, all, and let me know if you need anything else.

The lurking host/administrator,
Michael

Thanks.

Perfectly acceptable reaction time, actually.

So far no one has started yelling protests about the branching policy. Therefore I assume that it is acceptable. Somebody please wikify it.

P.S.: I hope you guys don't mind, that I try to off-load some work like wikifying on you. We recently had a large influx of non-coders, so we should have enough spare manpower. I think my time is better spend on the code.

We are almost ready for 0.9.0 and most developers are idling. Can't have that. So we will start the work for 0.10.0 in parallel to the release preparations for 0.9.0.

I have seen some code from Peppe regarding dialogue GUI, so I added him with this task to the roadmap. Anyone else for anything? Pick something from the suggested tasks list, if you feel like it. Or something from the other tasks section, if that is preferable.

jhooks, I think you were planning to do animations? You can continue with it or pick something else if you want.

I had some questions via PM regarding physics and terrain.

Bullet CMake integration: This is listed as a separate task. The person, who does the integration does not need to be the same, who does the physics work. We may have a volunteer for the actual physics work. Can we find a volunteer for the CMake integration too?

Terrain: Nico did some work on the background stuff (getting the data from the ESM records). First step would be to evaluate how far he got with it.

For the frontend (the actual rendering) we have two options:

1. Write a custom solution

2. Use the Ogre Terrain component

It is largely up to the implementor, but I suggest strongly, we go for the 2nd option. The terrain component may be a bitch to work with and it will particularly hard to integrate it with the MW terrain data model. But the following arguments speak in favour of it:

- Doing terrain properly (including all required optimizations) is a huge amount of work. Even if Ogre Terrain is fiddly and will result in lots of head scratching, using it will still save us a large amount of work.

- If we ever decide to bring the OpenMW graphics up to date, Ogre Terrain already offers everything we need (for terrain at least).

- The terrain component will eventually get some improvements from the Ogre community. By using it we can leech their work.

There is also old terrain rendering code. Nico wanted to give a try but he didn't reported any resoults...

I still can't pull from zini.

This is depressing. Been trying different things but I don't understand why it still doesn't work.

...Is it possible that my client is out of date?

You know what would be cool?
If I could manage my fork from the website the same way I could from a console application.

Odd. Firewall blocking git, maybe? You could try access via HTTP instead. That would be: https://[email protected]/zinnschlag/openmw.git

I still can't pull from zini.
This is depressing. Been trying different things but I don't understand why it still doesn't work.

There is a spelling error, zinnshlag is not the same as zinnschlag.

It's just a typo. You typed zinnshlag instead of zinnschlag

EDIT: Damn, too late

Lol, didn't see the spelling mistake in my own name. I think I need new glasses.

Lol, didn't see the spelling mistake in my own name. I think I need new glasses.

:O

Hmm...that's a start.

Well, I'm now up to date. I guess I can get back to work..Wow...what a silly mistake.

Somebody please wikify it.

http://openmw.org/wiki/index.php?title=Branching_Policy

Linked from the "Development" section on the main page for now.

Thanks.

Zini, I updated to your latest on git and made the changes you requested. I like the activation crash fix, the crashes have been bugging me for a while.

Looks like we are ready. Will poke the release manager now.

OK, I pulled a fresh new branch from Zini, followed the official instructions and everything went fine, the game compiles and plays just fine.

So, impressions:
The NPCs are there, the music plays, I can hear environment sounds, the character menu works, the console works and is case insensitive. I found no regressions (well, the NPC dialogue menu doesn't work, but compared to the previous version that's an improvement).

Issues:
Sometimes the music track changes whenever I enter a new cell (and sometimes it's fine, wtf?).
Also I thought this cute little crash

Code: Select all

openmw: /usr/local/include/OGRE/OgreSharedPtr.h:160: T* Ogre::SharedPtr<T>::operator->() const [with T = Ogre::Skeleton]: Assertion `pRep' failed.

was fixed, apparently not.
Also, the bug -where rotating the camera gets stuck whenever the mouse reaches the barrier of the window- is there. As far as I know this is an X11 bug and we'll need to find a workaround (I heard that other games warp the mouse back to the center)

System:
The game was tested on Ubuntu 10.10 with an X1950 Radeon card, the latest (x-swat) open source drivers and seems to work fine (compared to windows) although the frame rate gets noticeably slow at some points, but I know the engine is very unoptimized.

Overall:
Yay, progress!
Congratulations to everyone involved.

-My fork
-Windows 7
-Fiddling with Cmake got it to generate a project
-Opened 2010 project,
-F7 - BUILD.
-Open bag of goldfish
-Nom nom nom
- OMG so many std::XXXX warnings
- Errors
- ========== Build: 4 succeeded, 2 failed, 0 up-to-date, 1 skipped ==========
pasting in things with line numbers:

Code: Select all

utility(163): error C2440: 'initializing' : cannot convert from 'int' to 'MyGUI::StaticTextPtr '
layouts.cpp(58) : see reference to function template instantiation
utility(163): error C2439: 'std::_Pair_base<_Ty1,_Ty2>::second' : member could not be initialized
utility(167) : see declaration of 'std::_Pair_base<_Ty1,_Ty2>::second'
utility(163): error C2440: 'initializing' : cannot convert from 'int' to 'MyGUI::StaticTextPtr '
utility(247) : see reference to function template instantiation 'std::_Pair_base<_Ty1,_Ty2>::_Pair_base<int&,_Ty>(_Other1,_Other2 &&)' being compiled
review.cpp(83) : see reference to function template instantiation 
utility(163): error C2439: 'std::_Pair_base<_Ty1,_Ty2>::second' : member could not be initialized
utility(167) : see declaration of 'std::_Pair_base<_Ty1,_Ty2>::second'

Conclusion: It doesn't build.

MFW:

-My fork
-Windows 7
-Fiddling with Cmake got it to generate a project
-Opened 2010 project,
-F7 - BUILD.
-Open bag of goldfish
-Nom nom nom
- OMG so many std::XXXX warnings
- Errors
- ========== Build: 4 succeeded, 2 failed, 0 up-to-date, 1 skipped ==========
pasting in things with line numbers:

Code: Select all

utility(163): error C2440: 'initializing' : cannot convert from 'int' to 'MyGUI::StaticTextPtr '
layouts.cpp(58) : see reference to function template instantiation
utility(163): error C2439: 'std::_Pair_base<_Ty1,_Ty2>::second' : member could not be initialized
utility(167) : see declaration of 'std::_Pair_base<_Ty1,_Ty2>::second'
utility(163): error C2440: 'initializing' : cannot convert from 'int' to 'MyGUI::StaticTextPtr '
utility(247) : see reference to function template instantiation 'std::_Pair_base<_Ty1,_Ty2>::_Pair_base<int&,_Ty>(_Other1,_Other2 &&)' being compiled
review.cpp(83) : see reference to function template instantiation 
utility(163): error C2439: 'std::_Pair_base<_Ty1,_Ty2>::second' : member could not be initialized
utility(167) : see declaration of 'std::_Pair_base<_Ty1,_Ty2>::second'

Conclusion: It doesn't build.

MFW:

Check my thread, Common Build Errors.

Check my thread, Common Build Errors.

Ahhh, good...I'll give it a shot later.

We'll have to make sure that fix stays in.

Issues:
Sometimes the music track changes whenever I enter a new cell (and sometimes it's fine, wtf?).
Also I thought this cute little crash

Yeah, known regression. Presumably something is going wrong with NPC rendering, but only in a few places.

@chewit: I think this should be mentioned in the release posting. Its better to let the user know about the crash than let him discover it for himself.

But we need to get this fixed. Too bad, that the original author of the code, that introduced the bug, isn't with us anymore.

Check my thread, Common Build Errors.

I must admit, that I don't understand completely what is going wrong here (guess I should start to look into MyGUI eventually). But if it is a known problem and we have a fix for it, then why don't I see it on github?

Check my thread, Common Build Errors.

I must admit, that I don't understand completely what is going wrong here (guess I should start to look into MyGUI eventually). But if it is a known problem and we have a fix for it, then why don't I see it on github?

Probably because (I think...IIRC...kinda fuzzy) it was a suspected nuance of VC2010 and no one wanted to deal with it.

All I can really say to that is, even though it might be a VC2010 problem, the compiler DOES exist to protect you from yourself. Whatever it was, I think we should just fix the error permanently and not have to make a reference item out of a compiler error.

Issues:
Sometimes the music track changes whenever I enter a new cell (and sometimes it's fine, wtf?).
Also I thought this cute little crash

Yeah, known regression. Presumably something is going wrong with NPC rendering, but only in a few places.

@chewit: I think this should be mentioned in the release posting. Its better to let the user know about the crash than let him discover it for himself.

But we need to get this fixed. Too bad, that the original author of the code, that introduced the bug, isn't with us anymore.

Ok thats fine, Will do. Still awaiting Linux and Windows packages!

I have a few questions regarding the Linux release.
First of all, taking into account that we can't presumably ship all the dependencies in a zipped file like we do in Windows then:
for an average-Joe Ubuntu user, is it possible to run a

Code: Select all

sudo apt-get install blah blah blah

command, and get all the required dependencies for OpenMW, so that he can then unzip a binary archive and have the game work without ever resorting to compiling anything?
If that is not the case, then is it really useful to have a binary archive at all for Linux at this point?
If it is the case, then wouldn't that type of release be much more useful if we actually had people that can make .deb, .rpm packages, or set up a ppa?

If the answer to both of my questions is positive can I help speed things up by zipping a clean Build folder, send it to Ed so he can upload it to github? (or I upload it directly?)
I don't mean to impose on whoever is assigned to make the Linux build (I forgot who it was), but this release is taking a while for no apparent reason.

Also, has anyone actually managed to build a working Windows version yet?


//Edit: Minor clarification. When I spoke about two questions I meant my first assumption and the question after it, and not any questions after that.

command, and get all the required dependencies for OpenMW, so that he can then unzip a binary archive and have the game work without ever resorting to compiling anything?

I don't know. That's the first thing, that needs to be investigated for a binary release.

If it is the case, then wouldn't that type of release be much more useful if we acttheually had people that can make .deb, .rpm packages, or set up a ppa

Definitely.

Also, has anyone actually managed to build a working Windows version yet?

Yes. We have active Windows developers, who do that on a daily basis.

I don't know. That's the first thing, that needs to be investigated for a binary release.

Last month I did try to transfer the files to another computer and try to get the binary to work by installing dependencies through the package manager and failed, but I can't say I tried hard enough, I might give it another go.

Yeah, the binary releases for windows work - the real problem with the windows build is trying to get everyone to be able to build openMW on THEIR windows system.

If I could just stop worrying about the details about building and compiling (outside of my own errors while working) It would go a long way about getting things done and I would learn a ton.

We should probably get a windows thread going after release tasks are finished so the problem of getting Windows folk set up and running correctly isn't such a problem.

i was going to do a build for linux and post up a x64 binary, but somethings up with my gut and was sick, so stayed in bed.. (don't feel a whole lot better either)

will loadup nix and do it after this post.


in the setup development environment there are a bunch of commands apt-get ones to get all the dependencies, the issue is with getting the 1.7.1 version of OGRE. which can be a pain.


i have looked at things for making deb packages, but due to the way the whole build system is setup, its not going to be easy for me to do it. i don't have the required knowledge to modify cmake/make files to get it all working right.

hey,

got it compiled and running.

here is my repo with x64 Linux Binaries.

https://github.com/pchan3/OpenMW-Linux-Binaries

Bit of an overkill to create a repository for a binary release

Anyway, I see you have .log files in there. They are not needed.. OpenMW.layout should definitely not exist in a binary distribution.

And ogre.cfg has to go. A wrong ogre.cfg can result in a crash; had that when distributing an Ogre program for the first time; very embarrassing.

Also, you can remove esmtools and the apps directory (not sure about extern).

yeah i wasn't sure what was needed, but you could take what is needed and put it in separate download section somewhere.
btw, i would have done a file hosting thing, but i hate them and git takes seconds.

The intended procedure was to mail the release to the release manager IIRC.

Since the binary Linux release isn't completely ready yet and there is already work going on to completely automate the process for 0.10.0 I suggest we go for a Linux source release once more.

May I ask, what the status of the release procedure is?

Is chewit going to handle the windows binary soon?

Apparently not. Seems he can't find anyone willing to build for Windows.

i tried building for windows. but got a can't find ogre.h header error. 70 times.
it took me 2 days to get cmake to work.

I've been able to build on windows with only small errors that are easily fixed.
CMake was a bit mean to begin with but it turned out to be because I had non-standard paths for some libraries.

The biggest problem I have with the building right now is that CMake is auto-selecting the x64 version of the OpenAL lib, which the sound system apparently can't build against.
This is easily fixed though as all that is needed is to change the linker include to the Win32 instead of Win64 folder on OpenAL

Looks like we might get the release going after all. Please make sure, that you build the 0.9.0 tag and not the head of my master branch. Releasing different versions on different platforms sucks (support-wise).

Also, at the current 0.10.0 progress rate, you probably shouldn't wait too long, because else we will have 0.10.0 before 0.9.0 (okay, I exaggerate. But only because the terrain is still on the roadmap).

Let's hope the 0.10.0 release will work more smoothly.

I have henceforth noticed that I can build it perfectly fine but I can't run the builds apparently

The release build compiles fine and works up to the point it opens a window titled OpenMW, then it crashes with the error:

Code: Select all

ERROR: MyGUI EXCEPTION : widget name 'Skills' in layout 'openmw_stats_window_layout.xml' not found.
 in MyGUI at G:\Programming\C++\OpenMW\source\libs\openengine/gui/layout.hpp (line 43)

This with the 0.9.0 tag

Are you sure, that all resources files are available and at the right place? There should be a directory named resources with two sub-directories (caelum, mygui).

Found it, had apparently missed one resource file whilst putting it together.
I have a .rar file with the 0.9.0 build now, where do you want it?

chewit is the release manager. See that you get an email address from him and mail it.

Sorry guys that I have gone quite. Busy with exams which will be over on Wednesday!

I now got a 32bit and 64bit Linux build, and the Windows build will be emailed to me shortly

I have the announcement ready to go and I will be doing some updates to the wiki. I will also post the news of OpenMW 0.9.0 release on Ubuntu Gamer!

Great!

Looks like we are almost done with the project recovery list. One the release is done, we have only one point left.

@Star: Are you still up for making another video? The same style as before would be nice (showing what we got in 0.9.0 and talking a bit about the current work on 0.10.0).

Seeing as I've been able to piece together a windows build without many problems I figure I might be able to take up the place as the windows builder

@Star: Are you still up for making another video? The same style as before would be nice (showing what we got in 0.9.0 and talking a bit about the current work on 0.10.0).

Sure. What you'll want to make now is a really good list of features we've done for 0.09. Soon as the windows release hits I'll grab it and start working off a list.

I am pretty sure we had this discussion already and I made you a list. Either that or I have a really bad case of d?Šj?  vu.

Anyway, here is your list:

- World interaction: You can pick up things and you can use load-doors (doors that connect cells)

- Exterior-rendering, but no terrain yet and unoptimized (very slow)

- Character creation: Most of the GUI and the game mechanics work. But currently you have to invoke the character creation from the console (EnableNameMenu, EnableRaceMenu, EnableClassMenu and so on). The result of the character creation displays correctly in the stats window (press I) and in parts of the HUD (health, magicka and fatigue bars).

- NPC rendering (not final, but much better than in the previous version)


Thinks to consider: There is still this NPC-related rendering crash. Happens rarely and we will mention it in the release notes. But I think it should not be shown in the video. So you better check the cells you want to show for being crash free.

Activation (space bar) of objects is still pretty problematic, because we are currently checking against the axis-aligned bounding boxes. This method lacks precision. Some objects (mostly doors) are very hard or even impossible to target. It sometimes helps to get very close and to target an edge.
You should mention this problem, but ideally it shouldn't show up constantly during the whole length of the video. Best make a test run first through the cells you want to show.


Stuff to mention for 0.10.0 (WIP):

- better NPC rendering

- activation against a proper collision mesh instead of a bounding box (will fix the problems mentioned above)

- the dialogue GUI

- various portability improvements (not sure if it is worth mentioning these)

Not Deja-vu - we were talking about the 0.08 release that other time.

This is going to be really hard to do in one take with those bugs. I can try to make it seemless, but we'll see.

Of course, I'll be giving it a play beforehand.

This is going to be really hard to do in one take with those bugs. I can try to make it seemless, but we'll see.

I assume you mean the targeting-problem here (which is not actually a bug, just a very early placeholder implementation). We don't want to cheat on the user/player. You shouldn't have much problems with picking things up, but if doors make you to much problems, you can still coc via the console, as long as you show at least once, that doors can be used.

Hmmm...Okay. While we're waiting on the windows release, I'll be thinking on some things.

If I had room to run my openSuse Box, I'd make one from that, too...
Never heard of any OSS video cap stuff for Linux, though.

Until chewit fixes up all the release things, I figure I could give you guys a small friendly URL.

Like this one:
http://ace.haxalot.com/projects/OpenMW/ ... -win32.rar

Very hard to pick things up - cursor is misaligned. Probably due to the low resolution. I have a similar problem in fullscreening my XNA applications.

Doors also hard to go through, but I can render the exterior cell and objects in side it - just no ground or water.

Menus work, but no ques that they are work. Made a Nord . Also - 100 unarmed? Very funny.

You can pick up items in interior cells but not exterior cells...what's the difference?

Some doors do function better than others. I COCed to Gnisis and used a door to the inn fairly easily compared to a telvanni door.

This definitely has something to do with the cells and the doors. the same type of door in milk performs fine compared to the one in basara.

Well, I guess when we officially release I 'll start work on a video.

Also - 100 unarmed? Very funny.

I am not sure, what you mean.

You can pick up items in interior cells but not exterior cells...what's the difference?

There is none. Are you sure, that what you want to pick up, really can be picked up? Not everything in MW can be moved.
The only reason I can think of is, that there are different object categories. If one of them isn't pickable and this specific category is used mostly in exteriors, it would explain what you experience. But that would consistent a bug.

I have had an idea.

GitHub is not great for hosting downloadable packages, and as the release manager I can not upload packages to it anyway.

My suggestion is to use Google Code to host downloads, and it could also be used as our bug and feature tracker. GitHub can just do its job for the developers to do their coding with.

What do you think?

Not overly thrilled about the idea of spreading our presence over even more sites. But it seems we don't have a reasonable alternative for downloads.

I am not so sure about the issue tracker. This is mostly a developer tool, so ideally it should stay with the development site. The github issue tracker is somewhat rudimentary, but we don't have that many issues and so far it has served us well enough.

Perhaps someone could request to take over the project on SourceForge?
From what I recall there is (or at least used to be) some procedure for that, but it is not very fast as the current owner have a couple of months or something like that to reject such a request.

There is none. Are you sure, that what you want to pick up, really can be picked up? Not everything in MW can be moved.
The only reason I can think of is, that there are different object categories. If one of them isn't pickable and this specific category is used mostly in exteriors, it would explain what you experience. But that would consistent a bug.

Nope. Same blue glass bowl. Many jugs and bottles also suffer - they are clutter that should be able to be picked up. In some cells they could be, in others they couldn't.

Fine, just use Google Code for the downloads page.

Do you want me to setup that up, I can then release 0.9.0 in the next few minutes, all my exams are now over

Yes, please.

Fine, just use Google Code for the downloads page.

Do you want me to setup that up, I can then release 0.9.0 in the next few minutes, all my exams are now over

hah! Grats, man!

OpenMW 0.9.0 is out!

My first release done!

Please tell me If I missed any New Features/Bug fixes I should have added to the Release Announcement/Change Log.

OpenMW 0.9.0 is out!

My first release done!

Please tell me If I missed any New Features/Bug fixes I should have added to the Release Announcement/Change Log.

According to Zini:

Issues:
Sometimes the music track changes whenever I enter a new cell (and sometimes it's fine, wtf?).
Also I thought this cute little crash

Yeah, known regression. Presumably something is going wrong with NPC rendering, but only in a few places.

@chewit: I think this should be mentioned in the release posting. Its better to let the user know about the crash than let him discover it for himself.

But we need to get this fixed. Too bad, that the original author of the code, that introduced the bug, isn't with us anymore.

we should mention the crash the happens in some cells that I mention there:

OK, I pulled a fresh new branch from Zini, followed the official instructions and everything went fine, the game compiles and plays just fine.

So, impressions:
The NPCs are there, the music plays, I can hear environment sounds, the character menu works, the console works and is case insensitive. I found no regressions (well, the NPC dialogue menu doesn't work, but compared to the previous version that's an improvement).

Issues:
Sometimes the music track changes whenever I enter a new cell (and sometimes it's fine, wtf?).
Also I thought this cute little crash

Code: Select all

openmw: /usr/local/include/OGRE/OgreSharedPtr.h:160: T* Ogre::SharedPtr<T>::operator->() const [with T = Ogre::Skeleton]: Assertion `pRep' failed.

was fixed, apparently not.
Also, the bug -where rotating the camera gets stuck whenever the mouse reaches the barrier of the window- is there. As far as I know this is an X11 bug and we'll need to find a workaround (I heard that other games warp the mouse back to the center)

System:
The game was tested on Ubuntu 10.10 with an X1950 Radeon card, the latest (x-swat) open source drivers and seems to work fine (compared to windows) although the frame rate gets noticeably slow at some points, but I know the engine is very unoptimized.

Overall:
Yay, progress!
Congratulations to everyone involved.

It happens for example when you leave the starting cave through the door, or when you type "coc Vivec" in the console.

Also about features, you forgot a pretty fundamental one, NPCs rendering.

Edit: Never mind, I just realized it's automatic.

So there I was - having a good take for the video, and I realized that custom assignments to skills don't work.


...Nuts...That was a good take, too...