Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Probably I'm not the best person for judging the code - as I said in my first post, I started new project recently just for learning 'good coding' techniques. I'm not the python guru - these roguelikes which was generally mentioned earlier usually have code that looked very bad at / from first glance. You know, Writhing Mass of CodeBut if you want to I could give a glace at pyherc code, no problem.
Not claiming to be the best person for the job nor claiming guru status, when it comes to Python I consider myself a journeyman/retired hobbyist. However, I dropped by your repo and poked around.
I liked what I saw. Good commenting, seems to have good test coverage, the unit tests looked useful, the code base is organized, and it uses good solid Pythonic practices as far as I can see. If I spent enough time I could probably nitpick something
There's always something that can be done better of course, but it's good to keep those things as small as possible.PS: couple of suggestions to consider; you might want to include the target version of Python in the file header info, and along the same lines, you might want to note somewhere a new Python programmer might see that the .hy files are for the lisp extension. Newcomers probably aren't aware of the various add on file extensions that they might run across, pyx files, hy files, etc.
First - roguelikes rarely has a good code. I checked large amount of code of open source python roguelikes and I didn's see any with really good code. Even my own
QuoteI don't mind if henchmen are doing these tasks by themselves. In case they find something that I would rather have on leader, I can always later manually move it.
Sure, but when you switch the leader to another actor, the previous one can spontaneously decide to get rid of that item and/or equip other items.
Another solution would be to let player mark items with an inscription {henchmen off} so that the henchmen AI knows it may not touch them. Post-5.0.
QuoteThis one I haven't done yet, but should. Does weight of a thrown object affect to damage or distance any way? Or would it be better if I would assing maluses to very heavy weapons?
The weight only affects the distance of throwing. Additionally LH melee weapons have attributes like 'toVelocity 40' in their ifeature field that limit the throwing velocity further. But, e.g., a dagger realistically can be thrown quite far. OTOH, not being balanced for throwing, it can hit with the wrong side, so additionally I add 'AddHurtRanged (-60)', which makes it as weak as a dart, but travelling much slower and closer. That balanced well with the durability, I guess, so the darts are not made obsolete once you find a few daggers.
Thank you again for the report. It's fixed now on branch master. I couldn't reproduce it, because I never use the 'e' command available when the game shows me the description of an item (the noun-verb command). Instead I use the standalone 'e' command and only then pick the item to equip, changing display modes as needed (this is the verb-noun command).
BTW, you probably noticed that your henchmen (non-leaders) sometimes move items from equipment to pack, etc. Would you perhaps prefer to reserve such item management for yourself and only allow them to autonomously pick up items? Or perhaps you'd prefer to only pick up items with your leader? If the former, I'd need to separate the picking up skill from the current item management skill, so this is post-0.5. The latter can already be accomplished by changing fskillsOther of playerHero.
Another thing: I just remembered that the ranged damage bonus (AddHurtRange) aspect only applies to the item in question, not to other items. The aspect comes into play only when the item is used as a missile. The logic is that when the missile hits, bonuses are calculated as if the missile actor hit the target actor in melee. The only tweak is that, instead of the melee damage bonus, the ranged damage bonus is taken into account. In the future, when missiles comprise of many parts, the bonuses of all the parts will naturally be taken into account, since all the parts are carried by the missile actor.
That's different than for AddHurtMelee and AddArmor*, which are summed over all items of the original actor, as can be seen in the ! screen. That's intentional, only the bonuses on the ammo and perhaps on the launcher should affect the ranged damage, which otherwise easily gets overpowered and also induces equipment micromanagement when switching from ranged to melee combat and back again. (That's also how, e.g., Angband does it.) I wonder how to prevent confusion both in the UI, the player guide and in the content code naming. Perhaps when launchers are added to the game this will settle down and become clearer, but I'm open to suggestions already.
So, items that add AddHurtRange are useless in equipment, they can as well be kept in the pack and thrown when appropriate.
This is also why I have huge AddHurtRange maluses on the melee weapons in LH --- this prevents their use as super-ammo (they have large damage dice and they are durable, unlike normal ammo). And, OTOH, this doesn't affect other items, so keeping them in equipment doesn't make other ammo weaker.
