how to let players select NPC without showing them info?

[MattH06]

I searched but didn't see this question. I have strict ownership on. How do I allow players to select the NPC/Monster tokens so they can use token macros yet it doesn't allow them to open up any info on the token?

Thank You.
-Matt

[jfrazierjr]

Select, as in "click on" to select cannot be done with Strict token ownership. if your intention is to perform targeting with macros, you will need to build list boxes using input(), frame(), or dialog() functions.

The wiki has a fully functioning example using input() in the docs for said function.

[MattH06]

Yes "clicking on" is what I meant. thanks

[jfrazierjr]

Yes "clicking on" is what I meant. thanks

Yes, then as I noted, it's not possible with Strict Token Ownership on.

[Mathemagician]

Well, it's best not to jump to conclusions. It's not possible (yet) to do this directly, however, you CAN do this in a roundabout way.

Let's say you want your players to fight a goblin. You'll want to create two goblin tokens, one to be kept out of line of sight, call it "Goblin1", and another dummy token, call it "Goblin1target." The Goblin1 token has all the stats, on it, while the Goblin1target token has just one stat "WhoAmI=Goblin1". Then, you have to add some lines of code to your macros:

So when your player's macro calls [targetList=getSelectedNames()], you need to do a quick loop:

Code: Select all

[h, foreach(target,targetList): newTargetList=list.Append(getProperty("WhoAmI",target))]

and then use that newTargetList as your list of targets.

This not as elegant of a solution as it seems, because there's more work to be done. Every time you change the state of Goblin1 (eg: he becomes dead), you also have to change the state of Goblin1target, so Goblin1 should also have a field that tells you who "Goblin1target", and then your code that updates states will also have to add that state to both tokens.

I should say that I think it was Craig that came up with this sort of idea. I think his version is better in that you hit a button "Select targets" which sort of copies tokens around so that you can click on them only when you're in this phase. Search for posts by him and "select targets" or "clickable targets." I think the word "invisible" is in there too. And maybe "copy token" or "copyToken."

Good luck!

[VileTerror]

I've got a City of Heroes framework project I'm attempting to make functional in Maptool, and I'm wondering if there might be a solution to this problem yet.

I've used the macro code of:
[h,code: {
[IDTemp=ID]
[PUser="VileTerror"]
[token(+PUser):Trgt=IDTemp] }]
Targetting [r:token.name].


The "ID" variable is populated by another macro, which inserts the token ID assigned by Maptool in to a token property field.
"IDTemp" is just temporary, and I'm not sure if it's even necessary. I'm having a hell of a time wrapping my head around this syntax and the exceptions to rules which I took for granted in other languages.
"Trgt" variable is used by my other macros to establish which Token needs to be 'poked' at. Once the "Trgt" variable in the player token is set, my other macros can attempt to attack and deal damage to the target NPC regardless of ownership.
I thought I was being clever with making this macro as a solution which might allow my players to declare their targets. No such luck.

       As a GM/admin, I can run this code for my players (just making different versions of it with their token name for the "PUser" variable), but that's time consuming and removes some of the interactivity away from those players. I can't seem to make a macro which my players can use while impersonating their own tokens, but highlight/selecting the unowned NPCs. That's my present objective, unless there's some other solution to this problem.
I've noticed talk about making things with input(), frame(), and dialog() functions; but I'd really like to avoid that due to the sheer number of tokens (with similar names) that I plan to have on my maps. That, and I'm still trying to wrap my head around some other things, and I'm not ready to bite off that much more than I can chew.

I hope I've been able to express myself clearly here. Code-talk always does my head in. I (sorta) get the logic, but syntax . . . it's a bane of mine. Additionally, my group is still using 1.3.b89, for various reasons. If this problem can be solved by simply upgrading to the latest version, I will try to do some cat wrangling; but a solution in 1.3.b89 would be ideal.
If anyone might be able to help, I would appreciate it. I've got a number of other hurdles I need to overcome too in the next two weeks (mostly related to almost all of my previously-working code now giving me stack overflow errors), but this one is my primary issue to overcome. Thank you to anyone who may be able to help.

[aliasmask]

Perhaps this function will help you: http://forums.rptools.net/viewtopic.php ... 52#p257652

[Jagged]

Additionally, my group is still using 1.3.b89, for various reasons. If this problem can be solved by simply upgrading to the latest version, I will try to do some cat wrangling; but a solution in 1.3.b89 would be ideal.

No reason not to upgrade to 1.4. But take a back up of your campaign and test before you do. The framework I am currently using is unchanged since about b70, so I would be surprised if you had any problems.

We are about to release a new stable version, so you I would suggest waiting for that.

I was a big fan of City of Heroes, played on Freedom and was also called Jagged in their forums

[Full Bleed]

I'm wondering if there might be a solution to this problem yet.

I not sure this *is* a problem any more. You're responding to a 7 year old thread...

I use "Strict Token Ownership" and my players can select to target enemies without "opening any info on the token". I know it hasn't always been that way... but it's been that way for a long time.

Am I missing something?

[VileTerror]

       Thank you for the suggestion, aliasmask, however I'm having a hell of a time deciphering that code so I can actually implement it. Seems like an awful lot just to grab an identity from a single token. Should I be able to just plug-and-play it by dropping it in to a new macro? If so, then what version of Maptool is it made for? I can't get it to do anything other than just post an empty message to the chat.
   
       Looking at http://forums.rptools.net/download/file.php?id=5321 , I worry that the macro will not be able to address a major concern presented by the nature of City of Heroes. If there are thirty "Blood Brother" tokens in a single mob, with multiple Blood Brothers being equal distances from the player-character's token, will there be any way for the player to actually get the one they want, without having to activate the macro multiple times until they get their desired target?
   
   
   
       There are reasons, Jagged. Previous attempts to upgrade were met with a wide slew of problems for my players, ranging from firewall issues to Java runtime errors to personal preferences of the players. The biggest issue is actually convincing these players to do this sort of thing /before/ our scheduled game sessions are meant to begin. So, you know; social engineering problems, mainly.
   
       When you say that you're about to release a new version, would you be able to give an estimated date? I'm slated to have this campaign start in two (maybe three) weeks.
   
       And as a fan of the old MMO, I'd be happy to discuss this project with you some more. Gameplay logic, changes from the MMO, plot-and-story, themes, or just whatever. Have you heard of Paragon Chat, for example? They're doing good stuff there. Hell! If I continue to have problems with getting my code to cooperate, I'll probably end up making a big ol' "OHGAWD! HELP ME!" post in a few days, heh.
   
   
   
       When my players were helping me test my macros, Full Bleed, they informed me that they would get an error along the lines of "you may not run a macro which affects the properties of a token you do not own." Since I want my players to be able to run macros to attack and damage enemy NPCs, without giving players ownership access of those NPC tokens, I have attempted to come up with some solutions. The one which was (almost) working involved finding and using the token ID for those NPC tokens in the attack macros. It allowed my players to successfully make their attacks, but since my macro to call the ID up (code in my first post) apparently "affects the properties of a token" which the player doesn't own still, the targetter macro isn't working as I intended.
   
       I apologize if my way of explaining this causes confusion. I've never been able to communicate clearly with coders. I use words that apparently have wildly different definitions between myself and the coders, so I try to speak in as simplified-as-possible terms, avoiding words that carry "coding baggage." I suppose I'm not being very successful.
   
       My goal is:
Player clicks-on and selects-and-impersonates their PC Token.
Player clicks-on and selects the enemy NPC token which they intend to attack.
Player presses "Select Target" macro button.
"Select Target" macro takes token ID of selected enemy, and puts it in the PC Token's "Target" property field.
   
       From there, I already have some macros which I've successfully tested and got working that do the desired tasks of checking to-hit/accuracy, and then dealing damage. (although, more and more I'm getting stack overflow errors, which I may be addressing in another thread later. First I'm going to attempt to split my macros up some more with the [Macro():] functions. But that's a different subject)

[VileTerror]

       Ok, stop the presses. I see now the error of my original code.
   
       It should have been:
[h, code: {
[IDTemp=getSelected()]
[PUser=getImpersonated()]
[token(+PUser):Trgt=IDTemp] }]
Targetting [r:getName(IDTemp)].
   
       And importantly, I needed to de-toggle "Apply to Selected Tokens" on the Details tab of the Macro Edit window.
   
       I apologize for drudging up this old topic. This should put me back on track. The next step is to find an efficient and stack-overflow-avoiding method to check 8 types of damage versus their respective resistances. If anyone has some suggestions for that, please feel free to contact me in private.

[Full Bleed]

The next step is to find an efficient and stack-overflow-avoiding method to check 8 types of damage versus their respective resistances. If anyone has some suggestions for that, please feel free to contact me in private.

You should start a new thread with the specifics of the problem you're having. Provide your Help>Gather Debug Information profile in the post and the code that causing the problem.

More than likely you're using the wrong memory configuration if you're having stack overflow errors.

[wolph42]

additionally I would suggest you read the 'stack overflow' article linked in my sig.

[Jagged]

When you say that you're about to release a new version, would you be able to give an estimated date?

I was expecting it this weekend, so it will be here very soon. The build is all ready to go. Its actually the Dev 1.4.1.7 build that is going to be released as the next stable version. Its well tested and ready to deploy