Skye

Thanks for the additional playthroughs. I know Ken has been working on making dialogue triggers more natural in cases where Ayden isn't initially in the party, but I'll bring the scroll bit to his attention just to make sure it doesn't slip through. I appreciate the feedback on the imp. It was initially just supposed to be a simple money stash because Ken got pissed off that he lost his money in SoD and then again SoA and, since you can't really stash the gold manually from your inventory, we decided to make it an NPC and give it a bit of character. The imp does play a somewhat bigger role in BG2 (including calling in the favor that was promised), but we'd love to hear if you have any ideas on how to improve on it in BG1 so that it's a bit more fun. I'm glad you like the Refuge. Making it grow dynamically has been a big challenge for us and we're very proud that we managed to pull it off.

1) Yeah, warlocks actually get spear and mace proficiency by default. We figured if warlocks get to use them, all thieves might as well. They fall in the simple weapon category in 3E anyway. They don't get to use wands by default but, as mentioned, we consider that to be part of the standard rogue package, so that's why the component exists. But yeah, they're both optional. I don't really find myself using the wands much with thief characters but YMMV, obviously. 8 ) I'll admit, we did hide that more than we probably should have. When selecting where you want to shadow walk, you have to ask Ayden to take you "somewhere special". After that, he'll transport you to the Refuge. It should at least be hinted at how to get there in the readme. The reasoning was that everyone would be curious enough to see where that option leads. Then again, the refuge used to be a very small island with a chest on it and now it's a full-blown stronghold area. He should probably take you there on his own if you don't ask him for a while. I'll open an issue for that. 10) It's an interesting idea. I'll pass that along.

Hey, Sergio. Thank you so much for trying out the Ayden Project. We've put a lot of work into it over the years and it's always nice to get some feedback. One of the members relayed your review to Ken and he wrote up a reply for you. In the future, if it's not too much trouble, please tag me in the message or post things in the mod thread, so that we get a notification. We would have completely missed this otherwise. We've already opened up several issues in our project tracker and the changes are due to be included in v2.7. Some of the bigger changes (like having Ayden stick around if you reject him at the beginning) probably won't make it into that one though.

Version 2.6.19 is out. It contains mostly fixes and minor additions for v2.6. The download link remains the same. Changelog: Reset weather when shadow walking to prevent it from following. Recovered missing icon for dimensional lure. Added new spell states for several invocations and abilities. Improved Ayden's SoD integration. Fixed random encounter difficulty algorithm. Injected some color into this bleak existence. Added combat delay to warlock AI to further mitigate friendly fire. Fixed some incorrect item recipe strings. Fixed incorrect journal entry for Forged in Fire quest. Added animation-covering polygon to astral mimic. Added new crafting components and craftable items. Added new checks for potentially missing items. Added wand usage for random encounter mages. Added new curse eater abilities.

We'll keep track of known issues in the top post to reduce the amount of redundant reports. Ones that are striked out are fixed for the next release.

That is almost certainly the case and the mod relies quite heavily on existing areas being how they are in the original game, so who knows what exactly happened. There's probably a random cauldron in the middle of Brynnlaw and whatnot.

Maybe nothing, maybe everything. Neither of us has bothered testing it on EET yet since that's a low priority ticket. That said, any reports of what does or doesn't work on EET will help us a lot when we start working on compatibility, so feel free to experiment.

Free a powerful warlock from his imprisonment and venture with him on a quest to find the lost Nether Scrolls. Discover a new way of unleashing arcane energies with a brand new thief kit: The Warlock. Quickly travel vast distances across the Plane of Shadow if you dare to brave its desolate environs. Relax and store your equipment in a planar safe haven. Unlock new features and forge alliances in this astral stronghold. Brew potions and craft powerful artifacts to enhance your strength and devastate your enemies. Introduction: Ayden is a mysterious warlock that's been magically imprisoned on another plane for decades. You will originally encounter him in Ulcaster Ruins, struggling to find his way back to the prime material plane. Should you help him, he will become a loyal companion and friend to you and will open up a world of new opportunities. Over time, you will get to know many things about him, his past, and the place he comes from, which will affect your actions and perhaps even the way you perceive the world around you. Where will the road ultimately lead you as you approach godhood on your quest? Who will you put your trust in? What to expect: A new thief kit: The Warlock. It comes with its own set of custom abilities and an AI script for convenience. A fully-fleshed out companion NPC that uses the new kit and will interact with you and the world around him. The ability to quickly move to any major area through the Plane of Shadow. Your very own pocket plane that will serve as a stronghold and staging area for your adventures. Several brand new areas and quests (with more on the way). More than 30 new (or familiar) enemies and a handful of new allies. A simple crafting system that will allow you to more easily acquire the gear you need. A number of new items, some for crafting purposes, others for fun. A couple of additional convenience components to make thief classes more fun. Known Issues in v2.6.19: One of the script actions is missing a parameter, emitting a warning. Ayden may lose his ability to ignore reputation breaking points Invocations may disappear from a warlock's repertoire if they are killed during cooldown. Some of Ayden's comments may pop up instantly upon recruiting him if the preconditions have been met, even if he was not in the party at that time.

I must have misunderstood how using multiple keys works. I thought $x(a b) = 1 was equivalent to $x(a) = 1, $x(b) = 1. The explanation of the array construct makes more sense now (any number of keys, single result). How does one do PHP_EACH with multiple keys though? Is that what the additional rows and columns arrays are for?

This macro will spit out a "2-dimensional" array structure for a given 2DA file. Since there's actually no such thing as a 2-dimensional array in WeiDU (to the best of my knowledge), it can't be a function. It needs to return a variable number of arrays (depending on the size of the 2DA file) for it to work. Also, I'm pretty sure I've seen this before somewhere, but I was bored and Google wasn't being helpful, so here it is. Once a 2DA file is consumed, you can easily reference any value in the table. For example: As a side note: While this will fill out any empty cells with the default value, just like the engine would, it will crash or malfunction for any 2DAs in a non-standard format (e.g. missing headers, repeating row ids, etc.). I wanted this to be an associative array table, but the macro would probably be more robust if it was numeric. YMMV

The new patch function is posted in the macro thread if anyone stumbles upon the same problem in the future.

Ken created a patch function that adds an arbitrary polygon to an area's WED and updates all the wallgroups: Example usage: Let me know if you find any issues with it so that we can fix it.

Thanks, I'll see if it comes in handy. Once we write a complete macro, I'll post it in that thread to save others some trouble.

Does anyone have a handy WeiDU macro for adding new polygons to wall groups in pre-existing areas? We are considering writing our own, but I figured we should ask first to save us some frustration. It seems straightforward enough, but working with binary data and offsets and counts generally leads to a lot of gray hair and corrupted files.

Ken and I have recently released our Ayden Project mod (we're still waiting for a G3 release, but it's available elsewhere), and we are currently working toward releasing the next version with some major content updates, including some new areas.

Yeah, we always start by studying the file formats and any relevant tutorials in order to understand how things work. I think we've managed to connect all the dots of how doors work, now it just comes down to execution and figuring out all the engine quirks.

I'll give this a shot. I feel like it should work, but there will no doubt be a lot of frustration involved, as is usually the case with map making...

I have an area where I would like certain parts to be passable or impassable periodically. Is there a way to dynamically block movement through a region on the map? I was thinking maybe an undetectable door that opens and closes via script. It has a blocking region and its own open/closed appearance, so that's convenient. Has anyone worked on anything with a similar effect? What was your approach?

Thank you. We will study those mods. If nothing else, we'll learn something new.

I see. This is poorly documented in IESDP too, then. Good to know if I ever decide to mess around with the table again. As long as all of us are a little bit wiser now, it wasn't a waste of time, I guess. I use that for certain parts of my mod, but it's not good enough for what I'm trying to achieve. I guess I'll look into modding the UI. Maybe I can achieve the same result with a custom panel and some Lua.

Doesn't do me any good. I also need the kit to start receiving HLAs very early, so it's not just about the ability table. You seem to be correct. The old BG:EE UI has the Abilities button. The SoD one does not. I suppose I could mod the button back in with a GUI mod. To answer some of my own questions: Despite IESDP saying otherwise, there seems to be no way to add a custom kit to LUNUMAB.2DA. As far as I can tell, the game ignores it. HLAs are theoretically available in BG:EE, but the GUI elements are missing in SoD UI and need to be added back in with a GUI mod. It is possible to define more than 24 HLAs in the LU*.2DA table, since the HLA screen is now scrollable and not just a fixed grid. The MIN_LEV field seems to behave strangely, at least with HLAs past the initial 24. Need to research it further. The rates in LUNUMAB.2DA can be decimals (0.5 seemed to work fine for 1 point/2 levels). At this point, unless someone knows something that I've missed, there doesn't seem to be any way for me to make a custom HLA progression for my kit, so this whole idea goes down the drain. My disappointment is immeasurable and my day is ruined...

We are attempting to make use of HLAs for one of our custom kits in BG:EE, with no success. The LUABBR.2DA has the correct suffix for the LU*.2DA file, we added the kit and set the correct values for it in LUNUMAB.2DA, but when a character levels up, nothing seems to happen. I tried to modify a standard thief's HLA gain rate in LUNUMAB.2DA and it just gets stuck at the level up screen, with no way to select an ability, but no way to finish leveling up either. In light of all that, I have the following questions: Are HLAs simply not available in BG:EE due to GUI limitations? Is there any way to enable them short of porting the entire game to BG2:EE engine? Can you even specify custom kits in LUNUMAB.2DA? It seems to disregard my entry entirely. Is it possible to specify more than 24 abilities in the LU*.2DA file or does the engine stop parsing at line 24?

So, I did test my theory and it turned out to be true. I also needed to update the BAM indices manually since argent's functions don't really support image resources that use the same PVRZ page. Doing so does have the added perk of being able to name your PVRZ files whatever you want though, which makes things a bit easier to work with. LAF FIND_FREE_PVRZ_INDEX RET large_pvrz_index = free_index END COPY ~project/pvrz/icons_large.pvrz~ ~override/MOS%large_pvrz_index%.pvrz~ COPY ~project/bam/mybam01.bam~ ~override~ READ_LONG 0x001c data_offset WRITE_LONG data_offset large_pvrz_index Something like that works just fine. Of course, if the BAM file were to have multiple data blocks or PVRZ pages, one would need to do a bit more work.

Yeah, what caught me off guard was that the script kept running after I had already left the area. That was just weird. But I do have a better idea of how trigger regions actually work now and I've completed the entire area without too much trouble.

Looking at the source code, from what I can tell, it only makes a difference if your BAMs use multiple PVRZ pages. You can then foreach through all of your PVRZs and update their indices to the new block indices that you got from UPDATE_PVRZ_INDICES. So for small images, like spell icon BAMs, you're probably better off copying them by hand to reduce the amount of unnecessary code.