Jump to content
The Dark Mod Forums

Script object fetch of inventory item count?


Geep

Recommended Posts

I'm working up a wiki article on how to create a custom inventory GUI with script object. This involves an example that extends the "skull on pedestal altar" that Fidcal provided in the existing "Inventory" article. My code (.script and .gui) is working, except I'm trying to figure out how to get the inventory item count maintained by the SDK. There's no getCurInvItemCount function. What I've tried in the script object is:

      entity curEnt = userEntity.getCurInvItemEntity();
      s = curEnt.getKey("inv_stackable");
      if(s == "1")
      {
         s = curEnt.getKey("inv_count");
         msg = "inv_count = " + s;
         sys.println(msg);
         float count;
         count = sys.strToInt(s);
         if(count > 0) {
             setGuiInt(overlayHandle, "Inventory_ItemStackable", 1 );
             setGuiInt(overlayHandle, "Inventory_ItemCount", count );
         }
      }

      else
      {
       setGuiInt(overlayHandle, "Inventory_ItemStackable", 0 );
       setGuiInt(overlayHandle, "Inventory_ItemCount", 0 ); // not strictly required
      }

But really, "inv_count" is not the right thing, that's just a static count of how many instances to acquire in one frob.

It appears I could maintain my own count in the script object, using a file global variable, but how would I detect when an object is dropped? I see problems keeping that count valid. Not helped by having a function to force a change to SDK's count, but no way to read SDK's count.

Or is all this just a known limitation, and inventory items with custom GUIs can't be stackable?

Link to comment
Share on other sites

The amount of the currently selected, stackable inventory item is stored in the gui variable "gui::Inventory_ItemCount". You don't have to set this manually, the sdk handles this for you. The only thing a scriptobject for such an item has to do is to perform the desired action on use and reduce the count by one.

I would suggest that you take a look at the scriptobject of stackable items and the hud gui to see how it is setup.

FM's: Builder Roads, Old Habits, Old Habits Rebuild

Mapping and Scripting: Apples and Peaches

Sculptris Models and Tutorials: Obsttortes Models

My wiki articles: Obstipedia

Texture Blending in DR: DR ASE Blend Exporter

Link to comment
Share on other sites

I thought, from looking at some of the code in Player.cpp, that gui::Inventory_ItemCount is handled by the sdk ONLY when the default inventory gui is used; once you specify a custom gui, then your script object becomes responsible for setting gui::Inventory_ItemCount. Am I wrong?

BTW, as context, my topic is now posted to the wiki, as "GUI Scripting: Inventory Icon Example". But nothing about stackable and count yet.

Link to comment
Share on other sites

Ah, now I see what you mean. My approach always was to override existing files, so I never came to the idea of doing it like that. But if the game allows items to tell the engine to use a different gui, then it should either provide the informations independent from the gui used or an alternative access (like a script function).

From what I've seen in the code it seems indeed to be the case that the desired behaviour is not done by the sdk, probably as said one can't know which gui variables exist and which not. The question is whether under that circumstances it is the best way to use the stackable entity type in combination with a custom gui (the fact it is stackable is more an abstract concept, the player doesn't really have several instances of an item)?

Maybe I can figure out something.

  • Like 1

FM's: Builder Roads, Old Habits, Old Habits Rebuild

Mapping and Scripting: Apples and Peaches

Sculptris Models and Tutorials: Obsttortes Models

My wiki articles: Obstipedia

Texture Blending in DR: DR ASE Blend Exporter

Link to comment
Share on other sites

It may be that for now, the guidance in my wiki article should be to not make the entity stackable if planning a custom inventory GUI. And maybe put in a feature request to the bugtracker to add a getCurInvItemCount() function, for the future.

Unless you find a short-term workaround.

Link to comment
Share on other sites

I'll also expand the writeup to include the alternative you note, to just override the default gui and not use a custom inventory script object. That would work particularly well if you wanted to affect the appearance of just about all inventory items in the same way. Otherwise, you'd have to code the GUI to recognize those items you wanted to treat specially.

Link to comment
Share on other sites

5 hours ago, Geep said:

And maybe put in a feature request to the bugtracker to add a getCurInvItemCount() function, for the future.

I can add this script function either way as I am messing around with the code currently. But maybe the workaround makes this unnecessary.

  • Like 1

FM's: Builder Roads, Old Habits, Old Habits Rebuild

Mapping and Scripting: Apples and Peaches

Sculptris Models and Tutorials: Obsttortes Models

My wiki articles: Obstipedia

Texture Blending in DR: DR ASE Blend Exporter

Link to comment
Share on other sites

It would be good to have getCurInvItemCount for 2.11. The script object writer would also need to know if stackable is true/false. They could use the technique I showed above:

     entity curEnt = userEntity.getCurInvItemEntity();
      s = curEnt.getKey("inv_stackable");
      if(s == "1")

But if you wanted to spare that awkwardness, you could either:

- define another function, getCurInvItemIsStackable

- have getCurInvItemCount return -1 to mean "count is 1, non-stackable"

Link to comment
Share on other sites

Just thinking through your alternative method of overriding default inventory GUI. I don't think that's going to work in the case where you want the customization to just apply to 1 type of entityDef. Because you can't easily identify that type in the GUI:

- Doing string check of Inventory_ItemName or Inventory_GroupName (within a GUI if statement) is unreliable due to possible translations by the SDK

- You could set an "inv_item_id" string in the entityDef, but the SDK ignores that; there is no Inventory_ItemId defined.

☹️

Link to comment
Share on other sites

Regarding the script function I would assume that having one function only that returns -1 if the item is not stackable as you proposed makes the most sense.

I never thought of having different custom guis for different inventory items. I am not even sure what this could be useful for. I for one would be way to lazy to write several guis :D But in that case overwriting the existing gui file is indeed not going to work well.

FM's: Builder Roads, Old Habits, Old Habits Rebuild

Mapping and Scripting: Apples and Peaches

Sculptris Models and Tutorials: Obsttortes Models

My wiki articles: Obstipedia

Texture Blending in DR: DR ASE Blend Exporter

Link to comment
Share on other sites

  • 2 weeks later...

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Recent Status Updates

    • nbohr1more

      TDM 15th Anniversary Contest is now active! Please declare your participation: https://forums.thedarkmod.com/index.php?/topic/22413-the-dark-mod-15th-anniversary-contest-entry-thread/
       
      · 0 replies
    • JackFarmer

      @TheUnbeholden
      You cannot receive PMs. Could you please be so kind and check your mailbox if it is full (or maybe you switched off the function)?
      · 1 reply
    • OrbWeaver

      I like the new frob highlight but it would nice if it was less "flickery" while moving over objects (especially barred metal doors).
      · 4 replies
    • nbohr1more

      Please vote in the 15th Anniversary Contest Theme Poll
       
      · 0 replies
    • Ansome

      Well then, it's been about a week since I released my first FM and I must say that I was very pleasantly surprised by its reception. I had expected half as much interest in my short little FM as I received and even less when it came to positive feedback, but I am glad that the aspects of my mission that I put the most heart into were often the most appreciated. It was also delightful to read plenty of honest criticism and helpful feedback, as I've already been given plenty of useful pointers on improving my brushwork, level design, and gameplay difficulty.
      I've gotten back into the groove of chipping away at my reading and game list, as well as the endless FM catalogue here, but I may very well try my hand at the 15th anniversary contest should it materialize. That is assuming my eyes are ready for a few more months of Dark Radiant's bright interface while burning the midnight oil, of course!
      · 4 replies
×
×
  • Create New...