Jump to content

Celtic Minstrel

Global Moderator
  • Posts

    4,121
  • Joined

  • Last visited

Everything posted by Celtic Minstrel

  1. At the moment we're most interested in additional PC graphics, particularly Vahnatai but also potentially sliths or nephilim. If you prefer to do other types of art (for example, items or talking portraits), that would also be great. Terrain graphics are currently closed except for improvements plus a few specific things (see spoiler if interested). We want the graphics to match the aesthetic of existing graphics as much as possible. EDIT: To add to ADoS's post a little, it'd be great to have at least one graphic for each race in each of a few basic archetypes, such as mage, priest, rogue, melee fighter, ranged fighter. Other possible archetypes are monk or bard, though those aren't a priority.
  2. I have committed this to the repository. We still need three more Vahnatai PC graphics, though. Anyone interested? Most of what I said in the second post also still applies, but note that there is very little room left for new terrains now.
  3. Well, I had contemplated adding spider glands (an alternative to holly IIRC), as well as toadstools and... uh, the other one that was different between E3 and E2 (maybe that's crypt shrooms?).
  4. I'm not sure why. It's just how it is. Unicorn horns aren't included as an item in the base anyway, so I hadn't planned to make unicorns drop them. Asp fangs on the other hand are universally useful as an alchemical ingredient. The short answer is nothing: the hope is that there are enough possible flags and people will select randomly enough to avoid an accidental collision. It's not an ideal system. Yeah, it's very not ideal. Perhaps I should implement an additional check when stacking items - for example, don't stack them if the names differ, even when the type flag matches.
  5. Emphasis on "eventually". I have no intention of doing any functional work on the scenarios when the programs themselves aren't working properly. I'll be using different scenarios (some of my own, a tutorial scenario, and possibly Bandit Busywork) as an aid for testing any new features before I consider using any of those features in the original three scenarios. Seriously, you don't need to jump on me every time I mention nebulous future plans or ask opinions on how to handle things. I know legacy compatibility and consistency is important. I know bugs are more important than feature creep.
  6. I don't really agree on this and have plans to eventually make changes to the scenarios to have them make use of some of the new features, such as quests. (I guess someone who really wants to play the unaltered version could download the original .exs and play from that instead.) Well, I assume some people do. The reason why I need to deal with it one way or another is because when two items stack, one of the items is destroyed and its charges are added to the other item's charges. In other words, it's effectively arbitrary whether you get the stats from one item or the other. (Technically, I believe you'll always get the stats of the item you're already carrying, meaning the stats of the scenario item will be lost.) Hmm, good point. Player-summoned monsters never drop "glands", but monster-summoned monsters do, so this would have an effect if an enemy (or ally!) casts Sticks to Snakes. Maybe I'll reduce it drastically... 5% or 10% maybe? I believe that the fact that asps don't drop their fangs would be surprising to a new player (once they know asp fangs are an item), and it would certainly be surprising to someone who'd only played Exile III.
  7. I think you can't tell unless you see it use its breath weapon. In BoE, the animation is the same a cold or electricity, and it deals unblockable damage, so wouldn't be affected by items that protect from cold or electricity. I'd guess the message in the transcript would be the best way to tell. It wouldn't really surprise me if people just assumed the Dark Wyrm should have darkness breath because of the name, but I would like to be as certain as possible. (Maybe someone could hack a Dark Wyrm into the crystal soul in a save file and test it that way?) EDIT: Also, does anyone else have opinions on what do do about the different missile stats in the three original scenarios? And the different value of the Smoky Crystal in one case.
  8. If I recall correctly, scry monster in legacy BoE did not show what kind of breath the monster has. I don't know if that was different in E3, though.
  9. The Wand of Nullity creates antimagic fields... at least, that's what its ability is set to in the Blades Base. I suppose that itself could be incorrect.
  10. I noticed a few more weird things - the Archer's Bow and Wand of Nullity have the concealed ability flag. The former has no ability at all, and the latter's ability seems somewhat obvious from the name. Are these items supposed to have a concealed ability? Is the Archer's Bow supposed to have some special ability?
  11. I'll try to compile a list. #2 is easy since I can just search for the flag in the source (in fact there's a list already in the repository, which I think is still complete); #1 and #3 are a bit harder and would hinge more on memory and/or old bug lists... or even comparing against the original code. (And the legacy flag is indeed set to true in ported scenarios and false in newly-created scenarios; there's no UI way to toggle the flag, though the scenario editor will offer to turn it off if it's on; it doesn't force it though. To turn it on you'd have to edit the XML.) Can we get back on topic now? This thread was supposed to be about the Blades of Exile Base, not mechanics.
  12. #1 and #2 applied. They also had an ability strength of 8, which was ignored by the game and had no effect. Other than bug fixes (like using the archery skill for archery, instead of... I think it was defense?), I think there might be a few numbers that are off by one or two compared to original BoE. There are some definite mechanical changes (or bigger bugfixes) that are disabled with a special flag in the scenario, such as resurrection balm being required for resurrection, or timers being triggered while resting (that was Ormus IIRC). There are likely also a few mechanicla changes which are unintended consequences of one thing or another, which could be considered bugs and eventually fixed (I think I recall something related to dumbfounding). So does anyone else have comments on the mysterious item stat changes in the preset scenarios? Or even on the Dark Wyrm?
  13. The latter is generally what I've done, actually - I changed the scale of the ability strength for certain abilities, but set the porting code to adjust the strength accordingly. (I don't recall the details off the top of my head, but it's easily looked up in the cItem::import_legacy function in the code.) The question here was more inclined towards questioning whether the behaviour of Micah's Gloves was in error (and should be corrected in the bladbase only, for future scenarios; that wouldn't affect older scenarios that used Micah's Gloves), but after this discussion (and realizing that the ability had always been a flat bonus irrespective of level or ability strength), I'm inclined to think that perhaps the question was misguided from the start. The asp dropping asp fangs is, similarly, something that would not apply retroactively to old scenarios, as it's a change to the Blades of Exile Base. Thus concerns of keeping things identical aren't quite the same as they are when fiddling directly with the game mechanics; several items have been tweaked already, such as Ogrish and Giantish Gauntlets (which were originally identical in effect). In Blades of Exile Base, the following stats are used: Darts: level 6; value 1 (for simple), 3 (for iron), 15 (for magic) Throwing Knives: level 9; value 2 (for simple), 7 (for iron) Arrows: level 11; value 1 (for simple), 7 (for iron), 25 (for magic) Javelins: level 12; value 2 (for simple), 8 (for iron) Bolts: level 14; value 2 (for simple), 12 (for iron), 50 (for magic) In Valley of Dying Things, the following stats are used: Darts: level 6; value 1 (for simple), 3 (for iron), 15 (for magic) Throwing Knives: level 9; value 2 (for simple), 6 (for iron) Arrows: level 12; value 1 (for simple), 20 (for iron), 40 (for magic) Javelins: level 12; value 2 (for simple), 12 (for iron) Bolts: level 17; value 3 (for simple), 40 (for iron), 80 (for magic) In A Small Rebellion, the following stats are used: Darts: level 6; value 1 (for simple), 3 (for iron), 15 (for magic) Throwing Knives: level 9; value 2 (for simple), 7 (for iron) Arrows: level 11; value 1 (for simple), 8 (for iron), 25 (for magic) Javelins: level 11; value 2 (for simple), 8 (for iron) Bolts: level 14; value 2 (for simple), 12 (for iron), 80 (for magic) (As a side note, Smoky Crystal also doubles its value in ASR - 200 instead of 100.) In The Za-Khazi Run, the following stats are used: Darts: level 4; value 1 (for simple), 3 (for iron), 15 (for magic) Throwing Knives: level 7; value 2 (for simple), 7 (for iron) Arrows: level 9; value 1 (for simple), 20 (for iron), 40 (for magic) Javelins: level 8; value 2 (for simple), 12 (for iron) Bolts: level 14; value 3 (for simple), 40 (for iron), 80 (for magic) Basically they're kind of all over the place. It seems particularly weird that they're the same items (same name and everything), but in several cases they do different amounts of damage (because different item levels). I could imagine that this was done to balance the individual scenarios, but the issue is, what if someone brings arrows from a previous scenario? I need to make them all the same, make them not stack, or carefully codify what happens when slightly different items are combined (which is to say, make an intentional decision and implement it, rather than just letting it work out however the code happens to be).
  14. I'm saying they always had the "Intelligence" ability, without referencing exactly what that ability does; and that in BoE they had an ability strength of 8. Calculation of the Int stat adjust does not reference the ability strength of Intelligence items, only checks for their existence, and that has not changed from the original code. I think the mindduel effect is new, though. It simply adds the total ability strength from Intelligence items to your total effective Intelligence for the purpose of mindduels (with a max of 20). Given all this, I guess exactly replicating the original item means it should have an ability strength of 0. Ported Micah's Gloves from other scenarios currently get an ability strength set equal to their item level, but that could easily be changed to force it to 0 always to preserve the older behaviour (ie, no bonus in mindduels). I guess I'll go implement both of those. Do you have any comments on the other points from the initial post?
  15. Pretty sure they've always had the Intelligence ability in Blades of Exile. Glancing over the code, it looks like that currently both affects your effective intelligence level and separately affects the intelligence "stat adjust" used for magic. However, the only place the former is actually used appears to be in mindduels. So what you describe is pretty much exactly what they do, though I think the mindduel effect wasn't there originally. More importantly... should the ability strength be raised? Based on the code, this would only affect mindduels, as the "stat adjust" only checks for the presence of the ability and ignores the ability strength. (In fact, if you wanted them to not affect mindduels at all, setting the ability strength to 0 would give that without any need for code changes; ignoring ability strength also means the stat adjust functions even when the ability strength is 0.) The only reason I suggested 8 for the ability strength is because that was the original ability strength set in the Blades of Exile Base.
  16. I've lately been going over old threads discussing errors in the Blades of Exile Base to ensure that all reported errors have been fixed. Most of them were already, and I caught a couple more that had not even been spotted (such as Feldspar Charm, found by comparing to the preset scenarios). There are, however, a few things that I'm still not sure of. The Dark Wyrm - should it or should it not have darkness breath? Someone suggested it should in another thread, but they seemed unsure. (I have E3, so I could check for myself if I knew where to find one at the beginning of the game with a god party - ie, not a hidden town.) I set asps to drop asp fangs with 60% chance, but maybe the percentage chance should be less? Also, I kinda wonder if any other preset monsters should have similar fixed drops. The scenarios disagree with the base on the stats of several of the missiles - arrows, bolts, and javelins. This would probably be troublesome when mixing these items from different scenarios, since they would stack, and whichever one was in your inventory first would take priority. Should I change them all to match the base? Or maybe change the base to more closely match the scenarios? I could also just give them a unique type flag so they don't stack with regular ones. Micah's Gloves has an ability strength of 1. Originally, it had an ability strength of 8, but the game ignored the ability strength. Should it be put back to 8? (For those who don't remember, Micah's Gloves boost your intelligence stat.) And finally... does anyone know of any additional errors that might have never been found? I used this thread and the linked Lyceum articles as my primary reference, so if it's mentioned in one of those places, I probably got it. The fixed bladbase is here; if you can get the scenario editor working and want to view it in the scenario editor, you can download that entire directory (one file at a time, unfortunately), then navigate to the "header.exs" file from the scenario editor (may require setting the file dialog to show "legacy or unpacked scenarios"). It's fairly human-readable too though, at least if you know what all those numbers mean (most are documented somewhere in the BoE documentation on calref).
  17. That was probably an endianness problem, which should be irrelevant now that everything's stored as compressed plaintext on disk. Endianness in particular shouldn't be relevant here, but some other difference in OS versions could be, I suppose.
  18. Hmm. I can't rule out the possibility that my old Mac is simply incapable of producing a build that works properly on modern Macs, though if that were the problem I would've expected crashes rather than subtle bugs like this... but the OSX APIs are Objective-C, so who knows. For my part, I was (by coincidence) doing both the things you described earlier today, without any trouble, so whatever the problem is doesn't show up on my computer, which makes it difficult or even impossible (if it's really due to library versions) to fix. It might even be necessary to get someone else to handle packaging for the Mac builds...
  19. ...what? Both those things work perfectly fine for me on the latest master (which only has a few changes relative to the linked build). What the heck is going on here... I suppose it might help if you tell me exactly what happens when you attempt to do those two things, but it seems like a long shot...
  20. ... Well, I suppose that's a possibility. I think I'd prefer something that doesn't shell out to an external text editor, honestly. Anyway, shelling out to an external text editor is likely not as easy as it sounds.
  21. The new scenario format (which is .boes instead of .exs) is literally a tarball with a specific directory structure. So yeah, it's compressed. (I guess designers might still pop it into a zip so they can add a readme, though.) Find/replace functionality for strings would certainly be great; you can already open the XML files in a text editor and use the find/replace there, but, well, that's quite a bit less convenient - you need to decompress the scenario first. (You don't need to recompress it though, since the editor can work just fine with a folder that has the same directory structure as a scenario tarball.)
  22. So basically, you're favouring the idea of parsing item descriptions based on whether the item is identified? I'll note that this by itself doesn't do much about eliminating duplicates, though. Size is not the only concern with duplicates. It makes it harder to work with descriptions when several items have the same description, because when you want to change that description, you need to change it in several different places.
  23. Okay, now can I get feedback from people who aren't ADoS? If I only wanted feedback from ADoS, I wouldn't've bothered to post here.
  24. Well, here's a new build for Mac and Windows that fixes some (but probably not all) of the bugs people have reported.
  25. Okay, first of all, let me respond to a couple of things that I missed (or more accurately, skipped over) before. I don't think the item descriptions need to be just boring physical descriptions. I think physical descriptions is their primary role, but there's no reason why humour and additional background info can't be included in some cases (like mention of the sliths or vahnatai). I do think descriptions of the item's properties and uses are a little out of scope (with the possible exception of some items with concealed abilities; I'm mainly thinking of the mist globe here). About swapping graphics... well, that just kinda makes the situation even worse in my opinion. My point is that identifying the item does not change its appearance. If you're swapping the description when it's identified, it doesn't necessarily suggest that the item looks different when identified. If you're swapping the graphic, well... suddenly identifying an item changes its appearance. If you accept that the item descriptions function as a detailed physical description of the item, then it's obvious that the item description should be the same independent of whether the item is identified. On the other hand, from that premise it's also obvious that some items would need to have descriptions which effectively identify what they are, even when they are technically marked as unidentified. For example, "This is a large shield with the name KLIN inscribed on the back." makes it obvious that the item is, in fact, the Shield of Klin and not some other generic shield. Or, "It's a small rock with bits of glitter in it." makes it obvious that what you have is not an ordinary rock but is in fact something more valuable, such as silver ore or rough diamond. So there's a clear problem with accepting that the item descriptions function as a detailed physical description of the item, even if you accept in the first place that that's what they're for. Now, the basic premise - "item descriptions are primarily a physical description of the item" - does not necessarily contradict a system where identified and unidentified items have different descriptions. You could argue that the identified description simply includes additional details that you had not noticed before you identified the item. But when those details are things that you could have easily noticed just on a cursory inspection, it kind of strains belief. Personally, I don't think it's necessarily a bad thing for item descriptions to sometimes hint that the item is more valuable than it appeared at first glance, nor do I think it's necessarily bad for a few items to have unique descriptions that instantly give away what they are, though I would prefer to avoid the latter as much as possible. Still, even in such a system, instantly knowing what the item is doesn't tell you its stats (unless you're metagaming and looking up the stats outside the game). So it's still useful to get that item identified even though you technically know what it is. ----- Now, on to what ADoS just said about the complexity of my earlier proposal. It's true - it's a complex proposal. (I'm particularly uncertain on point #3.) From the designer's perspective, they would be presented with a dialog offering two separate descriptions, but one of those descriptions is shared by multiple items, and changing the item's unidentified name has the side-effect of altering its unidentified description. I'm not entirely satisfied with the solution, which is kinda why this thread exists in the first place. As for your alternate proposal... well, referencing scenario strings is definitely possible. It's not even particularly difficult. However, it causes problems when you leave the scenario, and/or when you enter a new scenario. Copying the strings into the item properties does kinda work as a solution. It feels like an ugly solution, but it's doable, certainly, and it's quite true that it solves any problems of fully-duplicate descriptions (though it doesn't solve partially-duplicate descriptions). In summary... I don't like your solution, but I can't see any strong points against it, either. ----- On an unrelated note... something needs to be done about preset items. These are the starter items that are given to your PCs at character creation time, as well as the potions made with the alchemy skill. Not only do they lack a description currently, they also don't stack with equivalent items in scenarios (when applicable - eg, arrows).
×
×
  • Create New...