Submitted on 2014-11-11 00h53 by Christoph, last changed by fluzz.
File name |
Uploaded |
Type |
Edit |
Remove |
items.c.diff
|
Christoph,
2014-11-13.03:10:00
|
text/x-patch |
|
|
savefiles772.zip
|
Christoph,
2014-11-11.00:58:14
|
application/zip |
|
|
Author: Christoph |
Date: 2014-11-11 00h53 |
|
The marking of items as "good quality" or "bad quality" is bugged.
1) Bad or good items placed on the floor apparently become normal upon
restarting and loading a saved game.
2) While initialising an item, it is at first determined whether it will be bad,
normal, or good. Then an item within the possible range of durability is
created. After that bad items are degraded in durability, and good ones
enhanced. This leads to the situation that normal items can in fact be worse
than some bad ones, or better than good ones, because normal items can obviously
be in the full durability range. The player then wonders whether a normal item
of durability 31 is overall better or less good than a "good quality" item of
durabilty 29. You have to read the code in order to see that only the numbers
count (or have endless test fights from the same save game to get reliable
statistics).
3) The repair function is bugged. You cannot enhance bad items to normal or
good, no matter how often you succeed in raising the maximum durability, because
only normal items can become good, and only good items can become normal due to
the code. It should never be checked which state an item was in before you were
increasing or decreasing the durability when deciding to change the current state.
To address problems 2) and 3), at the end of the functions should the good or
bad property be added to the base name depending only on the item's current
property values.
4) The repair function doesn't check whether an item is already fully repaired
if you have reached the maximum skill level of 9. Using the skill repeatedly
will slowly increase the maximum durability further because of the 3% chance of
degradation and 5% chance of enhancement.
5) The repair skill is balanced badly. The player will learn from experience
early in the game to never use the skill on good items, because they will be
rapidly rendered useless due to degradation even on higher repair skill levels
than 1. The player won't come to think that this skill might be worth improving,
because it becomes useful only on its highest level, where the behaviour changes
drastically.
6) For armour, the quality should not only depend on durability, but also the
armour's protective value, because this is what is primarily considered as
"good" for such items.
7) The maximum durability can decrease to 0, and even become negative on repair
skill level 9, creating an indestructible item of (initially) bad quality.
Load the attached save file. There are three helmets. One has once been of bad
quality initially, repaired several times at maximum skill level, degrading it
to 0 durability, and then a negative value, making it indestructible and
unrepairable. The "bad quality" addition got lost leaving it on the floor upon
saving and reloading.
Two helmets and the super exterminators are normal. Repairing them will make
their quality "good" immediately, because they obviously meet the durability
requirements.
I suggest that "good" and "bad" quality designations should be applied
consistently to any items in the lower third and upper third percentage range of
the overall durability range.
To address problem 6) I suggest to make armour bad, if maximum durabilty OR
protective value are in the lower third of the possible range, while good armour
must be of both a maximum durablity AND protective value in the upper third of
the possible range for its type. Everything else should be normal. Reason: it
cannot be considered "good" or even "normal" if it offers low protection OR
deteriorates rapidly. Both are a sign of low quality. On the other hand, really
"good" armour must offer a good protection AS WELL AS last long.
|
Author: Christoph |
Date: 2014-11-11 00h58 |
|
See attached file for example items.
|
Author: jesusalva |
Date: 2014-11-11 23h08 |
|
Ok, let me try to see.
1) I couldn't play test. Never really cared about this system. I only know that
'bad' haves less durability but bigger armor value, and 'good' have more
durability, but less armor.
2) You should check on a shop the armor/damage values. They change as well and
it's up to you decide if a high armor item that breaks fast is better or not
than a low armor item that takes time to break.
3) ...I didn't knew that repair function could enhance your item. May try it
next time that I cheat. :P
4) ...Why would it check? Only if you want to print: "That's futile!" on the
console. :P
5) I agree with you! Fell free to rebalance it and send a patch! :)
At least you'll get your name on credits. :)
(Doubts about that can be solved on IRC)
6) -
7) Items with 0 durability should be destroyed immediately in my opinion. We
need to add a check for this (fell free to do it :) )
Ok, so. About the "good" and "bad" reclassifying, it's an "idea" not "bug". :P
...But the negative durability is 'release-blocker'.
Hmmmm...
|
Author: Christoph |
Date: 2014-11-12 18h16 |
|
It's not only a suggestion to reclassify "good" and "bad". Only the paragraph 6)
is a suggestion, because "bad" and "good" do not influence something other than
durability at all. That high armour protection values are often associated with
low durability and vice versa is unrelated. I've not found anything in the code
yet causing this deliberately, seems to be random.
The current code leads to situations where the "good" and "bad" attributes are
not consistently applied to items. There can exist "bad" and "good" items with
exactly the same protection and durability numbers and thus no difference in
"behavuiour" as an armour whatsoever.
Those ARE bugs in my eyes:
2) Normal items (not just armour) can end up with better durability than "good
quality" or lesser durability than "bad quality" items when created.
1) Items dropped on the floor lose their "quality" if you save and reload. The
numbers do not change, but they become "normal". Things in Tux' inventory keep
the "quality".
3) Even if you don't rebalance the functions, bad items will stay bad forever
(except put on the floor, saved and reloaded, see 1) for that), while good items
can become normal if they are degraded during repair, and normal items can
become good during repair when enhanced, but nothing will ever become bad when
degraded, no matter how low its durability becomes.
Moreover, the quality fix when repairing is calculated differently than when
creating an item.
Creation:
A) Decide if we make a bad, normal or good one.
B1) Make a bad one: 50%…100% * BASE_DURABILITY
B2) Make a normal one: BASE_DURABILITY + 0%…100% * MODIFIER
B3) Make a good one: 100%…150% * BASE_DURABILITY
So here we've already got a problem: depending on the MODIFIER, normal and good
items end up in the same durability range.
Repair:
C) Make normal if good and new durability < BASE_DURABILITY
D) Make good if normal and new durability > BASE_DURABILITY
See B1) and C): items created as good are degraded to normal by repairing them
if they end up in a durability range, where a newly created item would have
become bad.
Any normal item will become good, if repaired and > BASE_DURABILITY.
In fact, the displayed quality is almost complete nonsense, the only relevant
things are the numbers. The player, however, won't read the code but probably
believe that those special items are somehow inherently better or worse than
other items.
|
Author: Christoph |
Date: 2014-11-12 18h54 |
|
The patch for the "release blocker" is easy. The following lines must be moved
near the end of the repair function, the check must be performed whenever
repairing, not only if you are below the highest repair skill level:
-8<---------
if (it->max_durability < 1) {
it->max_durability = 1;
}
-8<---------
On the other hand, the quality issues cannot be repaired through patches WITHOUT
reclassifying anything, because there is no consistent definition of "bad" and
"good" in comparison to "normal" in the current code.
There is a solution without influence on the current game mechanics: we don't
alter the calculations, so the non-uniform value distribution remains as is, but
"reclassify" items at the end of the creation and repair functions and set the
quality state there. If an item "intended to become good/bad" in the first place
isn't actually exceptionally good or bad after rolling the dice, it would be
consistently reclassified according to the actual outcome of the process.
This needs a new definition in non-overlapping maximum dirability percentage
ranges, however, which I wanted to discuss here before submitting patches
according to my personal taste which would then be postponed because they
contain a mix of bug fixes and my own game balance preferences.
|
Author: jesusalva |
Date: 2014-11-12 21h16 |
|
"""
Those ARE bugs in my eyes:
2) Normal items (not just armour) can end up with better durability than "good
quality" or lesser durability than "bad quality" items when created.
1) Items dropped on the floor lose their "quality" if you save and reload. The
numbers do not change, but they become "normal". Things in Tux' inventory keep
the "quality".
"""
Yes, those are bugs. Why? Did I said something wrong and you misinterpreted me? :P
> The player, however, won't read the code but probably believe that those
special items are somehow inherently better or worse than other items.
Possibly. I'm not sure about the usefulness of this at all. It wasn't there on
0.14.1 and I'm unsure if it was present on 0.15.1.
Well, if you can repair it, please consider submitting a patch at:
'rb.freedroid.org'. Remember to register first. :)
If you need help, the best place to ask is at IRC. I'll appoint you xenux and
fluzz, they will probably be able to help you (they're here longer than me, anyway)
> The patch for the "release blocker" is easy.
Please do the following steps to submitting a patch (it's easier for DEVs :) ):
1- Edit the code.
2- in your console type: "git diff filename.c > bugfix.patch"
Where 'filename.c' are the name of the files modified by you.
3- Register at rb.freenode.org and click at 'New Review Request'
4- Upload the 'bugfix.patch' file that git diff generated and fill the
formulary. This will take about 5 minutes. In 'reviewers' add group
"core_reviewers". :)
5- Submit your Review Request. Soon someone will check your file and it will be
shipped as soon that it's ready to ship. :)
> On the other hand, the quality issues cannot be repaired through patches
WITHOUT reclassifying anything, because there is no consistent definition of
"bad" and "good" in comparison to "normal" in the current code.
Well, fell free to reclassify they and submit a patch with the reclassification
explained. :) Your help balancing the game will be greatly appreciated. :)
> [...] before submitting patches according to my personal taste which would
then be postponed because they contain a mix of bug fixes and my own game
balance preferences.
In this case, first submit your suggestion of game balance. You can do this on
IRC but will be slow, or on Wiki but you would need the password. You can also
do it on review board as commented code.
If matthiaskrgr and fluzz ACKS your balance (say that it's fine), then it's the
official game balance and you can and should do your patches based on that
balance. It's now official!! :D
|
Author: Christoph |
Date: 2014-11-13 03h10 |
|
Patch attached to prevent items from ever reaching a maximum durability lower
than one through unsuccessful repairs.
This patch doesn't do any other things than just moving the check out of the
second if-branch where it would not be performed on the highest item repair
skill level.
It is now called unconditionally immediately after the durability modification
of the repair. If this initial modification has set the new maximum durability
to a value lower than one, it is reset to one.
|
Author: jesusalva |
Date: 2014-11-14 19h41 |
|
Alright, your patch works.
You can submit it to rb.freedroid.org .
There it will not have much visibility as on rb. :/
|
Author: jesusalva |
Date: 2014-11-24 00h26 |
|
...or do you want to me upload it? :P
|
Author: fluzz |
Date: 2018-03-21 17h20 |
|
Fixed part#1 in commit 8702c1d01
Fixed part#7 in commit e33acf25a
|
|
Date |
User |
Action |
Args |
2018-03-21 17:20:01 | fluzz | set | messages:
+ msg3554 |
2014-11-24 00:26:30 | jesusalva | set | messages:
+ msg2984 |
2014-11-14 19:41:44 | jesusalva | set | messages:
+ msg2975 |
2014-11-13 03:10:00 | Christoph | set | files:
+ items.c.diff messages:
+ msg2974 |
2014-11-12 21:16:24 | jesusalva | set | messages:
+ msg2973 |
2014-11-12 18:54:49 | Christoph | set | messages:
+ msg2971 |
2014-11-12 18:16:10 | Christoph | set | messages:
+ msg2970 |
2014-11-11 23:08:55 | jesusalva | set | messages:
+ msg2963 |
2014-11-11 00:58:14 | Christoph | set | files:
+ savefiles772.zip messages:
+ msg2957 |
2014-11-11 00:53:14 | Christoph | create | |
|