[N1kX]

I tried to watch print Lego, interested in the question. Why does the y position not change

func void PrintS_Ext(var string txt, var int color) {    var int h; h = new(gCPrintS@);
    var gCPrintS p; p = get(h);
    var int v;


    v = Anim8_NewExt(1, gCPrintS_Alpha, h, false);
    Anim8_RemoveIfEmpty(v, true);
    Anim8_RemoveDataIfEmpty(v, true);
    Anim8 (v, 255, PF_FadeInTime,  A8_Constant);
    Anim8q(v, 0,   PF_WaitTime,    A8_Wait);
    Anim8q(v, 0,   PF_FadeOutTime, A8_SlowStart);
    p.a8_Alpha = v;


    v = Anim8_NewExt(PF_PrintY, gCPrintS_Position, h, false);
    Anim8 (v, PF_PrintY - PF_TextHeight, PF_MoveYTime, A8_SlowEnd);
    p.a8_Movement = v;


    //p.tv_Text = Print_Ext(PF_PrintX, PF_PrintY, txt, PF_Font, color, -1);
	p.tv_Text = Print_Ext(-1, PF_PrintY, txt, PF_Font, color, -1);
	p.vr_Pos = PF_PrintY - PF_TextHeight;
    gCPrintS_COff += 1;
    if(!gCPrintS_Act) {
        gCPrintS_COff = 0;
    };
    gCPrintS_Act += 1;
    p.vr_Offs = gCPrintS_COff;
};

By x, the text has moved to the center, as expected, and changing PF_PrintY does not change anything. I feel that change is necessary in this function and not in func int Print_Ext

[Lehona]

I don't understand your question, this seems to be a language barrier thing Can you explain again a) what you are trying to achieve, b) what you have done to get that result und c) what is happening instead?

[N1kX]

Good. I want to use this function, I could change the vertical position of the text. By x, I changed to -1 and the text became centered. Changed the y values but the text does not change the vertical position. Sorry is my English, he is bad.

Here, at the beginning of the video you can see that I would like to shift this text closer to the top.
https://youtu.be/PoOjz5HF_kM

[Lehona]

You are not supposed to modify LeGo files directly. Instead modify the Userconst.d*, which has constants that govern the position of PrintS-text, in particular PF_PrintX and PF_PrintY. Modifying the latter will change what you want.


Edit: Some more explanation because why not: The Anim8-code above Print_Ext frequently changes the Y-position (to something based on PF_PrintY), so changing the value passed to Print_Ext does nothing.

*I realize that this is a LeGo file as well but obviously you have to modify something.

[N1kX]

You are not supposed to modify LeGo files directly. Instead modify the Userconst.d*, which has constants that govern the position of PrintS-text, in particular PF_PrintX and PF_PrintY. Modifying the latter will change what you want.

Edit: Some more explanation because why not: The Anim8-code above Print_Ext frequently changes the Y-position (to something based on PF_PrintY), so changing the value passed to Print_Ext does nothing.

*I realize that this is a LeGo file as well but obviously you have to modify something.

Thanks. I added my constants and made a derivative of this function in order to use my constants and not change the original function.

[blood4ng3l]

Heyho,

while I was trying to read INI values for a scaling Option, which can also be controlled by ingame menu, I came across this issue.
It seems not to be possible to access an "array" with an variable (the readout INI value).

The whole reason why I'm doing this with an array is that I can "interpret" the set option to my liking.

Here is a code snippit:

Spoiler:(zum lesen bitte Text markieren)

----userconst.d
...
// interpretations of ini Setting
const int B4DI_BarScale_off 		= 100; // will not be used?
const int B4DI_BarScale_auto 	= 100; // will not be used?
const int B4DI_BarScale_50 		= 50; // 50 %
const int B4DI_BarScale_100 		= 100; // 100%
const int B4DI_BarScale_150 		= 150; // 150%
....

------bars.d

...
//========================================
// [intern] Helper Scales depenting on Resolution
//========================================
var int B4DI_BarScale[5];
func void B4DI_InitBarScale(){

    B4DI_BarScale[0]= B4DI_BarScale_off;
    //TODO replace Auto const Resolution based Scale
    B4DI_BarScale[1]= B4DI_BarScale_auto;
    B4DI_BarScale[2]= B4DI_BarScale_50;
    B4DI_BarScale[3]= B4DI_BarScale_100;
    B4DI_BarScale[4]= B4DI_BarScale_150;
};

func void Bar_dynamicScale(var int bar){
...
    B4DI_InitBarScale();
    var int scaleOption; scaleOption = STR_ToInt(MEM_GetGothOpt("B4DI", "B4DI_barScale"));
    var int scaleFactor;
    if (!scaleOption) {
        return;
    } 
    else if(scaleOption == 1){
        scaleFactor = B4DI_BarScale[scaleOption];
    } else{
        scaleFactor = B4DI_BarScale[scaleOption];
    };

    var int dynScalingFactor; dynScalingFactor = scaleFactor/100;
....
};

So I get the error with "ScaleOption" which must be a integer const, as it seems.

Do I have to somehow initialize the array, or am I missing something?

note: do not mind the for now useless double "else"

Something else is there an option to manipulate int values with an slider in the option? Or a way to properly cast Gothic vanilla floats into integer? I am a little confused with the floats with integer representation mixing in ^^

Thx and Greetz

[Cryp18Struct]

You can use the ikarus function MEM_ReadStatArr to read from an array with a variable index.

[blood4ng3l]

Heyho,

I am working on a UI Mod, I am using the view and Bar framework of Lego, which i am extending for that purpose. But I can not figure out why the original bars look so different than the new ones. Should not both use the same texture? using directly the -C.tex does not work, then i get anything but not the correct texture loaded.

[Bild: attachment.php?s=e1633c8f09a5432b197804d2f72f1fb6&attachmentid=48326&d=1565786839&thumb=1]

I am experimenting with alpha blend modes, but it seems not to be the right path,.. I imagine that when using the tga in the script it will be converted into a tex automatically? May it be a conversion problem? But than I would expect that both Bars look the same since both should use the original texture?

Can someone explain whats happening?

Greets

PS: btw thats that array thing worked, thx =)

[Lehona]

You haven't really shown us what exactly you did, so all I can say is that it looks different because it looks different. The fact that it is partially transparent seems pretty obvious, though, but it sounds like that was intended. It's a bit blurry, maybe because it's rendered in a larger size than the texture (i.e. it has to be scaled up).

Using a .tga is correct - Gothic will compile said .tga to a -C.tex (unless it exists already in compiled form) and then use the -C.tex-file as a texture.


You had a question about floats in a previous post - if you could expand on that question I'm sure I will be able to clear things up.

[blood4ng3l]

You haven't really shown us what exactly you did, so all I can say is that it looks different because it looks different. The fact that it is partially transparent seems pretty obvious, though, but it sounds like that was intended. It's a bit blurry, maybe because it's rendered in a larger size than the texture (i.e. it has to be scaled up).

Using a .tga is correct - Gothic will compile said .tga to a -C.tex (unless it exists already in compiled form) and then use the -C.tex-file as a texture.

Yeah the comparison picture is not the best choice, indeed cause I experimented with other Alpha functions at that moment too.

What did I do: I just used the basic implementation of the bars.d you provided with LeGo.

I noticed it looks different even at nearly the same size as the original HP Bar.
So I was wondering why, cause it should be the same texture.

On Further investigation (zooming in^^) I noticed that the "original" Bar consist of 3 views meaning there is the Bar_TempMaxBar texture between the bar tex and the back tex. Also the offsets don't look the same on the bottom and the top as in your implementation. So I think the textures are actually the same and the alphafunc used are also the basic ones and the difference comes from the additional middle texture, which is half transparent in the middle and has a black border around it, which gets covered by the actual bar texture if it is full and the slightly uneven offsets on the bottom and top.

Now my new Bars look almost like the original. =)

You had a question about floats in a previous post - if you could expand on that question I'm sure I will be able to clear things up.

Concerning the float thing:
"userFloat[0]" I only found this kind of option for the menu sliders and I would prefer integer values. But now I have a Choice instead of a slider, which works fine with integers.

Further digging into the float.d (again) helped me to get the answer I was looking for; so I assume the float value form the "options slider" which will be write into the ini can be converted into an ikarus float with castToIntf for further calculations?

Some other things^^

I was also wondering, whats purpose of the childs of views. In my tests the position of the childs did not change when changing the position of their parent, that was at least what i expected would/should happen to ease the work with "staked" views, while for example aligning the parent to other positions on the game screen, without handling the child views separately.
I assume the parent child relation is only there for accessing reasons, so to have this desired feature(relative movement,"gluing child views onto their parent") I would have to implement it myself, yes?

I also did not get the ViewPtr_SetMargin function to work, how can I leave the parent parameter to be "null" so the screen would be used? I tried 0 and even MEM_ReadInt(screen) but the view is gone after the usage of this function.

I am also a bit confused, what is the difference between a pointer and a handle in my imagination both are somekind of pointers but not the same? When should I use which one?

What does this "_^()" do exactly?

lot of dump questions

Thank you for all your efforts and time =)

Greetz

[Lehona]

Yeah the comparison picture is not the best choice, indeed cause I experimented with other Alpha functions at that moment too.

What did I do: I just used the basic implementation of the bars.d you provided with LeGo.

I noticed it looks different even at nearly the same size as the original HP Bar.
So I was wondering why, cause it should be the same texture.

On Further investigation (zooming in^^) I noticed that the "original" Bar consist of 3 views meaning there is the Bar_TempMaxBar texture between the bar tex and the back tex. Also the offsets don't look the same on the bottom and the top as in your implementation. So I think the textures are actually the same and the alphafunc used are also the basic ones and the difference comes from the additional middle texture, which is half transparent in the middle and has a black border around it, which gets covered by the actual bar texture if it is full and the slightly uneven offsets on the bottom and top.

Now my new Bars look almost like the original. =)

Does that mean you have an extended version (or something on top) of Bars.d? In that case it would be great if we could integrate that into LeGo, so everyone's bars will look slightly closer to the original bars - or you could post your script without integrating it into LeGo

Concerning the float thing:
"userFloat[0]" I only found this kind of option for the menu sliders and I would prefer integer values. But now I have a Choice instead of a slider, which works fine with integers.

Further digging into the float.d (again) helped me to get the answer I was looking for; so I assume the float value form the "options slider" which will be write into the ini can be converted into an ikarus float with castToIntf for further calculations?

I don't know a lot about menu stuff, but casting a type-level float to an "integer-float" is indeed done by that function.

I was also wondering, whats purpose of the childs of views. In my tests the position of the childs did not change when changing the position of their parent, that was at least what i expected would/should happen to ease the work with "staked" views, while for example aligning the parent to other positions on the game screen, without handling the child views separately.
I assume the parent child relation is only there for accessing reasons, so to have this desired feature(relative movement,"gluing child views onto their parent") I would have to implement it myself, yes?

As far as I can remember, child views are positioned relative to their parent views. I don't think this "feature" is used by LeGo in any way, though, so I can't really prove it without writing code for it. Maybe I'm just thinking of zCViewText (i.e. lines of text) which are positioned relative to the parent.

I also did not get the ViewPtr_SetMargin function to work, how can I leave the parent parameter to be "null" so the screen would be used? I tried 0 and even MEM_ReadInt(screen) but the view is gone after the usage of this function.

I never really understood the Margin-stuff, because Gottfried wrote them on his own for his own project/problem. The screen is just another view, though, so you probably don't want the parent to be null. Edit: I just looked at the implementation, I get what you're saying now. 0 would indeed be the correct choice. You could also try setting MEM_Game._zCSession_viewport as the parent.

You seem to have an idea what those functions are about, I'm sure people would find it helpful if you could write a very short explanation for them so I could add that to the wiki.

I am also a bit confused, what is the difference between a pointer and a handle in my imagination both are somekind of pointers but not the same? When should I use which one?

They are the same thing conceptually, yes. A pointer is directly tied to the hardware, i.e. it directly identifies where the data is stored in your RAM.* This is a problem, because that memory gets erased when you e.g. close Gothic. Even if the data gets saved into a savegame and then after restarting is loaded into memory again, it will be at a different address, thus the previous pointer is now pointing nowhere (and will crash if you try to access it).

Handles are simply an extra "step" in the middle. Using the handle, LeGo can use an internal table to look up what pointer belongs to that handle. After loading the data from the savegame, LeGo simply updates the table with the new pointer, so the modder can use the handle to refer to the data without caring about implementation details such as closing Gothic.

What does this "_^()" do exactly?

lot of dump questions

Thank you for all your efforts and time =)

Greetz

If you have used a language like C or C++ before, it's simply the *-operator. If you have not: Every value is located somewhere in RAM - that is true for simple values such as an integer, but it is especially true for complex values such as an Npc (oCNpc). If you declare a variable [tt]var oCNpc npc;[tt], it is "empty" or "null". With _^() you can assign this variable a memory location (that only works for complex values, though).

Originally this function was available in Ikarus as MEM_PtrToInst(ptr), but because it's so important, Sektenspinner gave it a second, very short name


*That's not quite true because all modern operating systems use virtual addresses, but you can think of it this way.

[blood4ng3l]

Does that mean you have an extended version (or something on top) of Bars.d? In that case it would be great if we could integrate that into LeGo, so everyone's bars will look slightly closer to the original bars - or you could post your script without integrating it into LeGo

Yes, also views.d but not finished and it might change again along the creation of my mod.

As far as I can remember, child views are positioned relative to their parent views. I don't think this "feature" is used by LeGo in any way, though, so I can't really prove it without writing code for it. Maybe I'm just thinking of zCViewText (i.e. lines of text) which are positioned relative to the parent.

For views it does not work that way or I tested it incorrectly. I assigned a view an owner, which should be then the parent, afaik, then moved the parent and child was still in place. Have to test it with text though.

I never really understood the Margin-stuff, because Gottfried wrote them on his own for his own project/problem. The screen is just another view, though, so you probably don't want the parent to be null. Edit: I just looked at the implementation, I get what you're saying now. 0 would indeed be the correct choice. You could also try setting MEM_Game._zCSession_viewport as the parent.

You seem to have an idea what those functions are about, I'm sure people would find it helpful if you could write a very short explanation for them so I could add that to the wiki.

Basically how I understand the function, you provide a view and a parent or size reference and then you specify margins on each side and the provided view will be resized as the reference but with the given margins "borders around" it. Thats at least what the code should do^^

Once I figured out how to use it correctly I can surly document it. I found it accidentally cause it is not mentioned on the wiki^^ Once I found it, I imagined it could make the bar creation a bit easier, but time will tell.

They are the same thing conceptually, yes. A pointer is directly tied to the hardware, i.e. it directly identifies where the data is stored in your RAM.* This is a problem, because that memory gets erased when you e.g. close Gothic. Even if the data gets saved into a savegame and then after restarting is loaded into memory again, it will be at a different address, thus the previous pointer is now pointing nowhere (and will crash if you try to access it).

Handles are simply an extra "step" in the middle. Using the handle, LeGo can use an internal table to look up what pointer belongs to that handle. After loading the data from the savegame, LeGo simply updates the table with the new pointer, so the modder can use the handle to refer to the data without caring about implementation details such as closing Gothic.

yeah okay have to dig myself eventually into the saving stuff but currently i am creating dynamically new bars as i need them so no saving necessary so far, i did not experiment with saving during framefunction exec of animations though,...everything is in prototype stage so far so I maybe coming back to you for some saving stuff or more advanced blending or aborting of animations like fadeout and size pulse.

If you have used a language like C or C++ before, it's simply the *-operator. If you have not: Every value is located somewhere in RAM - that is true for simple values such as an integer, but it is especially true for complex values such as an Npc (oCNpc). If you declare a variable [tt]var oCNpc npc;[tt], it is "empty" or "null". With _^() you can assign this variable a memory location (that only works for complex values, though).

Originally this function was available in Ikarus as MEM_PtrToInst(ptr), but because it's so important, Sektenspinner gave it a second, very short name


*That's not quite true because all modern operating systems use virtual addresses, but you can think of it this way.

So it simply dereferences the pointer? Man, this shortend coding style is horrible to read and comprehend, at least for me.

I will happily provided my extension code once its "stable"/refactored. But it might not fit into your style since i prefer more descriptive naming I am currently not sure if it is okay to change certain things in the LeGo Framework, since I am not sure about the implications which might come along with the change.
For instance: Is there any reason the class should be kept as minimal as possible, like game saving purposes?

For example I extended the bar class to carry more values, for certain reasons concering the dynamic nature of the bars in my mod. different Initial Positions and Sizes as reference for the animations. Not sure if I should extract that to be only in my mod or extend your framework.

Currently I am extending, so once I am happy with the result and before the extraction process I can show you, what I've done and you can decide?

Greetz and thnx for the infos =)


PS: Concerning Language, does communicating in english broaden the audience or narrowing it down?

[Lehona]

For views it does not work that way or I tested it incorrectly. I assigned a view an owner, which should be then the parent, afaik, then moved the parent and child was still in place. Have to test it with text though.

Views also have a list of childs (it's a zList, which is different to zCList and zCListSort - no idea how it works exactly), maybe that is more important than the parent.

yeah okay have to dig myself eventually into the saving stuff but currently i am creating dynamically new bars as i need them so no saving necessary so far, i did not experiment with saving during framefunction exec of animations though,...everything is in prototype stage so far so I maybe coming back to you for some saving stuff or more advanced blending or aborting of animations like fadeout and size pulse.

Everything created via new() will be saved automatically (because it returns a handle), that's the whole point

So it simply dereferences the pointer? Man, this shortend coding style is horrible to read and comprehend, at least for me.

It's still longer than *, so I'm not sure what exactly you are complaining about. It surely beats writing MEM_PtrToInst every time. The only other weird abbreviation is _@(), but that's just MEM_InstToPtr and I feel like is a very intuitive alias. new/get/getPtr/free/delete from PermMem are pretty descriptive, I think, and model C++ where possible.

I will happily provided my extension code once its "stable"/refactored. But it might not fit into your style since i prefer more descriptive naming I am currently not sure if it is okay to change certain things in the LeGo Framework, since I am not sure about the implications which might come along with the change.
For instance: Is there any reason the class should be kept as minimal as possible, like game saving purposes?

I don't really want to throw him under the bus, but Gottfried can be blamed for a lot of the weirdly short names Everything is saved as ASCII in our own format (horrible decision...), so the impact might be comparatively big, but everyone has huge harddrives so it doesn't matter. Just change whatever you think is worth changing and we will discuss the PR/diff if necessary.

For example I extended the bar class to carry more values, for certain reasons concering the dynamic nature of the bars in my mod. different Initial Positions and Sizes as reference for the animations. Not sure if I should extract that to be only in my mod or extend your framework.
Currently I am extending, so once I am happy with the result and before the extraction process I can show you, what I've done and you can decide?

Just send a PR once you're happy with (some of) your changes

PS: Concerning Language, does communicating in english broaden the audience or narrowing it down?

I personally don't care and LeGo development seems to be a lot more international than other topics in this forum.

[N1kX]

I found that starting from version 2.3.2 and higher, loading of a new location with the package Union ceases to work in my mode; when I roll back to version 2.3.0b, it works with Union. Has anyone tested their mods with the package Union? How is it going? The ikarus version does not affect, I tried both the last and the old, it works in all. The dilemma is to make a mod with support Union but with bugs (there is not always an inscription of the B_LogEntry function) or the last 2.6.0 but without support Union.
I can’t even establish the cause of the freeze, when I enter the trigger point of the world change, the game just crashes without error.
And GothicStarter_mod.exe simply does not start along with zspy to try to find the error...

[pawbuj]

I have following problem in attached code. This is used for NPCc who have nothing to say. Instead of starting dialog with "ENDE" decription to used to say "Not Now". the problem is some NPCs f.e. Drax or Fletcher can not start dialogues. Can anybody looks into this? This was pasted into beginning of B_ASSESSTalk

if (Npc_GetPermAttitude(self, hero) == ATT_HOSTILE)
    {
        return;
    };
    var C_Npc her;
    var C_Npc rock;
    
    //extra_refusetalk ();//from Fawkes 8.02.2019r. 
    //---

    var int infoCount;
    infoCount = oCInfoManager_GetInfoCount (self, other);
    
    if (infoCount == 0)&&(self.npcType == npctype_main)
    {
        B_SayOverlay (self, other, "$NOTNOW");
        Print ("");
        return;
    };


    if (infoCount == 1)
    {
        var int infoPtr;
        infoPtr = oCInfoManager_GetInfo (self, other, 0);
        
        if (infoPtr)
        {
            var oCInfo dlgInstance;
            dlgInstance = _^ (infoPtr);
            
            if (Hlp_StrCmp (dlgInstance.description, DIALOG_ENDE))&&(self.npcType == npctype_main)
            {
                B_SayOverlay (self, other, "$NOTNOW");
                Print ("");
                return;
            };
        };
    };

[Lehona]

2.3.0 (and 2.3.2) are really old versions, more than 4 years old. There have been various rewrites and overhauls of which any could be the cause. Without some more information about the crash I'm afraid I won't be able to fix it. If you attach a debugger to Gothic (such as via the free version of IDA), maybe you could attain a stacktrace from the crash?

Also consider talking to the Union developers, they might know more


Edit: @pawbuj: Please clarify your description. When you talk to (interact with) e.g. Drax, what happens? Just nothing? In that case: Make sure the code you posted is actually the problem, e.g. via filling in those print statements that are currently just empty strings. Do they appear on the screen? Does it work if you remove that code? B_SayOverlay does not seem to be a function that exists in the original scripts, so you should post that too. Please make sure to indent your code correctly (it is currently indented incorrectly). Does this even have to do anything with LeGo? If not, consider making a new thread.

[pawbuj]

@Lehona the easiest way to explain my request is I need a working condition to check if NPC has no any dialogues options (well without of course ENDE), rest it should be pretty easy to create.

[Milky-Way]

@Lehona the easiest way to explain my request is I need a working condition to check if NPC has no any dialogues options (well without of course ENDE), rest it should be pretty easy to create.

Some old code that might or might not have worked:

// new dialogues
        if (1) && (Npc_CheckInfo(oth,0)) {
            if (1) && (Npc_CheckInfo(oth,1)) {
                col = Focusnames_Color_Neutral();
            };
        }

(which we used with LeGo Focusnames, thus the setting of the color)

[F a w k e s]

Drax or Fletcher can not start dialogues

Not really a LeGo issue

This topic is quite complicated - you have to re-think a lot of dialogs which you have.

At the moment your B_AssessTalk is checking number of available dialogs for NPC - if it is only 1 and if dialog description says 'ENDE' NPC will not talk to player. Sounds easy ...

However in case of Fletcher (same applies for more NPCs) - his vanilla G1 dialogs are available only under specific circumstances - when you start game - in-game time says 8 am and if you want to talk with him - when B_AssessTalk script will run - his only available dialog is 'ENDE' - look below:

INSTANCE DIA_Fletcher_EXIT(C_Info)
{
    npc = GRD_255_Fletcher;
    nr = 999;
    condition = DIA_Fletcher_EXIT_Condition;
    information = DIA_Fletcher_EXIT_Info;
    important = 0;
    permanent = 1;
    description = DIALOG_ENDE;
};

func int DIA_Fletcher_EXIT_Condition()
{
    return 1;                //Only available dialog is DIALOG_ENDE - B_AssessTalk will force NPC to tell you Not Now
};

func void DIA_Fletcher_EXIT_Info()
{
    AI_StopProcessInfos(self);
};

INSTANCE DIA_Fletcher_First(C_Info)
{
    npc = GRD_255_Fletcher;
    nr = 1;
    condition = DIA_Fletcher_First_Condition;
    information = DIA_Fletcher_First_Info;
    permanent = 0;
    important = 1;
};

func int DIA_Fletcher_First_Condition()
{
    if (Wld_IsTime (0,0,6,0))        //This dialog is availale only in the early morning midnight - 6 am
    {
        return 1;
    };
};

func void DIA_Fletcher_First_Info()
{
};

INSTANCE DIA_Fletcher_Hello(C_Info)
{
    npc = GRD_255_Fletcher;
    nr = 2;
    condition = DIA_Fletcher_Hello_Condition;
    information = DIA_Fletcher_Hello_Info;
    permanent = 0;
    important = 1;
};

func int DIA_Fletcher_Hello_Condition()
{
    if (Npc_IsInState (self, ZS_Talk))    //This dialog is only available if you are in ZS_Talk - which you wont be since B_AssessTalk wont let you in !
    {
        return 1;
    };
};

func void DIA_Fletcher_Hello_Info()
{
};

In case of Drax - I don't see anything obvious atm - you will probably have to paste his whole dialog (ideally into a new thread).
Also when testing make sure you press 'T' when looking at NPC - this will show you their active perceptions. Might be you disabled PERC_ASSESSTALK by mistake somewhere in a routine code.

In my case I ended up disabling this 'feature' - it was far too complicated for me to even think about it.
In my B_AssessTalk.d I commented it out. I am only checking if NPC has 0 dialogs - in that case I wont let player talk to NPC:
edit: I completely disabled it ... had a situation in which unless NPC is in ZS_Talk there is no dialog option - in this case NPC didn't talk to me at all.

/*
    var int infoCount;
    infoCount = oCInfoManager_GetInfoCount (self, other);
    
    if (infoCount == 0)
    && (self.npcType != npctype_ambient)
    && (self.aivar [AIV_PARTYMEMBER] == FALSE)
    {
        B_SayOverlay (self, other, "$NOTNOW");
        return;
    };
    
    if (infoCount == 1)
    && (self.npcType != npctype_ambient)
    && (self.aivar [AIV_PARTYMEMBER] == FALSE)
    {
        var int infoPtr;
        infoPtr = oCInfoManager_GetInfo (self, other, 0);

        if (infoPtr)
        {
            var oCInfo dlgInstance;
            dlgInstance = _^ (infoPtr);

            if (Hlp_StrCmp (dlgInstance.description, DIALOG_ENDE))
            {
                B_Msg_Add ("1 dialog");
                B_SayOverlay (self, other, "$NOTNOW");
                return;
            };
        };
    };
*/

[blood4ng3l]

Heyho,

I would like to access the currently selected item in the inventory, to display the impact of the item to the HP/Mana of the hero once used.

As i understood the instances like hero defined in content/_intern/classed.d, which is the NPC instance of the player, I had assumed that item would be the same just for the currently selected item in the inventory. But it seems not to be the case. It is always an empty instance, as far as spy informs me corretly.

Then i tried different Engine Functions:

//oCItem * __fastcall oCViewDialogInventory::GetSelectedItem(void)   	0x00689110	0	6
const int oCViewDialogInventory__GetSelectedItem = 6852880;   	//0x00689110	// HookLen:	6
//virtual oCItem * __thiscall oCItemContainer::GetSelectedItem(void)   	0x007092C0	0	5
const int oCItemContainer__GetSelectedItem		 = 7377600;   	//0x007092C0	// HookLen:	5

HookEngine(oCViewDialogInventory__GetSelectedItem, 6, "B4DI_oCViewDialogInventory_GetSelectedItem");
HookEngine(oCItemContainer__GetSelectedItem, 5, "B4DI_oCItemContainer_GetSelectedItem");

func void B4DI_oCViewDialogInventory_GetSelectedItem(){
	MEM_Info("B4DI_oCViewDialogInventory_GetSelectedItem");
	var oCItem selectedInvItem; selectedInvItem = MEM_PtrToInst(EAX);

	B4DI_debugSpy("B4DI_ITEM_is: ", selectedInvItem.name);
};

func void B4DI_oCItemContainer_GetSelectedItem(){
	MEM_Info("B4DI_oCItemContainer_GetSelectedItem");
	//var oCItem selectedInvItem; selectedInvItem = MEM_PtrToInst(EAX);
	//var oCItem selectedInvItem; selectedInvItem = CALL_RetValAsStructPtr();

	//B4DI_debugSpy("B4DI_ITEM_is: ", selectedInvItem.name);
};

B4DI_oCViewDialogInventory_GetSelectedItem does not get called at all, as far as my experimentation got.

B4DI_oCItemContainer_GetSelectedItem gets called right after a load game, constantly while in inventory and always when an item gets picked up. So this might not be the function i am looking for.
Besides my attempts (commented out) to get the return value of the hookedFunction lead to crashes.

Is this even the correct way to get return values of hooked functions? I recently learned that the ECX Register contains the "this_caller" so i assumed that EAX might contain the return value?

Does anybody has experiences worth sharing about this topic?

Thank you =)

Greetz

blood4ng3l