Invision Community 4: SEO, prepare for v5 and dormant account notifications Matt November 11, 2024Nov 11
Posted February 10, 201015 yr Please tell me it is being improved. I just uploaded a new set and can't change the activation words. I really don't like it.
February 10, 201015 yr Activation words are "global". If I use something like :this_is_my_emoticon_code: for instance in a post, then that same code needs to be in ALL emoticon sets, or it won't parse in the emoticon sets it doesn't exist in. Because of this, you change activation words in the default emoticon set, and they're carried over to all sets.
February 10, 201015 yr Author Maybe its a user error. http://www.screencast.com/users/BHL_Tutorials/folders/Jing/media/e75ed547-c4e4-44a4-a00d-c1f1524642c4
February 10, 201015 yr Author Activation words are "global". If I use something like :this_is_my_emoticon_code: for instance in a post, then that same code needs to be in ALL emoticon sets, or it won't parse in the emoticon sets it doesn't exist in. Because of this, you change activation words in the default emoticon set, and they're carried over to all sets. So If I make the filename the same and set it in the defaults it will carry over? I will try this now Again sorry for posting it in feedback I thought it was confusing for everyone but I guess it is not.
February 10, 201015 yr Yes, that is correct. It used to be separate / per-pack. The problem is, a user on skin "A" would post an emoticon. Then a user on skin "B" which was using a different emoticon pack would quote the post and the emoticon wouldn't parse. Or a user on skin "A" would post an emoticon, and then the emoticon would be a broken image on skin "B" because the image name was different for that activation code. The only way to ensure consistency of the emoticons in different packs is to make file names + activation codes global for all packs. You then can overwrite the specific image files on a per-pack basis to make them look different, but the available emoticons remains the same.
February 15, 201015 yr Yes, that is correct. It used to be separate / per-pack. The problem is, a user on skin "A" would post an emoticon. Then a user on skin "B" which was using a different emoticon pack would quote the post and the emoticon wouldn't parse. Or a user on skin "A" would post an emoticon, and then the emoticon would be a broken image on skin "B" because the image name was different for that activation code. The only way to ensure consistency of the emoticons in different packs is to make file names + activation codes global for all packs. You then can overwrite the specific image files on a per-pack basis to make them look different, but the available emoticons remains the same. Was surprise not to be able to do that and now I know I have to wait...or make a mod. There is a solution: make the code like the translate folder: a default emoticon set that you can extand and the corresponding translation list for each different skin. Easy! ;) See you.
February 15, 201015 yr Was surprise not to be able to do that and now I know I have to wait...or make a mod. There is a solution: make the code like the translate folder: a default emoticon set that you can extand and the corresponding translation list for each different skin. Easy! ;) See you. That's exactly how it works now.... The "default" set in IPB is the "master" set for all intents and purposes. Then, by creating new packs you can "extend" it and change the "translation" (upload a different image for a code).
February 15, 201015 yr That's exactly how it works now.... The "default" set in IPB is the "master" set for all intents and purposes. Then, by creating new packs you can "extend" it and change the "translation" (upload a different image for a code). Sort of like skins, where the 'root' skin is the default and as you go down deeper into skins/sub skins, the template bits that are changed over-ride the default?
February 16, 201015 yr Sort of like skins, where the 'root' skin is the default and as you go down deeper into skins/sub skins, the template bits that are changed over-ride the default? Yes, that's the idea. Except in this case, the "template bits" are the image files themselves.
Archived
This topic is now archived and is closed to further replies.