From crossfire-devel at archives.real-time.com Fri Dec 3 19:14:38 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:57:17 2005 Subject: [CF-Devel] repelled spell paths, working too well? Message-ID: Has something changed so that repelled is now working like denied when it comes to spell paths? With some feedback from other players on crossfire.metalforge.net, it appears that repelled spell paths are working the same way as denied. I had the following: 396 spell points Power and Int of 30 Level 1 in summoning Repelled to summoning (confirmed with perceive self spell, character worshipped Mostrai) When I tried to cast summon lesser golem (lvl 1 spell) I would see this message: You lack enough skill to cast that spell. Checking with the cast command: summoning spells [lvl] [sp] summon lesser golem 1 3 I switched gods, and then was able to summon the golem without any problems. -- _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Sat Dec 4 11:54:33 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:57:17 2005 Subject: [CF-Devel] repelled spell paths, working too well? In-Reply-To: References: Message-ID: <200412041854.38779.tchize@myrealbox.com> Skipped content of type multipart/signed-------------- next part -------------- _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Sat Dec 4 12:20:50 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:57:17 2005 Subject: [CF-Devel] repelled spell paths, working too well? In-Reply-To: <200412041854.38779.tchize@myrealbox.com> References: <200412041854.38779.tchize@myrealbox.com> Message-ID: <398dd1ee041204102037f1972@mail.gmail.com> >From what I know about how crossfire works there are two functions that it uses to deal with attunements. Here are some comments from the code in server/spell_util.c , hope that will provide some insight. /* * This function takes a caster and spell and presents the * effective level the caster needs to be to cast the spell. * basically, it just adjusts the spell->level with attuned/repelled * spellpaths. Was called path_level_mod * * caster is person casting hte spell. * spell is the spell object. * Returns modified level. */ int min_casting_level(object *caster, object *spell) ... and /* This function returns the effective level the spell * is being cast at. * Note that I changed the repelled/attuned bonus to 2 from 5. * This is because the new code compares casting_level against * min_caster_level, so the difference is effectively 4 */ int caster_level(object *caster, object *spell) ... So based on this I think you need to be 4 levels higher if you are denied a spell path and once you are able to cast that spell it will be cast at a lower level. Intresting thing is whether or not one is able to cast spells earlier(at a lower level then usual) if they are attuned to a path. I have not actually done any testing on this. Salathar _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Sat Dec 4 16:32:20 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:57:18 2005 Subject: [CF-Devel] python plugin trigger bug? Message-ID: <1102199540.4795.5.camel@oberon.kameria> Hmmm, everytime I hook a pedestal to a python script with the trigger hook I get a segfault. The python script doesn't seem to matter - even if it does nothing it still segfaults - is there something in the trigger hook that is broken? Here is the GDB error I get. > 0x080a4da3 in update_button (op=0x8a52b48) at button.c:187 > 187 (!strcmp (tmp->slaying, "player") && _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Sat Dec 4 19:25:50 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:57:18 2005 Subject: [CF-Devel] python plugin trigger bug? In-Reply-To: <1102199540.4795.5.camel@oberon.kameria> References: <1102199540.4795.5.camel@oberon.kameria> Message-ID: <1102209950.4795.19.camel@oberon.kameria> Not to be rude, I'll reply to myself on this - when I switch the calling object from a pedestal to a button I get the following error: The unknown trigger type error maybe seems to indicate that the hook has tried to pass the player as the trigger object... PYTHON - HandleEvent:: got script file >/python/guilds/guild_pedestal.py< -1073745037 Unknown trigger type: Avion (1) PYTHON - HandleEvent:: script loaded (/python/guilds/guild_pedestal.py)! PYTHON - triggerEvent:: eventcode 10 PYTHON - HandleEvent:: got script file >/python/guilds/guild_pedestal.py< Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1024 (LWP 13108)] find_event (op=0x0, etype=10) at loader.l:1855 1855 for(found=op->events;found!=NULL;found=found->next) On Sat, 2004-12-04 at 17:32, Todd Mitchell wrote: > Hmmm, > > everytime I hook a pedestal to a python script with the trigger hook I > get a segfault. The python script doesn't seem to matter - even if it > does nothing it still segfaults - is there something in the trigger hook > that is broken? > > Here is the GDB error I get. > > > 0x080a4da3 in update_button (op=0x8a52b48) at button.c:187 > > 187 (!strcmp (tmp->slaying, "player") && > > > > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Tue Dec 7 01:34:51 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:57:18 2005 Subject: [CF-Devel] python plugin trigger bug? In-Reply-To: <1102209950.4795.19.camel@oberon.kameria> References: <1102199540.4795.5.camel@oberon.kameria> <1102209950.4795.19.camel@oberon.kameria> Message-ID: <20041207073450.GA10563@idefix2.dvlp.in-medias-res.com> Todd Mitchell wrote: > Not to be rude, I'll reply to myself on this - when I switch the > calling object from a pedestal to a button I get the following error: > The unknown trigger type error maybe seems to indicate that the hook > has tried to pass the player as the trigger object... Sorry, but I can't reproduce your problems here. I use the current cvs server. The objects (pedestal/button) in my map are: arch pedestal event_trigger_plugin Python event_trigger /pedestal.py x 2 y 6 end arch button_small event_trigger_plugin Python event_trigger /pedestal.py x 3 y 6 end The script (pedestal.py) I use is: import CFPython CFPython.Say(CFPython.WhoIsActivator(), "activator: script is running") Whenever I enter or leave the pedestal/button, I receive the messages pedestal says: activator: script is running or small button says: activator: script is running _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Tue Dec 7 21:34:33 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:57:18 2005 Subject: [CF-Devel] python plugin trigger bug? In-Reply-To: <20041207073450.GA10563@idefix2.dvlp.in-medias-res.com> References: <1102199540.4795.5.camel@oberon.kameria> <1102209950.4795.19.camel@oberon.kameria> <20041207073450.GA10563@idefix2.dvlp.in-medias-res.com> Message-ID: <1102476873.3490.5.camel@oberon.kameria> Ah, the activator is the switch in this case, I thought it should be referencing the player activating the trigger as it is in other events. Whoami is the object itself usually, no? My script had whoami to determine the object being activated - whoami is not valid causing a segfault... Try this for the script: import CFPython activator=CFPython.WhoIsActivator() activatorname=CFPython.GetName(activator) whoami=CFPython.WhoAmI() info = CFPython.GetEventOptions(whoami, 10) # 10 is trigger event CFPython.Say(activator, "activator: script is running") CFPython.Say(whoami, "object: script is running") > Sorry, but I can't reproduce your problems here. I use the current cvs > server. The objects (pedestal/button) in my map are: > > arch pedestal > event_trigger_plugin Python > event_trigger /pedestal.py > x 2 > y 6 > end > arch button_small > event_trigger_plugin Python > event_trigger /pedestal.py > x 3 > y 6 > end > > The script (pedestal.py) I use is: > > import CFPython > CFPython.Say(CFPython.WhoIsActivator(), "activator: script is running") > > Whenever I enter or leave the pedestal/button, I receive the messages > > pedestal says: activator: script is running > > or > > small button says: activator: script is running > > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Thu Dec 9 04:07:24 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:57:18 2005 Subject: [CF-Devel] python plugin trigger bug? In-Reply-To: <1102476873.3490.5.camel@oberon.kameria> References: <1102199540.4795.5.camel@oberon.kameria> <1102209950.4795.19.camel@oberon.kameria> <20041207073450.GA10563@idefix2.dvlp.in-medias-res.com> <1102476873.3490.5.camel@oberon.kameria> Message-ID: <20041209100723.GA20343@idefix2.dvlp.in-medias-res.com> Todd Mitchell wrote: > Ah, the activator is the switch in this case, I thought it should be > referencing the player activating the trigger as it is in other > events. Whoami is the object itself usually, no? The comment in the source (located somewhere in the server code, just before the plugin code is called) says: originator (WhoAmI) is the object that caused victim (Other) to move onto trap (Activator). Therefore I'd say Other is the object on the trigger. I did a quick survey for the events used in the server code (see the attachment). I'll add this information to doc/Developers/python. > My script had whoami to determine the object being activated - whoami > is not valid causing a segfault... I'm currently fixing the plugin code to prevent (or at least reduce) such crashes. The current plugin code has at least the following problems: - It does not always check if a valid object is present and therefore passes NULL objects to the plugin code. On the other hand, it does not check objects passed in from the plugin code, using these NULL objects. The solution I implemented is: pass the Python-value "None" for NULL-objects. But your script revealed a problem: I get the (misleading) error message "TypeError: an integer is required". (But the server does not crash.) Is this behavior acceptable or should I pass the integer 0 to the script for NULL objects and raise a Python exception if such a value is used by the script? - The internal stack for WhoAmI (and other values) is not always completely cleared. Therefore you may get invalid (read "left over") values if you call (for example) WhoAmI from an event script that does not set this value. > Try this for the script: [...] Did that: I got a server crash, too. -------------- next part -------------- events generated for objects ============================ event activator who other msg result value comment ------- ------ --------- ----- --- -------------------------- ----------------- APPLY op book -- -- -- op reads book APPLY pl_ob altar -- -- !=0:do not pray at altar APPLY pl_ob op -- -- !=0:do not apply object aflag=always apply flag ATTACK hitter hitter op -- -- ATTACK hitter op victim -- (value read but ignored) ATTACK hitter weapon op -- -- CLOSE pl_ob container -- -- !=0:do not close container DEATH -- pl_ob -- -- !=0:pl_ob should not die DEATH hitter op -- -- !=0:do not kill object atype=attacktype DROP who op -- -- !=0:do not drop object op is already removed PICKUP never generated SAY op inv-obj npc txt !=0:do not say inv-obj is an object in npc's inventory SAY op npc -- txt !=0:do not say STOP -- op -- -- -- thrown object op is stopped TELL never generated THROW op throw_ob -- -- -- TIME -- op -- -- -- TIMER never generated TIMER op -- -- -- -- TRIGGER pl_ob item -- msg -- pl_ob writes msg into item TRIGGER teleporter op -- -- !=0:do not move object teleporter/player changer moves op TRIGGER trap originator victim -- !=0:do not activate trap originator is the object that caused victim to move onto trap; originator (who) seems not to be set when leaving the trigger object global events ============== event activator who other msg result value comment -------- --------- ---- ----- -------- ------------ --------------------------- BORN pl_ob -- -- -- -- CLOCK -- -- -- -- -- GDEATH never generated GKILL never generated KICK pl_ob -- -- param -- LOGIN pl_ob pl_ob -- hostname -- activator=who LOGOUT pl_ob pl_ob -- hostname -- activator=who MAPENTER pl_ob -- -- -- -- MAPLEAVE pl_ob -- -- -- -- MAPRESET -- -- map-path -- MUZZLE pl_ob -- -- param -- param is the (possibly partial) player name REMOVE pl_ob -- -- -- -- pl_ob quits the game SHOUT pl_ob -- -- message -- Notes: - pl_ob=player object - the value "--" means that the value is not set in the current code. - the TRIGGER event for writing messages always skips the "normal" writing code if a script is present -------------- next part -------------- _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Thu Dec 9 16:18:33 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:57:18 2005 Subject: [CF-Devel] python plugin trigger bug? In-Reply-To: <20041209100723.GA20343@idefix2.dvlp.in-medias-res.com> References: <1102199540.4795.5.camel@oberon.kameria> <1102209950.4795.19.camel@oberon.kameria> <20041207073450.GA10563@idefix2.dvlp.in-medias-res.com> <1102476873.3490.5.camel@oberon.kameria> <20041209100723.GA20343@idefix2.dvlp.in-medias-res.com> Message-ID: <41B8CF39.7000400@sympatico.ca> Andreas Kirschbaum wrote: >The comment in the source (located somewhere in the server code, just >before the plugin code is called) says: originator (WhoAmI) is the >object that caused victim (Other) to move onto trap (Activator). > >Therefore I'd say Other is the object on the trigger. > >I did a quick survey for the events used in the server code (see the >attachment). I'll add this information to doc/Developers/python. > > > Thanks for the table. It will be very helpful. I did look at the trigger event hooks for that case you mention and actually thought that it was wrong. I would rather see whoami return the object that contains the trigger script and the activator return the object that caused it to fire. I actually switched victim and trap around in the code there to see If I could change it that easily but there was somehting else wrong since I didn't change the plugin code and I hadn't tried to figure out other changes needed due to the trap code as it applies to buttons and levers and such so it isn't that simple... I really really think that most of the time (85%?) the trigger event code will be used to find out when a player pulls a lever or steps on a button and so would like to see activator as the object that 'activates' the trigger object and whoami as the trigger object itself. This would bring it in line with other common events. I don't know how possible it is but it should be doable since it passes the info to the plugin so all adjustments would be in the plugin, no? I can try to help if it is hard to do but I feel pretty strongly that it should work consistantly if possible. >>My script had whoami to determine the object being activated - whoami >>is not valid causing a segfault... >> >> > >I'm currently fixing the plugin code to prevent (or at least reduce) >such crashes. The current plugin code has at least the following >problems: > I'll have to look more and I am certainly not an expert in these matters. I think that Python did not always have a 'NULL' and I usually work with a 0 rather than a 'NULL' myself. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Sat Dec 11 02:17:02 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:57:18 2005 Subject: [CF-Devel] python plugin trigger bug? In-Reply-To: <41B8CF39.7000400@sympatico.ca> References: <1102199540.4795.5.camel@oberon.kameria> <1102209950.4795.19.camel@oberon.kameria> <20041207073450.GA10563@idefix2.dvlp.in-medias-res.com> <1102476873.3490.5.camel@oberon.kameria> <20041209100723.GA20343@idefix2.dvlp.in-medias-res.com> <41B8CF39.7000400@sympatico.ca> Message-ID: <20041211081702.GA23951@idefix2.dvlp.in-medias-res.com> Todd Mitchell wrote: > I did look at the trigger event hooks for that case you mention and > actually thought that it was wrong. I would rather see whoami return > the object that contains the trigger script and the activator return > the object that caused it to fire. I would like it that way, too. But there are some more events for that WhoAmI() does not return the object that contains the script. I attached an updated version of the event table: now the objects that contain the script are written in capitals. To make WhoAmI/Activator return the "right" object, I'd suggest the following changes: - event attack, line "'hitter' hits 'op'": set WhoAmI=OP. This would give: - WhoAmI=object that contains the script - Activator=hitter - Other=object being hit - event timer: set Activator=none, WhoAmI=OP - event trigger: - line "'op' writes 'msg' into 'item'": set Activator=op, WhoAmI=OP, Other=item - line "'teleporter' moves 'op'": set Activator=none, WhoAmI=TELEPORTER, Other=op - line "'originator' causes 'victim' to trigger 'trap'": Activator=victim, WhoAmI=TRAP, Other=originator This would give: - WhoAmI=object that contains the script - Activator=object that writes the book/causes the "trap" to trigger - Other=auxiliary object (book written into/object being teleported/originator pushing victim into trap) > I don't know how possible it is but it should be doable since it > passes the info to the plugin so all adjustments would be in the > plugin, no? I don't think that it would be very hard to change the code: the events in different lines in the event table are generated in different places in the code. Therefore we can adjust them independently. Note that I think we should change the server code, not the plugin code: the server code fills a CFParm structure and passes it to the plugin code. This structure basically says which objects should be Activator/WhoAmI/Other. Therefore it would be easy to adjust it in the server code but (very) hard to do it in the plugin code because the plugin code can't distinguish between (for example) the there different kinds of trigger events. -------------- next part -------------- What parameters are available to a script? ------------------------------------------ The object that contains the event script in written in capitals. event Activator WhoAmI Other Message parm1 parm2 parm3 result comment ----- --------- ------ ----- ------- ----- ----- ----- ------ -------------- apply op ALTAR - - 0 0 0 yes 'op' prays at 'altar' apply op BOOK - - 0 0 0 no 'op' reads 'book' apply op ITEM - - aflag 0 0 yes 'op' applies 'item' attack hitter hitter OP - 0 dam wc no 'hitter' hits 'op' attack hitter ITEM op - 0 dam wc no 'hitter' hits 'op' with 'item' close op CONTAINER - - 0 0 0 yes 'op' closes 'container' death - PLAYER - - 0 0 0 yes 'player' dies death hitter OP - - atype 0 0 yes 'hitter' kills 'op' drop op ITEM - - nrof 0 0 yes 'op' drops 'item' pickup (not yet implemented) say op ITEM npc msg 0 0 0 always 'op' tells 'msg' to 'item' in 'npc''s inventory say op NPC - msg 0 0 0 always 'op' tells 'msg' to 'npc' stop - OP - - 0 0 0 no thrown object 'op' is stopped throw op ITEM - - 0 0 0 no 'op' throws 'item' time - OP - - 0 0 0 no 'op' takes a turn timer OP - - - 0 0 0 no timer of 'op' has expired trigger OP item - msg 0 0 0 always 'op' writes 'msg' into 'item' trigger TELEPORTER op - - 0 0 0 yes 'teleporter' moves 'op' trigger TRAP originator victim - 0 0 0 yes 'originator' causes 'victim' to trigger 'trap' Notes: - result column: no=result value is unused; prevent=non-zero result value prevents the action; always=prevents the action regardless of result value - apply event: aflag=always apply flag - death event: atype=attacktype - trigger event: originator is unset if the trap (pedestal/button) is left - parm1..3 are not currently available to the script - attack event: 'item' can be a weapon or a missile -------------- next part -------------- _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Sat Dec 11 23:53:47 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:57:18 2005 Subject: [CF-Devel] python plugin trigger bug? In-Reply-To: <20041211081702.GA23951@idefix2.dvlp.in-medias-res.com> References: <1102199540.4795.5.camel@oberon.kameria> <1102209950.4795.19.camel@oberon.kameria> <20041207073450.GA10563@idefix2.dvlp.in-medias-res.com> <1102476873.3490.5.camel@oberon.kameria> <20041209100723.GA20343@idefix2.dvlp.in-medias-res.com> <41B8CF39.7000400@sympatico.ca> <20041211081702.GA23951@idefix2.dvlp.in-medias-res.com> Message-ID: <1102830827.5878.31.camel@oberon.kameria> for starters I'm going to try changing the event trigger in the move_apply function, just by changing the params to: CFP.Value[1] = victim; CFP.Value[2] = trap; CFP.Value[3] = originator; The script I put up before seems to be working now. Your table helps a lot too and I think it should go into the python plugin docs. > I don't think that it would be very hard to change the code: the events > in different lines in the event table are generated in different places > in the code. Therefore we can adjust them independently. > > Note that I think we should change the server code, not the plugin code: > the server code fills a CFParm structure and passes it to the plugin > code. This structure basically says which objects should be > Activator/WhoAmI/Other. Therefore it would be easy to adjust it in the > server code but (very) hard to do it in the plugin code because the > plugin code can't distinguish between (for example) the there different > kinds of trigger events. > > ______________________________________________________________________ Yes, I did mean changing the event code which passes the params to the plugin, but what I meant by changing the plugin code was that the plugin may have to change in places to compensate for these changes... _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Mon Dec 13 18:03:51 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:57:18 2005 Subject: [CF-Devel] Rolling stats is not fair Message-ID: <41BE2DE7.9040609@aladin.ro> I don't think rolling stats is fair. The maximum average is 15, so that doesn't guarantee equally powered characters. We should always let the average be 15, so that the less patient players, that won't spend want to spend a lot of time rolling stats, get good stats too. Server admins should be able to activate this feature (I mean this constant average) through a configuration option rather than rebuilding the server. They should also be able to let players create their character manually, without rolling stats (again, through a configuration option, without having to rebuild from source). Regards, Eduard Gabriel Munteanu _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Mon Dec 13 18:16:20 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:57:18 2005 Subject: [CF-Devel] Rolling stats is not fair In-Reply-To: <41BE2DE7.9040609@aladin.ro> Message-ID: <20041214001620.89342.qmail@web61004.mail.yahoo.com> BS Rolling stats is fair. Too freaking bad for non-patient players. That's what they get for not developing that virtue. --- Munteanu Eduard Gabriel wrote: > I don't think rolling stats is fair. The maximum > average is 15, so that > doesn't guarantee equally powered characters. We > should always let the > average be 15, so that the less patient players, > that won't spend want > to spend a lot of time rolling stats, get good stats > too. > Server admins should be able to activate this > feature (I mean this > constant average) through a configuration option > rather than rebuilding > the server. They should also be able to let players > create their > character manually, without rolling stats (again, > through a > configuration option, without having to rebuild from > source). > > Regards, > Eduard Gabriel Munteanu > > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel > __________________________________ Do you Yahoo!? Send holiday email and support a worthy cause. Do good. http://celebrity.mail.yahoo.com _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Mon Dec 13 20:12:46 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:57:18 2005 Subject: [CF-Devel] Rolling stats is not fair In-Reply-To: <41BE2DE7.9040609@aladin.ro> References: <41BE2DE7.9040609@aladin.ro> Message-ID: This is currently in the TODO list. http://cvs.sourceforge.net/viewcvs.py/crossfire/crossfire/TODO?view=markup - Changing the stat generation system - instead of roll based, give some number of points. This makes it easier for players to choose what they want to play - otherwise, I think some clients will be written that will do this for the players in any case. Such a change would require server side coding updates, but also client updates/changes and HOWTO or help documentation (IMO) for the new interface. It's a little more involved and intricate then it first appears or sounds. FWIW, this has been the topic of discussion in the past.. http://archives.real-time.com/pipermail/crossfire-devel/2001-February/001151.html http://archives.real-time.com/pipermail/crossfire-devel/2003-July/004836.html http://archives.real-time.com/pipermail/crossfire-devel/2001-December/002871.html _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Tue Dec 14 05:46:21 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:57:18 2005 Subject: [CF-Devel] Rolling stats is not fair In-Reply-To: <20041214001620.89342.qmail@web61004.mail.yahoo.com> References: <20041214001620.89342.qmail@web61004.mail.yahoo.com> Message-ID: Yeah, well, I _too_ think, that players who spend most of their lifetime playing should get some benefits after all, and peepo who have family, work and other stupid things to attend to just suck and should quit playing anyway, and if NOT, well, they should simply bear the consequences. On a non-free mud I'd understand that. After all, paying muds need the money, and the more time you have to spend doing annoying, useless things which won't give you any excitement, the more time you will spend overall - and the more you will PAY for it. Result: Mud full of stupid hardcore players spending most of their time tapping 2 or 3 buttons/min. on the average. An honorable goal, indeed! Sounds like a man speaking of wisdom! Freaking non-patient players. :-/ It's not about patience! It's about time. I believe that one should pay the price for anything he gets, and time is one of the most precious currency. We should sacrifice some of it, if something was that important to us. BUT, on the other hand, we shouldn't ask for it without a considerable reason! What's the reason here? Teaching players patience? Give me a break! Rolling stats is a stupid thing anyway. (Here at least you can do it over and over.) It's just a remainder of an old tradition. Hardcore "wiseguy" gamers tend to like it. Tho, they are never able to explain why. (Well, no better argument, than "My grandfather did this way, sure it must be the one and only!") > BS > > Rolling stats is fair. > Too freaking bad for non-patient players. > That's what they get for not developing that virtue. > > --- Munteanu Eduard Gabriel > wrote: > >> I don't think rolling stats is fair. The maximum >> average is 15, so that >> doesn't guarantee equally powered characters. We >> should always let the >> average be 15, so that the less patient players, >> that won't spend want >> to spend a lot of time rolling stats, get good stats >> too. >> Server admins should be able to activate this >> feature (I mean this >> constant average) through a configuration option >> rather than rebuilding >> the server. They should also be able to let players >> create their >> character manually, without rolling stats (again, >> through a >> configuration option, without having to rebuild from >> source). >> >> Regards, >> Eduard Gabriel Munteanu >> >> _______________________________________________ >> crossfire-devel mailing list >> crossfire-devel@lists.real-time.com >> > https://mailman.real-time.com/mailman/listinfo/crossfire-devel >> > > > > > __________________________________ > Do you Yahoo!? > Send holiday email and support a worthy cause. Do good. > http://celebrity.mail.yahoo.com > > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel > _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Mon Dec 20 14:53:32 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:57:18 2005 Subject: [CF-Devel] Missing archetypes used by python plugin In-Reply-To: <20041018180424.GB25816@laranja.org> References: <20041018175104.GA30872@idefix2.dvlp.in-medias-res.com> <20041018180424.GB25816@laranja.org> Message-ID: <20041220205332.GA18213@idefix2.dvlp.in-medias-res.com> Lalo Martins wrote: > > The python plugin code uses the non-existent archetypes > > "player_info" and "player_force". Can someone add them (or give me a > > hint how to define them)? > > You don want to create those; you want to fix the plugin. They are > legacy code. OK. According to the cvs logs these archetypes were removed about two years ago. But the log message did not reveal why they have been removed. After examining the code, my impression is that most invisible objects are created from the "force" archetype and possibly changing some attributes (such as expiry timeout/slaying/name). The Python plugin currently implements the following functions that access invisible objects: - CheckInvisibleObjectInside(who, str): Returns the first object obj in who's inventory with obj->type=FORCE and obj->slaying=str. - CreateInvisibleObjectInside(who, str): Inserts a new object obj (archetype "force") into who's inventory. Sets obj->speed=0 and obj->slaying=str. - CreatePlayerForce(who, str): Inserts a new object obj (archetype "player_force") into who's inventory. Sets obj->name=str. - CreatePlayerInfo(who, str): Inserts a new object obj (archetype "player_info") into who's inventory. Sets obj->name=str. - GetPlayerInfo(who, str), GetNextPlayerInfo(who, prev_obj): Returns the first/next object obj from who's inventory that has obj->arch->name="player_info" and obj->name=str. - SetAlignment(who, str), SetGender(who, str), SetGuildForce(who, str), SetRank(who, str): Modifies the first object obj in who's inventory that has obj->name="ALIGNMENT_FORCE/GENDER_FORCE/GUILD_FORCE/RANK_FORCE" or obj->arch->name="alignment_force/gender_force/guild_force/rank_force". Sets obj->title to a new value depending on str. - GetGuildForce(who): Returns the first object obj from who's inventory that has obj->name="GUILD_FORCE" or obj->arc->name="guild_force". >From my point of view only the functions CheckInvisibleObject() and CreateInvisibleObject() are useful (and currently working). The remaining functions should be removed. Is this "fix" of the plugin code acceptable? _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Mon Dec 20 16:38:12 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:57:19 2005 Subject: [CF-Devel] Missing archetypes used by python plugin In-Reply-To: <20041220205332.GA18213@idefix2.dvlp.in-medias-res.com> References: <20041018175104.GA30872@idefix2.dvlp.in-medias-res.com> <20041018180424.GB25816@laranja.org> <20041220205332.GA18213@idefix2.dvlp.in-medias-res.com> Message-ID: <41C75454.2000205@sympatico.ca> Andreas Kirschbaum wrote: >>From my point of view only the functions CheckInvisibleObject() and >CreateInvisibleObject() are useful (and currently working). The >remaining functions should be removed. Is this "fix" of the plugin code >acceptable? > >_______________________________________________ > > I believe so. I have only ever used the invisible object function and the others I have not as I assumed they were legacy code. I don't know if there is an issue where it is different with inserting these invisible inventory objects as opposed to visible inventory objects. Really you should just create the arch by name and it will have visibility as a property or not - there should be no diffrnece in creating a marker or spell object from creating a shield or glove object. However, I haven't tried this and if there is a difference then the way this should work is to be able to insert these types of archetypes by passing their name from a single function instead of having a function for each type. Perhaps adding an optional archetype name field which defaults to 'force' to the InvisibleObject() functions. Another big thing along the same lines would be to clean up the spell and skill stuff... I don't know how the spell and skill wrappers can be loaded into the plugin any longer now that they are dynamically loaded from the arches, but this is a lot of legacy code in the plugin. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Tue Dec 21 16:21:36 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:57:19 2005 Subject: [CF-Devel] Monks wearing weapons Message-ID: <41C8A1F0.2080800@laposte.net> 'lo everyone. I checked code related to bug #1082534 ( https://sourceforge.net/tracker/index.php?func=detail&aid=1082534&group_id=13833&atid=113833 ), about monks able to wear weapons. The issue is pretty simple: when becoming monk, code sees the classname is 'monk' and clears the 'use_weapons' flag. Then, when praying over an altar, the code updates that flag with the god's one - thus setting it (not Gaea's case !). For dragons, isn't an issue as they don't have arms in the first place and thus can't wear weapons. But other players can use weapons again. I see 2 ways to fix that: * use the 'body' [precisely arm counts] fields for the player to remove weapon use - ie change the player's body according to class, setting arms to 0 for monks. * inserting a force in player's inventory to keep track of that fact, or the class. Both hae drawbacks - 1st may be weird, and cause issues if we ever decide to let players change class. 2nd may be expanded to something else (rings, girdles, ...) but requires a few more checks. Note that you can't simply tweak the god change code, as when switching from Gaea to another god you wouldn't know whether the 'no weapon use' comes from the god or the class. Ideas? Ryo _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Tue Dec 21 17:22:16 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:57:19 2005 Subject: [CF-Devel] GTK client crash (under Windows, at least) Message-ID: <41C8B028.6060102@laposte.net> Hello. Checked bug #1006968 ( https://sourceforge.net/tracker/index.php?func=detail&aid=1006968&group_id=13833&atid=113833 ) about GTK client (under Windows) crashing. The map itself is ok, server doesn't mind anything, image is correct (trap is a regular trap => red square). But what happens is that, when stepping on the rune, client gets a face '0' sent. But the 'pixmaps' structure is not initialized (it's apparently NULL for all items), so client'll crash on gx11.c:989 (pixmaps[0] == NULL). Checking code, it seems 'pixmaps' is used with 'CONFIG_CACHE', which is the 'cache images' option in configuration. It's unchecked on my client, and the 'init_cache_date' function (responsible for loading the pixmaps) does not get called, thus 'pixmaps[0]' is NULL. Tried checking 'cache image', client crash lol. So wondering: client crashes because image 0 (question mark) is not properly handled. Should client check that special case? Should pixmaps[0] get the question mark anyway? Wondering, as i'm not all that familiar with this part of the client. Nicolas _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Wed Dec 22 02:27:54 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:57:19 2005 Subject: [CF-Devel] GTK client crash (under Windows, at least) In-Reply-To: <41C8B028.6060102@laposte.net> References: <41C8B028.6060102@laposte.net> Message-ID: <41C9300A.3010807@sonic.net> Nicolas Weeger wrote: > Hello. > > Checked bug #1006968 ( > https://sourceforge.net/tracker/index.php?func=detail&aid=1006968&group_id=13833&atid=113833 > ) about GTK client (under Windows) crashing. > > The map itself is ok, server doesn't mind anything, image is correct > (trap is a regular trap => red square). > > But what happens is that, when stepping on the rune, client gets a face > '0' sent. But the 'pixmaps' structure is not initialized (it's > apparently NULL for all items), so client'll crash on gx11.c:989 > (pixmaps[0] == NULL). note that face 0 is never a valid face to display. If memory serves, face 0 is used to denote that there is nothing to display on tha layer anymore. If you look at the images, face 0 is actually a little bug symbol, or at least used to be. > > Checking code, it seems 'pixmaps' is used with 'CONFIG_CACHE', which is > the 'cache images' option in configuration. It's unchecked on my client, > and the 'init_cache_date' function (responsible for loading the pixmaps) > does not get called, thus 'pixmaps[0]' is NULL. > > Tried checking 'cache image', client crash lol. > > So wondering: client crashes because image 0 (question mark) is not > properly handled. Should client check that special case? Should > pixmaps[0] get the question mark anyway? > > Wondering, as i'm not all that familiar with this part of the client. I haven't looked closely at the bug. The real question is then why face is being sent or trying to be displayed. It's unclear to me why the client would be trying to display that different on cached vs non cached image mode. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Wed Dec 22 02:53:03 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:57:19 2005 Subject: [CF-Devel] Monks wearing weapons In-Reply-To: <41C8A1F0.2080800@laposte.net> References: <41C8A1F0.2080800@laposte.net> Message-ID: <41C935EF.5040705@sonic.net> Nicolas Weeger wrote: > 'lo everyone. > > I checked code related to bug #1082534 ( > https://sourceforge.net/tracker/index.php?func=detail&aid=1082534&group_id=13833&atid=113833 > ), about monks able to wear weapons. > > The issue is pretty simple: when becoming monk, code sees the classname > is 'monk' and clears the 'use_weapons' flag. > Then, when praying over an altar, the code updates that flag with the > god's one - thus setting it (not Gaea's case !). > > For dragons, isn't an issue as they don't have arms in the first place > and thus can't wear weapons. But other players can use weapons again. > > I see 2 ways to fix that: > * use the 'body' [precisely arm counts] fields for the player to remove > weapon use - ie change the player's body according to class, setting > arms to 0 for monks. > * inserting a force in player's inventory to keep track of that fact, or > the class. I'd be most inclined to do something like #2 - insert a copy of the appropriate class force object into the player, so we can know what attributes come from class vs other attributes. Because that is the real cause of the problem now - the can_use_weapons is a simple flag, so when you change from a god that doesn't allow weapons to one that does, there is no way for the source to really know if you should be allowed to use weapons (was the prohibition god, or god + class/something else). > > Both hae drawbacks - 1st may be weird, and cause issues if we ever > decide to let players change class. > 2nd may be expanded to something else (rings, girdles, ...) but requires > a few more checks. I can't see any real problems with it. Note that the can_use_weapons is 'special' in the sense you can't use weapons, but can use other equipment that requires ones arms (eg, shields, possible other things). _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Wed Dec 22 07:07:49 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:57:19 2005 Subject: [CF-Devel] GTK client crash (under Windows, at least) In-Reply-To: <41C9300A.3010807@sonic.net> References: <41C8B028.6060102@laposte.net> <41C9300A.3010807@sonic.net> Message-ID: <41C971A5.2080709@laposte.net> > note that face 0 is never a valid face to display. Actually, in the gtk code, if CONFIG_CACHE is set (and i think it's the 'cache images' configuration option), pixmaps[ 0 ] does get a valid image to display. But otherwise, it's apparently NULL. So code doesn't seem to check that. > I haven't looked closely at the bug. The real question is then why > face is being sent or trying to be displayed. The face obviously appears when you step on that specific trap, i guess. Now maybe because that trap is weird - but at least server doesn't log anything... Trap's archetype is just 'trap', but it may be missing fields, i'd have to check. Ryo _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Wed Dec 22 07:59:40 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:57:19 2005 Subject: [CF-Devel] Monks wearing weapons References: <41C8A1F0.2080800@laposte.net> Message-ID: <001001c4e82e$7e4cf990$8024a2cd@YUANC8000> How about when someone chooses to become a monk ( and has arms ), a "cursed" weapon is automatically equipped that cannot be "un-cursed" while the character is a monk? ie... "monk fists". ----- Original Message ----- From: "Nicolas Weeger" To: Sent: Tuesday, December 21, 2004 4:21 PM Subject: [CF-Devel] Monks wearing weapons > 'lo everyone. > > I checked code related to bug #1082534 ( > https://sourceforge.net/tracker/index.php?func=detail&aid=1082534&group_id=13833&atid=113833 ) > , about monks able to wear weapons. > > The issue is pretty simple: when becoming monk, code sees the classname is > 'monk' and clears the 'use_weapons' flag. > Then, when praying over an altar, the code updates that flag with the > god's one - thus setting it (not Gaea's case !). > > For dragons, isn't an issue as they don't have arms in the first place and > thus can't wear weapons. But other players can use weapons again. > > I see 2 ways to fix that: > * use the 'body' [precisely arm counts] fields for the player to remove > weapon use - ie change the player's body according to class, setting arms > to 0 for monks. > * inserting a force in player's inventory to keep track of that fact, or > the class. > > Both hae drawbacks - 1st may be weird, and cause issues if we ever decide > to let players change class. > 2nd may be expanded to something else (rings, girdles, ...) but requires a > few more checks. > > Note that you can't simply tweak the god change code, as when switching > from Gaea to another god you wouldn't know whether the 'no weapon use' > comes from the god or the class. > > Ideas? > > Ryo > > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel > _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Wed Dec 22 12:45:49 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:57:19 2005 Subject: [CF-Devel] I have a few patches for you Message-ID: <41C9C0DD.4060604@aladin.ro> This is a patchset for the Crossfire Server; diff was ran on the last week's CVS. I hope you like it and include it in the following release (I'll leave the Changlog changes to you). Don't worry about that fuzz in the patchset (I had to edit smth in the patch by hand). Descriptions of the patches: 1) logger.diff - added llevFatal to LogLevel enumeration - when LOG(llevFatal, ..., ...) is called, the server dies (not before trying an emergency save, if enabled) - if DIE_ON_MAX_ERRORS is defined, the server dies when MAX_ERRORS is reached (again, not before trying an emergency save, if enabled) 2) settings.diff - now we can modify the behavior of stats rolling, by changing the minimum and maximum sum of stats that can be rolled during character creation, which can be achieved by editing the settings file (min_initial_stats_sum, max_initial_stats_sum). - when the server starts and loads settings, if the settings file is misconfigured, the default behavior is to die by calling LOG(logLevel, ..., ...), where logLevel is llevFatal by default (but can be changed by modifying INIT_LOAD_SETTINGS_LOGLEVEL). - janitorial work 3) sighup_reload_settings.diff - this is highly experimental: the server now behaves differently when it recieves a SIGHUP signal, by reloading the settings file (if there are errors in the settings file, the server does _not_ die; here, logLevel is llevError) I hope my future patches will include both client and server side changes that will allow, if the server administrator permits it, the clients to manually setup their character's stats. Please tell me if you liked this patch. Cheers, Eduard Gabriel Munteanu -------------- next part -------------- A non-text attachment was scrubbed... Name: patches.tar.gz Type: application/gzip Size: 4617 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20041222/6935bd7e/patches.tar.bin -------------- next part -------------- _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Sat Dec 25 12:17:58 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:57:19 2005 Subject: [CF-Devel] I have a few patches for you In-Reply-To: <41C9C0DD.4060604@aladin.ro> References: <41C9C0DD.4060604@aladin.ro> Message-ID: <41CDAED6.90902@laposte.net> Hello ! Thanks for your patches :) Haven't tested'em or committed yet, but read diff, here are a few comments: > 1) logger.diff Seems ok, just not sure that new level is necessary or not :) > 2) settings.diff The only thing which bothers me is the stat rolling method. If you set min & max stat sum too close, you may need many rolls to get correct values - but well, not that an issue maybe. > 3) sighup_reload_settings.diff Seems ok. > Please tell me if you liked this patch. So far so good :) Thanks! > Cheers, > Eduard Gabriel Munteanu Ryo _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Sat Dec 25 12:34:41 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:57:19 2005 Subject: [CF-Devel] GTK client crash (under Windows, at least) In-Reply-To: <41C8B028.6060102@laposte.net> References: <41C8B028.6060102@laposte.net> Message-ID: <41CDB2C1.9000407@laposte.net> Checked some more the code. What happens is that the trap doesn't have any animation linked. So the 'show_trap' code simply inserts a blank (0) face, and client crashes on that. The trap on the spot is 'trap' archetype. So wondering whether to fix code to check that situation and not display animation, or fix the trap itself :) Nicolas _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Sat Dec 25 18:19:15 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:57:19 2005 Subject: [CF-Devel] I have a few patches for you In-Reply-To: <41CDAED6.90902@laposte.net> References: <41C9C0DD.4060604@aladin.ro> <41CDAED6.90902@laposte.net> Message-ID: <41CE0383.2080406@aladin.ro> Nicolas Weeger wrote: >> 2) settings.diff > > > The only thing which bothers me is the stat rolling method. If you set > min & max stat sum too close, you may need many rolls to get correct > values - but well, not that an issue maybe. Yes, the rolling code should do better than to crunch numbers until he gets good values. I'll have a look at this matter. Thanks for feedback. Eduard Gabriel Munteanu _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Sat Dec 25 22:27:47 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:57:19 2005 Subject: [CF-Devel] GTK client crash (under Windows, at least) In-Reply-To: <41CDB2C1.9000407@laposte.net> References: <41C8B028.6060102@laposte.net> <41CDB2C1.9000407@laposte.net> Message-ID: <1104035267.8676.3.camel@oberon.kameria> Well it will take little effort to add an animation to the trap arch so I'll do that and you can then decide if you still want to fix the code or not. Thanks for figuring this out it was hanging on my concience for a while now but I had no clue how what the problem could be. On Sat, 2004-25-12 at 19:34 +0100, Nicolas Weeger wrote: > Checked some more the code. > > What happens is that the trap doesn't have any animation linked. > So the 'show_trap' code simply inserts a blank (0) face, and client > crashes on that. > > The trap on the spot is 'trap' archetype. > > So wondering whether to fix code to check that situation and not > display animation, or fix the trap itself :) > > Nicolas > > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel -- Todd Mitchell _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Mon Dec 27 15:29:33 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:57:19 2005 Subject: [CF-Devel] Re: [Crossfire-cvs] CVS commit: crossfire Message-ID: <41D07EBD.1050401@sonic.net> crossfire-cvs-admin@lists.sourceforge.net wrote: > Module Name: crossfire > Committed By: ryo_saeba > Date: Sat Dec 25 18:09:29 UTC 2004 > > Modified Files: > crossfire: ChangeLog > crossfire/common: map.c > crossfire/server: c_chat.c c_party.c c_wiz.c main.c > > Log Message: > Patches #1086095 and 1088385, party password length tweak A few minor issues on this patch: > Index: crossfire/common/map.c > diff -c crossfire/common/map.c:1.68 crossfire/common/map.c:1.69 > *** crossfire/common/map.c:1.68 Sun Oct 17 23:54:35 2004 > --- crossfire/common/map.c Sat Dec 25 10:09:29 2004 > *************** > *** 317,323 **** > } > } /* if check_inv */ > else if (QUERY_FLAG(tmp,FLAG_NO_PASS) || (QUERY_FLAG(tmp,FLAG_ALIVE) && > ! tmp->head != ob && tmp != ob && tmp->type != DOOR)) > return 1; > } > --- 317,324 ---- > } > } /* if check_inv */ > else if (QUERY_FLAG(tmp,FLAG_NO_PASS) || (QUERY_FLAG(tmp,FLAG_ALIVE) && > ! tmp->head != ob && tmp != ob && tmp->type != DOOR) && > ! !(QUERY_FLAG(tmp,FLAG_WIZ) && tmp->contr->hidden)) > > return 1; > } I'd like to see some more parens in that if statement there. It may in fact be a reasonable idea to split that if into a few if statements to make it clearer. Stylisticly, I don't like ! complex expressions, eg, the !(a && b) - OTOH, I guess the one thing by doing that is it is known the tmp->contr is a valid structure. But still, trying to read such statements and figure out what they are doing starts to get pretty complicated at some point. the forbid_play() function in main.c is similarly changed to have such a construct, but isn't as bad as it is the only thing in the if statement, so is easier to follow the logic in that one. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Mon Dec 27 15:29:02 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:57:19 2005 Subject: [CF-Devel] I have a few patches for you In-Reply-To: <41C9C0DD.4060604@aladin.ro> References: <41C9C0DD.4060604@aladin.ro> Message-ID: <41D07E9E.7040403@sonic.net> Took a quick look - a few comments: Munteanu Eduard Gabriel wrote: > 2) settings.diff > - now we can modify the behavior of stats rolling, by changing the > minimum and maximum sum of stats that can be rolled during character > creation, which can be achieved by editing the settings file > (min_initial_stats_sum, max_initial_stats_sum). Seems reasonable. The comment about it could possibly take a large number of rolls to get valid stats is reasonable, but in most cases, shouldn't be an issue. The problem probably really occurs if the min stats is set to some value close to the max threshold - if it is set to 133 for example, that means the average stat roll for all the stats would 19. That could take a very long time - I think it may be reasonable that if the stat total is above some percentage of maximum allowed stats (90%?) to at least print a warning. Also, instead of hardcoding the value '7' in the load_settings for min values, you should use the NUM_STATS value instead. Unlikely new stats will be added, but you never no. > - when the server starts and loads settings, if the settings file is > misconfigured, the default behavior is to die by calling LOG(logLevel, > ..., ...), where logLevel is llevFatal by default (but can be changed by > modifying INIT_LOAD_SETTINGS_LOGLEVEL). I don't think I like that as a default. The real case here is that different errors have different priorities. As mentioned above, something like the stat average being too high might be a warning, something like invalid values might be a warning (because it just falls back to built in defaults), but there can certainly be cases where something should really be fatal. One real concern I have here is the potential for values currently in the settings files to be obsoleted. This would mean a player using their old settings file would find that there server no longer starts - this would be very obnoxious for those servers that automatically restart on failure. I think the default should be to log the errors, but not actually halt. > - janitorial work > 3) sighup_reload_settings.diff > - this is highly experimental: the server now behaves differently when > it recieves a SIGHUP signal, by reloading the settings file (if there > are errors in the settings file, the server does _not_ die; here, > logLevel is llevError) Don't like that as is - sighup right now is the only signal one can send to the server to get it to shut down cleanly. Changing that behaviour is likely to cause confusion. Using another signal for the reload of data (sigusr1 perhaps) is more reasonable. However, I'm not sure how much I like the idea - certainly, it is convenient to be able to reload those values. However, at the same time, I'm fearful that people will use it and get strange side effects and file bugs against them, of which there may be no way to fix them - if you make a function available, people then expect to be able to use it. If sufficient disclaimers are placed perhaps it is then reasonable. > > I hope my future patches will include both client and server side > changes that will allow, if the server administrator permits it, the > clients to manually setup their character's stats. > Please tell me if you liked this patch. Other than those minor notes, it looks good. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Mon Dec 27 15:32:24 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:57:20 2005 Subject: [CF-Devel] Monks wearing weapons In-Reply-To: <001001c4e82e$7e4cf990$8024a2cd@YUANC8000> References: <41C8A1F0.2080800@laposte.net> <001001c4e82e$7e4cf990$8024a2cd@YUANC8000> Message-ID: <41D07F68.9020201@sonic.net> Yua CaVan wrote: > How about when someone chooses to become a monk ( and has arms ), a > "cursed" weapon is automatically equipped that cannot be "un-cursed" > while the character is a monk? ie... "monk fists". The problem is that adds more specialized code (is the player a monk? If so, don't let remove curse work, etc). It'd also be odd to see those objects in your inventory. I personally like a more generic approach of adding a class force object that uses up the players arms. This then means that if other non weapon using classes are ever added, it should just work without any additional changes. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Mon Dec 27 15:37:01 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:57:20 2005 Subject: [CF-Devel] GTK client crash (under Windows, at least) In-Reply-To: <41C971A5.2080709@laposte.net> References: <41C8B028.6060102@laposte.net> <41C9300A.3010807@sonic.net> <41C971A5.2080709@laposte.net> Message-ID: <41D0807D.4090704@sonic.net> Nicolas Weeger wrote: >> note that face 0 is never a valid face to display. > > > Actually, in the gtk code, if CONFIG_CACHE is set (and i think it's the > 'cache images' configuration option), pixmaps[ 0 ] does get a valid > image to display. But otherwise, it's apparently NULL. > So code doesn't seem to check that. But face 0 is never really meant to be displayed. Basically, since it is known that is never a face, it can be used to hold a pixmap to display while waiting for the real pixmap to come down the pipe. BAsically, what happens is something like: S->C: display face 1234 C: doesn't have 1234, so updates 1234 to point at 0 to have something to display. Request 1234 face from server. S->C: sends face 1234 C: renders face 1234, putting it in the right spot, so that 1234 no longer points at 0. Use of face 0 here was just a convenience on the fact that faces started at 1, so zero is available, and is in all the arrays. The last face in the array could just as easily been used, in which case this would have also crashed with caching - its really a side effect that caching sets up this face to use for its own purposes. Note even in caching, face 0 should never be sent by the server as something to display - rather, it still uses the real face number, it's just the client uses face 0 instead. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Mon Dec 27 15:55:26 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:57:20 2005 Subject: [CF-Devel] Missing archetypes used by python plugin In-Reply-To: <41C75454.2000205@sympatico.ca> References: <20041018175104.GA30872@idefix2.dvlp.in-medias-res.com> <20041018180424.GB25816@laranja.org> <20041220205332.GA18213@idefix2.dvlp.in-medias-res.com> <41C75454.2000205@sympatico.ca> Message-ID: <41D084CE.2030501@sonic.net> Todd Mitchell wrote: > Andreas Kirschbaum wrote: > >>> From my point of view only the functions CheckInvisibleObject() and >> >> CreateInvisibleObject() are useful (and currently working). The >> remaining functions should be removed. Is this "fix" of the plugin code >> acceptable? >> >> _______________________________________________ >> >> > I believe so. I have only ever used the invisible object function and > the others I have not as I assumed they were legacy code. I don't know > if there is an issue where it is different with inserting these > invisible inventory objects as opposed to visible inventory objects. Shouldn't really be any difference (aside from the obvious, like visible objects will be seen by th player). But I believe even invisible objects can merge, it is just that most every invisible object has 'nrof 0' so it won't merge. > Really you should just create the arch by name and it will have > visibility as a property or not - there should be no diffrnece in > creating a marker or spell object from creating a shield or glove > object. However, I haven't tried this and if there is a difference > then the way this should work is to be able to insert these types of > archetypes by passing their name from a single function instead of > having a function for each type. Perhaps adding an optional archetype > name field which defaults to 'force' to the InvisibleObject() functions. Creation of objects is all the same. The only real difference is in the defaults - if you are making a glove, starting from the glove archetype is easier, becaus it will ahve the type/subtype/body_info/etc all set up as needed, where if you do it from an empty object, more work needs to be done. In the case of the player_force objects, it sounds like the only special feature they had was the name, so not much extra work there. I'm not sure if perhaps their removal had something to do with the older character creation system (back when there was just a class/race feature as one selection, not like now where you can select both class and race as two distinct features) > > Another big thing along the same lines would be to clean up the spell > and skill stuff... I don't know how the spell and skill wrappers can be > loaded into the plugin any longer now that they are dynamically loaded > from the arches, but this is a lot of legacy code in the plugin. I don't know how out of date the skill stuff is. The spell stuff is, for lack of better term, broken, since the the new spell code is completely different. OTOH, since spells are now objects, one can insert/remove/change them through normal object manipulation functions - before, they were basically hard coded values stored in an array in the player structure, so removing and adding them required special functions. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Thu Dec 30 18:42:03 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:57:20 2005 Subject: [CF-Devel] immunity force applied after death & godpower(?) Message-ID: The following change was made to the Crossfire server code: server/player.c: Insert force into the player when they die making them immune to any spells on the space they reappear on - this prevents multiple deaths if there is large spell effect going on in the savebed location. Duration of force should be long enough for most spells to run their course, but no so long that the player can use it for much of an advantage (plus, killing yourself to get such an advantage seems odd, and the force only makes the player immune to the attacktypes currently on the space) Assuming this is in place on the crossfire.metalforge.net server, I saw today a player die 3 times to godly retribution. They died the first time out in a dungeon, and then 2 more times while back in their apartment and on their save bed. What attack type is godly retribution? Is it godpower? Is immunity to godpower granted by this force? Or is it another issue or problem that allowed this to happen? -- _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel