Geep

I'll test those new features when the 2.11 dev version that includes them becomes available through the tdm_installer.

I added bug report 6096, as a feature request for both getCurInvItemCount() and gui::Inventory_ItemId

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.

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"

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.

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.

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.

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?

In the Sleeping AI wiki article, I've replaced the "Known bugs" section at the end, discarding Fidcal's circa-2009 items, and putting in this problem and another relatively recent unsolved one from the bugtracker.

I just did a major rewrite of wiki's Bindings and User Settings. Twice the content, in tables now, organized to match the Settings/Controls submenus. Plus an intro. Eyeballs to find flubs appreciated, as always.

Sounds good. Since I'm only 2% sure what's going on here , I'll leave any wiki update about all this in your capable hands.

Agree with that, but I suppose there could be some backward compatibility issues if changing that behavior. BTW: Wiki wording changed RE controller on just 1 side of door

Yes, I read it as just citing an example. But I'll change the wording to be less ambiguous. Also, for I also would have thought that setting ai_should_not_handle on the secret door would still allow the AI to go through it if its open. But if not, and by design, then an easy workaround (once established) should be documented.

Just to understand, the outcome of this discussion (and bugtracker post) so far is that: - The wiki post is correct as is. "frobable" on the door IS considered by the AI. So if "frobable 0" and the door has a controller that accessible to the AI, the AI will use it. - except if fleeing, and that is a bug.

*crickets* Well, that question must of been too obscure. I'll come back to that, but first help me clear up GUI command "runscript", that could appear in an event handler code block. I'm going to claim, despite some engine C++ code to parse it, that - on purpose - this command no longer works in TDM. In either form, "runscript ..." or "set 'cmd' runscript...". If you know about this, please either agree with that claim, or provide a counter-example, such as a working test map or a pointer to an FM that successfully has a GUI file that uses runscript. Thanks!