When somebody thinks of something that is still broken/not reimplemented she/he should note it here.

When you start working on something put your name on the item so that others wont try to do it at the same time. When it is done move the item into the Done part.

Todo for 3.0.0

Engine

ToME module

Done

Will not do

Chatter

TOMEfourever: Is this project still being worked on?

NeilStevens: Yes, though DG's ability to devote time to it comes and goes, apparently. So some months a LOT happens, and some months not very much happens. I've actually been meaning to get back to the item list pretty soon myself.

KhymChanur: How is player levels above 50 going to work? Will levels past 50 only increase the player's max HP and MP, or will the player get more skill points as well? Will skills still have an upper limit of 50?

Oh, wait, I guess that would be a per-module thing that shouldn't be hard coded in the engine, and the the ToME module will still do things the same?

Also, what is this "GUSS" that you refer to regarding pseudo-magic schools?

DarkGod: Yup per module basis. GUSS = Grand Unified Spell System

NeilStevens: GUSS is the magic system introduced in ToME 2.0. Since so many discussions of ToME 3 improvements include rewriting various things into GUSS, we eventually named it the Grand Unified Spell System, and then we needed the acronym to make it easy to type!

Zonk: regarding levels above 50...The current alphas currently use a table for experience needed, and they (of course)don't allow you to go above 50. When you introduce skills and experience levels > 50, you might add the option to use a formula instead of a table, so one could, for example, use the same formula as D&D -> exp needed to reach next level = (exp needed to reach the current one + current level x 1000)

DarkGod: Persistant levels already work, no ?

NerdanelVampire: I noticed the CVS todo mentioned time travel. It'd be interesting to know how that's supposed to work, particularly as time travel is canonical for the Modules/Zothiqband I've been working on and in fact a part of my planned plot.

DarkGod: It's in the todo for over 4 years now ;) The basic idea at the time was to allow prefixed to the past time travel. That is a specific point in time is selected and any travel will get back there. Basically this works as a second savefile. But I'm not sure yet(yes afetr 4 years ;)

RavenRed: FearofFours, Mindcraft was already rewritten into lua by MM in the Mindcraft Module. It was altered, but it's there. And "The Rush" was, as I recall, for the short-lived "Blade" class in the late-Pern era...

IainMac: Anyone know what needs to be done for the cleanup of the level generation code ?

(Discussion of other forms of time travel moved to Modules/Time Travel

KhymChanur: Tome3 is crashing on me in overland mode travel; I think it's because of a memory bug. So I'm using Valgrind to track down memory bugs. Looks like there might be a lot of them.

RavenRed: Er... when you say "* Get archery working again.", will that be a functional replica of the 2.x system or a new one?

JulesBean: I did some work on this a while back, had it more-or-less working (and using flags, ToME 3 stylee) but without traps. Depending how far you've got it might or might not be useful to you.

JohnGilmore: I though I'd implement an enhanced "visible monsters list" functionallity under tome3, and make it even better than my patch for tome2. And maybe if that goes well, I'll do a "objects on ground" list like I did for tome2.

Unfortuneatly, I can't. The player appears trapped in forest, and cannot move even in wilderness travel mode. can't debug a monster list if I can't see any monsters! ODE doesn't even allow STARTING a char, much less seeing a monster.

<rant> I thought that the engine (and the tome module) was stable enough that I could develop against it. I guess I was wrong. I'll just go back to enhancing tome2, I guess. (bored, frustrated) I've got a great mod for making objects your companions are carrying persistent across levels. Works great. Or, at least well enough. I think I've got the object duplication issues worked out. And with a bit of lua (mostly borrowed from t-plus2's m_barter.lua) I can give my companion "horse" stuff to carry back to town to sell, and all sorts of other neat stuff. So there! /me sticks tongue out. </rant>

Seriously, what gives? Is this just today, or...

JohnGilmore:Ok. I feel a little better now. There is probably an official version that I should have grabbed. But the Alpha3 release is 5 months old. Old enough that it's probably pointless to write a patch on it to add the hook needed to add an option window type. So I'm a little lost here. I think it's time to patch it up and release it again. Or something. I don't know. I just know that I don't know what to do next.

DarkGod: Uh ? http://forum.t-o-m-e.net/viewtopic.php?t=7535 It works well with ODE(remember to delete your ~/.tome/3.0 directory). And yes I'm most quiet currently :/

NerdanelVampire: Any plans to luafy the skill calculations or at least make it so that the module can choose how bonuses should be added up? I've looked into a way of making the racial etc. skill bonuses behave like true bonuses that do not affect skill level overages but do affect skill maximums. I found out that the relevant code was still in C.

NerdanelVampire: A simple request: I would like an user-definable drop_chance function (default: return true) for the object_enchant_drop subsystem that would check if anything at all would be dropped and would then exit if not. Namely, I successfully reduced dungeon litter by making it only 20% likely for every drop to pass through, unless it was dropped by a ONLY_GOLD or MIMIC monster, but the move to the subsystem broke this. I really wouldn't like to maintain a separate branch of object_enchant_drop.lua just for a single if clause, particularly as the subsystem in its current state is still missing the all-important object enchantment code that I've been waiting for so that Zothiqband could become beatable in practice like in theory and the players could see all the nice places like R'lyeh without the wizard mode.

NerdanelVampire: I'm not sure where to put this, but I took a look at the CVS and found out what seems to be Neil's reaction to my usability comments in the form of a change to engine/birth.lua. "Don't re-randomize the name at birth once it's set in the save" What? I think the character name should only be preserved when it is essentially the same character as you chose 'y' at the game start to restart. But when you want to play totally different characters with the same savefile (I only use one savefile per module EVER unless stopped by incompatibilities between versions) it doesn't make sense that the Martian, the Frenchman, the savage subhuman, and the bat demon familiar all have the same name. And if you want to make character dumps, it's not nice to have your old dumps get accidentally overwritten simply because the name is the same.

And hey, I made an all-new random name generator with lots of syllables hand-picked to be thematic, I'd like to see it get use with every character that is not just a restarted version of an old one. I've even been thinking of making multiple name generators to accommodate the multiple types of playable characters (Zothiqband is all about the happy meeting of a strong theme and a gamist playing style, and default character names are strictly on the theme side of the divide), and the previous change just trashes the idea from the start.

I want the baby interface die a nasty death, and if not that, I want it to stay in its corner and stop bothering the polishedness rest of the game with nonsensical changes. :(

NeilStevens: That change had nothing to do with you. That change fixed my remaining annoyance with Babyface: that replaying the same quickstarted character every time would result in a new, differently-named savefile every single time.

Oh, and this change doesn't affect anything that modules are able to do. Instead of doing this: 

    -- Make up a random name based on the race(and not subrace) descriptor 
        { action = "random_name" random_name_descriptor = "race" },

Do this: 

{ custom = function()
        player_name(birth.create_random_name(player.get_descriptor("race"))
end }

As for babyface, I really don't see DG ditching it. He spent a fair amount of time fixing all MY complaints about it when it first came out. And as far as I'm concerned, you get the same functionality now you had before. You just need to adapt to it.

DarkGod: Savefiles will now be correctly renamed by Babyface based on the new choosen name for the character. And yes babyface is here to stay ;)

DarkGod: Curse is just a test in the inventory subsystem, I'm not sure it really deserves a specific subsystem. Pseudo id is indeed a good thing to subsystemify.

DarkGod: About birth options, why ? Or rather which birth option would be needed? As for random quests we need to discuss what we want exactly. A few princess or FF quests here and there are fine, but then they should not be too common. I was thinking of having "wilderness encounters" that could be more than just sucky ambushes. Like you encounter a merchant, or a guy that gives a quest to do some random thing in some random place(possibly a randomly generated dungeon nearby the guy's location). As for learning new "weird" skills(like summoning, possession, necro, ......) I thought there should be either an hardcoded quest for it somewhere in the world or be available with one of those wilderness encounters(you meet a yeek, which happens to really be a possessor that got "stuck" into this body, and he needs *whatever* to be done to free him).

KhymChanur: For birth options, even if the ToME module winds up not needing any, there needs to be something in the birth interface to allow for asking for options in case a different module needs them, plus there might be module addons that a player wouldn't want on for every game, but allowing it to be turned on or off after player birth would be cheating. For the ToME module, I was thinking ironman rooms, always small levels, and allowing/disallowing fates.

DarkGod: I don't think we want/need ironman rooms/small levels or fates anyway ;) As for displaying options at birth, a call to option_display should be all that is needed IIRC. IMO wilderness encounters/random quests are more important

NeilStevens: I don't think we need a special engine anything to do birth options. You can just mark a page of options as Birth Options, and only READ the options at birth. NPPAngband does it this way for example: you can change the birth options at any time, but they just don't take effect until the next game.

And yes remember: the birth sequence is infinitely customizable, so the engine needs NOTHING special here.

As for fates: if they come back they need fixed. Too many fates at level 1. As for random ToME 2-style dungeon quests, ironman roomsm and small levels, those will depend on how many other quests we can cram into the game. If we put enough things to do into the game, all three can be dropped entirely.

So let's make that our goal.

DarkGod: Yup

Developers Corner/3.0.0 ToDo (last edited 2007-05-24 18:06:51 by KhymChanur)