#tfl@irc.freenode.net logs for 27 Oct 2006 (GMT)

Archive Today Yesterday Tomorrow
tfl homepage

[02:41:08] <-- wizardrydragon has left IRC (Read error: 110 (Connection timed out))
[02:54:07] --> Marzo has joined #tfl
[02:54:08] --- ChanServ gives channel operator status to Marzo
[02:55:18] <Marzo> wizardrydragon: Should you read this, there are a few spam posts demanding deletion at the TFL forum
[02:56:02] <Marzo> (or, at least, they were a couple of posts when I last looked at the forum)
[02:56:34] <-- Marzo has left IRC (Client Quit)
[14:08:43] --> wizardrydragon has joined #tfl
[14:08:43] --- ChanServ gives channel operator status to wizardrydragon
[14:48:45] --> Marzo has joined #tfl
[14:48:46] --- ChanServ gives channel operator status to Marzo
[14:48:56] <Marzo> Hi
[14:49:13] --- wizardrydragon removes channel operator status from exultbot
[14:49:18] <wizardrydragon> moo
[14:49:45] <Marzo> I have been thinking about making a few changes (or rather, additions) to UCC
[14:50:00] <Marzo> More specifically, regarding scripts
[14:50:17] <wizardrydragon> Oh goody, breaking our code is fun
[14:50:18] <wizardrydragon> :D
[14:50:24] <Marzo> And I thought I'd bounce the ideas around for thoughts
[14:50:39] <Marzo> Which is why I changed to 'additions' :-)
[14:51:09] <Marzo> I am thinking about adding a third way to create and execute scripts
[14:51:43] <Marzo> (the first being the [delayed_]execute_usecode_array intrinsics, and the second being script blocks)
[14:53:11] <Marzo> The idea being to use something like this: you create a script (using normal UCC script block syntax) and execute along the lines of 'AVATAR.run_script(script, otd_delay);'
[14:53:43] <Marzo> Where 'script' is, in the end, an array similar to the one from [delayed_]execute_usecode_array
[14:53:56] <Marzo> But it is created similar to a script block
[14:54:04] <wizardrydragon> Hmm
[14:54:26] <Marzo> The syntax I have been thinking goes like this:
[14:54:28] <Marzo> var test;
[14:54:29] <Marzo> test << { step 0; step 0; };
[14:54:29] <Marzo> test << { step 2; };
[14:54:55] <Marzo> The '<<' appends the commands on the right to the var in the left
[14:55:35] <Marzo> And in case you are wondering: the reason for this is that I am thinking of using this to completely overhaul the spell system
[14:56:39] <Marzo> Right now, spells have two mostly identical script blocks, one for when the casting succeeds and one for when it fails
[14:56:55] <wizardrydragon> How about, instead of reinventing the wheel, we put the wheel on a wagon first? :P
[14:57:08] <Marzo> Explain, please
[14:57:42] <wizardrydragon> We've been sitting around fiddling with a half-complete NPC spell system for a while. Instead of frequently rewriting it, how about we just finish it?
[14:58:07] <Marzo> This rewrite would be for the spells mostly
[14:59:00] <Marzo> The other functions would remain almost untouched
[14:59:06] <wizardrydragon> And what's the major focus of a spell system, if not the spells?
[14:59:21] <Marzo> What I am going for is to centralize the checking of whether or not the spell failed
[15:00:14] <Marzo> If you check the code, almost all spells check to see if there is a magic storm in progress and a few other conditions
[15:00:18] <wizardrydragon> I see. How is this something we couldn't do with existing construscts?
[15:00:20] <Marzo> (if not all)
[15:01:12] <Marzo> And while some of them have other actions and other conditions, this can be dealt with in a way that centralizes condition checking
[15:02:36] <Marzo> The main benefit would be to have basically a single ritual for each spell which is modified by adding the spell failing code or the spell sucees code
[15:03:18] <wizardrydragon> I don't see how this couldn't be addressed by simply calling an external function declared in a header file.
[15:03:36] <Marzo> It could be done with the [delayed_]execute_usecode_array intrinsics
[15:04:07] <wizardrydragon> Well, simply because it can be done that way doesn't mean it's the best way to do it :)
[15:04:24] <Marzo> Which is why I am not wanting to do it that way :-)
[15:04:44] <Marzo> For it to work well, it requires somewhat dynamic scripts
[15:04:44] <wizardrydragon> Mind you, I've had thoughts about how the spell system can be redone as well, but not along those lines.
[15:05:08] <Marzo> What have you been thinking about?
[15:05:40] <Marzo> The main advantage of doing it the way I am thinking is that it would be easier to have NPCs cast spells for 'show'
[15:06:16] <Marzo> For example, in a custom usecode schedule where the master is teaching an apprentice to cast a spell
[15:07:05] <wizardrydragon> I was thinking of reorganizing it to form it a little like the way Morrowind handles spells, because it makes a great deal of sense to me
[15:07:05] <Marzo> (I am thinking of having a centralized function that 'distributes' the spell rituals, BTW)
[15:07:20] <Marzo> You will have to explain more
[15:08:02] <wizardrydragon> Basically it has a "spell" which is an array of "spell effects" which has "requirements" to cast, and, sometimes, consumes certain items when cast.
[15:08:30] <wizardrydragon> Many spells have variable magnitude, as well.
[15:08:37] <Marzo> Oh, you mean having leveled spell effects
[15:08:47] <wizardrydragon> Not neccesarily, but that would help.
[15:09:02] <Marzo> That would be easy to do
[15:09:04] <wizardrydragon> Basically, I want to modularise the spell code a bit.
[15:09:17] <Marzo> How so?
[15:09:22] <wizardrydragon> And I want to seperate the effects of a spell from the actual spell.
[15:09:40] <Marzo> The latter goal is similar to what I have in mind
[15:09:54] <wizardrydragon> Where I want to have ritual spellcasting in some cases, I want the "spell" code to only contain the ritual, not the affect of the ritual
[15:10:29] <Marzo> Heh... like I said, exactly what I aiming for by adding this new scripting method
[15:10:45] <wizardrydragon> As well, seperating the spell effect from the spell code, would allow the spell effect to be recycled across different spells, doubly so if we add allowances for magnitude.
[15:10:51] <Marzo> Although I want to move the ritual out, not the spell effect
[15:11:13] <Marzo> I don't think there will be many cases in which it will help
[15:11:42] <wizardrydragon> Where the spell system for TFL will be independant, there will be many cases in the foreseeable future.
[15:11:44] <Marzo> (but that is just my impression after reformatting all of the original spells)
[15:11:52] <Marzo> Good point
[15:12:14] <wizardrydragon> Same when I go to add in SI's spell system, which also should be independant
[15:12:44] <Marzo> I don't think that the spell systems actually need to be independant, BTW
[15:13:16] <wizardrydragon> I do.
[15:13:21] <Marzo> The current one is quite capable of handling them all with the same mechanics and being quite transparent to the player
[15:13:39] <wizardrydragon> You misunderstand what I mean by independant, however, I think
[15:13:47] <Marzo> Er... transparent as in the player not having an idea that they are all the same code
[15:14:04] <Marzo> Then, please explain
[15:14:09] <wizardrydragon> Yes, they'd have the same system, that's the entire reason I am thinking of ways to change things.
[15:14:44] <wizardrydragon> What I mean by independant in the case of TFL and SI spells, is I think there should be seperate instances of spells for TFL/SI/BG versions.
[15:15:17] <Marzo> I don't think this will be really needed
[15:15:24] <Marzo> But I could be wrong
[15:15:50] <Marzo> One could just check the map and select the desired effect
[15:16:23] <wizardrydragon> Er, I want it so you can "port" spellsystems across maps.
[15:16:33] <Marzo> (but maybe that is me being dense -- it has been known to happen :-p)
[15:16:45] <Marzo> Oh, right
[15:17:04] <wizardrydragon> Anyways, Im going to get some lunch, be back in while (since I'm eating out) :P
[15:17:12] <Marzo> The way things currently are done, the spells would need a different name
[15:17:25] <Marzo> I too will be going out
[15:17:34] <Marzo> BBL
[15:17:59] <-- Marzo has left IRC ("Marzo vanishes suddenly.")
[15:37:54] <-- wizardrydragon has left IRC (Read error: 110 (Connection timed out))
[16:59:28] --> Marzo has joined #tfl
[16:59:28] --- ChanServ gives channel operator status to Marzo
[17:02:48] --> wizardrydragon has joined #tfl
[17:02:48] --- ChanServ gives channel operator status to wizardrydragon
[17:09:53] --- Marzo is now known as Marzo_away
[17:17:45] --- Marzo_away is now known as Marzo
[17:17:45] <Marzo> Hi
[17:18:12] <wizardrydragon> moo
[17:18:18] <Marzo> bah
[17:18:22] <wizardrydragon> lol
[17:18:30] <Marzo> :-)
[17:18:35] <wizardrydragon> and you get touchy when *I* go into sheep mode ...
[17:19:05] <Marzo> That wasn't sheep mode, it was just an ordinary dismissive interlocution :-)
[17:19:11] <wizardrydragon> lol
[17:22:18] <wizardrydragon> anyways, where did we leave off on spells?
[17:22:42] <Marzo> Let me see
[17:23:12] <Marzo> I was thinking of a way to move the spell rituals from the spell functions and proposed a new scripting mode for UCC for it
[17:23:21] <wizardrydragon> I thought that isolating spell effects from spell functions (having the spells them selves as wrappers) would make it much easier for modders using our work to make new spells
[17:24:01] <wizardrydragon> It'd also make it easy to have a spell creation system in game if anyone feels that ambitious :)
[17:24:21] <Marzo> That would be difficult, but possible
[17:24:32] <Marzo> Yes, I can see how it would be done
[17:25:04] <Marzo> There would be the need for a lot of ready-made functions, but it is possible
[17:25:10] <wizardrydragon> Indeed.
[17:25:38] <Marzo> In any case, you never gave me your opinion about the new scripting schema I proposed
[17:25:42] <wizardrydragon> I don't really plan on going that far, but it would make things a lot easier for people modding the spellsystem to have the spell effects modularized in that way, in any event
[17:26:20] <Marzo> The modularization would be piece of cake compared to the 'spell research' I thought about
[17:26:28] <wizardrydragon> :)
[17:26:44] <wizardrydragon> I don't think I quite understood said "spell research"
[17:27:03] <Marzo> The ability to create new spells through in-game 'research'
[17:27:35] <Marzo> ('research' meaning you spend some time creating the spell ritual and defining its effects)
[17:28:13] <Marzo> Specially given that the spells have a vocal component which should match the spell's effects
[17:28:15] <wizardrydragon> Hmm
[17:28:28] <wizardrydragon> If we have the spell effects thing, that would not be difficult, I dont think
[17:28:37] <Marzo> Liek I said, possible -- but difficult
[17:28:45] <Marzo> Oh, yes, it would :-)
[17:28:51] <Marzo> *like even
[17:29:04] <wizardrydragon> I dont think so.
[17:29:24] <wizardrydragon> But what I asm thinking of may differ from what yhou are, so please, elaborate :)
[17:29:51] <Marzo> Well, creating a spell would essentially require a way to have dynamic usecode
[17:30:01] <wizardrydragon> Not neccesarily.
[17:30:03] <Marzo> This is possible through indirect addressing
[17:30:25] <wizardrydragon> But it'd require changes, what I'm thinking of, as well.
[17:31:06] <Marzo> If the possible spell effects are 'hard-coded', you are right; if the player gets to write his own spell, the dynamic usecode is very mandaroty
[17:31:08] <wizardrydragon> spell = playerspells[spellindex[spelleffects]]
[17:31:25] <Marzo> *mandatory
[17:31:35] <wizardrydragon> I don't know if you can nest arrays like that in UCC, though
[17:31:47] <Marzo> You can; like this:
[17:31:57] <Marzo> array1[component] = array2;
[17:32:22] <Marzo> Any other methods fail
[17:32:38] <wizardrydragon> So then have an array of player spells, and have a spell reference be an array of the spells effects
[17:32:42] <Marzo> (and fail by design)
[17:33:05] <wizardrydragon> Then when you cast the spell, have a lookup if its a custom spell
[17:33:27] <Marzo> You are missing the details here; I was thinking of the spells themselves, not the calling of the spells
[17:33:45] <wizardrydragon> In game terms it would be transparent
[17:33:49] <Marzo> (more specifically, how the usecode of the player spells itself would work)
[17:34:02] <Marzo> The calling is the easy part
[17:34:03] <wizardrydragon> You would have a "new spell" that would be a reference of "spell effects"
[17:34:12] <wizardrydragon> The tricky part
[17:34:16] <Marzo> Which is my point
[17:34:39] <wizardrydragon> Would be getting a name for it, since there is no way to get text input inherent to U7 IIRC
[17:35:15] <Marzo> It is possible to give them names, but it would be boring
[17:35:30] <wizardrydragon> Boring, how?
[17:35:38] <Marzo> All that is needed is to ask letter by letter and concatenate it
[17:35:45] <wizardrydragon> Ah
[17:36:18] <wizardrydragon> I was thinking more of just a textbox ingame somehow, even a bland SDL one would be ok as a placeholder :P
[17:36:23] <Marzo> It would be boring for the player and boring for the poor usecoder
[17:36:45] <wizardrydragon> Usecoding IS boring, whats the point? :P
[17:36:57] <Marzo> Although I must say that a text-entry intrinsic would have MANY uses
[17:37:01] <Marzo> :-p
[17:37:07] <wizardrydragon> The fun part is seeing it actually work in Ultima VII
[17:37:14] <wizardrydragon> If it works, anyhow
[17:37:24] <Marzo> I like usecoding, don't go dissing it :-)
[17:37:50] <wizardrydragon> (Did I miss an 'I"? My mind is rather foggy since I'm doped up on morphiene atm)
[17:38:25] <Marzo> ?
[17:39:18] <wizardrydragon> hahahaha
[17:39:25] <wizardrydragon> Theres a good quote, I jsut read
[17:39:37] <wizardrydragon> "Understandingh is half the battle. Fireballs are the other half."
[17:39:43] <Marzo> lol
[17:39:55] <wizardrydragon> Hmm
[17:40:00] <Marzo> I likely sound pushy, but you still haven't said what you think about the alternate script method I proposed
[17:40:18] <Marzo> I want to know if I should waste time implementing it or not :-)
[17:40:30] <wizardrydragon> Oh I thought I had. I think its good, but I wondered if what you were hoping to accomplish with it couldn't be done in other ways.
[17:41:11] <Marzo> I was trying to modernize how some scripts are written; for example, the earthquake spell
[17:41:41] <Marzo> Right now, it requires the use of execute_usecode_array, which is outdated :-P
[17:42:05] <Marzo> (er... *tremor* spell)
[17:42:18] <wizardrydragon> EUA is to UCC what Assembler is to C - mostly archaic but sometimes neccesary.
[17:42:47] <Marzo> Preciselly why I wanted to update that part of the code
[17:43:13] <Marzo> So that it *won't* be neccessary
[17:43:16] <wizardrydragon> hrm
[17:43:31] <Marzo> (I think there are too many 'c's in the last sentence, but I might be wrong)
[17:44:05] <wizardrydragon> Actually, you *proper* spelling is neccesary, common spelling is lazy and drops a c :)
[17:44:14] <Marzo> And besides, it has other uses (such as removing the rituals from spell functions)
[17:44:15] <wizardrydragon> (That happens a lot with double constanants)
[17:44:52] <wizardrydragon> (And, apparently, with u
[17:45:16] <wizardrydragon> Hmm, thats where I wondered if there wasn't other ways to do that.
[17:45:24] <Marzo> OK, I have figured out a way to make the required dynamic usecode for custom spells
[17:45:27] <wizardrydragon> It's still useful for cutting down EUA usage though.
[17:46:05] <Marzo> In the spell rituals: currently, each spell ritual appears twice in each spell
[17:46:13] <Marzo> In schematic notation:
[17:46:26] <Marzo> if (notInMagicStorm())
[17:46:45] <Marzo> {
[17:47:04] <Marzo> script item nohalt; sfx num; ritual;
[17:47:05] <Marzo> }
[17:47:08] <Marzo> else
[17:47:10] <Marzo> {
[17:47:23] <Marzo> script item nohalt; ritual; call spellFails;
[17:47:24] <Marzo> }
[17:47:32] <wizardrydragon> Hmm
[17:47:45] <Marzo> Where 'ritual' stands for a sequence of motions made when casting the spell
[17:48:08] <Marzo> (the exact position of the sfx varies by spell)
[17:48:12] <wizardrydragon> Would it not be logical to remove it from the conditional if it's being called in both cases?
[17:48:36] <Marzo> ('spellFails' is a function which displays the puff of smoke and plays the sound of the failing spell)
[17:48:58] <Marzo> It would, but current script blocks don't let it
[17:49:10] <Marzo> Which is the point of moving the ritual out
[17:49:10] <wizardrydragon> Hmm. Howso?
[17:49:22] <Marzo> There would be a basic spell 'skeleton'
[17:49:30] <Marzo> Like this:
[17:49:52] * wizardrydragon believe our ends are the same, its how were thinking of doing it that's different :)
[17:50:00] <Marzo> ritual << getSpellRitual(circle, spell);
[17:50:11] <Marzo> if (notInMagicStorm())
[17:50:12] <Marzo> {
[17:50:39] <Marzo> er... scratch that
[17:50:43] <Marzo> Better way:
[17:50:44] <wizardrydragon> lol
[17:51:13] <Marzo> var failed = norInMagicStorm() && targetHasCrown() && whatever();
[17:51:23] <Marzo> if (failed)
[17:51:44] <Marzo> scratch that too :-)
[17:51:50] <Marzo> var failed = norInMagicStorm() && targetHasCrown() && whatever();
[17:51:54] <wizardrydragon> Er
[17:51:55] <wizardrydragon> Wouldnt the proper logic al operator be OR?
[17:52:05] <Marzo> ritual = getSpellRitual(circle, spell, failed);
[17:52:14] <Marzo> Yes, that too
[17:52:35] <Marzo> item.run_script(ritual);
[17:52:52] <Marzo> And getSpellRitual would return the proper ritual
[17:53:04] <Marzo> Having the concatenation of rituals
[17:53:12] <Marzo> er... of *scripts*
[17:53:16] <Marzo> like this:
[17:53:28] <Marzo> ritual << {nohalt;};
[17:53:40] <wizardrydragon> Hmm
[17:53:44] <Marzo> it (failed)
[17:53:44] <wizardrydragon> That would make a LOT of sense
[17:53:56] <Marzo> {
[17:53:59] <Marzo> ritual << spellritual;
[17:54:09] <Marzo> ritual << {call spellFails;};
[17:54:10] <Marzo> }
[17:54:13] <Marzo> else
[17:54:14] <Marzo> {
[17:54:26] <Marzo> ritual << {sfx spellsfx;};
[17:54:39] <Marzo> ritual << spellritual;
[17:54:40] <Marzo> }
[17:54:55] <wizardrydragon> That would make a lot of sense.
[17:54:57] <Marzo> And a lookup table filling in spellritual and spellsfx
[17:55:01] <wizardrydragon> Indeed
[17:55:26] <wizardrydragon> THen just add in a call that looks up the spell effect, to have the modularized spell effects :)
[17:55:36] <Marzo> The spell skeleton would then also call the spell function for its effects
[17:55:39] <Marzo> Yes
[17:56:15] <Marzo> So you see, we were after the same goal more or less
[17:56:32] <wizardrydragon> [27/10/2006 13:49 EST-5] * wizardrydragon believe our ends are the same, its how were thinking of doing it that's different :)
[17:56:39] <Marzo> :-)
[17:57:32] <Marzo> I even believe that we could use a single function to return the casting words, ritual and sfx by the use of an array
[17:58:13] <wizardrydragon> Hmm
[17:58:36] <wizardrydragon> Casting words might be best kept as a part of the ritual itself
[17:59:04] <Marzo> Possible; but as it stands right now, they are said through item_say intrinsic
[17:59:41] <wizardrydragon> I mean, have the itemsay be part of the ritual of casting.
[17:59:59] <wizardrydragon> It makes sense after all, since it very much is part of the "ritual" of the spell casting
[17:59:59] <Marzo> I got that
[18:00:16] <Marzo> I agree; I was just saying how it is right now :-)
[18:00:49] <Marzo> It would likely have to be placed right after 'nohalt' to preverve the way spells appear
[18:01:25] <Marzo> The best part of this new way of doing things is that the check for failed spells is done once, and is easily modified
[18:01:33] <wizardrydragon> Indeed. I'm not terribly concerned about keeping everything exactly as it was -after all we're doing all this to make changes to begin with :)
[18:01:43] <Marzo> True
[18:01:56] <Marzo> But I meant more their appearance in-game
[18:03:06] <wizardrydragon> TruWell, we're also changing spells in game. In either event, if you CAN preserve previous appearance, then do so, but don't move mountains to do so either :)
[18:03:18] <wizardrydragon> *True. Well,
[18:03:25] <Marzo> Another set of changes I which I am toying about: letting events (in a script function call) and global flags (both for getting and for setting) accept variables as input
[18:03:35] <Marzo> Agreed
[18:03:43] <wizardrydragon> brb
[18:03:46] <Marzo> k
[18:07:54] <wizardrydragon> back
[18:07:59] <Marzo> wb
[18:08:03] <wizardrydragon> lol
[18:08:40] <wizardrydragon> Anyways, one thing I've trying to implement is an concept of item ownership
[18:09:03] <Marzo> That will be though
[18:09:07] <Marzo> er tough
[18:09:18] <wizardrydragon> Hense, trying
[18:09:34] <Marzo> Urgh, the pain :-)
[18:10:21] <wizardrydragon> It needs done though
[18:10:39] <Marzo> (I was referring also to the 'hense')
[18:10:43] <wizardrydragon> Else you wont be able to move furniture in your own house that youve bought or rented with the Housing System
[18:11:15] <Marzo> That could be done by setting the OKAY_TO_TAKE flag on everything in the house
[18:11:30] <wizardrydragon> That raises additional problems though
[18:11:41] <Marzo> Like?
[18:12:04] <wizardrydragon> For one, it'd nerf NPC Theives which I plan on implementing somewhere down the road
[18:12:18] <Marzo> How so?
[18:12:27] <wizardrydragon> For two, it'd be hard to set everything OKAY_TO_TAKE in non-square houses
[18:12:31] <Marzo> I mean: how does it nerf them?
[18:13:12] <wizardrydragon> I thought it was obvious. Taking something not OKAY_TO_TAKE is theivery :)
[18:13:31] <Marzo> But NPCs aren't affected by it
[18:13:43] <Marzo> Only the avatar -- or better, the player -- is
[18:13:51] <wizardrydragon> But they would be if I implemented NPC thieves :)
[18:14:16] <wizardrydragon> Anyways, thats a ways down the road, I just don't want to shoot off both feet if I can help it ;)
[18:14:31] <Marzo> I am not sure I follow you
[18:14:56] <Marzo> In the avatar's house, objects are OKAY_TO_TAKE
[18:15:07] <Marzo> Non-party thieves stealing them would be in trouble
[18:15:30] <wizardrydragon> I don't think I follow that :P
[18:15:50] <Marzo> On other houses, all thieves (part or not) would be in trouble for stealing objects which are not OKAY_TO_TAKE
[18:16:14] <wizardrydragon> I suppose that could work but it's counter-intuitive.
[18:16:52] <Marzo> I assume that the OKAY_TO_TAKE flag means that the avatar is free to take them at will
[18:17:01] <Marzo> (which is how it works in Exult)
[18:17:28] <Marzo> NPCs would only check it in usecode
[18:17:34] <wizardrydragon> What I mean is, it would be counter-intuitive to have code penalizing NPCS for taking items that are OKAY_TO_TAKE
[18:17:39] <wizardrydragon> :)
[18:17:44] <Marzo> (Exult only checks the flag when the player takes the item)
[18:18:15] <Marzo> Like I said, I it would assume that the flag means 'belongs to avatar'
[18:18:29] <wizardrydragon> Indeed.
[18:18:30] <Marzo> (too many 'I's in that sentence)
[18:18:44] <Marzo> There is no problem with that
[18:18:51] <wizardrydragon> But what if an NPC "steals" it's own item? :P
[18:19:08] <Marzo> The item wouldn't be marked as OKAY_TO_TAKE
[18:19:14] <Marzo> But I see your point
[18:19:39] <Marzo> Likely, the 'thief' schedule would not be in effect in the thief's home, no?
[18:19:53] <wizardrydragon> It may be in the same area, however.
[18:20:12] <wizardrydragon> Since theif is more or less "Wander" plus some less than legal actions
[18:20:32] <Marzo> If he is at home, he shouldn't be stealing; if he is not, he should be penalized for stealing :-)
[18:20:50] <wizardrydragon> Another thing I have to work on when I do add it
[18:20:58] <Marzo> Wander keeps the character moving around a central spot
[18:21:06] <wizardrydragon> Is I dont want the guards to be 100% effective
[18:21:10] <wizardrydragon> With players OR npcs
[18:21:20] <Marzo> And they shouldn't, really
[18:21:24] <wizardrydragon> Indeed.
[18:21:31] <wizardrydragon> But they were more or less in U7
[18:21:34] <Marzo> For starters, if no one sees the thief, no guards should come
[18:21:48] <Marzo> (and they are even more in Exult :-p)
[18:22:14] <wizardrydragon> The speed changes makes it much harder to get away from multiple guards
[18:22:30] <Marzo> Try going into god mode and attack Batlin or LB and watch the piles and piles of corpses :-)
[18:22:54] <wizardrydragon> What we SHOULD do, is "call" existing guards to the location, not generate a new "guard"
[18:22:56] <Marzo> It makes it nigh impossible, actually
[18:23:11] <wizardrydragon> If theres no guards in range, then you're free :)
[18:23:21] <Marzo> The problem is that there are very few existing guards in the game itself
[18:23:32] <wizardrydragon> That can be easily remedied though.
[18:23:38] <Marzo> And many of them are generated by eggs qhen you get close enough
[18:24:07] <Marzo> Further, there are hard-coded calls to guards when you attack people
[18:24:22] <wizardrydragon> True, but just do a call - look for any monster_eggs that generate guards nearby, if one exists, then spawn a guard and draw them to the location
[18:24:43] <wizardrydragon> This gives you a "window of opprotunity" to get away before he arrives and busts you down :P
[18:25:09] <Marzo> Sadly, there are no ways in usecode to see if an egg generates a guard or a troll
[18:25:26] <wizardrydragon> Wouldnt the shape# be a property of an egg?
[18:25:32] <Marzo> But it is a good idea, though
[18:26:00] <Marzo> Yes, but there are no intrisics that allow you to get the shape or the created creature
[18:26:04] <wizardrydragon> At least in Pagan, theres a reason for the "hguard" to show up instantneously :)
[18:26:50] <Marzo> (before it is created, I mean)
[18:26:55] <wizardrydragon> Anyways, I'll be back later, I have to run some errands.
[18:27:00] <Marzo> I *could* add one, however...
[18:27:06] <Marzo> cya
[18:27:25] <wizardrydragon> If you could do so it'd aid a lot of the code I'm thinking of adding greatly.
[18:27:28] <wizardrydragon> BBL
[18:27:40] --- wizardrydragon is now known as wizardrydrgon_aw
[18:27:50] --- wizardrydrgon_aw is now known as wizardrydragon_a
[18:28:12] --- wizardrydragon_a is now known as wiz_away