Login
User Name:

Password:



Register
Forgot your password?
Vote for Us!
tintin++ ogg sound player script for linux
Author: Robert Smith
Submitted by: Vladaar
6Dragons ogg Soundpack
Author: Vladaar
Submitted by: Vladaar
6Dragons 4.4
Author: Vladaar
Submitted by: Vladaar
LoP 1.46
Author: Remcon
Submitted by: Remcon
LOP 1.45
Author: Remcon
Submitted by: Remcon
Users Online
CommonCrawl, DotBot, Yandex

Members: 0
Guests: 12
Stats
Files
Topics
Posts
Members
Newest Member
481
3,739
19,386
621
KellieBusb
Today's Birthdays
Rane (42)
Related Links
» SmaugMuds.org » General » Coding » Affects - Overhauling the sys...
Forum Rules | Mark all | Recent Posts

Affects - Overhauling the system
< Newer Topic :: Older Topic >

Pages:<< prev 1, 2, 3, 4 next >>
Post is unread #21 Apr 16, 2009, 6:21 pm
Go to the top of the page
Go to the bottom of the page

Kayle
Off the Edge of the Map
GroupAdministrators
Posts1,195
JoinedMar 21, 2006

You wouldn't switch. that command would stay affected.
       
Post is unread #22 Apr 16, 2009, 6:23 pm
Go to the top of the page
Go to the bottom of the page

Hanaisse
Magician
GroupMembers
Posts196
JoinedNov 25, 2007

I concur with David to use effect. In fact, most dictionaries claim 'affect' is no longer a noun so this makes more sense; "The effect affects your character." However, having said that I think there may be cause to use both depending on the implicit meaning of the code. But we're far from coding new so this can be resolved later. We don't even have to use those words *gasp*.

Back on track...

Something I've been thinking about, and feel free to correct me if I'm wrong in any assumptions.

There are two kinds of effects: spells and flags

Spell effects relate to characters, mobs, equipment/objects, race, deity, herbs, potions.
Flag effects relate to rooms, area, polymorph(?), equipment/objects.

Flags can be spells but they also have their own set of definitions. I guess this is where the pile of spaghetti starts as they are both used in the same context with much the same code to provide an effect to something. Would it help to separate them?

For example;

Things could be effected_by spells
Things could be influenced_by flags

Or would that just complicate matters more? Just thinking outside the box here.
       
Post is unread #23 Apr 16, 2009, 6:27 pm
Go to the top of the page
Go to the bottom of the page

Kayle
Off the Edge of the Map
GroupAdministrators
Posts1,195
JoinedMar 21, 2006


Hanaisse said:

Things could be effected_by spells


That would still be affected_by, I believe.
       
Post is unread #24 Apr 18, 2009, 7:31 pm
Go to the top of the page
Go to the bottom of the page

Quixadhal
Conjurer
GroupMembers
Posts398
JoinedMar 8, 2005

Just to pipe up with a suggestion of my own.... as long as you're thinking of using an STL container anyways, why not use std::map or multimap?

If the key side is the effect name (or ID, or whatever), the value side could be the structure and all the data for that effect. Only effects which are present on the character/object/mob/room/whatever would be present.

So, to see what effects are on newblet the level 1 warrior, you just get the keys of the map. Done.
To get the details of one of them, ch->effect["PARALYSIS"].

As to maps vs. multi-maps, that depends on how much you want to change the system. Right now, if I remember right, if you have an effect on something, and you cast another of the same type, it merges the data in a non-standard way. IE: it may refresh the duration, a stronger one may override the values of a weaker one, etc. Using std::map would keep this behavior.

Using multimap, you could cast bless on yourself, and if someone else did the same, you'd have two effects stacked, presumably gaining the benefit from one until it wore off and then getting the other. On the plus side, you can then have more complex spell systems where a dispel of one copy of a buff might not remove the others. On the minus side, all that would have to be changed in code.

Personally, I prefer using strings as identifiers, rather than mucking about with #defines and "magic" bit numbers, but I know the C people would hate that, and the purists who count clock cycles would also complain. Only downside is that you do have to ensure that arbitrary strings can't get used, else typos will be really hard to spot. (IE: use validation for the arguments of affect_add, _join, etc...)
       
Post is unread #25 Apr 19, 2009, 8:26 am
Go to the top of the page
Go to the bottom of the page

Kayle
Off the Edge of the Map
GroupAdministrators
Posts1,195
JoinedMar 21, 2006

I'm still learning C++ myself, and the only thing I have a good handle on is bitset so far, Samson's got the lists down, so we'll for sure be using the two of those. Map/Multimap I'll have to read a bit on before I make a call either way on those. I'm trying to keep the system as simple as possible, so that I can attempt to maintain compatibility with existing snippets and the like. Bitset is going to throw off snippets, as is the std::list, but at least these are easy to spot. a std::map/multimap might not be as easy to spot.

After Kiasyn showed Samson and I a copy of what he had started to do to Drazon when he started working on it, I had a few ideas for things I'd like to improve upon in the new affects code.

1. I'd like people to be able to set up heal-over-time and damage-over-time spells easily. Without having them have to be poison related.
2. I'd like it to allow for multiple modifiers to a single effect. For instance, a single affect could give +5 Str, +3Wis, +2Holy Resist. Without having three entries showing up on the affected by/affects commands.


As far as a definite plan for how we're going to go about this... Uh.. I'm still working on it. I'm having a lot of trouble doing this because of how inately boring the code for affects is, and I'm finding it hard to gather up the drive to work on this.
       
Post is unread #26 Apr 19, 2009, 8:30 am
Go to the top of the page
Go to the bottom of the page

Kayle
Off the Edge of the Map
GroupAdministrators
Posts1,195
JoinedMar 21, 2006

Actually, come to think of it. David brought up a valid point earlier and I totally missed it until I basically restated what he said in my last post.

Maybe the Affects thing is something that we should just do, but then Branch it off in to a separate SmaugFUSS base.

That way, we have SmaugFUSS which continues to be about fixing things that are wrong with the system.
And then, we have SmaugFUSS++ (or SmaugFUSS-Modernized, or something.) which is about modernizing, and replacing systems.

This way the Traps can go in both since they are legitimately broken, and then Affects can be fixed in one, and if the solution doesn't absolutely trash compatibility with snippets, maybe it can go in the normal one too. But then SmaugFUSS++ or whatever can be worked on and modernized, and have things updated to use more modern techniques.
       
Post is unread #27 Apr 19, 2009, 1:51 pm
Go to the top of the page
Go to the bottom of the page

Samson
Black Hand
GroupAdministrators
Posts3,643
JoinedJan 1, 2002

All fine and dandy until someone has to pick up the workload of maintaining two different codebases. That person is not me. One is enough.

I think it's arguable that we've come almost as far as we can on bugfixes alone. There aren't that many issues left to be fixed other than the trap code. At some point we'd end up in a modernization anyway because otherwise the codebase goes dormant. Some may see that as good, I don't. Letting it rot will eventually create the perception that it's no longer being worked on in any capacity. Splitting off a new branch is only going to lead to confusion for most people who won't get why there's even a difference.
       
Post is unread #28 Apr 20, 2009, 2:12 am
Go to the top of the page
Go to the bottom of the page

Quixadhal
Conjurer
GroupMembers
Posts398
JoinedMar 8, 2005

Kayle said:

I'm trying to keep the system as simple as possible, so that I can attempt to maintain compatibility with existing snippets and the like.


As I discovered from the little bit of work I did on the RAM project, backwards compatibility is a myth. :)

That is to say, if a snippet is being applied by a competent coder, it can be pushed into some code that's been chopped up and spun around a few times, as long as they are patient enough to read the snippet AND the code they're trying to merge it into. If not, nothing short of a perfect patch file will be good enough, and unless they get lucky, that never happens.

With that in mind, I suggest going for the tool that makes the job easiest to do, and also makes the code easiest to modify and work with. I don't know that maps are that tool, they're just the one that seems the closest fit to me.

Kayle said:

1. I'd like people to be able to set up heal-over-time and damage-over-time spells easily. Without having them have to be poison related.
2. I'd like it to allow for multiple modifiers to a single effect. For instance, a single affect could give +5 Str, +3Wis, +2Holy Resist. Without having three entries showing up on the affected by/affects commands


Good goals. For that, I would suggest making the affect structure/class itself contain a std::list which contains all the modifers that affect contains. That way, you can extend the system in arbitrary ways, such as making an affect that gives +5 to strength and causes you to be unable to wear armour.

The code that does checks for things like that could either know that the spell "HULK" prevents you from wearing armour, or it could iterate through the set of affects and then search each one's list for such a thing.

As for timed affects... probably just having a defined pair of counters would work. One for number of ticks, and one for delay between ticks, and then a tick() method that gets called to adjust the affects.

All pseudo-code hand-waving below:

class affect {
int tick_count;
int tick_delay;
int tick();
...
}

Let's say you had an affect from the fireball spell, after the initial damage, it applies aff_fireball to you, which lasts for 6 ticks, spaced apart by 2 seconds each.

ticks: 6 -- ch_printf(ch, "Your are blinded by the intense light and feel your hair burning off!";);
ch->add_affect("blindness", 2);
ch->damage(20);
ticks: 5 -- ch_printf(ch, "Your eyes are still tearing up and you're pretty sure your shirt has burned away";);
ch->damage(20);
tmp_item = ch->unequip(chest_slot);
remove_item(tmp_item);
ticks: 4 -- ch_printf(ch, "Your vision returns, and you notice your arm is on fire too!";);
ch->damage(10);
this->tick_delay = 1.5 seconds;
ticks: 3 -- ch->printf(ch, "The fire has ignited your spellbook, and your pants are smouldering.";);
...

You get the idea.

Obviously, the closer you want to stick to the original implementation, the less possible many of these things are... but if you really want to rip this subsystem out and rewrite it, there's no reason you can't make it far more flexible in the process.

In this toy example, the fireball affect actually added the blindness affect to the character, with a tick count of 2.... and let that affect manage itself.

It all boils down to your overall goals. If you want SmaugFUSS to remain strictly a bugfix only version of Smaug, then any real changes are going to be very difficult to accomplish. If you want to make the system more flexible and rip out infrastructure, don't worry about compatibility, because it won't be possible to maintain anyways.

Soooo.... "Smaug" in technical implementation, or "Smaug" in the more nebulous look-and-feel?
       
Post is unread #29 Apr 22, 2009, 5:01 pm
Go to the top of the page
Go to the bottom of the page

Kayle
Off the Edge of the Map
GroupAdministrators
Posts1,195
JoinedMar 21, 2006

Quixadhal said:

As I discovered from the little bit of work I did on the RAM project, backwards compatibility is a myth. :)

That is to say, if a snippet is being applied by a competent coder, it can be pushed into some code that's been chopped up and spun around a few times, as long as they are patient enough to read the snippet AND the code they're trying to merge it into. If not, nothing short of a perfect patch file will be good enough, and unless they get lucky, that never happens.

With that in mind, I suggest going for the tool that makes the job easiest to do, and also makes the code easiest to modify and work with. I don't know that maps are that tool, they're just the one that seems the closest fit to me.


That's the biggest issue I'm having. There are a lot of tools to choose from to accomplish this, and I don't know which are going to be the easiest for people to understand and work with while learning to work with the code. Or even those that know the code to learn to use new tools. As for compatibility, the more I look at the existing implementation, the less and less I feel like reworking it, and I've pretty much decided that the only way to really make these easier to interact with and modify is a clean slate approach. Now it's just a matter of figuring out what the new implementation needs to do to be a viable replacement for the old one. I think it's time to ignore the existing implementation and figure out a list of things the new one needs to do.

Quixadhal said:

Good goals. For that, I would suggest making the affect structure/class itself contain a std::list which contains all the modifers that affect contains. That way, you can extend the system in arbitrary ways, such as making an affect that gives +5 to strength and causes you to be unable to wear armour.


Exactly. This is the kind of dynamicity and flexibility I'm looking to add with a new system. I want people to really be able to design most of their skills and spells simply, and efficiently from inside the game without having to truly need to modify the code except in extreme circumstances. I'm not sure std::list is the best method for this though. Then again, I'm not entirely sure what *is* the best way to accomplish it.

Quixadhal said:

The code that does checks for things like that could either know that the spell "HULK" prevents you from wearing armour, or it could iterate through the set of affects and then search each one's list for such a thing.

As for timed affects... probably just having a defined pair of counters would work. One for number of ticks, and one for delay between ticks, and then a tick() method that gets called to adjust the affects.

All pseudo-code hand-waving below:

class affect {
int tick_count;
int tick_delay;
int tick();
...
}


A good idea, but I think I'd like to pursue an even simpler solution then that.

Quixadhal said:

Let's say you had an affect from the fireball spell, after the initial damage, it applies aff_fireball to you, which lasts for 6 ticks, spaced apart by 2 seconds each.

ticks: 6 -- ch_printf(ch, "Your are blinded by the intense light and feel your hair burning off!";);
ch->add_affect("blindness", 2);
ch->damage(20);
ticks: 5 -- ch_printf(ch, "Your eyes are still tearing up and you're pretty sure your shirt has burned away";);
ch->damage(20);
tmp_item = ch->unequip(chest_slot);
remove_item(tmp_item);
ticks: 4 -- ch_printf(ch, "Your vision returns, and you notice your arm is on fire too!";);
ch->damage(10);
this->tick_delay = 1.5 seconds;
ticks: 3 -- ch->printf(ch, "The fire has ignited your spellbook, and your pants are smouldering.";);
...

You get the idea.


A lot more elegant than I was thinking, but it works.

Quixadhal said:

It all boils down to your overall goals. If you want SmaugFUSS to remain strictly a bugfix only version of Smaug, then any real changes are going to be very difficult to accomplish. If you want to make the system more flexible and rip out infrastructure, don't worry about compatibility, because it won't be possible to maintain anyways.

Soooo.... "Smaug" in technical implementation, or "Smaug" in the more nebulous look-and-feel?


I guess at this point, it's really going to boil down to fixing design flaws in the system since there seem to be very few real bugs left to track down. Maintaining some semblance of compatibility though would be nice, but it's probably a pipe-dream if we really want to modernize the base and breathe new life into it.
       
Post is unread #30 May 3, 2009, 6:34 pm
Go to the top of the page
Go to the bottom of the page

Kayle
Off the Edge of the Map
GroupAdministrators
Posts1,195
JoinedMar 21, 2006

So as I've been working on this the last week or so, I keep hitting the same roadblock. I seem to keep going in circles. I'll get to a point where I think I'm ready to start developing the struct/class and then as I work on it, I end up with the same fields that the existing ones have, and for a clean slate approach that's not a very good idea. Last I checked clean slate meant it shouldn't start the same way as the existing implementation. Although given the troubles I've been having with this an actual revision might be easier then rewriting the thing from scratch. So I'm forced to pose the question here, which might prove to be a difficult task, as I have sporadic access to the internet since having my internet connection turned off at home because I'm sick of Comcast's bullshit. But that's a tale for another time. So...

What do these need to do? What kind of things do these absolutely HAVE to do. I'm not talking cool features people want to see. I'm talking things they NEED to be able to do. Necessities always come before wants.

I know they need to interface well with characters, mobs, objects, and rooms, and also with the OLC Skills/Spells.
I also know they need to be easier to use.

What I don't know is how to go about doing it. Or where to start. So any suggestions are welcome. I'm tired of going in circles and getting no where, I'd like to finally get further then planning on this.
       
Post is unread #31 May 3, 2009, 9:15 pm
Go to the top of the page
Go to the bottom of the page

David Haley
Sorcerer
GroupMembers
Posts903
JoinedJan 29, 2007

I think a good start would be to do what the current system already does, frankly. If the idea is to completely overhaul the system, that's not the kind of thing one person working in isolation would do -- that's a pretty massive question! If the goal is however to clean up the implementation while preserving the functionality, that's at least achievable.
       
Post is unread #32 May 3, 2009, 10:26 pm
Go to the top of the page
Go to the bottom of the page

Kayle
Off the Edge of the Map
GroupAdministrators
Posts1,195
JoinedMar 21, 2006

Unfortunately, I'm forced to work in isolation for the time being, because until I get this crap with Comcast sorted out, I won't have internet again. The short version is that they were charging me for services rendered, while said services were suspended because I forgot to "make the payment in a timely manner" (read: it totally slipped my mind and I spent the money on something else, vastly less important). But anyway, enough about my fiscal irresponsibility.

A revision of the current system might be the best way to approach a complete rewrite, and honestly, if done properly, it could avoid the need for a rewrite entirely. Either way, I'm still not sure where to start. I'll be around off and on till about noon tomorrow while I'm here at the hotel doing some prep-work for an upcoming server replacement before I vanish off back into the tranquility that is my net and cable-less house. Which I've actually come to enjoy not having all those distractions, I've gotten a lot of reading done, and some planning for some major systems for MW as well. Imagine that, not being able to talk on ichat endlessly for days has made me productive. :P

       
Post is unread #33 May 4, 2009, 8:43 am
Go to the top of the page
Go to the bottom of the page

Quixadhal
Conjurer
GroupMembers
Posts398
JoinedMar 8, 2005

It's been a while since I really looked at the SmaugFUSS code, so for all I know this might already be done, but a first suggestion I have is to run through the code and eliminate any instances where the bit values matter.

That is to say, if(blah.affected_by & AFF_FOO) is bad, if(affected_by( blah.affected_by, AFF_FOO) is better, if(blah->affected_by(AFF_FOO)) is better still. In MY mind, if(blah->affected_by("foo";)) would be the best, but some people still harp on the efficiency bandwagon.

That frees you to change the code-side of things without worrying about how the order of bits matters, or exactly how various combinations get applied.

The next step after that (for my thinking) would be to make the data files more well-defined. Instead of affected_by bit values crammed into integers, and tossed in arbitrary fields of objects, make a solid data format that describes what needs to be saved. Initially, this might just be "AFFECTS\nfoo\nbar\nEND AFFECTS\n". Later, you might want to add in values or properties for some of them.

One other thing I've found is that people in Dikuland seem to treat their data file formats as sacrosanct. It's trivial to store a version number at the top of each area file and use the appropriate loading routine, always saving with the "current" format. If there's no version ID, it must be "old", where old might be defined as what's used now. It made a bit more sense before OLC, but the supposed goal of OLC is to NOT have people hand-editing the files.... so changing them shouldn't matter, as long as the conversion is seamless.

I dunno if that's helpful at all, but maybe approching it from that angle might lead you to think about things differently, and thus get around the sticking point you were at. :)
       
Post is unread #34 May 14, 2009, 7:08 am
Go to the top of the page
Go to the bottom of the page

Kayle
Off the Edge of the Map
GroupAdministrators
Posts1,195
JoinedMar 21, 2006

So I've been meaning to work on this, but TES4: Oblivion on my 40" HDTV was a bigger draw. I've been attempting to pull myself away from it to get some work on this done, but I've been failing miserably.

So, while I will eventually get to this, if anyone else wants to take up the torch and run with it, feel free. I'll pick up where ever who ever takes the torch leaves off when I get the drive to work on this.
       
Post is unread #35 Jun 19, 2009, 9:20 am
Go to the top of the page
Go to the bottom of the page

Kayle
Off the Edge of the Map
GroupAdministrators
Posts1,195
JoinedMar 21, 2006

Well, it appears no one wanted to take the load while I was distracted. So I guess it's time for me to take up the mantle of Affects rewriter again. Well, here's hoping this attempt goes a lot better than the last one.
       
Post is unread #36 Jun 19, 2009, 4:52 pm
Go to the top of the page
Go to the bottom of the page

Conner
Sorcerer
GroupMembers
Posts870
JoinedMay 8, 2005

Good luck?
       
Post is unread #37 Jun 20, 2009, 11:55 am
Go to the top of the page
Go to the bottom of the page

Kayle
Off the Edge of the Map
GroupAdministrators
Posts1,195
JoinedMar 21, 2006

Thanks I may need it. XD Affects are a lot bigger beast then the Weather was.
       
Post is unread #38 Jun 20, 2009, 2:25 pm
Go to the top of the page
Go to the bottom of the page

Conner
Sorcerer
GroupMembers
Posts870
JoinedMay 8, 2005

Hmm, does that mean you overhauling them is going to make SmaugFUSS become version 1.10? :tongue:
       
Post is unread #39 Jun 20, 2009, 2:44 pm
Go to the top of the page
Go to the bottom of the page

Kayle
Off the Edge of the Map
GroupAdministrators
Posts1,195
JoinedMar 21, 2006

That or make it 2.0. Depends on how we decide to handle the next version bump. :P
       
Post is unread #40 Jun 20, 2009, 5:37 pm
Go to the top of the page
Go to the bottom of the page

Conner
Sorcerer
GroupMembers
Posts870
JoinedMay 8, 2005

Hmm, I thought Samson was waiting on bumping the version number to 2.0 for something a bit more momentous, but I suppose it is a possibility.
       
Pages:<< prev 1, 2, 3, 4 next >>