Jump to content
  • Announcements

    • AndalayBay

      Orphan Attachments   07/31/2018

      I have been doing some housekeeping lately and I've noticed that I had a lot of orphaned attachments. Attachments get orphaned when the PM or post is deleted without removing the attachment first. Deleting a PM or post does not delete the attachment and the file or image remain on the server. I'd like to ask all members to go through their attachments and delete any attachments you don't need anymore or those that have been orphaned. Where can I get a list of my attachments? Click on your display name in the upper right corner of the forums and pick "My Attachments" from the drop-down list. How can I tell an attachment is orphaned? If the PM has been deleted, you'll see a message like this in your attachment list: Unfortunately there is no message if the post has been deleted, so please check your old posts. We do purge old birthday threads every once in a while. Also some hosted projects have been shut down, so you may have orphaned attachments on one of those locations. Thanks!

Munch Universe

Project Lead
  • Content count

  • Joined

  • Last visited

  • Days Won


Munch Universe last won the day on September 23 2017

Munch Universe had the most liked content!

About Munch Universe

  • Rank
  • Birthday 06/21/1962

Profile Information

  • Gender
  • Location
    Baden, Germany

Recent Profile Visitors

577 profile views
  1. Craftybits 0.812 Bug Reports

    Hammering a hardwood or softwood plank to make a wood panel is not working. The script is running and recognizes the hammer, but the menu isn't coming up and I'm not scoring any hits on the board. I've tried some debugging but without success. HoundAkragth, if you find the time, perhaps you can have a look and see if you spot anything amiss. CBWoodHammerQS is the script in question. CBWoodCarvingQS is very similar, just uses a blade instead of a hammer and it is running as it should. That may help to track down the problem. I'll have a look myself in the AM when I'm fresh but right now I'm just spinning my wheels.
  2. Craftybits 0.812 Bug Reports

    OK, that is convincing. I'll make the change. Thanks very much for your help. EDIT: After a closer look, I see that the basket is a dynamic reference. It used to be a permanent reference, as described above, but I found it could be dynamic and changed it several years ago. But factoring in AndalayBay's tips, I'm wondering if the change may play a role in the current problem. It would be easy to switch back to a permanent reference, should that be necessary.
  3. Craftybits 0.812 Bug Reports

    Correct about the comment being erroneous, or more correctly obsolete. It now reads: elseif eval( iProc == 1 ); meat and fish conversions set Equip to 1 Player.PlayGroup CastTouchAlt 1 set Num to rConvRef.GetRefCount Player.AddItem rNew Num Originally iProc 1 covered other things, but they were systematically removed, leaving only the meat and fish conversions. I believe the stack conversion will work fine, I just hadn't thought of it. In theory you are right about the lack of rConvRef.Activate but there are only two conditions in which Equip is set to 1. In one case, it requires a drawn weapon, making the activation unnecessary and in the other we're converting fish or meat, so there is no need to activate. I'll add a note for future reference but leave the code unchanged. You are right about if eval( nameIncludes $sInclude rConvRef && GetObjectType rConvRef != 25 ) not working. I discovered the problem during testing and fixed it. I like your suggestion to speed the code and verify type. I implemented this way: if eval( Grabbing == 0 && rConvRef != 0 ) ForEach arTemp <- arConvert if eval( ar_HasKey arTemp["Value"] 4 ) if eval( arTemp["Value"][4] == 1 && rConvRef.GetObjectType != 25 ) continue endif endif I added a second 'if' to ensure they are executed in the right order. If memory serves, obse handles statements connected with && from right to left. By doing the value check first, it ensures it runs first and the other two do not run unless that one is true, whether my recollection of the order of execution is correct or not. The array check with key 4 can cause a crash if there is no value there, so it should be contingent on the presence of a value. I'm in the process of some in-game testing, so I'll run some tests to see where things stand.
  4. Craftybits 0.812 Bug Reports

    So far we haven't used any command specific to OBSE 21, but there are some from OBSE 20, so that is what we've been using as the requirement. Given the slightest need, I wouldn't hesitate to require 21, there just hasn't been a need so far. Music is working, at least to a degree. It could be that it isn't working on all NPCs, but certainly it works on some, since I've tested it and seen things added to the basket. Even if it is slightly broken, it may not matter since the in-game result seems about right. Which is not to say that I am not interested in a fix, only that I had no idea there was a problem. I appreciate the help. As HoundAkragth pointed out, the first problem is figuring out how to test it properly. If the basket is not set to be owned by the player, what happens when the player finishes and goes to pick up the basket? Without SetOwnership, the ownership is that of the ground it is placed on. Sometimes that won't be a problem, but in other instances it could lead to your basket belonging to someone else. There may be an easy way around that problem, but it could be a problem that needs to be dealt with. The MusicBasket is a permanent reference, normally stored in the basement of the CBGuildHall, a hidden cell added by CB, and transported to the player as needed. Perhaps if it is assigned to the player first, SetOwnership isn't needed. SetOwnership is also a bit tricky because I've found it often behaves like a return or at least can impact code downstream of itself. So I try to put it as late in a block of code as possible. Thanks for the tips regarding the BonePile. It tests successfully in game, but it is possible I've always opened the bone pile when testing and thus never seen the problem. I'll get back to you on the CBKey suggestions. They look good.
  5. Craftybits 0.812 Bug Reports

    I'm getting a crash whenever I get close to the canoe. Close enough to see it as something I can activate but before I actually do anything to it. Can anyone confirm this as a bug? EDIT: Found and fixed the problem. Two of the canoe scripts for the canoe were of an older version in CB-Marooned. They were overwriting the newer versions and caused the crash. After having updated CB-Marooned, the canoe crashing ceased. I'll update CB-Marooned when the rest is ready for general release.
  6. Craftybits 0.812 Bug Reports

    Regarding forging rings, I guess the truth is that we never really thought about it in any detail. I implemented it but I think CLShade and Ben were involved in conceiving of it. Now that you mention it, you have a point. It depends on what metal is being used. Gold, silver and copper melt at forge temperatures so that casting is an option. To fully melt Iron needs higher temperatures not readily achieved in a forge without bellows and I think even then the temperatures are better for getting it hot enough to work but perhaps not enough to liquify. One argument for casting is to illustrate the process, even if hammering would be another way to get the same result. I'm afraid I don't quite track what you mean with "tanning". As in tanning leather? But if so, what does that have to do with nutrition? Or do you mean as in skin becoming tanner? Assuming you are talking about tanning leather, that was intended and might well have been the next major thing to be implemented. Introducing bulk salt was, in part, preparation for tanning. We have acorns to provide tannic acid and urine can be assumed to be readily available. I think what pushed this down the list of things to do is that making leather production take some time and more complicated leaves it less useful to the player than metal forging. We already have that problem with clothing, where there is a nice tailoring system but it is involved enough that the player needs to work hard for something relatively cheap while something rare and expensive can be made with comparative ease. There is no obvious solution to this problem because making smithing even more complicated does not seem wise, in this case more from the scripting side because the player experience isn't overly complicated. I'm looking forward to see what you come up with for the retexture. If nothing else, it is enough of a change to rate a short explanation and perhaps gather a little attention on the Nexus for a week.
  7. Craftybits 0.812 Bug Reports

    Thanks for the warning. If Oblivion was a strictly medieval European simulation, pemmican would be out of scope. But as you are certainly aware, Bethesda didn't design the game to be a strict medieval European simulation. In fact TES3 Morrowind leans pretty heavily on Native American culture and as you point out, the flora (and fauna) are not all derived from Europe. We've talked out this kind of thing in the team in the past. We do have the ambition of trying to be "realistic" but it is best to take the games and lore as a given, describing a foreign civilization on a foreign planet at some unknown time in history. If you consider the level of technology, it depends a bit on where you look. For the most part it is roughly Renaissance (availability of full plate wasn't until around 1500 plus or minus 2 decades) but the ships are probably about a century more advanced. The Dwemer ruins employ steam technology which is roughly Victorian in look and feel, but given that it works without maintenance for thousands of years, it is far more advanced than anything we have today. So Bethesda doesn't make it easy for us. I'm guessing what you are calling protein poisoning is gout, a very painful swelling of the joints as a result of the accumulation of urea in the blood, which precipitates and forms deposits in the joints. Scurvy is caused by a lack of vitamin C and indeed, flavourings can help to provide at least some of the required vitamins. Most of these would affect the player over a time scale a bit long for the game. I suppose you could play for a year or two of game time, but in my experience about 2 months will get you through the main quest pretty easily. The whole disease system in Oblivion and all the TES games is really pretty absurd, but there probably is no good solution to the problem. Imagine playing for 7 weeks of game time and on the threshold of completing the main quest, your character comes down with the plague and dies. It would be entirely realistic and entirely frustrating. So sometimes we need to concede the limitations of the format and not worry too much about "realism". Don't worry too much about digressions. Often they lead to interesting ideas. I'm old school. An email which is longer than 2 paragraphs is not impolite in my book. If you know a lot of "useless" information, you are perfect for CB, since it is mostly a collection of "useless" information. The whole point to being interested in "realism" is so that stuff you learn in the context of playing a silly game might actually relate a bit to the real world and teach you something you may profit from. We strip complicated activities down into a few steps, but you do gain a little insight into things like cooking, construction and smithing. Maybe it is enough to spark some interest and get someone to look into these things in the real world. To me, that would be the real pay off for taking the time to develop CB, along with the comradeship of the virtual friends I make this way. EDIT: With regard to the retexture, we are not in a hurry and if you would like to do it, that would be great.
  8. Craftybits 0.812 Bug Reports

    This was hard to understand until I got into the weeds of the script. Once I did, it was clear as it could be. It is possible this will not work out as it should when the option to add to inventory is not set. But if that proves to be the case, it is easy to use the variable to place one or the other as the situation requires.
  9. Craftybits 0.812 Bug Reports

    The early pre-emptive reset is intentional because it was necessary to clear variables otherwise carried over from an earlier version. Anyone who started using CB in the last several years (around 3-4) won't be affected. Though I suppose if the script was midstream when saved, then this reset kicks in, it would delete a soapbar. As a result, I commented out ; set rSoapRef to 0 not needed, could delete a soapbar on game start The old version doesn't need rSoapRef set to 0, it was only a wish to reset everything unless known to be counterproductive which included it in the list.
  10. Craftybits 0.812 Bug Reports

    I decided to add two protections from this bug. The main fix involved moving acquisition of the original properties out of the Horn if statements so that they are now unconditional. The second protection was to ensure that a set value is never 0. This should no longer be necessary if the first fix works, but I also see no cost to the protection aside from being a tiny fraction of a second slower. If one of the values is already 0 and should stay that way, failing to set it to 0 will not matter. In any other case, if somehow a 0 slips in here, we no longer need to worry about it overwriting a non-zero value. ; get original properties of parental bow set CValue to (GetGoldValue rBow) set CHealth to (GetObjectHealth rBow) set CDamage to (GetAttackDamage rBow) set fCSpeed to (GetWeaponSpeed rBow) ; modify properties based on materials if Horn == 1 set CValue to CValue * 1.1 set CHealth to CHealth * 1.1 set CDamage to CDamage * 1.25 set fCSpeed to fCSpeed * 1.1 elseif Horn == 2 set CValue to CValue * 1.15 set CHealth to CHealth * 1.15 set CDamage to CDamage * 1.35 set fCSpeed to fCSpeed * 1.15 endif if eval Fiber == 2 SetIgnoresResistance 1 rProduct set CValue to CValue * 1.1 set CHealth to CHealth * 1.1 set CDamage to CDamage * 1.1 set fCSpeed to fCSpeed * 1.1 endif if eval( CValue ) SetGoldValue CValue rProduct endif if eval( CHealth ) SetObjectHealth CHealth rProduct endif if eval( CDamage ) SetAttackDamage CDamage rProduct endif if eval( fCSpeed ) SetWeaponSpeed fCSpeed rProduct endif
  11. Craftybits 0.812 Bug Reports

    Yours is a good solution. Implemented as suggested with an additional comment to explain: set TrapDeployed to 9 ; park the script until disable and delete can run
  12. Craftybits 0.812 Bug Reports

    CBKey + Fish: I think there is a simpler solution to this problem, though your proposal is solid and would work, as far as I can tell. The only conversions which use their name are "meat" and "fish" ( see top of Scn CBMstCBKeyInitOS). So if line 178 of CBMstCBKeyQS is changed from this: if eval( nameIncludes $sInclude rConvRef ) to this: if eval( nameIncludes $sInclude rConvRef && GetObjectType rConvRef == 25 ) only objects of type ingredient will be considered. This is a little better because it winnows the candidates down as early in the script as possible, which will make it just a little faster. It is unlikely that the player will ever notice, but as a matter of principle faster is always better than slower because the delays can add up. In the current version Proc 1 is only used for these two cases. That used to be different because there were other things which could be converted and added to inventory directly, but somewhere along the lines that changed. This particular conversion is quite new. Its sole purpose is to allow meat or fish acquired from some foreign mod to be converted into a form suitable for use in CB. It could get a switch that needs to be enabled, but since it is so easy to ignore, it seems simpler to just leave it there. The improvement to the Equip block looks like a great idea. I'll implement it as proposed, except for relieving the requirement for it to be a weapon. This can be used for anything that goes straight into inventory.
  13. Craftybits 0.812 Bug Reports

    Pemmican sounds interesting. For us modern types, whose exercise often consists of pushing keys on the keyboard, it might not be such a good thing. But for a hero in a cold environment full of hard physical exercise, it is certain to be a good thing. A basic version would be easy, just add tallow instead of salt. Flavorings are tempting, but would require a fair bit more effort to integrate into the existing scripting. I'd be tempted to give pemmican a low level bonus property due to the wealth of calories it would provide. Your approach to testing sounds brilliant. If nothing else, putting a second pair of eyes on the code will help because often one gets trapped in a particular way of seeing things, then just never questions them again. Your fix to the bait problem, for example, immediately made sense to me but I failed to spot the problem until you pointed it out. I know my way around GIMP2 well enough to retexture things reasonably well. Though when it comes to things like spectral properties, that tends to be a bit over my head. I know enough to recognize a problem but not necessarily how to fix it. I looked at Blender, then decided not to learn how to use it. It was a deliberate decision because I'm busy enough with the scripting that I didn't want to pile that on top as well. In addition, I like working with collaborators and if I can't find someone who is interested enough in a particular project to devote some time to modelling, then it probably isn't worth doing. In principle CB is so open ended that there is almost no limit to what could be done in its context. So it is useful to have some way to check if something is really worth doing. Another thing I tend to factor in a lot, but almost no one else can, present company most likely excluded, is how hard it is to make a change. Take pemmican, for example. Given a suitable model, the scripts will only need an extra line or two. The whole thing won't take 30 minutes. So even if it is relatively low value, it is so easy it is worth doing. Something of high value would be to restructure construction to use a series of wood pieces of different sizes and shapes. It would make CB a fair bit more realistic, but it would require redoing a large number of items, rewriting a dozen scripts, would create compatibility problems with existing saves and may end up weighing the mod down with excessive detail. We wanted to go in that direction some day but the hurdles were just too high to launch into it while the team was still active and we never got to it. One of the efforts I'm particularly proud of is the barrels. A skilled animator, Koniption, created the barrels and animated them, then I rigged up the scripting. It was one of those cases where she couldn't have done the complex scripting they took and I couldn't have done the animation without spending a year learning how to do such things well. But together we produced something pretty spectacular. I realize most players probably barely notice, but in a way that is good, too. If everything goes so smoothly and immersively that it seems normal, that is a good thing. Unfortunately Koniption ran into some health problems and retired from modding, as far as I know. I haven't heard from her in a number of years. Coming back to pemmican, it sounds like a retexture it all it would take. That might take an extra hour, so it is no big deal. GIMP2 needs an extension to handle what Oblivion needs of it (normal mapping), but is otherwise not hard to learn or use. If you are feeling ambitious and would like to take a crack at it, I'd be happy to explain. If you'd rather not, I can do it. To be honest, it would probably take less time for me to do it myself than to explain how to do it but I'd be happy to teach you how to use GIMP2, if you would like.
  14. Craftybits 0.812 Bug Reports

    Thank you for the compliments. I am quick to point out when others have made the main contribution, such as in inventing almost all the mechanisms. But in terms of organizing the code, I can claim that for myself and it is very gratifying to discover that someone else could immerse themselves in it and actually find their way around. Interestingly barding is a old system, always a little neglected and I did only what was necessary to get it to work right as designed. Cooking, on the other hand, has been almost redone. Probably hardly a line of the original scripts still stand unchanged. I suppose it has always been my favorite part to mess with, but even I haven't ever memorized most of the recipes for use in game. As a result quite a number were still defective but I recently fixed them, I think. Some systems lend themselves well to expanding pretty easily and cooking is one of those. How would you define pemmican and how does it differ from air-dried jerky? If we can come up with a suitable model and a sensible recipe which isn't hopelessly redundant with another, I'd be happy to add it. If you think it would be time effective, you are certainly welcome to poke through the scripts to look for problems. I know more about coding now than I did then, but it would surprise me if you end up finding much that way. In my experience the problems mostly come from something not behaving in-game like it seems it should based on the scripts. The fish problem, for example, probably comes from compare working a little strange. If the search string is "blue marlin" and the animal is named "blue marlin" I would expect a match. But I have a suspicion the comparison is breaking the strings into words and comparing "blue" with "blue". In this case it will still match but it may also match with "bluegill". I need to run some tests to be sure, but I think it would account for your observations. The best way to find problems, I find, is to just play and try new things out. If something doesn't work like the guide says it does, or even if it just doesn't work like you think it should, it is worth discussing. Sometimes there are good reasons why something has to be a particular way, but sometimes it is just a matter of no one having thought of the most intuitive approach to take. Have you done anything with smithing so far? In terms of complexity of the scripting, that set of scripts wins. It has enormous potential because it is designed to allow new weapons and armor to be forgeable, providing modellers with an immersive way of getting their things into the game with relatively little effort. But it never caught on, which I think had to do with its timing, coming so late in CB's own history. If we had found a few modellers interested in using the system, it might have taken off. In retrospect, I probably should have actively approached a few of the better known modders and created a small patch to make it happen. Once it became apparent how easy and seamless it is, it might have caught on. In any case, I think you may find it worth a look, though you may struggle with it a bit due to the complexity. The execution path of certain activities ping pongs between two or three scripts in a way which may be hard to follow. The scripting is nasty complicated but that is in order to make it easy to tack things on by adding an extra mini-script.
  15. Craftybits 0.812 Bug Reports

    Wow, I don't think I've ever had anyone pick through the scripts like this before, at least until recently. I'm grateful. I'll go through each problem and proposed fix systematically but I just wanted to start by saying thank you. I've looked at a few of the problems already and came to similar conclusions to the ones you did. I didn't look at the bait problem but your explanation and proposal is so convincing that I'm sure that is both the source of the trouble and a viable fix. I think I know what is wrong with spriggan and gnarl, a missing script on the staves. Taken together, it looks like it will be pretty easy to find and fix every one of the problems. Expect some news today or tomorrow. Munch