Portal-Zone Gothic-Zone Gothic II-Zone Gothic 3-Zone Gothic 4-Zone Modifikationen-Zone Download-Zone Foren-Zone RPG-Zone Almanach-Zone Spirit of Gothic

 

Page 15 of 15 « First ... 481112131415
Results 281 to 293 of 293
  1. View Forum Posts #281 Reply With Quote
    Abenteurer
    Join Date
    Aug 2018
    Posts
    71
     
    N1kX is offline
    I tried to watch print Lego, interested in the question. Why does the y position not change
    Code:
    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

  2. View Forum Posts #282 Reply With Quote
    Dea
    Join Date
    Jul 2007
    Posts
    10,153
     
    Lehona is offline
    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?

  3. View Forum Posts #283 Reply With Quote
    Abenteurer
    Join Date
    Aug 2018
    Posts
    71
     
    N1kX is offline
    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
    Last edited by N1kX; 11.08.2019 at 15:35.

  4. View Forum Posts #284 Reply With Quote
    Dea
    Join Date
    Jul 2007
    Posts
    10,153
     
    Lehona is offline
    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.
    Last edited by Lehona; 11.08.2019 at 19:31.

  5. View Forum Posts #285 Reply With Quote
    Abenteurer
    Join Date
    Aug 2018
    Posts
    71
     
    N1kX is offline
    Quote Originally Posted by Lehona View Post
    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.

  6. View Forum Posts #286 Reply With Quote
    Lehrling blood4ng3l's Avatar
    Join Date
    Sep 2009
    Location
    Berlin
    Posts
    34
     
    blood4ng3l is offline

    Question Accessing "var int array[5] with a var int variable - not possible? "expected integer constant

    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)

    Code:
    ----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

  7. View Forum Posts #287 Reply With Quote
    Sword Master
    Join Date
    Aug 2009
    Location
    Hessen
    Posts
    732
     
    Cryp18Struct is online now
    You can use the ikarus function MEM_ReadStatArr to read from an array with a variable index.

  8. View Forum Posts #288 Reply With Quote
    Lehrling blood4ng3l's Avatar
    Join Date
    Sep 2009
    Location
    Berlin
    Posts
    34
     
    blood4ng3l is offline

    Color Difference

    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=893b461a39a7aa449edb8944e2889644&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 =)

  9. View Forum Posts #289 Reply With Quote
    Dea
    Join Date
    Jul 2007
    Posts
    10,153
     
    Lehona is offline
    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.

  10. View Forum Posts #290 Reply With Quote
    Lehrling blood4ng3l's Avatar
    Join Date
    Sep 2009
    Location
    Berlin
    Posts
    34
     
    blood4ng3l is offline
    Quote Originally Posted by Lehona View Post
    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. =)


    Quote Originally Posted by Lehona View Post
    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
    Last edited by blood4ng3l; 15.08.2019 at 22:10.

  11. View Forum Posts #291 Reply With Quote
    Dea
    Join Date
    Jul 2007
    Posts
    10,153
     
    Lehona is offline
    Quote Originally Posted by blood4ng3l View Post
    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

    Quote Originally Posted by blood4ng3l View Post
    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.

    Quote Originally Posted by blood4ng3l View Post
    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.

    Quote Originally Posted by blood4ng3l View Post
    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.

    Quote Originally Posted by blood4ng3l View Post
    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.

    Quote Originally Posted by blood4ng3l View Post
    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.

  12. View Forum Posts #292 Reply With Quote
    Lehrling blood4ng3l's Avatar
    Join Date
    Sep 2009
    Location
    Berlin
    Posts
    34
     
    blood4ng3l is offline
    Quote Originally Posted by Lehona View Post
    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.

    Quote Originally Posted by Lehona View Post
    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.

    Quote Originally Posted by Lehona View Post
    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.

    Quote Originally Posted by Lehona View Post
    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.

    Quote Originally Posted by Lehona View Post
    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?

  13. View Forum Posts #293 Reply With Quote
    Dea
    Join Date
    Jul 2007
    Posts
    10,153
     
    Lehona is offline
    Quote Originally Posted by blood4ng3l View Post
    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.

    Quote Originally Posted by blood4ng3l View Post
    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

    Quote Originally Posted by blood4ng3l View Post
    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.

    Quote Originally Posted by blood4ng3l View Post
    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.

    Quote Originally Posted by blood4ng3l View Post
    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

    Quote Originally Posted by blood4ng3l View Post
    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.

Page 15 of 15 « First ... 481112131415

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
Impressum | Link Us | intern
World of Gothic © by World of Gothic Team
Gothic, Gothic 2 & Gothic 3 are © by Piranha Bytes & Egmont Interactive & JoWooD Productions AG, all rights reserved worldwide