NerdanelVampire: I want randarts in my module, and I'm not the only one. At least IngeborgNorden has similar plans. So I embarked upon the task of including randarts. Making a functional randart.lua (the file with all the randart parts) that gets loaded properly without errors wasn't too hard, but now I'll have to get the game to do something with it. (And to solve the issue of how to have randarts add player powers, but that's a lesser priority.)
There's some randart code still in C, but I'm not sure if that gets ever called. In any case, the wizard mode errors out when I try to create a good/great object and the object tweaking menu doesn't even have the option to turn an item into a randart. So I would have to try to find a randart the old fashioned way, which is quite impractical, as I don't know if I'm searching in vain.
In any case, looking at the engine code, it doesn't seem to take randarts into account. For example, the function default_monster_drop in object_enchant_drop.lua has no check for DROP_RANDART and random_objects.lua seems to have mention only of fixed artifacts. I think randarts are a thing that merits being in the engine itself (if only because the parts are already loaded by info.lua) but in any case I would appreciate advice in how to get them (and their testing) working.
IngeborgNorden: From the very beginning, I've suggested that the presence/absence of randarts should be module-specific; what's suitable for ToME may not be suitable for other T-Engine games. Adding a line to module.lua that tests some "allow_randarts" variable shouldn't be too hard to code; neither should cutting back the power level for such items. (NeilStevens cited multiple immunities as a problem; why not limit randarts to one immunity at most, and set a maximum percentage for lesser resists?) Not every module-maker plans to include juggernaut characters who can wield three of everything; banning randarts altogether penalizes people who don't abuse the code.
NerdanelVampire: The thing is, if you have an empty randarts.lua like the current version of ToME, no randarts can ever be created. It's that easy. Randart power can be toned down by tweaking the numbers in randarts.lua/removing some of the more powerful entries. There is a number field to prevent a randart part from being chosen more than a specified number of time to prevent unwanted stacking for resists, etc. And if you don't like multiple immunities on the same randart (which doesn't describe me - you need some very good stuff in order to deal with all of those hideously powerful Starspawns of Cthulhu, Night Hounds, Silent Ones, etc.), I noticed that there's a mechanism so that you can have a randart part to be opposed to another randart part. For example, you might have the fire immunity be incompatible with every other immunity, and so on. That might not actually be implemented, but info.lua can read it in...
DarkGod: randarts.lua should do nothing, as the code that handles is does not exist. Now it is not very hard to make it either. After all randarts are really kind of like infinite ego items with shiny names and a cherry on top..
NerdanelVampire: Is there any official movement on this? Namely, I've forked object_enchant_drop.lua and am about to fork random_objects.lua (from the ENGINE) so that I can have randarts. (By the way, is alpha14 coming soon? It has a long list of changes, and I'd like to get digging finally functional.)
NeilStevens: I haven't had a chance to do any ToME work this year. I'd still like to rewrite object generation, but I can't promise it'll happen soon.
DarkGod: I postponed releasing a14 because of LordBucket's flyers, I suppose I can release it soon now ? *whips neil*
NerdanelVampire: Yes, please, preferably right away. I'm waiting to fix all the new compatibility issues.
ToME Wiki