Nicely done

[Guest Chiv]

Gemrb really has come a long way since I last tried it, you guys have done an incredible job reverse-engineering everything about the game and re-newing it. I can see the light at the end of the tunnel, I hope so can you

 

My only grief with it is it is still not so simple to get up and running, not for my sake, but I'm sure it scares away the less persistent. It requires so many paths to be manually entered, it kills the 'impulse testing' potential audience... and generally, the cd1/2/3 etc paths can be assumed from the game path, and the gemrb file paths can be assumed from the install prefix. I believe a smarter startup routine would only need to know the location of the installed game, and then guess all the other settings in the config. But I can understand that there are more important things to take care of, so useability has fallen down the wayside

 

Maybe I could have a go at fiddling with it... which file would be a good place to start looking?

[Guest Chiv]

Nevermind, I worked out it begins in interface.cpp. I am a real novice coder, but I really think this is worth doing so I am going to try.

 

I want to implement a: more sensible file locating b: ability to run without config and c: saving of default config if none found

 

I would like to assume that plugins can be found in ../lib/gemrb and guiscripts in ../share/gemrb relative to the path of the binary - is that a reasonable assumption for a default setup?

 

Also, I don't have a good idea of where the cache dir ought to default to. I have mine in ~/.gemrb with my configs, which I think would probably work for most people? Or perhaps somewhere in /tmp?

[Chilvence]

Well that's odd.. while I was prodding I worked out that Gemrb doesn't even need most of the cfg variables set specifically, so that's saved me most of the work I was planning. But... why, by ye gods isn't that functionality used already to simplify things for general users? It may be non obvious, but the way it is packaged with the ini makes it seem like you have to specify every minute detail in order to start the game, and getting any of it wrong causes a premature abort. It's much too sensitive for my taste!

 

It looks as if all that is needed to make it fully automated is to pick a resolution, choose the right game mode and find the game data.

[Avenger]

I know people are working on installers and launchers.

The reason for all those options is because we don't know the target audience (different platforms, possible new game developers) also the game is still in a 'beta' development state.

I guess someone could make a Windows based installer for it. (NSIS is a good choice).

[Chilvence]

Still, it couldn't hurt to add some guessing logic to the startup routine, if gemrb doesn't know what to do with itself when you run it. It wouldn't get in the way, because it would only be used as a fallback if the configuration can't be found.

 

I don't think anyone needs to go as far as making an installer, it would be good enough that if you unpack it in the right place, it works, like any other win program -- or that in linux, it at least tells you what settings/cmd line it needs in the console. Those are the two main platforms I see; if anyone is game enough to install it on anything else, then they probably are smart enough to work out what to do themselves!

 

Anyway, I am just glad gemrb works as well as it does - I just want to try and make it so other people can see it working without being put off by the fiddling about, if that is alright?

[Chilvence]

Ok, I have the game running sans config file, it now only requires a command line switch for the game path (-g) , and is able to rudimentarily decide between bg2 and iwd2 at the moment. It will be simple now to negate the requirement of the command line as well if gemrb is inside the game directory (assumed windows setup). When I get more time to install all the other games and test them I will finish the gametype detection and try and submit a patch.

 

Might be a while before I have a go at the config writing, I have alot of things I should be doing instead of mucking about, but hey!

[Avenger]

One thing: gametype detection shouldn't be hardcoded. It is fine if there is some code support for it in the core, but nothing game specific. We try hard to eliminate any such things from the core, so no need to reinfect it with such things.

[Chilvence]

So in less words, you are saying its a bad thing for gemrb to be able guess what it is supposed to be doing from the average user's point of view? I'm sorry but I dont understand the reasoning behind that logic.

 

There isn't such a thing as 'hard-coding' in the same sense as the original engine anyway - hard-coding in IE is bad because nobody has the source, that was the only reason. If it was out in the wild, like Doom, Quake or Dn3d, anyone could have already done what they want to the original game and you would never have had to make GemRB at all.

 

But in GemRB's case, there is no reason not to do this - there is no reason to make all the users suffer just because of zero-tolerance enactment of a general design philosophy. Having to set configuration options before a program can run at all is extremely bad in my opinion. Look at the users come here just to ask how to get the game running - and that is only a sampling of all the anonymous testers that must be getting turned off by the hassle.

 

It's a really hard experience to relate to someone very close to the project, but the experience of finding Gemrb and getting it to run at the moment is something like getting a christmas present from your dear old senile Auntie Nora, finding out to your pleasant surprise that it is a Playstation 3 rather than an assortment of floral placemats, then opening the box and discovering that in order to get it running, you have to buy a special cable adapter for your television, and it is -50 degrees outside, and all the shops are shut because it's christmas day, and you have to stay in anyway because Uncle Scrooge has come to visit and he only comes once a year, and yes I know he can be cantankerous but please make an effort to be nice, and please could you not say anything about the smell this time, because he's nearly 96 and its not his fault, its his health -- when all you really want to do is plug the damn thing in, close the curtains, tell the rest of the world to shove it, and crack some heads!

 

So please, make a tiny little comprimise and let it be simpler for Gemrb to fulfill its primary mission, that is, to emulate the original Black Isle / Bioware games.

 

Bearing in mind, that the code I want to introduce only comes into action when a config file CANNOT be found, and the game would otherwise do nothing but drop out to the console with a big red error message and no user advice.

[Jarno Mikkola]

So in less words, you are saying its a bad thing for gemrb to be able guess what it is supposed to be doing from the average user's point of view? I'm sorry but I don't understand the reasoning behind that logic.

Well, there's always a reason for everything... but you could make the add on package able to configure a lot of things with a few assumptions, so I am assure that a custom configuration addition could be handy, especially if it's in an 'easy to read' format so a lesser capable programmer eventually could understand it. So I don't think that Avenger says that he doesn't want you to do this, but just that it might not become permanent part of the whole... so the engine can be used for other things too.

 

Bearing in mind, that the code I want to introduce only comes into action when a config file CANNOT be found, and the game would otherwise do nothing but drop out to the console with a big red error message and no user advice.

See, this is where our approaches would differ, yours would be the last recourse of the last failed coder... mine would be the first resource for the possible player that want's to be an editor to use... or something like that.

[Chilvence]

. So I don't think that Avenger says that he doesn't want you to do this, but just that it might not become permanent part of the whole... so the engine can be used for other things too.

 

Thats what I think is the misunderstanding - I am appreciative that gemrb is well and truly capable of doing other things than bg2, etc - I would not want to make it difficult to create a new game. I actually want to make my own stuff for GemRB myself, eventually!

 

All I would like is a clause in the code that scrambles around for something to doif nothing else has been specifically configured because the vast majority of players will just want to run the game and nothing else. It's just a matter of convenience, and it will silence all the questions from visitors about how to get the game running, because this is the kind of thing they expect.

[zefklop]

You should take a look at how weidu does this. Also, you should consider the option of creating a 2DA file, this si how you make unhardcoded things in GemRB :-)

[Chilvence]

What does WeiDu do? My only experience with WeiDu is running packages that have been made with it, I have no actual frame of reference to know what it does and how.

 

I don't know about making a 2da file for detecting the original games - it doesn't seem logical, it isn't intended to be code that is re-used. But it seems so far that everybody who has responded to this idea has done so negatively. It doesn't make any difference to me whatsoever, but if people aren't going to be intrested in a patch my way, I may as well not make it. I am not going to try and design to someone elses spec either, any idea you guys have for this is probably well beyond my level of programming. I just wanted to do a warm up exercise before working on something else, not get dragged down a rabbit hole

[lynx]

No need to get all worked up. A 2DA file is basically a space delimited CSV that IE uses for storing plaintext tables. There are plenty examples of that in the IESDP and gemrb. Zefklop is right that this is the best approach for keeping the engine clean, while getting the autodetection. Handling tables in the code is pretty easy.

 

An example how this gametype.2da would look like if you were testing by looking for unique files:

2DA V1.0
*
	  FILE1	   FILE2
BG1	 x
BG2	 bgmain.exe	  y   
PST	 torment.exe
IWD	 idmain.exe	  
HOW	 idmain.exe	expmap.wmp
IWD2	iwd2.exe

 

Then if we ever add another game type or somebody else uses the engine, all they have to do is edit this table.

[Avenger]

I didn't want to hurt your feelings. My intentions were just the opposite.

I just didn't want you to work futile in case you want your changes to be incorporated in the main branch.

I don't mind at all if you change gemrb in a way i don't want, you can even host/distribute the patches (even in our project as a patch), or the whole changed project somewhere else. It is entirely in your rights, and many would probably like it.

But it is always better to work together on a single item, everyone adding what they can to the whole.

Lynx and Jarno explained my reasons for the reluctance of hardcoding. And Lynx gave a very good approach, that would work very well, even fully in the core.

 

There are very good reasons to try to keep the code clean, beyond pure programmer whims.

The core should be as independent of the original dataset (which have copyright on them) as possible, because of legal reasons. This is the same reason i want us to implement the combat rule differences via datafiles/scripting.

In case of a copyright dispute, it doesn't hurt if you can show that the core is completely 'general purpose' and has nothing to do with the original 'IP'.

[Chilvence]

Yes, I can see how that could work - you have to forgive me, I am not really used to these sorts of topics - I thought you were being evasive when really you would just rather the detection be done a certain way that didn't occur to me. The trouble is, it seems like such a simple oversight, that until you explain the reasoning like you have to me, its hard to understand. But I can respect that you don't want to get the core dirty, I just hadn't realised why my quick hack would be considered dirty... I guess I should consider there might be other motives than my own before putting my foot in my mouth

 

Anway, sorry for making a storm in a teacup issue over it. As it happens, what I have already done can probably be easily stretched to follow lynx's example, after I study the 2da module a bit. Then I should be able to cracking on my own experimental stuff that I have conceptualised on the back of an envelope