Angband.oook.cz
Angband.oook.cz
AboutVariantsLadderForumCompetitionComicScreenshotsFunniesLinks

Go Back   Angband Forums > Angband > Development

Reply
 
Thread Tools Display Modes
Old June 9, 2011, 16:01   #1
jens
Swordsman
 
Join Date: Apr 2011
Location: Göteborg, Sweden
Posts: 348
jens is on a distinguished road
EyAngband item prefixes

As seen in the thread:
http://angband.oook.cz/forum/showthread.php?t=4494

Quote:
Originally Posted by Magnate View Post
For ego_item.txt:
Add minor ego types based on EyAngband prefixes. There are also a whole bunch of new ego types suggested in this thread.
I am not sure that you are interpreting the ticket the same way that takkaria meant it.

Nowhere on the ticket are ego items mentioned, and the milestone is set to 4.0. If it was ment as a simple addition of ego items I feel it would have been formulated differently? I have not played EyAngband, but I looked through the spoilers. Some of the prefixes in the spoilers are prerequisites for certain ego types. Which implies they are not the same in EyAngband...

My interpretation is that takkaria meant something like: a layer of items between ordinarily enchanted items and ego items. Governed by a text file 'prefix.txt' that gives a name and some modifiers that can be applied to all weapons/armors.

If it is ego items we are talking about a few names can be taken from EyAngband, not much more. Some prefixes would seem to work as ego items, but ego_items.txt does not allow negative values, weight modifier does not work, etc.

Just creating new, low level, ego items is easy. And borrowing a few names from EyAngband might be a good place to start. But I just don't see that this would resolve the ticket...

All that aside I have to say I enjoy ego items, and will probably cook some up ;-) But please clarify the dev position...
Quote:
Originally Posted by Magnate View Post
Add A: lines to ego_item.txt - although the code has yet to support this, it would be very helpful if someone put these in first, with carefully balanced min and max depths for each ego type, and the alloc_prob.
I might well do this, because I really want this functionality to get into ego_items.txt, plus I could smuggle a few other improvements into the file ;-)

I suppose that lines the parser does not understand are ignored, so the file would still work?

How much work would you say is left to do after the allocation lines have been added to ego_items.txt?
jens is offline   Reply With Quote
Old June 11, 2011, 09:11   #2
Magnate
Angband Devteam member
 
Join Date: May 2007
Location: London, UK
Posts: 5,057
Magnate is on a distinguished road
Send a message via MSN to Magnate Send a message via Yahoo to Magnate
You are right that the original ticket was not about adding the Ey prefixes as ego types - that was an interpretation of mine which would incorporate them in a way which required minimal coding. I was compiling a list of things people could do without coding, so it seemed sensible at the time. It may indeed be better to have a layer of prefixed item types between standard items and ego items - by analogy with Diablo II, these would be the blues between whites and yellows. But if we were going to do that, one would seriously consider junking ego templates altogether and re-writing nonartifact item generation from scratch, which is a lot of coding work.

So in the meantime adding some of the easier Ey prefixes as ego types might be a useful approach. You can now specify negative pvals btw (by leaving min_pval at 0), and you've always been able to specify negative to-hit, to-dam and to-ac.

When the A: lines are added, it should be as simple as adding a single parse_e_a function to the parse_ego code, to get them read in. Actually using them then requires some changes to the code in make_ego_item, but it shouldn't be too much work.
Magnate is offline   Reply With Quote
Old June 11, 2011, 10:16   #3
jens
Swordsman
 
Join Date: Apr 2011
Location: Göteborg, Sweden
Posts: 348
jens is on a distinguished road
Quote:
Originally Posted by Magnate View Post
You are right that the original ticket was not about adding the Ey prefixes as ego types - that was an interpretation of mine which would incorporate them in a way which required minimal coding. I was compiling a list of things people could do without coding, so it seemed sensible at the time. It may indeed be better to have a layer of prefixed item types between standard items and ego items - by analogy with Diablo II, these would be the blues between whites and yellows. But if we were going to do that, one would seriously consider junking ego templates altogether and re-writing nonartifact item generation from scratch, which is a lot of coding work.
Not that it matters, but when would the ticket in question be considered to be resolved? After adding a few new ego items, or first after a big rework of item generation?

I've been thinking about writing up a whole bunch of minor ego items. Say that I would post an edited ego_item.txt in a weeks time with say 40 new entries in it. I'm thinking it would need some time in nightlies to adjust game balance before getting into V, so I feel I should wait with it until after 3.3 is out. Any thoughts on that?

Quote:
Originally Posted by Magnate View Post
So in the meantime adding some of the easier Ey prefixes as ego types might be a useful approach. You can now specify negative pvals btw (by leaving min_pval at 0), and you've always been able to specify negative to-hit, to-dam and to-ac.
I haven't tried it recently, but in 3.2, when specifying negative values you got 256 - abs(value) instead. Or was that only when specifying negative min values? In any case, since min values could not go below 0 it was not possible to achieve negative values for anything (at least that was the case if you happened to use the 'M:' line anywhere early in 'ego_item.txt'. Which btw is manifested today as in no ego armor having a tohit penalty). I will check this out, but I'm going away for the weekend soon...

Quote:
Originally Posted by Magnate View Post
When the A: lines are added, it should be as simple as adding a single parse_e_a function to the parse_ego code, to get them read in. Actually using them then requires some changes to the code in make_ego_item, but it shouldn't be too much work.
OK, I'll try to write them in next week, and hope to have the functionality before 3.3 is released :-)
jens is offline   Reply With Quote
Old June 11, 2011, 10:42   #4
Magnate
Angband Devteam member
 
Join Date: May 2007
Location: London, UK
Posts: 5,057
Magnate is on a distinguished road
Send a message via MSN to Magnate Send a message via Yahoo to Magnate
Quote:
Originally Posted by jens View Post
Not that it matters, but when would the ticket in question be considered to be resolved? After adding a few new ego items, or first after a big rework of item generation?
This varies from ticket to ticket. For bugs it's easy, the ticket's closed when the bug is fixed (or when it's decided that this particular behaviour is acceptable). For changes, it depends what the original intention was. In this particular case, I think the intention was to add flavour - so that could be considered accomplished after adding a bunch of new ego types. If we then wanted to rewrite nonartifact generation, we could create a new ticket for that.
Quote:
I've been thinking about writing up a whole bunch of minor ego items. Say that I would post an edited ego_item.txt in a weeks time with say 40 new entries in it. I'm thinking it would need some time in nightlies to adjust game balance before getting into V, so I feel I should wait with it until after 3.3 is out. Any thoughts on that?
I agree - it would be a good idea to do this after 3.3, so that the new egos get plenty of playtesting for 3.4.
Quote:
I haven't tried it recently, but in 3.2, when specifying negative values you got 256 - abs(value) instead. Or was that only when specifying negative min values? In any case, since min values could not go below 0 it was not possible to achieve negative values for anything (at least that was the case if you happened to use the 'M:' line anywhere early in 'ego_item.txt'. Which btw is manifested today as in no ego armor having a tohit penalty). I will check this out, but I'm going away for the weekend soon...
If you had looked at http://trac.rephial.org/ticket/1394, you would have seen that this was fixed in [r821f59d] by making min_pval of 0 mean "apply no minimum". You can therefore specify negative pvals (with the caveat that there is some odd behaviour in random_value parsing, which will be addressed in #1451) without them being overridden. You cannot specify minima below 1 though.
Magnate is offline   Reply With Quote
Old June 11, 2011, 19:38   #5
takkaria
Veteran
 
takkaria's Avatar
 
Join Date: Apr 2007
Posts: 1,947
Donated: $40
takkaria is on a distinguished road
Quote:
Originally Posted by Magnate View Post
This varies from ticket to ticket. For bugs it's easy, the ticket's closed when the bug is fixed (or when it's decided that this particular behaviour is acceptable). For changes, it depends what the original intention was. In this particular case, I think the intention was to add flavour - so that could be considered accomplished after adding a bunch of new ego types.
FWIW, the intention was just to copy EyAngband's prefix system. If a similar effect can be realised using new minor ego types, that's fine too, but I don't think I'd consider the ticket closed (I'd want either the prefix system or a rewrite of object generation that did a similar thing).

In the meantime, minor ego types would be gladly accepted.
__________________
takkaria whispers something about options. -more-
takkaria is offline   Reply With Quote
Old June 11, 2011, 19:50   #6
Magnate
Angband Devteam member
 
Join Date: May 2007
Location: London, UK
Posts: 5,057
Magnate is on a distinguished road
Send a message via MSN to Magnate Send a message via Yahoo to Magnate
Quote:
Originally Posted by takkaria View Post
FWIW, the intention was just to copy EyAngband's prefix system. If a similar effect can be realised using new minor ego types, that's fine too, but I don't think I'd consider the ticket closed (I'd want either the prefix system or a rewrite of object generation that did a similar thing).
Ah yes, I had forgotten the virtues of plagiarism. If we can just copy Ey's prefix system wholesale, that's a lot less work than rewriting item generation ... and would neatly add a layer of interest between magical and ego. If I can time it for just when rune-based ID is finished, it should drive Eddie plenty nuts ... ;-)
Magnate is offline   Reply With Quote
Old June 16, 2011, 12:15   #7
jens
Swordsman
 
Join Date: Apr 2011
Location: Göteborg, Sweden
Posts: 348
jens is on a distinguished road
So I'm about to start adding the A: line to ego_item.txt, just a quick question...

The allocation value is the reverse of the rarity right? i.e. we use that number directly when adding to the object list, rather than 100/r. And it can go beyond 100? Not saying it will, just checking the grounds before doing the work :-)

Will go for a run, to have a chance of an answer before I start ;-)
jens is offline   Reply With Quote
Old June 16, 2011, 15:14   #8
Derakon
Prophet
 
Derakon's Avatar
 
Join Date: Dec 2009
Posts: 9,023
Derakon is on a distinguished road
As I understand it, each item gets allocated a number of slots equal to the number in its allocation line; then the game chooses a slot and generates the corresponding item. So bigger numbers are more common, and there shouldn't be any logical reason why the allocation couldn't go beyond 100.
Derakon is offline   Reply With Quote
Old June 16, 2011, 20:00   #9
Magnate
Angband Devteam member
 
Join Date: May 2007
Location: London, UK
Posts: 5,057
Magnate is on a distinguished road
Send a message via MSN to Magnate Send a message via Yahoo to Magnate
Quote:
Originally Posted by Derakon View Post
As I understand it, each item gets allocated a number of slots equal to the number in its allocation line; then the game chooses a slot and generates the corresponding item. So bigger numbers are more common, and there shouldn't be any logical reason why the allocation couldn't go beyond 100.
I honestly don't know whether alloc_prob > 100 would break anything. But it might be safe to treat it as a percentage scale (even though that isn't how the allocation table works).
Magnate is offline   Reply With Quote
Old June 16, 2011, 20:23   #10
takkaria
Veteran
 
takkaria's Avatar
 
Join Date: Apr 2007
Posts: 1,947
Donated: $40
takkaria is on a distinguished road
Quote:
Originally Posted by Magnate View Post
I honestly don't know whether alloc_prob > 100 would break anything. But it might be safe to treat it as a percentage scale (even though that isn't how the allocation table works).
I think it can go up to 255. But I wouldn't bother trying.
__________________
takkaria whispers something about options. -more-
takkaria is offline   Reply With Quote
Reply


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
Item tune down/up Timo Pietilä Vanilla 1 April 10, 2011 00:38
Item (-1) [5,0] what does the parenthesis mean? pwnmonkey Vanilla 4 June 13, 2010 18:24
EyAngband OS X for 0.5.2? ElectricPaladin Variants 1 April 24, 2009 19:40
Item configurator? Jabba Vanilla 6 October 30, 2008 08:09
Item names Kiyoshi Aman Vanilla 3 May 5, 2007 23:01


All times are GMT +1. The time now is 10:54.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2020, vBulletin Solutions Inc.