Well, I like that you can have up to 8 cursors click on a hotspot and have a separate interaction trigger for each of them..
Hotspot1_Interact
Hotspot1_Look
ecc
Why can't we have more than 3 for inventory items?
Just Look Interact Talk (and other click and use inventory on inventory).
Well, I can't think of too many AGS games that go beyond Look, Interact and Select, and if one wants to use the other interactions, it's not too hard to script. I admit that it would make the IDE look more consistent, but there are other things I'd consider higher priority.
When was the last time you opened, pushed, repaired, scared, or talked to an inventory item? ;)
Quote from: Ghost on Tue 14/07/2009 20:29:27
Well, I can't think of too many AGS games that go beyond Look, Interact and Select, and if one wants to use the other interactions, it's not too hard to script. I admit that it would make the IDE look more consistent, but there are other things I'd consider higher priority.
When was the last time you opened, pushed, repaired, scared, or talked to an inventory item? ;)
Can you do it using only keyboard controls? and using runinteraction?
Both times, yes.
To use any cursor mode on an inventory item, you can check against the cursor mode in "other click". It's simple to make a keyboard shortcut to that.
Same with runInteraction- depending on the cursor mode you can *script* anything into that function, so that it contains the results of, say, open, push, pull and simmer.
Personally I'd rather have it simpified down to use cursor since evaluating the mouse mode used in code is so easy (plus if I've renamed my cursors to something custom its less confusing to me).
Quote from: Crazy on Tue 14/07/2009 21:00:00
Personally I'd rather have it simpified down to use cursor since evaluating the mouse mode used in code is so easy (plus if I've renamed my cursors to something custom its less confusing to me).
Exactly my point. I can make a workaround. It's not the point. The point is the inconsistency. Hotspots have it, characters have it, objects have it, inventory items don't. It's racism against inv items that's what it IS!!!
Ah, I misinterpretted the topic.
Quote from: Ghost on Tue 14/07/2009 20:56:02
Both times, yes.
To use any cursor mode on an inventory item, you can check against the cursor mode in "other click". It's simple to make a keyboard shortcut to that.
Same with runInteraction- depending on the cursor mode you can *script* anything into that function, so that it contains the results of, say, open, push, pull and simmer.
I;m not using the mouse at all, that makes it a bit more difficult to do the same thing I'm doing with keyboard shortcuts for Hotspots, to do it for Inventory items.
Okay I'm even more confused now. What "it" is missing?
if you want to run the command InventoryItem.RunInteraction you can only have three kinds of interactions. Mode look, use, talk.
while in hotspot you can have up to 8.
InventoryItem.RunInteraction(CursorMode) will accept
any cursor mode. If it's not one of those three specifically it just gets passed through to the "other click" event handler function. However Dual does have a point that the other click function doesn't have any built-in way of getting the CursorMode passed through when RunInteraction is called.
I just checked and
game.used_mode isn't updated when calling RunInteraction, so there's no way short of manually tracking it like:
CursorMode used_mode = eModeWalkto;
// wherever
used_mode = eModeTalkto;
iNavigatorHead.RunInteraction(used_mode);
function iNavigatorHead_OtherClick() {
if (used_mode == eModeTalkto) dNavigator.Start();
used_mode = eModeWaklto;
}If game.used_mode were to be updated when we call InventoryItem.RunInteraction then that would eliminate the user-created variable. Dual's suggestion would prevent the need for the generic "other click" function altogether by offering only mode-specific functions (as are available elsewhere).
I'm not against the suggestion but I would say it's low-priority. A separate item which I'd rate higher priority would be the ability to check which mode was actually passed through RunInteraction.
Quote from: Ghost on Tue 14/07/2009 20:29:27When was the last time you opened, pushed, repaired, scared, or talked to an inventory item? ;)
Well...
someone hasn't played The Secret of Monkey Island lately!
Quote from: monkey_05_06 on Wed 15/07/2009 04:08:24
Well...someone hasn't played The Secret of Monkey Island lately!
That was *meant* to be a slightly tongue-in-cheek reference to the fact that very few AGS games actually bother to extend inventory interaction to more specialised, obscure verbs. Of course there *are* many games that do so. It's just not so common in this community.
I have thousands of code on the global script because of inventory_otherclick functions. It would really simplify my work. And I think it's something game makers will use more and more.
Right-click to cycle verbs is so out of date, man!
But so are the games many people make on these forums. People here 'like' out of date.
I say that if someone is using RunInteraction function for Inventory items, then there's no point allowing you to put any mode on the bracket when you can't run the certain's mode interaction.
iKey.RunInteraction(emodePickUp);
for example.
You could've just renamed the cursor modes...
iContraption.RunInteraction(eModeFiddle);
So actually being able to get the active mode seems feasible. Having all of them on the grid might confuse new users, but people who need them would know they can script it if need be.
Is there any actual, practical reason for this suggestion besides discrimination?
Because I don't see it.
IMO, reacting to all the different modes in one function is cleaner anyway. The current system of having three to six functions for one hotspot to me looks like a remnant of the interaction editor days and maybe wouldn't even have been implemented in the first place if AGS had started out without it.
And the amount of code is roughly the same, btw.
ProgZmax, I do believe people here 'like' out of date as it was, but want to make it in a different way.
I shouldn't have to explain myself that my comment was a joke as it was pretty clear.
And I also belong to this forums.
KhrisMUC, I am not an experienced coder so I do have more code scattered on the global script when regarding inventory, it is MY problem anyway.
Quote from: KhrisMUC on Wed 15/07/2009 23:24:12
The current system of having three to six functions for one hotspot to me looks like a remnant of the interaction editor days and maybe wouldn't even have been implemented in the first place if AGS had started out without it.
Agreed. I find that rather annoying.
Quote from: Mr Matti on Wed 15/07/2009 23:44:15
Quote from: KhrisMUC on Wed 15/07/2009 23:24:12
The current system of having three to six functions for one hotspot to me looks like a remnant of the interaction editor days and maybe wouldn't even have been implemented in the first place if AGS had started out without it.
Agreed. I find that rather annoying.
I refer you to my original post. I can understand Chris has to depreciate features to a certain degree instead of removing them when updating the editor but stuff like this just strikes me as pointless considering its become rather half-baked as coding various checks within the events is a necessity now, so why bother saving people an extra line of code and a couple of brackets?
You could use one function if you really wanted to, just by manually typing the function name in for each of the events. The only problem then becomes the same as that of the OtherClick function...
If the user is simulating the interaction by using InventoryItem.RunInteraction there is no way to tell which CursorMode was passed as the parameter. If they actually click via the mouse then of course mouse.Mode or game.used_mode would be appropriate. However as Dual said he is trying to simulate these clicks which means that for any extraneous modes he would have to take extra measures for something which IMO AGS should compensate for. There should be some way of getting the mode passed through to the function.
EDIT: I'm not saying that Dual's suggestion is a bad idea IMO as keeping the editor consistent is important; though realistically there are loads of other things that I would (personally) rate as a higher priority. The most important thing, I insist, is that even with the way it's currently set up there is no way to determine which CursorMode gets passed through the RunInteraction function in the event it is not one of the aforementioned modes. Whether or not this suggestion gets immediately implemented or not, I still feel that there needs to be a way to recover this information! If it were available it would at the very least provide a built-in way of dealing with the situation instead of having to entirely script a custom method.
Hell, guys I CAN MAKE A WORKAROUND. It's not the problem, in this case. Jeez.
The thing is I'm making an interface for someone other's game, who isn't equally experienced as i am, and I feel it would feel better if what I'm saying could be implemented.
Now you've gone and pissed him off.
Quote from: Snake on Fri 17/07/2009 19:41:08
Now you've gone and pissed him off.
That's right, prepare my WRATH!!...
*prepares Dualnames some his famous wrath*
It should be expect right? Well, prepare to shit yourself.
EXPECT MY WRATH!!
I'm expecting Crazy's wrath now. It sounds delicious.