Jump to content


  • Posts

  • Joined

  • Last visited

Everything posted by Avenger

  1. You need to configure language in the 'weidu options'.
  2. Avenger


    The DragonLance Total Conversion Editor Pro ( DLTCEP ) is an unofficial game file editor/checker/browser for Infinity Engine games. Data file updates and technical support are available in the forum. The main program is maintained at Sourceforge, on the GemRB project page. igi has written a tutorial on setting up DLTCEP.
  3. Lynx, are you sure it is a mod error? It works in the original, and the only difference is the engine. This might be the problem: The characters in the vanilla-engine save have *name in their "creature" field. The characters in the gemrb save have empty "creature" field and their proper name is being shown. I also opened the game files in NearInfinity and i get "*name" for the vanilla engine save but in the gemrb case i get "null (none)". This one, is a mod error. though: Edit: I think i found the cause. When i tried to open the f_*.cre files in dltcep, i got a message "creature will be reordered. harmless inconsistency". I then proceeded to save each .cre file. I then made a new save from within gemrb and voila SK can open it fine. If they resaved only a mod-supplied file by dltcep. The solution is just that, resave in dltcep before release. (Or fix the weidu script).
  4. The engines are compatible, you just need to use a newer version. Except PST, whose code was forked. Ah, you meant the original engine... well, in that case tobex
  5. Hmm, i thought snow works. IWD is full of snow, no rain. What didn't work in the original engine is fog.
  6. The second parameter initially was the number of wish choices set up, but then it was hard coded to 5.
  7. One thing that may have gone wrong is, decompressing an area may cause the game to fail. In this case you need to delete the tis from the override to get things go back to normal. I think this happens only in the original game.
  8. It is working only with the 'fist only' bit.
  9. Yes, the spells are hardcoded to not go over 50. I can confirm that, so you can be quoted
  10. I just guess what's your problem, but it seems, you need all files, not just the minimal install. So copy in all the resources and fix the paths. http://www.gemrb.org/wiki/doku.php?id=installation#installing_the_games
  11. Sadly, I can't tell you the magic weidu command of the day that would add a quest to bgee.lua. Because i've never gone too deep into weidu. ADD_JOURNAL TITLE sounds like what you need. From its doc: If the game is of an EE-type, this action patches BGEE.SQL or BGEE.LUA (depending on game version) with the provided quests and journal entries, so they will work with the EE-type journal system. You probably need to check your weidu version (240 should be ok). Then look at the changes it does to bgee.lua (it should go into the override). If it changed bgee.sql then you definitely have to upgrade (bgee.sql is an outdated file).
  12. Look for function buildQuestsTable() in bgee.lua. In order to have a quest you need to call: createQuest ( 74295 ) to create a group, and createEntry ( 74295, -1, 96383, {}, nil ) to create an entry.
  13. That is just garbage. The engine has 31 unused dwords after the flags. (and only 2 bits of the flags are used).
  14. Yeah, the limitation is due to a programmer's error in original bg, comparing zero terminated strings vs resref type. This was in multiple places, but gradually got fixed in EE's.
  15. 10 - bardsong 15 - inventory Both disable and reenable should work in EE.
  16. Sadly no. HasDLC("nosuchthis") returns true. You need to have a DLC variable set to 0 to actually get any negative result. And that's what you can do with SetPrivateProfileString('DLC','dlcname','0')
  17. I don't know if this helps. On windows, SetPrivateProfileString('DLC','dlcname','0') disables a dlc (HasDLC('dlcname') will return false). Sadly this won't work on tablets or linux. You can even use this cmd in the console. (without the leading C: prefix)
  18. This is because the spell 'Mislead' creates a copy of a player character that isn't a global creature. This creature has a name that isn't in the tlk table. PC's don't have more than 32 character length names, so this should be safe (it is used only when the strref name is null). You can probably use this to have differently named creatures using the same .cre (the .cre should have its short/long names set to -1). I've not tested this.
  19. 3 Crushing Reduce by Percentage is a vanilla feature, apparently. Except in iwd2, where it is save for half. Old DLTCEP effect desc might be using the IWD2 syntax only because at the time we didn't know how that bit works, except in IWD2. Save for half can be achieved in EE in a different way (special field, bit 0x100). Doesn't set to 0 percentage (2), or damage 101% (3) work just as you wanted?
  20. script_area is a script slot, like script_race, script_override, etc. The area script level should be different than the race script level. See scrlev.ids This slot is not present in the .cre structure, it is only stored in the area's creature entries (this is why it is called 'area' script level).
  21. OOps, i was wrong. "there is no way the opcode will ever touch player A." is not true Actually, it uses the source of opcode 146 (player A) for a lot of things. It would use player B as source only if it is coming from a save or something like that. Now i can only hope it is still the same as in the original, because i have my name all over this part of the code
  22. Well, tl;dr. But i looked at the first line where you used Effect: Opcode 146, target = (1 or 9), parameter2 = (0 or 1), resource = SpellB. By using target type 1, you effectively disabled targeting B. I wrote "The 'target' of 146/148 is your thief or whoever wants to cast a mage spell. " You made 'A' as the target of the effects. B is irrelevant for target type 1. Even with target type 9, where the projectile is targeted at B, opcode 146/148 will still get their target as A (original caster). Obviously, you don't do that if you want 'B' as target. I also wrote: It is always the affected creature who casts the spell in #146/#148 If you use target type 1, obviously the affected creature is A. Admittedly, i didn't chew myself through your whole chart. Maybe you want to show me this: SpellA: Ability Target: Living Actor -Effect: Opcode 146, target = 2(Preset), parameter2 = (0 or 1), resource = SpellB SpellB: -Effect: Opcode 12, target = 1(Self) = affects Player A I'm pretty sure this part is in error. If SpellA really affected player B, there is no way the opcode will ever touch player A. Maybe you could also add a displaystring (139) with the same targeting as opcode 146, to see if your 146 indeed targeted the intended creature.
  23. I've always gotten different results from that: Opcode 146: The source always does the casting. If p2=2 and target=(1 or 9), Source casts spell at "Preset Target" and this effect bypasses targets deflection/reflection effects (though its subspell's effects are still subject). Otherwise, Source casts spell at any/all specified target(s). Opcode 148: The source always does the casting when p2=0, and the spell is cast once for each effect target. The target(s) always does the casting when p2=1. With either p2 value, the spell is always cast at the ability target(point). To compare: Opcode 258 (activate sequencer) The target is always the caster, and is who must have the spells sequenced. Opcode 260 (activate sequencer at point) The target is always the caster, and is who must have the spells sequenced. Opcode 326 (apply effects list) The source always does the casting. Unless target = 2, this effect bypasses targets deflection/reflection effects (though its subspell's effects are still subject). When target=(1 or 9), Source casts spell at "Preset Target". Otherwise, Source casts spell at any/all specified target(s). Delaying the effects can further complicates the identify of "Source" and "target", as they revert to defaults if you save&reload before the delay expires. Using them further in Subspells also complicates the identity of "Source" and "target". The target of those effects is supposed to be the 'would be' caster of the spell stored in their resource field. You can test this by targeting them at someone other than self, but with a spell that targets self. You must see the spells affect the second guy, not the first.
  • Create New...