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 - argoon

Pages: [1] 2 3 ... 18
1
That is one of the idtech 4 games with the most complex gui's I've seen, how the hell was he able to do that with so few GUI tutorials? He sure is a good coder no doubt about it, btw i would kill to know how he made the drag&drop functionality for his gui's, is one of the things that i would love to have.

why don't you get in touch with the dev and ask ?

I already did waiting on a reply.

2
That is one of the idtech 4 games with the most complex gui's I've seen, how the hell was he able to do that with so few GUI tutorials? He sure is a good coder no doubt about it, btw i would kill to know how he made the drag&drop functionality for his gui's, is one of the things that i would love to have.

3
id Tech 4 Engine Coding / Re: Getting var values from GUis?
« on: September 30, 2017, 09:04:47 AM »
I tought about your inventory mod and how to realize it.

Can you describe the main algorithm?

Let say:

1. Allocate window in pda.
2. Draw grid, split to units (cells).
3. Fill cells with items indexes based on some items inv. parms.
4. If receive onAction from window then convert mouse coords to cells.
5. Read index (item id) from target cell.
6. Do action.

Something like this?

First i must say i'm not using the Doom 3 pad gui script at all, mine is totally new, but is more or less that, I don't convert mouse coords to the cells location tho, I just set a "gui::Slot_id" var to a number corresponding to the array index that i know a priory that gui slot belongs to, in that way i can go directly to the array index instead of doing a search, I don't know if this is a good way to do it but it works. :)

4
id Tech 4 Engine Coding / Re: Getting var values from GUis?
« on: September 29, 2017, 07:46:50 AM »
Is official i'm dumb, it was right there in front of my face and i just didn't see it, to "get" values from gui's is just how to "set" values from gui's... just use - set "gui::varname" "value".  :-[

After doing that i was able to retrieve the value.

So this means all other vars in a gui file that don't use the gui::varname system are only visible in the gui scope. I mean they seem to be invisible to anyone outside the GUI file.

   

5
id Tech 4 Engine Coding / Re: Getting var values from GUis?
« on: September 29, 2017, 06:06:48 AM »
Well, we can easy get/set entity's keys.
Is it necessary to store info about ltem location in gui parm?

You are certainly right but I want to do this for performance reasons, reading strings from the entities def file and convert them to float for example,  is very performance heavy,  even id recommended not doing that to much, and I will have plenty of information on my inventory to be reading it all from the player def file, but if I have no choice then I will do that.

6
id Tech 4 Engine Coding / Re: Getting var values from GUis?
« on: September 29, 2017, 05:04:02 AM »
If you can't get the value how do you know you are actually setting it? Neither get or set state functions will inform you if are trying to read or write to a variable that can't be found or doesn't exist. Are you sure your variable can be found?

Hello Phrozo thanks for the reply,  I'm really not sure of anything, I'm still learning this stuff, because gui scripting tutorials are so scarse, I'm learning by trial and error, the only thing I'm sure of, is that when inspecting the gui in the visual studio watch window, I see that at lest the variable name I wrote in the gui desktop is there.

In the case of set, at lest for variables using "gui::varname" I know I'm setting the values from the c++ side  because they work, for other vars I never really tried, I've used namedEvents for the most part,  never tried to "get" a variable value back from the gui.

I also see that Id almost never used GetStateInt or others like it, so perhaps I'm just not thinking this in the right way, but for now I can't see how I could make what I'm trying to make without retrieving a var value from the gui.

Tell me, what would you do, if you add a inventory system where you have a grid based look and you assign different items to each slot (this part already works fine),  the "grid" in the c++ side is just a array of structs, with info like, slot ID, what item is in what slot, a icon path, a item counter per slot, etc, ( I use namedEvents and gui::varname,  to assign the right info to the right "slot"  in the gui file), but then you wanted to have the ability to click in a particular slot (onAction) and have that affect the right array index in the c++ side?

I know I can use set "some cmd name", by using the "handle single gui cmds" function from the player.cpp, like id did but for that, I think I need to do different cmd's to every item in the inventory, if they happen to be in different slots, for example, if I wanted to remove a key from slot 1 in the inventory,  I would need to do,  a remove key1 function,  do another function to remove key2 from slot 2, etc, instead of the a single -  set "removeItem"  function and have that remove the right item from the right gui slot and the right array index. Why I think so?  Because afaik there's no way to tell the c++ code in what window a particular onAction was triggered without using variables ?

Again I may be thinking all this wrong (most likely) and there's a simple way to do that I'm just ignorant about.

AFAIK this works like entity -> somegui -> parm. Then parm is for entity, not for gui itself (not sure about pda gui, perhaps the player is that entity).

That is right and for the pda gui the player is indeed the entity, the pda gui is called from the player def file, still don't know how this can help me, do I need to define the var with gui::varname for "get" like I do for set ? Not near my pc so can't test.

7
id Tech 4 Engine Coding / Getting var values from GUis?
« on: September 28, 2017, 04:07:16 PM »
Hello guys i know that i can set a variable value in a GUI from the engine code using for example somegui->SetStateInt("varName"); and it works fine, but i can't seem to do the inverse, get a value from a gui variable to the game code, i tried using the somegui->GetStateInt("varName"); but it returns zero every time, no matter to what value i set the GUI variable.

what i'm trying to do is create a grid based inventory system, and when i click in a "slot" i tell the c++ code what slot i interacted with.

8
id Tech 4 Needs Help / Re: how i can spawn models in map ?
« on: September 08, 2017, 03:56:54 PM »

9
id Tech 4 Scripting / Re: Zooming by run loop script
« on: September 03, 2017, 11:14:48 AM »
A while (1) loop is in it self a infinite loop unless you break from it, so be free to use sys.wait(1), btw a frame takes less than a second to run, if you open the doom_defs.script you will see that id software defined a frame time as 0.016 seconds (16 milliseconds), and i seam to recall that if you make a sys.wait() with less than 0.016 your loop will stop working.

About performance by using "thread" keyword before the function name you are making sure the loop doesn't clog the pipeline, also unless your loop is made of very complex chain's of if else's and many entity spawn arguments queries, like using many getkey() etc, than performance eating imo is not that bad, plus you should try to break from a while(1) loop ( break; ) if possible, unless it is required to run for the entirety of the game or map.

10
id Tech 4 Textures / Re: Another Material Question
« on: September 03, 2017, 10:44:33 AM »
models/mapobjects/tablecart1ball

This is the object that I want it to apply to. When you say player script, you mean doom_main.script? There's no player.script. Is this all 1 set of instructions or 2 ways of doing it?

That isn't a object, its a material. That script won't help you without one.

So much for that...

Materials are attached to objects, deform sprite also rotates the object not the material itself plus deform sprite requires models made of a single flat face (a plane), wheres my script works with any object.
You need to find, using the editor, all the objects using that material, Dark Radiant (from the DarkMod) has a option where it will select all objects using the same material, with all selected you can assign the key value, i suggested, to all of them at the same time.

11
id Tech 4 Scripting / Re: Zooming by run loop script
« on: September 02, 2017, 05:14:41 PM »
I trying to achieve a sniper zooming effect via 'g_fov' CVar.

It's realized via level script but as I think same algorithm can be used in weapon script.

The example below is works but from time to time g_fov is not set correct (stays in previous state or sets several times in one pass).

I thing it's because cycle checks is too fast.

Has anyone idea how to fix it?

Thanks.

Code: [Select]
void    debug_print()
        {
        sys.println( "^3g_fov set to: " + sys.getcvar( "g_fov" ) + " ^5at:" + sys.getTime() + "sec" );
        }

void    pressed_fov()
        {
        float userbuttons, btn2;                      // inspired by modwiki

        boolean already_set = ( false );              // each second "Z"-press will reverse this flag and reset g_fov

            while(1)
            {
            userbuttons = $player1.getButtons();
            btn2 = 4 & userbuttons;                   // 0000 0100 & 0000 0100 = true

              if(btn2)                                // 'Zoom' was pressed
                {
                     if( already_set )                // is it second press?
                     {
                        sys.setcvar( "g_fov", "90" );
                        already_set = !already_set;
                        debug_print();
                        sys.waitFrame();
                     }
                     else
                     {
                        sys.setcvar( "g_fov", "10" );
                        already_set = !already_set;
                        debug_print();
                     }
                }
            sys.waitFrame();
            }
        }

void main()
        {
        thread pressed_fov();       // always run when level is loaded
        }

I don't know but it could be because getbuttons runs more than one time at button press(was made for continuous pressing like shooting), no matter how fast you press it, so that perhaps is messing things up, before i add full access to impulses (they run only one time) this also caused many problems to me, you need to find a way to make the code run only one time at button press, unfortunately that is easier said than done.

12
id Tech 4 Textures / Re: Another Material Question
« on: September 02, 2017, 09:44:19 AM »
Btw when I try to replace 'while(1)' to 'eachFrame' (for level script) I get an error "Built-in function can't be used without an object".

Hum I didn't knew that was locked to objects only, need to study why, I'm working on engine c++ so have not scripted any level for a while now.
I'm not near my computer tho so will see later, for now continue using while loop for level scripting as always, sorry.

Try sys.eachFrame

sys is indeed a object but eachframe that I recommend is not a c++ function, callable by sys, is just a script macro made using #define, it is written at the bottom of the doom_defs.script if I'm recalling correctly.


models/mapobjects/tablecart1ball

This is the object that I want it to apply to. When you say player script, you mean doom_main.script? There's no player.script. Is this all 1 set of instructions or 2 ways of doing it?

That isn't a object, its a material. That script won't help you without one.

Exactly my script needs to be assigned to a entity in the editor or on a def file, it has no knowledge of materials it will only change the yaw (rotation) of a object no matter the materials on its surface.



bitterman add a thought, I assume you're calling your map script from within the map folder, using the script with the map name next to the map file,  perhaps that is why it doesn't work, if you open the script folder you see Id software put map scripts there as well, and call them from the doom_main.script just like with objects. The difference with this method is that you need to enclose your script code inside a "use namespace mapname" or all function/variables names will conflict with each other.

13
id Tech 4 Textures / Re: Another Material Question
« on: August 31, 2017, 09:27:19 PM »
argoon thanks for your posts.

Сan I ask a few questions about example above?

1. What is the expression '#ifndef' (it's not about general purpose, it's about D3 scripting)?

2. If entity on the map have a scriptobject and init() as described above then it (init) will be start at start of level? IMO this is not typical behavior for level script wich must be placed in /maps, not in /script.

Those are called pre-processor keywords on c and c++, they are special keywords that are run before the script compiler, they are used by script engine to create macros and Global variables, etc. In this case i'm defining _LOOK_AT_  before compilation so any variable i put inside this script doesn't conflits with variables with the same name on other script files.  Is akin to using the:  "using namespace mapname" keyword for map scripts.

About the second question, this is not a map script, this is a object script and those go on the script folder, init() in a object script is just like constructors in c++, so any function inside init() will run at the exact moment the entity (object) spawns in the game, it can be at level start or not.

Quote
You mention the entity and the map, but it's not a single entity but rather all instances of a material I need it to work on, and that's on any map.

object scripts run on any map the object exists, because they are called by the entities them self's at spawn time.

To know more about this i recommend that you guys read about OOP programming (Object Oriented Programming).   

14
id Tech 4 Textures / Re: Another Material Question
« on: August 31, 2017, 08:21:21 AM »
There is a player script, look carefully, is not called player.script but has player written on its file name. ;)

Imo what i wrote is very explicit, but maybe is because i wrote it, and others maybe have problems reading it, i don't know, ok what i posted was two ways for doing this, one (bad way) from the player script side and one where you make a new script.

15
id Tech 4 Textures / Re: Another Material Question
« on: August 30, 2017, 05:34:37 PM »
For this particular function you need to put it on the player script.

Like this.

on the player script inside the player object write:

void lookAtPlayer( entity ent );

then outside the player object, below the Init() function write the function i posted, btw put the code inside the lookAtPlayer function, the one inside the {},
inside the following code:

eachFrame { past the code here }

then inside the player Init() function write this:

thread lookAtPlayer($entityName);    // entityname is the name of the object you want to always look at the player;

and that's it.

There's a serious problem with this code tho, because it runs from the player script side, unfortunately makes it very complex for multiple objects, this way you need to write "thread lookAtPlayer($entityName);" for every single object you want to always look at the player! Not pretty.

But if you make it run from the object script instead (if it has one), then you just need to pass in the player ($player1) to a single look at function and multiple objects (of that type) will then look at the player just fine.

I recommend that you learn how to script is very important if you want to make more complex modifications to the game.
But for now, here is a small tutorial in how to create a new BASIC game object script, hope this make you want to learn more:

1 - inside the scripts folder create a new txt file

2 - rename it to lookAt and change the .txt extension to .script

3 - inside the script file past the following code:

Code: [Select]
#ifndef _LOOK_AT_
#define _LOOK_AT_

object lookAT {


vector plAngles;

entity player;


void init();
void lookAtPlayer();
};

void lookAT::init()
{
player = $player1;

        thread lookAtPlayer();
}


void lookAT::lookAtPlayer()
{
      eachFrame
      {
           plAngles = player.getViewAngles();

   plAngles_x = 0;
   plAngles_y = plAngles_y + 90;
   plAngles_z = 0;
   self.setAngles(plAngles);
      }
}
#endif


5 - open the doom_main.script

and past the following code after the ai_base script

Code: [Select]
#include "script/lookAt.script"

6 - open the editor, select the entity you want the script to run on

8 - write the following key value par:

key - scriptobject
value - lookAT

9 - Run the map
 

Pages: [1] 2 3 ... 18