Python version

[Guest Serious Callers Only]

I have python version 2.4 installed in windows xp. Is this version incompatible with the current version of gemrb? (Its giving me an error in the core inicialization)

 

Also if i wanted to try my hand at the phyton scripts what would be good areas to check out? I have BG1 (no totsc), BG2 (no tob), pst and iwdII.

 

How do you know what a strref refereces (in the example of the gui python scripting)?

[Avenger]

I have python version 2.4 installed in windows xp. Is this version incompatible with the current version of gemrb? (Its giving me an error in the core inicialization)

 

Also if i wanted to try my hand at the phyton scripts what would be good areas to check out? I have BG1 (no totsc), BG2 (no tob), pst and iwdII.

 

How do you know what a strref refereces (in the example of the gui python scripting)?

<{POST_SNAPBACK}>

The current windows binary version is incompatible with python 2.4.

It is possible to recompile the engine with 2.4.

I don't know if it is possible to make a windows binary which accepts both versions

 

You can look up strrefs with a tlk editor. DLTCEP is recommended But NI can do it just as well.

Or if you want to know which strref is responsible for a given string, turn strrefs on in the engine. (set StrrefOn=1 in the .ini)

[Guest Guest]

Thanks. I can't compile c++/c projects right now (no mysys) so i'm going to get 2.3.

 

BTW, just like the original games engine is compatible with platter fixes or the various BG mods, so is gemRB, right?

 

Thank you for your wonderful work.

[Avenger]

Thanks. I can't compile c++/c projects right now (no mysys) so i'm going to get 2.3.

 

BTW, just like the original games engine is compatible with platter fixes or the various BG mods, so is gemRB, right?

 

Thank you for your wonderful work.

<{POST_SNAPBACK}>

We try to be fully binary compatible with the original engines, including quirks.

But some stuff won't be the same, for example, ChangeStat in iwd2 will accept a lot

more stats than the original engine did.

And we'll fix some bugs that crash the original engine.

I guess, most of the mods will stay compatible, but if they rely on a special bug, then

they'll be broken.

Another example: SaveObjectLocation accepts only capitals in the variable context name.

ie: only SaveObjectLocation("GLOBAL","VARIABLE", Myself()) will work.

Our engine will accept "global" as well.

So, it is possible to write stuff that works differently.

[Guest Edheldil]

Also if i wanted to try my hand at the phyton scripts what would be good areas to check out? I have BG1 (no totsc), BG2 (no tob), pst and iwdII.

 

Look at this document (also available from the rightside menu at our pages):

GUIScripting Intro

[Guest Guest]

I'm trying to do a small thing, implementing the saving of checkboxes in OpenGameplayOptionsWindow (Torment). I've noticed that there is a small example of how to do it in the OpenAudioOptionsWindow function. Is this a correct manner to do it?

 

Also if i do manage to do it is the funcionality of those commands implemented (run gore etc). If not it is still the python part or the c++ part?

 

 

Anyway i noticed that in OptCheckbox ()

GemRB.SetButtonState (window, button, IE_GUI_BUTTON_SELECTED)

 

causes the program to not recognize the first click on the checkbox(es)

The color is off too.

Also the tooltips are not reacting like the original but i've been unable to pinpoint it.

 

Is the error of the windows after the new game (as opposed to loading a savegame) resolved?

[Guest avenger_work]

The gui and the engine communicate via script variables (as described in docs/en/GUIScript/data_exchange.txt), and sometimes via direct access functions (Like GemRB.GameSetReputation()).

 

The gui configurable options use the same variable names as they are written in the original engine's .ini file. You won't see any effect ingame (since effects/combat are not implemented yet).

But if you implement the options screen correctly (use the same variable as in the .ini file), you will see that whatever is set in torment.ini as gore option, will be seen in the options screen correctly. Right now we don't rewrite the .ini file (as we don't want to overwrite the original setup yet).

[Guest Serious Callers Only]

A little example.

I did this :

 

In GUIOPT OpenAudioOptionsWindow function, to the for that saves the sliders state i added 'CreativeEAX', 'SoundProcessing', 'MusicProcessing'. Those are the names of the Checkboxes in this window. (couldn't find them in the original Torment.ini (patch 1.1) )

 

In GUIOPT OptCheckbox function, after

 

button = GemRB.GetControl (window, button_id)

GemRB.SetButtonFlags (window, button, IE_GUI_BUTTON_CHECKBOX, OP_OR)

GemRB.SetButtonState (window, button, IE_GUI_BUTTON_SELECTED)

 

, i added

 

GemRB.SetVarAssoc (window, button, name, 1)

This seems to work only i'm not quite sure why

since data_exchange says of checkboxes :

the associated variable will be or-ed with the value

 

the value in the first run should be 0

1) 0 || 1 = 1

2) 1 || 1 = 1

3) 1 || 1 = 1

etc

 

So how the heck it is changing again to 0 if i click in it? Isn't the value given always 1. Isn't it or-ed with the old value?

[Guest Serious Callers Only]

Now that i see the torment.ini with a little more attention the values are there. Ignore that part.

[Avenger]

The values are xor-ed, not or-ed.

[Guest Guest]

By the way since you say that the "The gui configurable options use the same variable names as they are written in the original"

Shouldn't the names of the checkboxes be changed to be identical to the ini?

The way i'm doing it the keys which are going into the global dictionary aren't the names in the ini. Ex:

 

ini ---------------------------------------- code

Environmental Audio CreativeEAX

Sound Processing SoundProcessing

Music Processing MusicProcessing

 

Also some options seem to require hardware tests in the original, for example i don't have EAX so that option is always grayed out no matter what i do in my machine.

 

Other little thing as it is the buttons bettwen their inactive color (dark blue) to their blocked color (grey) when it should be light blue.

[Guest avenger_work]

Use EnvironmentalAudio instead of CreativeEAX

The other names should be ok, i think.

 

I have no idea about EAX, but i guess, since we use OpenAL, it will use EAX when it is possible (if you got hardware and openal is capable). OpenAL is partly (mostly) written by Creative.

[Guest Guest]

I've noticed that the Start.py script seems to become DOA the second time it is run.

I don't know why. The only thing i know that is different, is that a print of the StartWindow variable the second time truu seems to yield a value of 1 as opposed to 0

Explicit StartWindow = None or StartWindow = 0 doesn't fix it.

 

It seems bizarre considering the

 

GemRB.UnloadWindow(QuitWindow)

GemRB.UnloadWindow(StartWindow)

 

calls on all significant exit points.

[Avenger]

Those variables get new values when the script is loaded (OnLoad).

If some windows stay loaded, they will get another number.

There should be no problem with Unloading those as any exitpoint would be called only once, after OnLoad.

Actually, if you don't need any previous windows, you can use GemRB.UnloadWindow(-1)

That will close all and any open windows.

If the start window behaves strangely only after you entered the game, then probably that is the reason. When entering the game, the system automatically closes all windows.

I just wonder why OnLoad of Start.py doesn't run the second time to load those windows.

[Tarrik]

The current windows binary version is incompatible with python 2.4.

It is possible to recompile the engine with 2.4.

I don't know if it is possible to make a windows binary which accepts both versions

 

Hmm, what about the Mac version? I have tried both Python 2.3.5 and 2.4 with --enable-shared and --with-shared but the gembr configure script can't find the shared libraries.

 

How does the configure script work to find out where the shared libs are?