From: Matthias T. <mt...@gm...> - 2005-09-08 20:25:29
|
so here is my problem: I cannot add arbitrary attributes to the item because these needs to be registered in the RPClass: marauroa.common.game.RPClass$SyntaxException: attribute attack isn't defined. An item *can* have arbitrary attributes...so either the item manages its own attribute pool or the RPClass transmits all properties which are not known as simple visible, volatile Strings. <very bad idea> add an attribute 'itemattribs' and manage the items attributes with a comma-separated string </very bad idea> Any suggestions? Regards Matthias SourceForge.net wrote: > Bugs item #1284306, was opened at 2005-09-07 23:19 > Message generated for change (Tracker Item Submitted) made by Item Submitter > You can respond by visiting: > https://sourceforge.net/tracker/?func=detail&atid=101111&aid=1284306&group_id=1111 > > Please note that this message will contain a full copy of the comment thread, > including the initial issue submission, for this request, > not just the latest update. > Category: None > Group: None > Status: Open > Resolution: None > Priority: 5 > Submitted By: Miguel Angel Blanch Lardin (arianne_rpg) > Assigned to: Nobody/Anonymous (nobody) > Summary: Stendhal: Items propierties > > Initial Comment: > Join them with attributes as we are repeating information > and methods. > > ---------------------------------------------------------------------- > > You can respond by visiting: > https://sourceforge.net/tracker/?func=detail&atid=101111&aid=1284306&group_id=1111 > > > ------------------------------------------------------- > SF.Net email is Sponsored by the Better Software Conference & EXPO > September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices > Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA > Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf > _______________________________________________ > Arianne-bugs mailing list > Ari...@li... > https://lists.sourceforge.net/lists/listinfo/arianne-bugs > |
From: Miguel A. B. L. <mig...@ho...> - 2005-09-09 07:20:38
|
>so here is my problem: > >I cannot add arbitrary attributes to the item because these needs to be >registered in the RPClass: > >marauroa.common.game.RPClass$SyntaxException: attribute attack isn't >defined. > >An item *can* have arbitrary attributes...so either the item manages its >own attribute pool or the RPClass transmits all properties which are not >known as simple visible, volatile Strings. Two solutions: - If attributes are known at compile time just add them all to RPClass. - If attributes are totally arbitrary, just don't define a RPClass for Items. IMHO we can have a basic set of attributes for most items and define an RPClass, special items will surely need a java class because they will have attributes and code to reply to actions ( f.e. a key to open a door with the Use with command, our chest, etc. ). This is really a not urgent task, simply that if propierties are going to be known also at client we better use Attributes to avoid repeating code that may add new ( and exciting! ) bugs. I think that Items situation is a bit different to Creatures, we can do the same approach with types of items: swords, shields, keys,... just my two cents. So, what we do? Regards, Miguel |
From: Matthias T. <mt...@gm...> - 2005-09-10 08:55:29
|
> Two solutions: > - If attributes are known at compile time just add them all to RPClass. They are not known. > - If attributes are totally arbitrary, just don't define a RPClass for > Items. I tried that...but there is a problem...I'll explain below > IMHO we can have a basic set of attributes for most items and define an > RPClass, special items will surely need a java class because they will > have attributes and code to reply to actions ( f.e. a key to open a door > with the Use with command, our chest, etc. ). I don't think so. The items are all the same but for their properties (so there is no need to create a bunch of classes for each differet type). For example weapons, shields and rings don't share any properties at all. So the attribute system of Marauroa would be perfect to handle these. > This is really a not urgent task, simply that if propierties are going > to be known also at client we better use Attributes to avoid repeating > code that may add new ( and exciting! ) bugs. ...boooring...no bugs no fun :) > I think that Items situation is a bit different to Creatures, we can do > the same approach with types of items: swords, shields, keys,... just my > two cents. Keep the java-stuff as clean and simple as possible. That's the reason I killed all those creature classes. > So, what we do? The attributes needs to be in the 'attributeIntegerMap' (somewhere around RPClass:55) mapping the names to a short int. This map is created when registering the RPClasses both on the server and the client at startup. Using an attribute which is unknown to the server or client results in a panic-exception. Solution: Make the RPClass dynamic from a client-side point of view. The client does not know any RPClasses at startup. The Sync'ed Perceptions transmits all currently known RPClasses to the client. When a new RPClass (or RPClass-less attibute) is introduced server-side the next perception send to the client is a sync'ing one. This has many advantages: more freedom when using RPClasses, no need to register them at startup (I don't like these static register stuff anyway) and, most important, a whole bunch of *new* and *exciting* bugs ;) I'm playing around a little bit with this solution Don't know yet if it is even possible. Regards Matthias |
From: Matthias T. <mt...@gm...> - 2005-09-10 15:04:30
|
huh, it's done. There are still some ugly things but it works. But, hey, I found a new bug. Looks like an old one: When I open the chest in the city and move an item to the ground I get this nice exception: --- 8< --- java.io.IOException: Declared array size=4 is not equal to actually read bytes count(2)! at marauroa.common.net.InputSerializer.readInt (InputSerializer.java:186) at marauroa.common.net.MessageS2CPerception.readObject (MessageS2CPerception.java:318) at marauroa.common.net.MessageFactory.getMessage (MessageFactory.java:108) [...] --- >8 --- Looks like the InputStream encapsulated by the InputSerializer does not have all data it should have. This results in a chest where the content is not updated (client-side) until it is closed and reopened. So the question is: new bug or old one (maybe bug 1236674: chest not updated correctly). If it is the old one I'll store the stuff on CVS and check the bug later... Regards Matthias Matthias Totz wrote: >> Two solutions: >> - If attributes are known at compile time just add them all to RPClass. > > > They are not known. > >> - If attributes are totally arbitrary, just don't define a RPClass for >> Items. > > > I tried that...but there is a problem...I'll explain below > >> IMHO we can have a basic set of attributes for most items and define >> an RPClass, special items will surely need a java class because they >> will have attributes and code to reply to actions ( f.e. a key to open >> a door with the Use with command, our chest, etc. ). > > > I don't think so. The items are all the same but for their properties > (so there is no need to create a bunch of classes for each differet type). > For example weapons, shields and rings don't share any properties at > all. So the attribute system of Marauroa would be perfect to handle these. > >> This is really a not urgent task, simply that if propierties are going >> to be known also at client we better use Attributes to avoid repeating >> code that may add new ( and exciting! ) bugs. > > > ...boooring...no bugs no fun :) > >> I think that Items situation is a bit different to Creatures, we can >> do the same approach with types of items: swords, shields, keys,... >> just my two cents. > > > Keep the java-stuff as clean and simple as possible. That's the reason I > killed all those creature classes. > >> So, what we do? > > > The attributes needs to be in the 'attributeIntegerMap' (somewhere > around RPClass:55) mapping the names to a short int. This map is created > when registering the RPClasses both on the server and the client at > startup. Using an attribute which is unknown to the server or client > results in a panic-exception. > Solution: Make the RPClass dynamic from a client-side point of view. The > client does not know any RPClasses at startup. The Sync'ed Perceptions > transmits all currently known RPClasses to the client. When a new > RPClass (or RPClass-less attibute) is introduced server-side the next > perception send to the client is a sync'ing one. > > This has many advantages: more freedom when using RPClasses, no need to > register them at startup (I don't like these static register stuff > anyway) and, most important, a whole bunch of *new* and *exciting* bugs ;) > > I'm playing around a little bit with this solution Don't know yet if it > is even possible. > > Regards > Matthias > > > > ------------------------------------------------------- > SF.Net email is Sponsored by the Better Software Conference & EXPO > September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices > Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA > Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf > _______________________________________________ > Arianne-devel mailing list > Ari...@li... > https://lists.sourceforge.net/lists/listinfo/arianne-devel > |
From: Miguel A. B. L. <mig...@ho...> - 2005-09-10 16:17:54
|
>huh, it's done. There are still some ugly things but it works. >But, hey, I found a new bug. Looks like an old one: > >When I open the chest in the city and move an item to the ground I get this >nice exception: > >--- 8< --- >java.io.IOException: Declared array size=4 is not equal to actually read >bytes count(2)! >at marauroa.common.net.InputSerializer.readInt >(InputSerializer.java:186) >at marauroa.common.net.MessageS2CPerception.readObject >(MessageS2CPerception.java:318) >at marauroa.common.net.MessageFactory.getMessage >(MessageFactory.java:108) >[...] >--- >8 --- > >Looks like the InputStream encapsulated by the InputSerializer does not >have all data it should have. >This results in a chest where the content is not updated (client-side) >until it is closed and reopened. It is strange, as I do open the chest, take one item out and I see no error. >So the question is: new bug or old one (maybe bug 1236674: chest not >updated correctly). If it is the old one I'll store the stuff on CVS and >check the bug later... If you can check the changes, but if you don't find it, commit and I will have a look to it. It is a really strange thing. |
From: Miguel A. B. L. <mig...@ho...> - 2005-09-11 09:02:00
|
Hi, I have been reading code and checking things and I think I have an idea about how it happen. Two or more players attack a creature. One of them kill the creature. ( on 0.30 now a corpse appears, but I added a change to allow the last hit to be visible ) HP is now 0, but the other player can attack too the creature and in fact kill it ( as HP is 0, even if he/she fails. ) So the creature is killed twice and that is the reason we get an error. I will fix this shortly. Sorry, Miguel >From: "Miguel Angel Blanch Lardin" <mig...@ho...> >Reply-To: ari...@li... >To: ari...@li... >Subject: Re: [Arianne-devel] Re: [ arianne-Bugs-1284306 ] Stendhal: Items >propierties >Date: Sat, 10 Sep 2005 18:17:47 +0200 > >>huh, it's done. There are still some ugly things but it works. >>But, hey, I found a new bug. Looks like an old one: >> >>When I open the chest in the city and move an item to the ground I get >>this nice exception: >> >>--- 8< --- >>java.io.IOException: Declared array size=4 is not equal to actually read >>bytes count(2)! >>at marauroa.common.net.InputSerializer.readInt >>(InputSerializer.java:186) >>at marauroa.common.net.MessageS2CPerception.readObject >>(MessageS2CPerception.java:318) >>at marauroa.common.net.MessageFactory.getMessage >>(MessageFactory.java:108) >>[...] >>--- >8 --- >> >>Looks like the InputStream encapsulated by the InputSerializer does not >>have all data it should have. >>This results in a chest where the content is not updated (client-side) >>until it is closed and reopened. > >It is strange, as I do open the chest, take one item out and I see no >error. > >>So the question is: new bug or old one (maybe bug 1236674: chest not >>updated correctly). If it is the old one I'll store the stuff on CVS and >>check the bug later... > >If you can check the changes, but if you don't find it, commit and I will >have a look to it. >It is a really strange thing. > > > > >------------------------------------------------------- >SF.Net email is Sponsored by the Better Software Conference & EXPO >September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices >Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA >Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf >_______________________________________________ >Arianne-devel mailing list >Ari...@li... >https://lists.sourceforge.net/lists/listinfo/arianne-devel |
From: Miguel A. B. L. <mig...@ho...> - 2005-09-11 09:10:28
|
ok, it is fixed. I have simply disallowed the attack on creatures whose HP is 0. Regards, Miguel |
From: Miguel A. B. L. <mig...@ho...> - 2005-09-12 11:17:16
|
Hi Matthias, I am checking the code of the modified Perception and I see you send RPClasses and Attributes. I just don't understand why you want to send the info twice, as sending RPClasses will send also the attributes, isn't it? Am I missing something important? BTW I am checking MessageS2CPerception because there is a bug there. https://sourceforge.net/tracker/index.php?func=detail&aid=1288591&group_id=1111&atid=101111 |
From: Matthias T. <mt...@gm...> - 2005-09-12 16:20:25
|
Miguel Angel Blanch Lardin wrote: > Hi Matthias, > > I am checking the code of the modified Perception and I see you send > RPClasses and Attributes. > I just don't understand why you want to send the info twice, as sending > RPClasses will send also the attributes, isn't it? > > Am I missing something important? There is a global list which maps attribute names to an unique id. When the RPClass is transmitted only the ids are stored. There is code to handle unknown attributes...but is looks like this doesn't work right. The bug below has something to do with it. So the attributes must be send before the RPClass'es so the Client can build the Attribute name to unique id map. It just sends all currently known attribute names with their unique ids. > BTW I am checking MessageS2CPerception because there is a bug there. Yep, i know. Check my old email ;) This seems to be a problem with marauroa and slot handling both serverside and clientside. Looks like I got the serverside stuff, but the client is killing me. Where is the code to handle slot-changes? Haven't found anything. Just gimme a day or two to find this one... Regards Matthias |
From: Miguel A. B. L. <mig...@ho...> - 2005-09-12 17:56:10
|
>>I am checking the code of the modified Perception and I see you send >>RPClasses and Attributes. >>I just don't understand why you want to send the info twice, as sending >>RPClasses will send also the attributes, isn't it? >> >>Am I missing something important? > >There is a global list which maps attribute names to an unique id. When the >RPClass is transmitted only the ids are stored. There is code to handle >unknown attributes...but is looks like this doesn't work right. The bug >below has something to do with it. >So the attributes must be send before the RPClass'es so the Client can >build the Attribute name to unique id map. It just sends all currently >known attribute names with their unique ids. I think RPClass send should be enough. I mean RPClass will send everything ( name<-->id map too ). Take a look to S2C Choose Character ACK ( I think RPClasses where send there ). Maybe it is simpler/more general to allow wilcards? Like RPClass item=new RPClass("item"); item.add("*",RPClass.BYTE); Coding this is very easy. We don't need to modify anything at all ( almost ) at Marauroa and we save the sending of RPClasses and Attributes on each sync perception. What do you think? > > BTW I am checking MessageS2CPerception because there is a bug there. > >Yep, i know. Check my old email ;) >This seems to be a problem with marauroa and slot handling both serverside >and clientside. Looks like I got the serverside stuff, but the client is >killing me. Where is the code to handle slot-changes? Haven't found >anything. It is at RPSlot ( I think ). But that code has little to do with attributes. I have been checking your code for any obivous bug but I haven't find anything, so I will have another look tomorrow. |
From: Matthias T. <mt...@gm...> - 2005-09-12 21:17:42
|
Miguel Angel Blanch Lardin wrote: >>> I am checking the code of the modified Perception and I see you send >>> RPClasses and Attributes. >>> I just don't understand why you want to send the info twice, as >>> sending RPClasses will send also the attributes, isn't it? >>> >>> Am I missing something important? >> >> >> There is a global list which maps attribute names to an unique id. >> When the RPClass is transmitted only the ids are stored. There is code >> to handle unknown attributes...but is looks like this doesn't work >> right. The bug below has something to do with it. >> So the attributes must be send before the RPClass'es so the Client can >> build the Attribute name to unique id map. It just sends all currently >> known attribute names with their unique ids. > > > I think RPClass send should be enough. > I mean RPClass will send everything ( name<-->id map too ). Take a look > to S2C Choose Character ACK ( I think RPClasses where send there ). > > Maybe it is simpler/more general to allow wilcards? > Like > RPClass item=new RPClass("item"); > item.add("*",RPClass.BYTE); I'll have a look. I don't really like the idea of wildcards. Are all unknown Attributes BYTE's with the above command? > Coding this is very easy. We don't need to modify anything at all ( > almost ) at Marauroa and we save the sending of RPClasses and Attributes > on each sync perception. > > What do you think? You do not need to send the info each perception. You need to send them when the tables (Attributes or RPClasses) changes, and then only the changes. The client code can manage this already, I just don't want to add too much too fast. It has to work correctly, tweaking can be done later. Ok, you got me, I must admit I was too lazy :) Regards Matthias |
From: Miguel A. B. L. <mig...@ho...> - 2005-09-12 22:02:09
|
>>I think RPClass send should be enough. >>I mean RPClass will send everything ( name<-->id map too ). Take a look to >>S2C Choose Character ACK ( I think RPClasses where send there ). >> >>Maybe it is simpler/more general to allow wilcards? >>Like >>RPClass item=new RPClass("item"); >>item.add("*",RPClass.BYTE); > >I'll have a look. I don't really like the idea of wildcards. Are all >unknown Attributes BYTE's with the above command? Yes, all the attributes of the class item. But I don't really understand all about the unknown attributes. You must know attributes at compile time or they are just simply useless. You have to know that a sword MUST have a atk attrib or that shield has a def attrib. As I said, I think it is(was) a simpler solution to have a RPClass item that define all the attributes that are needed. >You do not need to send the info each perception. You need to send them >when the tables (Attributes or RPClasses) changes, and then only the >changes. >The client code can manage this already, I just don't want to add too much >too fast. It has to work correctly, tweaking can be done later. >Ok, you got me, I must admit I was too lazy :) I would like to beg for extreme caution when modifing marauroa code as changes there affects everything related to arianne ( 2 games right now, but many more soon ). |
From: Matthias T. <mt...@gm...> - 2005-09-13 18:00:42
|
> I would like to beg for extreme caution when modifing marauroa code as > changes there affects everything related to arianne ( 2 games right now, > but many more soon ). As marauroa is stable but not final you have to develop the games against a certain version of marauroa. Stendhal is the reference client for the current version. Or did I misunderstood something? I know what I am doing. That is the main reason why I wanted the commit-notification mails. I read all your commits and try to understand what you changed. You may do the same with my commits ;) All major changes (protocol specific and stuff) are discussed on the list before implementation is started, as with the attributes stuff I did. I think that is ok. Regards Matthias |
From: Miguel A. B. L. <mig...@ho...> - 2005-09-13 22:55:15
|
I am not really satisfied with the solution for the attributes problem. I am rechecking sourcecode and I will perhaps try to provide a better solution. In fact my first change is going to be restorage of Delta^2 thing ( applyDifferences thing ) as they are two methods very fragile that can introduce lots of bugs. On the way I have found this: //deleted.add(new RPObject(new RPObject.ID(object))); deleted.add((RPObject) object.copy()); [ I will fix these ] The idea is that by creating a new object with just the ID we save the process of copying the whole object ( a process that can be slow ). PD: Ok, after checking the whole code I think the error is at RPClass and anon attributes. I still don't think it is a good idea to have totally random attributes created at server. And in fact I think that it is not a good idea to have a single class Item to encapsulate very diferent things like shields, armors, swords, keys, potions, doors, furniture, etc... |
From: Matthias T. <mt...@gm...> - 2005-09-18 16:44:43
|
Sorry, a bad system crash killed my proxy, so my reply comes a little late: Miguel Angel Blanch Lardin wrote: > I am not really satisfied with the solution for the attributes problem. > I am rechecking sourcecode and I will perhaps try to provide a better > solution. It was a try and now we know better... > In fact my first change is going to be restorage of Delta^2 thing ( > applyDifferences thing ) as they are two methods very fragile that can > introduce lots of bugs. > > On the way I have found this: > //deleted.add(new RPObject(new RPObject.ID(object))); > deleted.add((RPObject) object.copy()); > > [ I will fix these ] > > The idea is that by creating a new object with just the ID we save the > process of copying the whole object ( a process that can be slow ). There was a problem with sending only the ID. Somehow the RPClass went missing (there is a default Class, but it vanished after a copy somewhere). Thats the reason I send the whole object. > PD: > Ok, after checking the whole code I think the error is at RPClass and > anon attributes. > > I still don't think it is a good idea to have totally random > attributes created at server. And in fact I think that it is not a > good idea to have a single class Item to encapsulate very diferent > things like shields, armors, swords, keys, potions, doors, furniture, > etc... Hm...I don't see an item as sword or shield but as an entity which does not move and does not have its own logic. So all thats different between items are their 'properties'. So why create a dozen of (nearly empty) classes which differ only in the RPClass they register and use. That very bad coding style and noone (from outside) will understand easily what's going on there. The annonymous attributes stuff may not be the best solution, but it was definetly a step in the right direction. Of course you do not have to use this Item-Class for each and every item you create. But a class for each weapon or each armor (as it was before) is not a good idea too. I think this is stuff for marauroa 1.1. As we proceed to add new stuff to stendhal this issue will come back anyway. Regards Matthias PS: What does PD: stand for? |