Mike1072

It's the cloud hosting plan offered by the makers of the forum software. We're expecting it to be $45 per month. That includes keeping the forum license renewed, which would be about $10 per month if we went with a different host.

Thank you. We will be setting up a donations page once we are moved over. The new host comes with higher monthly fees. I'm not sure what's wrong with your phone, but if it can't access any SSL websites, that's a huge problem. We will definitely be trying to set up SSL on here. It's crazy to have a site with user accounts and passwords and no SSL. For clarity, this migration applies to G3 only.

Hey everyone. As you may have noticed, the forums have been offline for about 3 weeks. Thank you for your patience. A special thanks goes to SConrad for getting us up and running again. We understand that lengthy downtime is frustrating. We're also aware that the outdated forum software has been causing some problems of its own. To remedy these issues, we're planning on migrating to a new web host and updating our forum software to the newest version. This migration is scheduled to take place this week, if all goes well. Starting Wednesday, December 19th, the forums will be taken offline for another couple of days while content is transferred over. We plan to be back online in time for Christmas. Things will probably look a little different when we come back up.

Yeah, I'll take a look to see if there are any references to the old spells.

None of the IRR changes have been added to IR.

Can these be implemented as .ini options? They seem like minor tweaks to existing components.

SET xp = LONG_AT (0x0014) * ((1 - 2) * (LONG_AT (0x0014) / 2000) + (3 / 2)) Integer division. -1 * 1250 / 2000 = 0. 3 / 2 = 1. 1250 * (0 + 1) = 1250 For greater precision, multiply your values and divide them at the end. -1 * 1250 * 1000 / 2000 = -625 3 * 1000 / 2 = 1500 1250 * (-625 + 1500) / 1000 = 1093

AT_NOW expects a string, so wrapping the command in tildes shouldn't be a problem.

The only options offered are to keep the game up-to-date automatically or to apply the updates when the game is launched.

I've created the function. Once we update it with the final list of spells that will be ADD_SPELLed, it can be applied to the current files to replace references to old resource names. I'll need to add code to SR to replace these placeholders with the newly assigned names, but most of the work's done: it will be reusing the replace_spell_resources.tpa file.

This spell is using a new spell slot and should therefore be ADD_SPELLed.

Are these timings from an install on a solid state drive or from an install on a traditional hard disk?

There's no way to turn off that feature. However, if you create a copy of the game folder as jastey suggests, the copy won't be updated.

What did I just read?

Great. I'll try to write up that function before Monday.

Yeah I was going to suggest this but then I saw you already posted it. My suggestion would be to have more-powerful versions override the less-powerful versions. That works with opcode 321 of course... but not for the non-EE opcode 206 versions. I suggest adding some custom code setting this up at the end of the EE .tpa file that adds 321. This talk belongs in a different thread. Any oddities or bugs you find should be noted and tabled for later, unless they prevent implementing ADD_SPELL changes. It's too easy to get sidetracked.

Anyone who noticed the redirect can take some comfort that the problem was on the forums, rather than malware on their machine or a malicious browser addon. Assuming users didn't do anything dangerous on the redirected site (e.g. downloading and running a file), they should be fine.

Thanks for the report. I believe I've located and fixed the problem for now. If you're interested in the details, check out this page.

The main component should not be required to install the revised shield component, so thank you for the bug report.

The posts were moved here because (from Incantar's edit) it sounded like he was using IRR. I made a post in the bugfix thread to clarify that bugs found when using IRR should be reported in the IRR thread first, and in the other thread only after determining if they impact IR as well.

If you're using IRR rather than IR, use the IRR thread to report bugs. If the bug is confirmed to affect IR as well, then it can be reported here.

FWIW, original design (v1 and v2) was that install order between SR and IR main components doesn't matter but IR main component should be installed very early, before quest mods, and IR global components should be installed very late. SR was traditionally installed later than the IR main component. We discussed that it might be a good idea to have a recommended install order so that we could better respond to the presence of the other mod where needed. (IR's main component sort of presumes that SR will be installed as well at some point, but that's more of a design consideration.)

I have a few thoughts: 1. Considerations for IWDEE shouldn't compromise any other part of the mod. SR wasn't designed for IWDEE. If the SR versions of spells would cause the IWDEE AI to mess up, we should simply avoid installing those spells on IWDEE. Later, we can examine ways to improve the IWDEE experience. 2. Any truly new spell added by SR (i.e. taking up a new spell slot rather than overwriting an existing spell) should be switched to ADD_SPELL. This will prevent and avoid a wide variety of compatibility problems. 3. "New" spells that are actually overwriting existing spells are probably best left alone. We can add IDS entries for them (aliases) if that helps. And I have a few suggestions for implementing ADD_SPELL: 1. First, identify all SPWI and SPPR spells that are going to be changed to ADD_SPELL and create a list of the filenames. 2. Create and run a little WeiDU function (I can code this) that searches through all .spl, .eff, .itm files included in SR's folders (and perhaps IR's too) for effects with a resource value that matches one of these filenames and replace them with a placeholder like "dvfaerfi" or "dvstrsto" depending on which value matched. 3. At install time, use ADD_SPELL for the files. After everything is installed, use the same WeiDU function from before to search through all .spl, .eff, and .itm files in the game and match the changed values (e.g. "dvfaerfi") with the newly assigned filenames. Likewise, we'll want to search the .tpa/.tph files to see if the old filenames are referenced in any libraries and modify those so they fetch the new filename from SPELL.IDS at install-time. Can anyone think of any references to old filenames that wouldn't be caught by this?

Nope, but feel free to post the answer for anyone who finds this thread years later.