Seems like the latest Token Height Indicator just broken compatibility with your extension.
https://www.fantasygrounds.com/forum...l=1#post618835
Printable View
Seems like the latest Token Height Indicator just broken compatibility with your extension.
https://www.fantasygrounds.com/forum...l=1#post618835
For making melee more fun I really liked tome of battle book of nine swords in 3.5. that book also has a lot of opposed skill rolls Quote:
Originally Posted by Kelrugem
We are waiting eagerly for your opposed skill rolls stuff, it will be awesome. There are several things we dont use because it slows down the game without automation. My suggestions are:
Make the opposed skill rolls work with if and ift effects.
Opposed skill checks can include your spell tags for bonus vs them, see example
Make is see how many times we have beaten it by 5, like hit by +5, hit by +20, miss by +10, like bmos ammunition manager. Or make it work with that extension.
When choosing skill we can choose every skill in the skill tab like knowledge religion or custom made skills
Static modiferer multiplied by Choose skill or cmb or caster level + field for static modifier + ability core modifier VS static modifier multiplied by opponents skill or cmd or AC or HD or CR +static modifier + opponents ability score.
There might be more options that is neccessary that I am missing here
Examples of use
Feint: bluff vs 10 + BAB + wis modifier
Demoralize: fear effect. Intimidate vs 10+HD wis modifier
Knowledge vs monsters. Knowledge vs 10+CR
Climb vs cmd, I get bonus based on how big they are (here is why ift: size effects are nice to have)
Ac bonus feat cant remember name: sense motive vs AC
Dont provoke AOO while moving: acrobatics vs CMD
I will post more if I remember them.
Edit: added feature how much we beat the opposed roll by
Thanks a lot :) I will bookmark it :)Quote:
Originally Posted by Svandal
For how much you beat the roll by you can absolutely steal my function from Ammunition Manager:Quote:
Originally Posted by Svandal
https://github.com/bmos/FG-Ammunitio....lua#L272-L278
https://github.com/bmos/FG-Ammunitio....lua#L109-L122
I've yet to see a need for more granularity than 5, 10, etc and that way it doesn't give away the exact DC.
Thanks for the suggestion, bmos :)
@all: Finallyyyyy, I have a github profile and have uploaded all my extensions as repositories here: https://github.com/Kelrugem :) So, in case you are a community dev who wants to contribute to some code, then feel free to do it via Github :) (but private messages and so on are still okay of course :) ) I also created a project: https://github.com/users/Kelrugem/projects/1. I also tried to link it with my Orcid ID (an ID for uniquely identifying authors of creative work, mainly research), but not sure if I succeeded (hence, I also simply added my Orcid ID to my profile description)
By the way, there is now a donation button in all Forge profiles of the people who toggled that they may sell an extension: https://forge.fantasygrounds.com/crafter/2/view-profile (upper right)
I was at the very beginning of the Forge testing, and then it was not possible to not toggle that, hence, I got the donation button, too. I can sadly not remove it, therefore I now thought a while on it what I should do with that. Since I basically cannot avoid that someone uses that button: If you want to donate something and you can really afford a bit, then I appreciate a donation :) but there is of course no obligation to do so, my extensions stay free of course, and there is no guarantee from my side how much time I can commit on my projects; so, only use the donate button if you are comfortable with the current features, not thinking about any possible kind of features I was thinking about loudly :) In case you ever donated something and realized that it was too much for you, then hit me a private message and I send it back of course :)
Thanks, and sorry that I am currently extremely slow with new features; my life is still chaotic, my new job should have already started in Taiwan, but Taiwan closed their borders because of the pandemic. Now I start on 1 October with my job as post-doctoral fellow, but with my home office still in Germany until the borders are open again :) (so, since the defence of my PhD I feel like "on the jump", but I cannot "jump" :D)
Yahoo! The only issue I see happening is that alternate overlays and original overlays are going to be hard to collaborate on since they're the same except for a few pictures.Quote:
Originally Posted by Kelrugem
I'd recommend putting them together and having some sort of build script that would mix/match the right stuff if you don't want to just make one a theme for the other.
Sorry to hear your move is postponed, that can be a very uncomfortable feeling.
Ah, yes, I was also thinking about that this may be confusing; not sure how to build an automatic script, but for now I may just delete the alternative or original version and copy the changes to the other version separately outside github :) (or rather replacing the graphics for the other version as I am usually doing it)Quote:
Originally Posted by bmos
(thanks for the words about the moving :) )
If I get a chance, I'll see if I can't help with that (the build script thing). My experience is with the business side of github, so I'm not sure if it'll translate, though.Quote:
Originally Posted by Kelrugem
could the overlays and alternative overlays be a menu toggle, like selecting a background decal is? or would that cause funky things if a map was already loaded?
oh, nice, let me know; thank you very much, I appreciate it :) The first time that I really use Github :DQuote:
Originally Posted by Croddwyn
the reason why I did not change that (yet?) was that then the users do not need to download all the graphics; especially the first version had rather big file sizes until bmos made their sizes smaller, and then I preferred to have a separate version for the alternative overlays :) If I am not mistaken, clients also need to download all the files on the first connection, and with that I wanted to avoid any problems with logins etc; but maybe I just overthink itQuote:
Originally Posted by Zygmunt Molotch
I think the best bet is still to have Extended Automation be a sort of "master extension" and then have Strain Injury and Alternative Icons be additional extensions to the core Extended Automation extension. This would maximize your code reusability and result in the fewest github repos to maintain. Though that would be a pretty big change for current users of your extensions.
About the icons as separate extensions we once spoke, but writing straininjury as an extension on top would be a mammoth project since there are a lot of changes in StrainInjury also affecting the codes of extended automation :) (StrainInjury affects so many files that one could start to argue to make it a .pak :D I actually also plan to release my homebrew extensions which is straininjury plus extras, and I will probably release this as a ruleset instead. But this is just some fun project I may have)Quote:
Originally Posted by SoxMax
At the moment I may simply just keep one Extended automation and one version with straininjury :) Then the code pull requests can be added to them and the versions with other overlays are simple enough done manually as usual :)
(About overlays: A separate extension just overwriting overlays still requires that the "alternative users" need to download certain files twice; and I am not sure how this affects the FG RAM usage because, if I am not mistaken, overlays are loaded into RAM, such that they are ready to use. I wonder whether overwritten files are not loaded into RAM? But if both versions are loaded into RAM, then I'd still prefer the current approach.)
Ahh, darn I hadn't realized how entwined StrainInjury was with the rest of the automation.
For the overlays as far as transfer goes, you could have the core mod not have any extensions at all, or blank dummy files. Then make it so one must subscribe to an icon pack to get any icons. This would alleviate the transfer problem upon connection and allow you to maintain the code independently of any icons.
But I may be overthinking it and just copying in new icons or using a packaging tool may just be easier.
hmm, this is actually a good idea, I didn't think about this :)Quote:
Originally Posted by SoxMax
Now I will think even more about it :D The only disadvantage may be of course that current users need to get aware of such changes if such a change is applied; but I will see :)
A solution to that would be a pop-up window that only shows up on first load which tells users they need to install an icon pack. But I think 2 extensions for everyone is perhaps worse than 2 extensions for some users. It would be great if you had stats on how many users use each version.Quote:
Originally Posted by Kelrugem
Hm, yeah, I see; by the forge the stats are currently: Original overlays at 199 subscribers, alternative one at 98, though there are surely people downloading both versions :) Hm, difficult to say what the best approach is, given that already many users are used to the given systemQuote:
Originally Posted by bmos
For generating multiple extensions from one github, I've been working on a packaging tool that could help.
https://github.com/SoxMax/FantasyGroundsPackager
It currently takes a directory and expects a single extension.xml file and pulls in all the files needed by the extension.xml
It should be easy enough to make it so you can specify an xml directly and rename it to extension.xml during packaging. This would let you put the extension.xml for each version along with all the needed icons in one repo and then just point each extension.xml to the set of icons it needs.
ah, nice, thanks a lot; I will take a look :)Quote:
Originally Posted by SoxMax
Sorry I just realized my post may be implying you can make that change to the packaging tool, let me know if you want me to make that change :pQuote:
Originally Posted by Kelrugem
Oki :D No worries, I am not even sure whether I am capable of adding such a change :D (besides FG coding I basically never did any coding, so, basically unexperienced with everything outside FG :D)Quote:
Originally Posted by SoxMax
Quick question. Is there a way to have the drbypass only work for specific dr types, such as dr magic. As I understand it and in my attempt to set this up properly drbypass is getting past all dr.
I am looking at setting up an Inquisitor's Judgement of Smiting.
Smiting: This judgment bathes the inquisitor’s weapons in a divine light. The inquisitor’s weapons count as magic for the purposes of bypassing damage reduction.
So while it needs to bypass DR magic, I don't want it to work on DR adamantine for example.
This would be for an applied effect and not applied to a weapon quality.
Thanks. I was super happy to see that greater minds like Kel and Phixation tackled this some time ago.
If you just want to avoid certain DR like in this case, then it is much easier just to provide the corresponding damage type :)Quote:
Originally Posted by Last Post
If it is a permanent ability, then just add magic as damage type to the weapon(s). If it is a temporary ability, then use the effect DMGTYPE: magic; this will add the magic damage type to all your weapon attacks :) (the latter of course also works for permanent abilities, but I usually prefer to keep the CT effect stuff as clean as possible :) )
And thanks for the words :D
Darn it! I knew this too. Now that you reminded me I have other players who've had similar abilities use this but it was my first time setting something like this up. Thanks Kel!!
hehe, happens, you're welcome :DQuote:
Originally Posted by Last Post
Hi :)
Just a short notice, the next bigger update is a very big one: https://www.fantasygrounds.com/forum...029#post624029 :) That means: It may be that I am not able to immediately update everything before this is released :)
Also: One of the changes is to remove FGC specific code. I will try to push soon finally my next updates (not accounting the changes on the test server); these versions will be also uploaded to the forums to be available for all FGC users. However, this will be then the last update for the FGC versions, the forge version will be then only for FGU (forge actually just downloads for FGU). Since FGC won't receive any updates anymore, there should be no danger of a suddenly broken extension :)
now I know I won't update for a while :°D
Is there a function in here that will allow force-based armor effects to work against incorporeal attacks? It sounds pretty niche, but things like mage armor and shield are very common spells, and incorporeal enemies such as wraiths aren't too rare. I just had this come up in a game and if there was a forcearmor and forceshield type that applied their bonus as normal but also against incorporeal attacks, it would be a pretty simple solution.
Just something to think about, I think I have a workaround that does well enough right now.
I once had a code snippet for this but decided against this because I thought it should already be possible to code this, I think :) I can check again maybe :) (it is too long ago)Quote:
Originally Posted by Dark_Soul
Right now I'm using AC: 4 armor; IFT: Incorporeal; AC: 4 force for a mage armor effect and it's working right. I'm not sure if it's even recognizing "force" as an armor type. I doubt it, and I'll probably be alright removing it, but it's what works for now.
I go with the following:Quote:
Originally Posted by Dark_Soul
MAGE ARMOR; AC: 4 armor; IFT: TYPE (incorporeal); AC: 4 melee
it's not perfect but still works most of the time:P
Precisely, that was probably the reason why I thought it is not needed to code it :) (or to publish the code I already had; maybe its prototype is still there but commented out in the code) The effect may be only problematic if the incorporeal creature attacks with a weapon? Not sure, never had incorporeal NPCs :DQuote:
Originally Posted by Asgurgolas
Incorporeal creatures with weapons still are incorporeal, unless those weapons are ghost touch. But even if it's the case, it'd be such a rare situation I'd just add a "IFT: CUSTOM (Mage Armor); ATK: 4 melee" pasted here and there
Just a short notice again: Next week probably will be a rather big official FG patch and I am not yet sure whether or not I can update all my extensions then :) My extension will likely break, I think
Right now I was concentrating on new features rather than just maintenance; if you are interested into spoilers about the possible new things: https://github.com/users/Kelrugem/projects/1 (the middle and right column are either already done in some sense or there is just straightforward progress left; so, these two columns will certainly make it into the next extension update) You probably see that there is a lot going on and some stuff will come soon :)
well I haven't updated since october or so because you said your extensions could break back then, so I can wait some more :pQuote:
Originally Posted by Kelrugem
When I said that, then I was referring to the patch coming next week :D I think I wrote "the next bigger patch soon" and there was no other bigger patch yet :DQuote:
Originally Posted by Asgurgolas
So, this week is still totally fine to update :)
Oh... then I'll go with updating now since I'm still in time o.O good to know
Has anyone noticed and issues with Kelrugem's extentions? I updated with out thinking about it, today 12/3. I did a quick check and the everything seems to be working.
Up until today there should be hopefully no problem :) The complicating patch comes next Tuesday :)Quote:
Originally Posted by RobboNJ69
Ok! That clears it up. With the earlier posts, I wasn't sure if today would see the possible issues. Thank you, Sir! I haven't been on here in a while... I hope you've been well.Quote:
Originally Posted by Kelrugem
I am fine so far, still waiting for Taiwan's borders to be opened such that I can see my new office there :D (my home office is in Germany so far)Quote:
Originally Posted by RobboNJ69
I hope you are well, too :) I am already updating my extensions and I try to add your request for the effect about lowering fortification :)