FIFE forums

Please login or register.

Login with username, password and session length
Advanced search  


FIFE 0.4.0 has been released on 15th of January, 2017!

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Wuntvor

Pages: [1]
That is one hell of a post!  ;D Since it touches so many topics, I'll try to only comment on those things where I feel I have something to add (just assume the rest looks fine to me:) ) and where your post doesn't mention that a separate thread should be created.

New Name
I agree that the name should be changed, and I'd also say it should remain FIFE. I'd prefer if it wasn't whatever you call those clever acronyms that contain themselves, but I don't have a better idea so that works for me as well.

Since I am the one "responsible" for this branch, I just want to reinforce with this that what the branch mainly needs now is people testing it, and, if it's on linux, it'd also be nice if they could try to fix it. This would include things such as adding "scons ext=1" support for physfs, fixing tests or whatever there is. Under Windows, all clients run (though there may be more subtle errors) and all tests work (besides one that fails because loading a non-existant image no longer throws an exception, see the commit by jasoka on trunk that caused this).
Please post your results with testing it (whether successful or not) in this thread

I'd suggest leaving the cmake dependency in. I am pretty sure PhysFS will require it, too, and investing time into a work-around just doesn't seem worth the effort. We require people to install other libraries and tools like swig or boost, so why not cmake?

Content restructuring / Maps
Sounds very good to me. What isn't so clear right now, at least for me, is how this is going to work ingame and in the editor. What I imagine would be that all packages are simply mounted into a common hierarchy, so that people using packages don't have to care what package a certain object is in (which would also make it easy to override things from a different package), so it'd all reside in one common tree. Is that kind of what's planned?

General feedback
(I'll skip point 3 for now, as I find it hard to separate from 1+2 right now)

1. In general, I am really surprised at how easy it was for me to jump right into things. Everyone on IRC has been very supportive, and if there's something to discuss, there's always an open ear. The infrastructure (like the build system incl. the sdk) is very good. In general, there is a lot of progress, new things are being worked on all the time and I feel the team is "getting things done".

2. I feel that FIFE may sometimes have a lack of direction. Maybe this is just because I'm still new, but I can't say that I can see a clear "vision" of what FIFE is going to be. Of course, there is a lot of material on the wiki, but it is not always helpful when looking at specific issues. This does have its advantages, and I'm not proposing some kind of dictator who tells me exactly what and how to write it, but in my opinion some more direction might make us more productive.
The only other thing I can think of right now is that sometimes the ticket system on trac could be used more, although I am very much guilty of that myself.

That's all I can think of right now. Again, I may have missed a lot of things being still rather new myself, so please excuse me if that should be the case. :)

Framework development / Re: VFS restructure
« on: March 16, 2008, 06:47:22 am »
Great to hear you've been able to resolve the linker error!

The editor should at least start and be able to load a map, I must admit that I haven't tested much more than that as I am not familiar with it at all. Did it not even start for you?

The tests should actually all work fine, at least they did for me on windows. Can you tell me which ones fail for you?

Framework development / Re: VFS restructure
« on: March 12, 2008, 09:48:53 am »
Accessing multiple directories at once isn't the real problem. You can mount any directories you want into whatever directories you want, so you could for example load C:\UT2004textures into /external/ut2004 or whatever you want and use it from there.

For now, I've implemented #1 again as it is the way the editor currently worked, and everything else is more of a question of the editors functionality. In my opinion, everything should be neatly added to a package before it can be used in the editor, as anything else just complicates things. Of course, the editor should eventually include tools to easily add resources to a package.

But that's just my point of view. Eventually, we'll certainly need the ability to access both files outside and inside of the VFS, so it makes sense to add that functionality for the file browser anyway.

Framework development / Re: VFS restructure
« on: March 12, 2008, 04:25:26 am »
Option 2 is the sanest idea, although I don't think we should be using physfs for the editor. One question, how is opening a random image from C:\mytextures handled ( as in does it go through physfs or not ? ).

Another solution would be to have multiple instances of physfs, one for the map file only, and another for global drive access.
How would you not use physfs in the editor? In my opinion, the environment of the editor should be as close to the environment of the "real" games, because otherwise you'll sooner or later run into issues where things are handled differently.

Currently, as far as I know, opening an image always goes through the VFS. But if you ask me, that's the way it should be. What happens if you use an image in your map that is located in C:\mytextures and later use that map in a game? When you want to package it and send it to someone else, you'd have to somehow move all those files into your game path and then change all references there.

If you absolutely must use the file from that path, you should add it to the VFS anyway, as that makes it easy to move the file later (as you just need to change your source path from C:\mytextures to whatever).

Multiple VFS trees aren't supported, as far as I know, so that solution doesn't work, unfortunately.

Framework development / Re: VFS restructure
« on: March 11, 2008, 02:05:32 pm »
The physfs-branch is coming along nicely. The old code has been removed, and now it's mainly a matter of fixing the current clients so they all work. The island demo works already, the editor kind of does and I haven't really checked the others yet.

The problem with the editor is the following: The old vfs code allowed access to files outside of the VFS. For example, if you set your root path on the project level, you could access the file "../whatever/bla". Physfs doesn't allow that, so the editor can currently access just its own files, which is pretty useless.

There are a few different options:

1. Make the editor have its root one level higher (i.e. in our case in the clients-directory). This is pretty much the way it has been in the "old" code, there'd just have to be some changes to make it work with the new code.

2. Change the way the editor works. The way I'd envision it, you'd have a "Open Project..."-button. When it is clicked, it'll show a directory selector, allowing you to choose what project you want to work on, for example "island demo". It'd then switch the vfs root to this directory. Of course, additional directories can still be linked in to the VFS.

Personally, I think that option #2 makes more sense, although it is of course also the option that'd take more work, as we'd need additional code to work with the actual fs instead of the vfs. This could be done using just python, though, so it sounds doable to me.

General discussion / Fallout-dat-support: Is it still needed?
« on: March 09, 2008, 06:02:38 pm »
I am currently working on integrating physfs into FIFE (branch /branches/active/physfs). Among other things, this should make it easy to add write support to our vfs code as well. However, there's one problem: The fallout dat-support.

Of course, it's possible to wrap physfs inside of the current vfs code (by just writing a sourceprovider for it), but it'd make this quite pointless as it'd mean that everything else still stays the same and we'd basically be wrapping a vfs inside of another vfs.
Otherwise we'd have to try and add support for the fallout file format to physfs, which doesn't sound like a trivial task either.

The question is, will anyone be using the dat-loader? Since FIFE won't really support anything else from Fallout (correct me if I'm wrong), it sounds kind of pointless to me anyway. If someone absolutely wants to use the Fallout graphics, he can still convert the files and just use these in FIFE.

Code: [Select]
<barra> yep, in case the need arises again later (e.g. somebody would like to create a game based on Fallout gfx) we could reevaluate it
<barra> and leave the work to this person :-)

So what do you all think?

For me, the more freedom for developers the better, so I'd be all for LGPL if possible.

I think 4 is both the most difficult and the least important of these. It'd be nice to have, but at least at this point the product isn't interesting to anyone besides the developers. However, what would be possible would be to have it be built on the server and then run the tests so one could always check at what point something broke. But still, that's a bit more advanced.

3 is very easy, I already have a basic logging bot written, but probably I'll take another look into premade solutions as they'll be a lot nicer formatting-wise.

1+2 isn't that hard to do, we'll just have to come up with a way for the server to be notified whenever a commit is made.

I do have a server that we could use for all of this, so that'd be taken care of as well (although you said we shouldn't worry about the server infrastructure for now :) ).

Can't really think of anything else we might need.

Has this ever really been decided on? Just curious, from what I've seen FIFE seems to be deeply integrated with python (judging by the amount of python code for stuff like the GUI), but I'd really like to know.

Pages: [1]