Our community module

[bricks]

Looking forward to it! I've had a lot of luck working on some various bits of code and made a pull request. I'm still trying to learn the terminology (branches vs. forks, commits and pulls and syncing). My implementation for combat accuracy is pretty shoddy, but it seems to work. The atomic effects have taken me a while to digest. I've more recently been working on a system for upgrading items, which are kind of like conditional egos. Once I've finished it should be possible to apply, remove, and overwrite upgrades that grant combat stats, wielder bonuses, and talents both as base item attributes and as egos.

[yufra]

I saw the pull request and looked at the code. I've also been thinking about how to handle the parts, specifically how to link the talents directly to them. It is non-trivial which is why I haven't actually pulled in your code yet since the development may go a different direction. I'll try to explain what I mean below, so if anyone is uninterested in technical details stop reading now.

In ToME we put the talents directly on the actor (player/NPC). This means that we cannot have duplicate, differently leveled talents without some hacking like is done for inscriptions. Inscriptions use a "getInscriptionData" call to get specific information about a talent, which is where the things like "duelist" ego and the relative power of the talent are stored.

In our module I think the more obvious place for talents to be placed is in the parts themselves. This way we can have two cybernetic arms, both of which have the T_SLAM talent but with different egos/etc. Then you would do things like:

Code: Select all

leftarm:useTalent(T_SLAM)
rightarm:useTalent(T_SLAM)

This approach means that the parts would need to be a mixed class of Objects and the ActorTalents interface, and the player's mechanism for using talents would have to search through the various parts to see what is available. I am still contemplating the pros/cons of this approach relative to ToME's inscription one. Thoughts on this?

[Canderel]

It would seem for me anyway that an arm would be a seperate object gaining exp leveling etc. So your suggested implementation seems better for this design.

[bricks]

Yes, keeping the talents closely associated with the objects would probably make the most sense. I don't anticipate the player having access to multiple talents of the same type (but with different levels), though it would be nice to have the option (and it would prevent a trainwreck down the road). I can't think of any "cons" associated with this approach, apart from the technical difficulty of implementing it. It may also make writing talent code a little more complicated without good examples. The inscription code already confuses the hell out of me, I once tried to interpret it for use in a custom ToME class I was fiddling with.

I'm going to look at fixing the melee talent's probability check. Part of the reason it's so messy was because I kept trying to use "+" as the "or" for two probabilities, due to a misread of the atomic effects page. As you might have seen, I didn't really intend those commits to pass on, they are quite ugly. I guess the best way to handle this is to make a local branch of my own fork, and then commit that branch to the master only when I want it included in pull requests.

[yufra]

Thanks for the feedback bricks. I am hoping to get a working concept ready for the meeting on Saturday so that people can give it a quick whirl, but we shall see how that goes. I am impressed that you managed to decipher the AtomicEffects to the extent that you did, I was afraid that the documentation was too sparse. If you feel comfortable (or just ambitious!) could you put together some talents that could be used for the working concept? I am thinking about getting a single cyberpart and a single gene working.

For the cyberpart we could use lukep's "Arm of Smashing" example (http://forums.te4.org/viewtopic.php?p=123994#p123994). The three talents he listed there should be fairly easy to do by modifying the Kick talent (for the first talent), looking at the Sweep talent from ToME and incorporating that with AtomicEffects, and I want to say the Smash talent from ToME although I am not sure on that one.

For the gene, I am not too sure. We already have Acid Spray talent, so maybe do something like the aliens from the Alien movie? We could have an Acidic Bite that does a MELEE_ATTACK with some ACIDBURN on hit, the Acid Spray, and maybe a bite that drains some life (I am thinking about that inner mouth). The last talent would mean adding another AtomicEffect, GAIN_LIFE, and if you want me to do that it shouldn't take me too long.

I guess the best way to handle this is to make a local branch of my own fork, and then commit that branch to the master only when I want it included in pull requests.

To be honest I don't have a lot of experience with GitHub either. It does look like GitHub supports branches (https://github.com/blog/611-branch-lists), but there is nothing wrong with having a bunch of ugly commits in your fork that you eventually clean up and initiate a pull request for. The one thing that I would suggest is that we not have a deep tree of forking. We can chat about this on Saturday, but it would probably be best if we have a single master fork (Reneen's) and then any developing off of that fork's hers and not mine. If we go with that model we just need to make sure that multiple people have access to the master fork so if Reneen disappears we can still process pull requests, etc.

Also, if you ever want to chat I am always logged in on the ToME IRC channel although I may not be physically at my computer. Cheers!

EDIT: DarkGod did add the recursive class inheritance to the TE4 engine in SVN, so one less thing to worry about moving forward.

[bricks]

I fumbled around for a long time but eventually got it to work. I rather like the concept and I think it will make adding new talents much less of a copy-and-paste ordeal; I can even see it being used in a procedural or ego'ed talent generator. I'm struggling more with LUA's syntax and types than anything, I'm so accustomed to python's types. Generally the more I fiddle with things, the more impressed I become with the work that DarkGod's already done.

I love the idea of Aliens-inspired parts. Acid Spray could be reworked as a shotgun-style attack, but depending on how ambitious I feel I may just leave it alone. The Acid Bite sounds good, and a final Devour talent could be as you say, with the added stipulation that it deals extra damage/recovers more health against enemies under the effects of acid burn. If this all works out nicely, I can see about getting genuine resource use in there, following the model I've described.

Edit: Ugh. I see now that I can combine Probability effects before actually calling them, like I had tried before. Melee hit checks are now much, much cleaner. It'll have to be redone if part-based criticals are implemented, but at least I'm no longer ashamed to look at it.

Edit2: The melee attack atomic effect now takes a part as a parameter. It's a bit more complicated but it allows differentiation between body parts for attacks - for example, the kick talent is independent of the melee part used. I also added two new talents and a heal atomic effect. I was considering making Acid Bite a sustain; having additional atomic effects trigger on-hit for melee parts would be a good feature.

[yufra]

I've been keeping an eye on your fork, cool stuff bricks! I finally have a version of the talents-on-parts code working, and I just committed it to my fork. Don't worry about updating your talents to work with it just yet, you can always do a pull request and I can update them myself. I would appreciate your feedback on the changes, though.

The main change is that the talent effect functions now explicitly receive the actor (previously self), the part and the talent. Here is an example diff for a basic melee talent:

Code: Select all

 newTalent{
-  name = "Attack",
+  name = "Punch",
   type = {"role/combat", 1},
   points = 1,
   range = 1,
-  effects = function(self, t)
+  effects = function(actor, part, t)
-    local tg = {type="hit", range=self:getTalentRange(t)}
+    local tg = {type="hit", range=part:getTalentRange(t)}
-    local x, y, target = self:getTarget(tg)
+    local x, y, target = actor:getTarget(tg)
-    if not x or not y or not target then return nil end
+    if not x or not y or not target then game.logPlayer(actor, "No valid target selected.") return end
-    if core.fov.distance(self.x, self.y, x, y) > 1 then return nil end
+    if core.fov.distance(actor.x, actor.y, x, y) > 1 then return nil end
-    local hit = self:calcEffect("ATOMICEFF_MELEE_ATTACK", target)
+    local hit = actor:calcEffect("ATOMICEFF_MELEE_ATTACK", target, {weapon=part})
     return {hit}
   end,
-  info = function(self, t)
-    return "Attack!"
+  info = function(actor, part, t)
+    return "A solid right hook."
   end,
 }

The majority of the "self" are now "actor", but all the ones that are specific to using a talent like "getTalentRange" now use the "part". I haven't updated the rest of the Talent code, but I will have the same argument order (actor, part, t) for all of the functions like desc, range, etc. What this allows is a talent to be closely linked with a specific part, but still have easy access to the actor. I also am passing the part to the ATOMICEFF_MELEE_ATTACK so that any attributes can be utilized there.

You can test this by booting up my repository and starting either the cybernetic or organic birth options. They both start with a single part with talents, and when you use "m" to bring up the UseTalents dialog you can see that the talents show up under the part. Now if you go and remove the part and then bring up the UseTalents dialog, you no longer have talents!

The way I am currently envisioning this to work is to have base organic or cybernetic parts filling each slot. These parts can then be customized using either genes or modules for their respective parts, almost like egos work in ToME. Swapping out the egos could be fairly trivial to do, whereas swapping out the actual part would be pretty intense.

[bricks]

Awesome, played it a little and reading through the commit right now. It'll take me a while to determine what you did from a technical perspective, but the change to talent effect functions was pretty much exactly what I had in mind.

There's one feature I've been trying to create/simulate that I'm sure you could offer some direction on. I'd like for weapons to determine hits using atomic effects, either through talents or base attributes. For example, I was considering making "Acid Bite" a sustained effect that would add ATOMICEFF_ACID_BURN and ATOMICEFF_DECREASE_BIOENERGY to melee attacks, causing acid burns on melee hits (and also decreasing bioenergy on hit). My instinct was to create a new combat table, combat.on_hit, which would be iterated over and applied whenever a melee attack was successful. Easy enough, and I'm sure I could have gotten it to work if I had continued, but I recognized that the effects would only be applied for basic melee attacks. What I wanted was for the effect to be applied to anything that made an ATOMICEFF_MELEE_ATTACK attempt. Obviously I could just copy-and-paste the code from the attack talent, but I was wondering if it was possible for atomic effects to be called by other atomic effects. I imagine there may be a much easier way of doing this that I'm missing. The idea I keep coming back to is "super effects" which would act like atomic effects but operate internally like talents.

[yufra]

My first instinct to handling "super effects" is actually to create a function that returns a list of effects that a melee attack would do. For example, you could add this to Actor.lua:

Code: Select all

function _M:melee_effects(target, weapon)
    local effs = {}
    local hit = self:calcEffect("ATOMICEFF_MELEE_ATTACK", target, {weapon=weapon})
    effs[#effs+1] = hit
    for eff, params in self.combat do
        local current = self:calcEffect(eff, params.target or target, params)
        -- Link the effects to a successful hit
        current.prob = current.prob * hit.prob
        effs[#effs+1] = current
    end
    return effs
end

Then you would call this for all melee talents like so:

Code: Select all

newTalent{
	name = "Punch",
	type = {"role/combat", 1},
	points = 1,
	range = 1,
	effects = function(actor, part, t)
		local tg = {type="hit", range=part:getTalentRange(t)}
		local x, y, target = actor:getTarget(tg)
		if not x or not y or not target then game.logPlayer(actor, "No valid target selected.") return end
		if core.fov.distance(actor.x, actor.y, x, y) > 1 then return nil end
		local effs = actor:melee_effects(target, part)
		return effs
	end,
	info = function(actor, part, t)
		return "A solid right hook."
	end,
}

Does using helper functions like this fit the bill?

[bricks]

Haha yes. I actually just started doing something like that. Amazing how just writing things down can help me figure out a solution.

[yufra]

Nice, you definitely seem to be getting comfortable with the code.

[bricks]

I've got a few last-minute changes coming down the pipes. I've managed (miraculously) to implement a display for the player's resources based on ToME's code, and now I'm looking at setting up a resource system like I described before. I was going to add in some xenomorph and robot NPCs, but the AI doesn't seem to know what to do yet.

Edit: Done! Hopefully anyone other than Yufra/myself who's interested (anyone?) can play around with this before the chat tomorrow.

[yufra]

EDIT: New instructions below and on the wiki

Yes, anyone that is interested in tinkering with what we have going on now can checkout either my or bricks branch:

https://github.com/mfajer/Gene-Revolution
https://github.com/bricks42/Gene-Revolution

This does unfortunately require a change patch to the engine code which has been incorporated into the SVN, but I will need to figure out how to put it into an add-on to make it easier for everyone to use. You can find the patch here: http://forums.te4.org/viewtopic.php?p=124015#p124015

Features that are implemented:

• AtomicEffects
• Talents associated with body parts, not the actor itself
• Some sample body parts + talents

The next thing I want to work on is having the UI take advantage of the AtomicEffects, namely give you feedback while targeting. Anyway, I am looking forward to seeing everyone tomorrow!

[bricks]

I may not make it in time for the start of the meeting, but I think my positions are pretty clear. Assuming I don't make it at all, could someone grab the transcript and put it on the wiki?

[yufra]

Hello all interested parties. The meeting went well, and you can find the results: https://github.com/TE4-Module-Developer ... 2012-01-07

If you looked at that link closely you will notice a change... we now have an official GitHub organization to store the main fork. I'll put the link below, and if you are interested in making a personal fork, or editing the wiki, etc. please do that on the main fork instead of my personal fork. That way we have everything in one place, and that place is not dependent on one person anymore. The organization can store multiple repositories, so we could even host other modules under the same organization.

https://github.com/TE4-Module-Developer ... Revolution

EDIT: In order to run Gene-Revolution, you will need to update your engine. Rather than require a patch I have created a new engine teae file, and a corresponding boot team file. Download these and put the teae file in game/engines (where you should see a te4-0.9.37.teae file already) and the team file in game/modules (where you should see a boot-te4-0.9.37.team already. Finally, make sure you download the Gene-Revolution directory from GitHub and put it into game/modules. Now when you run ToME you should see Gene-Revolution pop up on your New Game screen.

Downloads:
te4-0.9.38.teae -> game/engines
boot-te4-0.9.38.team -> game/modules
Gene-Revolution -> game/modules (after you unzip it)