Jump to content


  • Posts

  • Joined

  • Last visited

Everything posted by DavidW

  1. Noted. This kind of assumes I put it in just to be annoying and make difficulty, rather than because I actually need it for something concrete that I can't work around on the current version of WEIDU.
  2. 2.0.14 is now out, fixing that issue with non-English translations and removing obsolete uses of LONG_BOW as a synonym for MAGE_ALL. Apologies to prowler et al that it took a bit longer to get to than I'd hoped.
  3. DavidW

    installation error

    Define 'works'. Versions 1.5-1.7 were written for 1.3, but they have quite a few bugs.
  4. Sorry, I missed this when you first posted it, but in any case you're probably better off doing your own first pass - I probably wouldn't have had a chance for a while.
  5. Most of this doesn't *sound* like SCS issues, though you never can tell. The arrow thing is a bit suspicious given that you're removing unrealistic items... I will have a look when I have a chance.
  6. Impossible without engine hacks, I *think*. (If there’s an ingame way to edit travel times, I don’t know it, though it’s not something I’ve looked for extensively.) If you’re set on this strategy, I agree with Lynx: do a technical proof-of-concept before worrying about fine details.
  7. At the technical level, the simplest way to do this is by script and dialog. Teleport just summons an invisible creature that initiates dialog. Use the dialog options to select where you teleport to and to control what options are available and whether you're allowed to do it at all. Implement teleportation to an area via an area-specific cutscene called from the dialog, and put the special effects into that cutscene. That's fairly easy to implement. It would obviously be cooler to have a graphical select option but it would be radically harder to do (lots of UI editing at the least, possibly EXE changes.) That said, I think the problems of breaking the plot are fairly severe. You have to lock down quite a few areas, with not very much in the way of in-game justification, in order to avoid messing with the whole leave-and-return structure of chapters 4-5. (A party who can teleport doesn't really have any reason to accept the underdark-vs-Saemon dilemma at the end of chapter 4.) And it would be quite difficult to deal with the various forced random encounters that the game (and probably also some mods) triggers from time to time.
  8. You can detect the main character's name: use the Charname() trigger. (The game uses it to get Drizzt to attack you if your character is also called 'Drizzt'.)
  9. Question: AI scripts for the planetar hardcode the spells they expect it to have, so if you add new spells, it won't use them. There's no workaround to that, short of writing your own AI. Requests: probably not in both cases, sorry. The complexity is excessive relative to the gain; use EEKeeper. And in addition I'm not aware of all the ramifications of putting kits on multiclass characters like that either, which means I don't want to risk implementing it and finding it leads to trouble down the line. I am *slightly* more tempted by the ability-score swap but it's very much not a priority.
  10. I think it’s more elementary than that: if a string is already in dialog.tlk, there’s no reason to pad it out by adding a redundant copy.
  11. @Luke you can do it with LOOPs though. BEGIN LOOP(x||65) INCLUDE FILE(test.ssl) END LOOP //////////////////////////// /////////////////////////// BEGIN LOOP(x||85) INCLUDE FILE(test.ssl) END LOOP I actually think I might have done it that way before and changed it on an erroneous assumption about how variable-substitution works in SSL. (Obviously, in this particular case it would be better to do BEGIN LOOP(x||65;85)
  12. No idea, then. It may be that this bit of SCS isn't working properly either. Ultimately this is the price paid for SSL being a messy bit of PERL I wrote 13 years ago when I knew a lot less about program structure, but also so embedded into SCS that I don't want to risk breaking anything by rewriting it.
  13. To be fair to Beamdog, it's not as if the flags are called that in any official material. It's what Near Infinity calls them. If NI's description doesn't match what the game engine does, that's for NI to fix. (The writing on the tin was put there by third parties, not the tin owner.) The proper description of the SPL flag would probably be 'ignore the dead-magic settings of opcode 66'. (And to be fair to Near Infinity, their descriptions are not intended to be full descriptions, just something short enough to fit in the interface.)
  14. I don't 100% recall, but I think the answer is that variables are read from an SSL file before substitutions are made to that file, but INCLUDEs and VARIABLEs are processed in parallel. So if you want to redefine a variable as you go along, make sure references to the variable live in a sub-script rather than in the top-level script.
  15. To repeat a comment of mine from earlier: "Mine is a pretty conservative restoration of the original cut content; Oversight’s has the same idea as the original cut content but a quite different implementation." I - obviously - prefer mine but the differences are comparatively minor (I think mine might be a bit more dialog-heavy, and you have to kill Kangaxx in Kish's). Given that mine doesn't have technical incompatibilities with SCS, you're probably better off using mine than trying to coax Kish's into working with SCS. There is a fairly detailed readme in my version that explains what it does in some depth, in case that's useful to you.
  16. I'm finding that the alignment comes back wrong even if you just permute rows. ... I'm basically concluding that this is more trouble than it's worth. The game is doing some weird lookup stuff that doesn't really track the implied logic of its tables, and the risk of breaking something is probably too high. Thanks for your help with it.
  17. Actually @argent77: when you say it 'fails to list available alignment entries' do you mean it doesn't list them at all, or that it gets them wrong? I'm finding that if I permute rows, I get the parent-class alignment table - kit is ignored.
  18. That's matching some of what I've just been finding. I got through character creation ok but was getting alignment anomalies. Will test a bit more, if only for my own curiosity. It offends my mathematical sensibilities to have arbitrary rules like this... EDIT: If I understand that correctly, won't it always be satisfied? I'm only permuting table entries, not deleting any. (But then, in that case I shouldn't have got alignment anomalies on my own run.
  19. That certainly complicates it, to be sure (not unmanageably so, but the cost/ benefit equation would change). I didn’t find that on my own testing but I may have missed something - will check again.
  20. That's one of the things I was interested in advice about. I think that the actual row number in kitlist.2da turns up in game in very few places. CRE files put the KITIDS entry from kitlist.2da into the kit field, not the row number. Likewise, opcodes 177, 318, 324, 326 check the ids number, So do BCS triggers. And of course rearranging the order of entries in kitlist.2da doesn't change which ids entry is associated with which kit. CLAB files appear directly in kitlist.2da and don't need looking up. LUA entries are from LUABBR, which looks up by rowname, not rownumber. Proficiencies are indexed directly via the proficiency entry in kitlist. And so on. The k_x_y 2das that associate kits to race/class combos do a direct lookup via kitlist rownumber. So far as I can tell that's the only place it's used. (And my code above updates them.) But: I admit freely that this is not my main area of expertise. If I'm missing something, I'd be glad to be told.
  21. This works, I think. DEFINE_ACTION_FUNCTION dw_reorder_kitlist BEGIN // parse kitlist to get number=>multiclas map ACTION_CLEAR_ARRAY is_multiclass COPY_EXISTING "kitlist.2da" override COUNT_2DA_COLS colcount READ_2DA_ENTRIES_NOW dw_kitlist_data colcount FOR (row=0;row<dw_kitlist_data;++row) BEGIN READ_2DA_ENTRY_FORMER dw_kitlist_data row 0 number READ_2DA_ENTRY_FORMER dw_kitlist_data row 8 class_id LPF class_is_multiclass STR_VAR class_id RET multiclass END PATCH_IF multiclass BEGIN SET $is_multiclass("%number%")=1 END END BUT_ONLY // destructively parse kitlist to get the data ACTION_CLEAR_ARRAY kitlist_contents COPY_EXISTING "kitlist.2da" override REPLACE_EVALUATE "^\([0-9]+\)[ %TAB%]+\([^ %TAB%].*\)" BEGIN SPRINT $kitlist_contents("%MATCH1%") "%MATCH2%" END "" BUT_ONLY // obviously it will change, this is just for neatness ACTION_CLEAR_ARRAY kit_number_map OUTER_SET number_new=0 OUTER_SPRINT kitlist_write "" // put the single-class data back ACTION_PHP_EACH kitlist_contents AS number=>data BEGIN ACTION_IF !VARIABLE_IS_SET $is_multiclass("%number%") BEGIN // single-class kit OUTER_SET $kit_number_map("%number%")=number_new OUTER_SPRINT kitlist_write "%kitlist_write%%number_new%%TAB%%data%%WNL%" OUTER_SET number_new=number_new+1 END END // put the multi-class data back ACTION_PHP_EACH kitlist_contents AS number=>data BEGIN ACTION_IF VARIABLE_IS_SET $is_multiclass("%number%") BEGIN //multiclass kit OUTER_SET $kit_number_map("%number%")=number_new OUTER_SPRINT kitlist_write "%kitlist_write%%number_new%%TAB%%data%%WNL%" OUTER_SET number_new=number_new+1 END END // write the data to kitlist APPEND "kitlist.2da" "%kitlist_write%" COPY_EXISTING "kitlist.2da" override PRETTY_PRINT_2DA // update the k_x_y entries COPY_EXISTING "kittable.2da" override COUNT_2DA_COLS colcount READ_2DA_ENTRIES_NOW dw_kittable_data colcount FOR (row=0;row<dw_kittable_data;++row) BEGIN FOR (col=1;col<colcount;++col) BEGIN READ_2DA_ENTRY_FORMER dw_kittable_data row col file INNER_ACTION BEGIN LAF remap_k_x_y STR_VAR file END END END END BUT_ONLY END DEFINE_PATCH_FUNCTION class_is_multiclass STR_VAR class_id=0 RET multiclass BEGIN PATCH_MATCH "%class_id%" WITH 7 8 9 10 13 14 15 16 17 18 BEGIN SET multiclass=1 END DEFAULT SET multiclass=0 END END DEFINE_ACTION_FUNCTION remap_k_x_y STR_VAR file="" BEGIN ACTION_IF FILE_EXISTS_IN_GAME "%file%.2da" BEGIN COPY_EXISTING "%file%.2da" override COUNT_2DA_ROWS 2 rowcount FOR (row=0;row<rowcount;++row) BEGIN READ_2DA_ENTRY row 1 2 number PATCH_IF IS_AN_INT number BEGIN SET new_number=$kit_number_map("%number%") SET_2DA_ENTRY row 1 2 new_number END END PRETTY_PRINT_2DA BUT_ONLY END END
  22. It does, so far as I can see. It's a very quick lightweight way of making a singleclass kit multiclassed, but it leaves out lots of features - the LUA table for one. I think it's mostly a curiosity. Do you know if there's any particular advantage of using 177 and EFFs rather than just 326? That does sound messy. I was thinking of something simpler - just run a function that reorders kitlist.2da and relabels the numbers in the k_x_y.2da files. Then you could call it after installing a single-class kit, and (unless I'm missing something) there wouldn't be any legacy-mod problems. I don't think that would be too hard to do - I might see if I can work something up.
  23. Partly for the sake of trying something new, I've been trying to get my head around how the kit system works on EE, especially with respect to multiclassed kits. Here's a quick summary of what I think is correct (and one proposal): if any of the various people who know this part of the engine better than me wanted to confirm (or deny!) that I'm understanding it correctly, I'd appreciate it. 1) The engine is perfectly happy for you to define a kit with a multiclass parent class. 2) The engine, and the chargen UI, are perfectly happy for you to assign a multiclass or single-class kit to the kit-selection 2da for a multiclass. 3) If you attach a single-class kit to a multiclass character, it overrides the relevant component class. So a Fighter/Mage could become a Berserker/Mage or a Fighter/Invoker, and the character will be listed as Fighter level X... Invoker level Y on the character page. (Indeed, that's how the existing Fighter/Illusionist is defined.) Since the component classes of a multiclass character determine the CLAB table, you end up using the kit's CLAB table for the relevant class. But since the multiclass controls the LUA table, you still use the vanilla multiclass HLAs. 4) Conversely, if you attach a multiclass kit to a multiclass character, it overrides the multiclass. So a Fighter/Mage could become... well, anything you like... though the character will still be listed as Fighter level X... Mage level Y on the character page. Since the component classes are unchanged, you draw the CLAB entries from the vanilla tables for the component classes, and any kit-defined CLAB is ignored (though of course you can do kit-specific abilities using a 318/326-gated AP_ in the component-class CLAB - I assume that's how QDMULTI works, though I haven't looked at the code). Since the multiclass is changed, you can sub in a kit-specific LUA. 5) The engine sulks (i.e. crashes) if you try to use a CLAB file defined in a kitlist.2da entry higher than 255. But it's otherwise happy to use kitlist entries as high as you like: it will cheerfully read names, descriptions, IDS entries etc from high-numbered kitlist rows. That means that the ceiling of 255 kits applies only to single-class kits: you can have as many multiclass kits as you like. BUT the single-class kits need to be first in kitlist.2da, or at least, any spaces after row 255 have to be for multiclass kits. (I appreciate there's also a problem if you use WEIDU's built-in ADD_KIT command, which is hardcoded to complain if you go above 255 kits. SFO's make_kit function doesn't have that problem, and I think argent77 also has a kit-adding function that avoids the problem?) If all that's right, presumably it would be sensible to sort kitlist.ids (and make the necessary adjustments to the k_x_y.2da files) after installing a single-class kit, so as to make sure single-class kits precede multiclass kits? (Otherwise you get quite a strong install-order constraint - install single-class kits first - albeit it only matters on quite heavily modded installs.) Am I missing any problem or subtlety that would arise from doing so? Has someone already written code to do it? (If not, I might write some myself.)
  • Create New...