More mutually exclusive talent nonsense!

If you have a module that you'd like comments on or would like to know how to create your very own module, post here

Moderator: Moderator

Post Reply
Message
Author
FinalParagon
Yeek
Posts: 10
Joined: Wed Aug 25, 2010 5:34 am
Location: Caisidhellain, Republic of Carcist

More mutually exclusive talent nonsense!

#1 Post by FinalParagon »

I found myself really busy with all manner of things, but recently picked up T-Engine again. Time for a question very related to my last one.

The problem this time isn't that I can't set talents as mutually exclusive, it's that the engine only fully recognizes this for the last talent in any given set.

For example, Knights have three masteries: Swordsmanship, Lancing and Archery. A point in any one should forbid the Knight from raising any other. What actually happens is as follows:
A POINT IN SWORDSMANSHIP: Properly forbids the other two.
A POINT IN LANCING: Forbids only Archery.
A POINT IN ARCHERY: Prevents nothing.

Additionally, the raise talent dialog disappears whenever the first two would be highlighted. It's still navigable, it reappears when any other talent is highlighted and you can still allocate points to those two talents if they're selected even though you can't actually see the dialog.

It's fairly clear what the problem is. The three talents are defined in that order (Swordsmanship, Lancing, Archery), but requirements for talents are read in at the same time as that talent is defined. This works fine for sequential requirements, but as soon as a loop in requirements occurs (In this case, talents mutually requiring not the other talents), it only recognizes the requirements which include talents already defined, and there's no way to reorder their definitions to prevent this.

So that's the problem, the question is: What's the solution? Altering the requirements using some sort of mutator function after all the talents have been defined seems like the easiest way to do it, but I don't see any obvious way of doing so.

yufra
Perspiring Physicist
Posts: 1332
Joined: Tue Jul 13, 2010 2:53 pm

Re: More mutually exclusive talent nonsense!

#2 Post by yufra »

I think what might be getting you is that there is a set of requirements that are handled outside of the require table. The first value in the type table is the string that identifies the talent category. The second value minus one is the number of talents in the same category that need to be known before this talent can be learned, and this may be what is tripping you up. If you either get rid of the second value entirely or set them all to 1 then you should be able to learn them independently, and then the require.talents can properly remove the others once you learn one talent.

If this doesn't work, maybe post the code so I can take a look at that?
<DarkGod> lets say it's intended

FinalParagon
Yeek
Posts: 10
Joined: Wed Aug 25, 2010 5:34 am
Location: Caisidhellain, Republic of Carcist

Re: More mutually exclusive talent nonsense!

#3 Post by FinalParagon »

Yeah, all of them are set to '1'. Actually, every talent has this set to one, since I'm only using talent categories as headers to separate like skills.

So here's their definitions as of right now. None of them have actual effects yet, but that hasn't affected any other talent in this way (or at all) while I've been testing.

Code: Select all

-- Swordsmanship - Stronger sword attacks.
newTalent{
	name = "Swordsmanship",
	type = {"Fighter/Warfare-Tactics", 1},
	points = 10,
	mode = "passive",
	info = function(self, t)
		return "Swords are often the weapons of heroes, owing to their tremendous versatility. Some Knights choose to specialize in the use of Swords, significantly increasing their Damage with them. Specializing in Swords opens up special Sword techniques, but prevents you from specializing in Lances or Bows."
	end,
	require = { talent = { { Talents.T_LANCING, false }, { Talents.T_ARCHERY, false }, }, },
}

-- Lancing - Stronger spear attacks.
newTalent{
	name = "Lancing",
	type = {"Fighter/Warfare-Tactics", 1},
	points = 10,
	mode = "passive",
	info = function(self, t)
		return "Lances are long and powerful, designed to focus immense energy into devestating thrusts. Some Knights choose to specialize in the use of Lances, increasing both their Damage and Pierce with them. Specializing in Lances opens up special Lance techniques, but prevents you from specializing in Swords or Bows."
	end,
	require = { talent = { { Talents.T_SWORDSMANSHIP, false }, { Talents.T_ARCHERY, false }, }, },
}

-- Archery - Stronger bow attacks.
newTalent{
	name = "Archery",
	type = {"Fighter/Warfare-Tactics", 1},
	points = 10,
	mode = "passive",
	info = function(self, t)
		return "The easiest way to survive is to avoid getting hit in the first place, and as such, some Knights choose to specialize in the use of Bows, increasing their Accuracy and Pierce with them. Specializing in Bows opens up special Bow techniques, but prevents you from specializing in Swords or Lances."
	end,
	require = { talent = { { Talents.T_SWORDSMANSHIP, false }, { Talents.T_LANCING, false }, }, },
}
stdout.txt shows an error about nil values, and that, plus the fact that it only acknowledges these requirements if the requirement was defined earlier than the current talent (Again, Archery works perfectly fine, Lancing half-works, Swordsmanship not at all), tell me that it's not acknowledging, say, T_LANCING in Swordsmanship, because Lancing technically doesn't exist when Swordsmanship is first loaded in.

yufra
Perspiring Physicist
Posts: 1332
Joined: Tue Jul 13, 2010 2:53 pm

Re: More mutually exclusive talent nonsense!

#4 Post by yufra »

I understand now, thanks for the explanation. I don't think the current ActorTalents.lua can support this behavior in an elegant fashion, and will first suggest a hack to get it working now and then a suggestion for DG to alter ActorTalents.lua.

The Hack
Remove the require table from the newEntity function calls. Then at the very bottom of the talent file add:

Code: Select all

-- Hack adding the requirements after all the talents have been defined
local talent = Talents:getTalentFromId(Talents.T_SWORDSMANSHIP)
talent.require = { talent = { { Talents.T_LANCING, false }, { Talents.T_ARCHERY, false }, }, }
local talent = Talents:getTalentFromId(Talents.T_LANCING)
talent.require = { talent = { { Talents.T_SWORDSMANSHIP, false }, { Talents.T_ARCHERY, false }, }, }
local talent = Talents:getTalentFromId(Talents.T_ARCHERY)
talent.require = { talent = { { Talents.T_SWORDSMANSHIP, false }, { Talents.T_LANCING, false }, }, }
Ugly, but it works.

The Suggestion
ActorTalents would benefit from gaining the resolve function from Entity.lua. Either a custom resolver could be written, or the resolver.generic could be used as follows:

Code: Select all

newTalent{
...
	require = { 
		talent = resolvers.generic(function(Talents, t)
			t.require.talent = { Talents.T_LANCING, false }, { Talents.T_ARCHERY, false }, }, }
		end,
	}
...
}
Assuming of course I have my signatures right. Thoughts DG?
<DarkGod> lets say it's intended

FinalParagon
Yeek
Posts: 10
Joined: Wed Aug 25, 2010 5:34 am
Location: Caisidhellain, Republic of Carcist

Re: More mutually exclusive talent nonsense!

#5 Post by FinalParagon »

That's exactly what I was trying to figure out how to do. It works perfectly now, thanks a bunch!

darkgod
Master of Eyal
Posts: 10750
Joined: Wed Jul 24, 2002 9:26 pm
Location: Angolwen
Contact:

Re: More mutually exclusive talent nonsense!

#6 Post by darkgod »

Resolves cant really work on talents since they are not resolved but I'll find a way :)
[tome] joylove: You can't just release an expansion like one would release a Kraken XD
--
[tome] phantomfrettchen: your ability not to tease anyone is simply stunning ;)

Patryn
Thalore
Posts: 130
Joined: Sat Aug 07, 2010 12:07 pm

Re: More mutually exclusive talent nonsense!

#7 Post by Patryn »

I'm not into lua, but AFAIK many languages offer the possibility to define a function/class/whatever before actually setting the function body. Especially with an interpreter language this seems kinda handy for exactly this reason. ;)

I can hardly believe lua hasn't anything like that... *wondering*

Post Reply