Mike1072

The problem is that Windows is now using CTRL+SPACE to swap languages. However, you can rebind or unbind this key sequence. I think in the latest version of Windows 10, it's located under Settings -> Devices -> Typing -> Advanced Keyboard Settings -> Language Bar Options -> Advanced Key Settings.

http://readme.classicadventuresmod.com/TobExReference.html#ruleset-item-restrictions

If the item specifically says that it casts a particular spell, then yes, it would use the vanilla version of that spell when SR isn't installed. However, items that simply emulate similar effects as spells have those effects based on the SR versions and don't change depending on whether SR is installed or not.

I think it throws that warning because you have a variable named target that you've initialized previously. So, you could: change the name or scope where the variable was used previously perform your suggested abomination to hide the warning disable all warnings of this type leave the warning in place because it's doing its job

Yes, changing mod items to make them follow the philosophies from IR's main component is out of scope. However, if you mean that these aren't (correctly) identified as armors by the global components (e.g. casting in armor, thieving in armor), then that can be fixed.

I haven't experienced any problems with them - visiting the link in the email redirects to the second link (or a different version if there are multiple pages) and seems to pull up the correct message.

In case anyone reading this topic doesn't understand why modders are being so outrageously protective of their work, here's some history. This idea of a master collection of mod downloads is not a new one. Modders have explained why they are against it many times before and aren't happy to repeat themselves. Mirrors inevitably end up out of date even with the best intentions. Players using outdated versions of mods will encounter bugs that have already been fixed, and show up on forums to report them. This wastes the time of players and modders. I don't think modders are being too unreasonable here. You'll notice that nobody freaked out over people supplying links to mods that are temporarily offline because of the situation at SHS. I'll leave you with the notice that CamDawg includes in his mods:

The program that handles mod installation (including compilation of .d files) is called WeiDU. When you run setup-modname.exe, you are running WeiDU. After you make changes to a .d file, if you want to see those changes reflected in game, you simply have to run setup-modname.exe and [re-]install whichever component of the mod it is that compiles that .d file.

I offer you the opportunity to respect modders and not be a turd.

Please remove any G3 mods from this collection that you do not have permission to mirror.

I've removed the link. You do not have permission to mirror G3 mods.

Done. It will probably be released on its own before then, unless @kreso happens to pop up.

@Cinnamon You can hit the Follow button at the top right of the page on specific topics if you want to be notified of replies.

Sure, I can just add the _DEPRECATED version for those spells rather than replacing the existing entry.

Implementation of ADD_SPELL in SR is undergoing testing now. Any modders who have included the code from the first post in their mods will need to remove it when the next SR version is released. In addition to choosing IDS names for the new spells, I followed a similar methodology as @DavidW and added and updated the IDS names for other spells as well. There are only a few differences between the assignments in the first post in this thread and the upcoming SR implementation. More IDS entries have been added for aliases and updated for deprecated spells The naming for Goodberry is different The SR version at level 1 is assigned the vanilla identifier CLERIC_GOOD_BERRIES The original version at level 2 is assigned the identifier CLERIC_GOOD_BERRIES_DEPRECATED The new names for the Animal Summoning and Monster Summoning lines of spells are different, e.g. Instead of CLERIC_ANIMAL_SUMMONING_SR_1, it's CLERIC_ANIMAL_SUMMONING_LEVEL_1 Instead of WIZARD_MONSTER_SUMMONING_SR_1, it's WIZARD_MONSTER_SUMMONING_LEVEL_1 The Animal Summoning and Monster Summoning lines of spells have been assigned a complete set of aliases, for both their SR and vanilla naming schemes, where possible, e.g. CLERIC_ANIMAL_SUMMONING_LEVEL_1 (new) CLERIC_ANIMAL_SUMMONING_LEVEL_2 (new) CLERIC_ANIMAL_SUMMONING_LEVEL_3 (new) CLERIC_ANIMAL_SUMMONING_LEVEL_4 (new) + CLERIC_ANIMAL_SUMMONING_1 (vanilla) CLERIC_ANIMAL_SUMMONING_LEVEL_5 (new) + CLERIC_ANIMAL_SUMMONING_2 (vanilla) CLERIC_ANIMAL_SUMMONING_LEVEL_6 (new) + CLERIC_ANIMAL_SUMMONING_3 (vanilla) CLERIC_ANIMAL_SUMMONING_LEVEL_7 (new) + CLERIC_ANIMAL_SUMMONING_4 (new) For the full listing of SR's changes to SPELL.IDS, please visit this page.

No problem, thanks for the report.

setup-divine_remix is just a renamed version of the weidu file from the WeiDU-Mac/bin/x86 folder, except it's an older version (v238), not the latest release (v246). If v246 is working for you, you can go ahead and replace setup-divine_remix with a copy of that weidu file - just delete the old setup-divine_remix and rename the copy to match.

Yeah, that's not supposed to happen. The info about v7.1 working is very helpful. Can you also tell us which version of the operating system you are running? For brownie points, can you try running the WeiDU executable included in the mod (named setup-divine_remix) and confirm if that's where the error message is originating from? If it is, can you try downloading the latest version of WeiDU from here and checking whether the WeiDU executables (named weidu) in the WeiDU-Mac/bin/x86 and WeiDU-Mac/bin/amd64 folders have the same issue?

The code to install spells was moved to a separate file. Take a look in spell_rev/components/main_component.tpa and you should be good.

Thanks, fixed.

If anyone wants to tell Jarno how they feel about this post, go ahead.

I've moved Jarno's off-topic derailment to this thread. Here's the only relevant part:

Testing seems to confirm: the highest positive value supported is 2147483647 (binary 01111111 11111111 11111111 11111111)‬. Adding to that will cause it to go negative. You can also use inlined files but it's the same idea. 4. I always use SET. The only time I think it's necessary is if you do something like SET EVALUATE_BUFFER ~%var%~ = 1. It doesn't understand EVALUATE_BUFFER ~%var%~ = 1 by itself. 5. I always use spaces. I know that hyphens can be interpreted as part of a variable name, so using spaces with operators (e.g. subtracting) can be important.

@AL|EN only cares that this distribution method makes it harder to include the mod in his install tool. Taking a mod and adding/editing content does not give someone the right to release that version without permission. IRR is not a separate mod. It is Bartimaeus' customised version of IR, available for others to use if they wish. Branching it into a full mod would make maintainability much more of a headache than it already is. To be clear, I'm not against including creative changes for IR or SR. However, my role in creating the mods was always focused on the technical side rather than the item and spell design. I provided feedback for some of the design ideas, but inclusion was always a consensus-driven affair led by Demi. If the community gets together and says, yes, we actually prefer implementation X over implementation Y, then I'm in favour of including it. I'm just not the guy to figure that out. Edit: I'm also not the guy to implement .itm/.spl changes. Regarding text changes, I acted as an editor for both IR and SR descriptions, so I have some of my own subjective opinions about them. I did implement a good portion of your suggestions into IR, but you're right, not all of them. On a technical level, it's been difficult to incorporate the things that we would automatically accept from your versions, like bug fixes, because they're not separated from any of the other changes. And as I said above, I'm not the guy to know if those changes are good or not. In an ideal world, your version would have a perfect git history breaking apart each individual alteration, from bug fix to content change, so we could go through them one-by-one, applying them to the base mod as desired, but that's not the case. I haven't said no, but Bartimaeus has never asked. Please stay out of it.

Might need @Wisp to weigh in. I think this is an oversight that can be removed from the docs & function parameters. If you are using READ_ASCII / WRITE_ASCII correctly, then you don't have to worry about it, so AFAIK nobody does. It looks like READ_LONG and READ_SLONG are identical in implementation. My guess is WeiDU internally treats all numbers as signed 32-bit integers, so unsigned 32-bit integers aren't supported.