scorch-devel Mailing List for Scorched Earth 2000

Yes... let's hear some thoughts Alex! :) 
and you are right Mikhail. createExplosion is actually more accurate for what the method is
doing... I was just referring to the already existing name -- but I mistyped it... it was suppose
to be ProduceExplosion.  peformExplosion is a bad name (since it is creating an Explosion class).

--- Mikhail Kruk <me...@cs...> wrote:
> Well, I definitely hate the name "performExplosion". Produce or Create 
> sounds better. 
> Let's not hurry with this though. I need more time to think. 
> BTW, Alex, I'd love to hear your opinion on this. With all due 
> disrespect to your design abilities... you are the smarter one now :)
> 
> > Good alternative.  However, wouldn't this generate more classes and code writing than
> overriding
> > performExplosion.  A Hashmap still requires the conversion from objects, but removes the
> > dependancy to get all the args in the right order.  I don't know.  They all work as solutions.
>  I
> > still fancy the performExplosion (for those that need it), but I'll implement whichever one
> you
> > want.
> > 
> > 
> > --- Mikhail Kruk <me...@cs...> wrote:
> > > You are probably right. It's a bit ugly. I see two ways to work around 
> > > this. Either go with your suggestion and path Properties object or 
> > > Hashtable object (of Properties are not in jdk1.1) or create a new bstract 
> > > class WeaponProperties. Abstract class won't have any methods. 
> > > Implementation will have methods like getRadius(), getBlah(), everything 
> > > inside will be read only and initialized by constructor. Then weapon class 
> > > itself will create an instance of that WeaponProperties class and pass it 
> > > to the setOptions() methods of Weapon (setArgument is gone then).
> > > What do you think?
> > > 
> > > > I got the liquid dirt to work with a few tweaks to the NapalmExplosion. (By the way... I
> still
> > > > don't know 1/2 of how things are working in the class.  There are a lot of things in the
> base
> > > APIs
> > > > that when I go to them via code they don't explain what they are or used for.... which
> leads
> > > to
> > > > more digging and looking to try to understand. However, I understand enought to create
> this
> > > new
> > > > class.)
> > > > 
> > > > Anyway, I started going down the path of handling more than 1 argument...
> > > > public void setArguments(Object args[])
> > > > The negative with this is that each class will pass in a varying amount of arguments, all
> of
> > > > different types.  It makes it more difficult for the developer when they are coding to
> > > understand
> > > > what is being used.  This also requires us to case a int to a Integer and then back to a
> int. 
> > > If
> > > > you don't mind these shortcomings, then I'll continue to move forward.  At a minimum, each
> > > > explosion class that implements this method should describe the input expected as the API.
> > > >   
> > > > > 
> > > > > > > I think I have a better idea. I kind of like the fact that 
> > > > > > > produceExplosion is so generic and that weapon class doesn't have to 
> > > > > > > implement any methods. The solution I have in mind is to make argument an 
> > > > > > > Object isntead of int. For example MIRVExplosion needs really 2 arguments: 
> > > > > > > number of particles and radius. Then the object passed to is as arument 
> > > > > > > would be an array of two ints. This might introduce some weird relation 
> > > > > > > ship between Weapon and Explosion class, but it looks good to me. At least 
> > > > > > > at 3am. Let me know what you think about this idea.
> > > > > > > 
> > > > 
> > > > 
> > > > 
> > > > __________________________________________________
> > > > Do You Yahoo!?
> > > > Yahoo! - Official partner of 2002 FIFA World Cup
> > > > http://fifaworldcup.yahoo.com
> > > > 
> > > > _______________________________________________________________
> > > > 
> > > > Sponsored by:
> > > > ThinkGeek at http://www.ThinkGeek.com/
> > > > _______________________________________________
> > > > Scorch-devel mailing list
> > > > Sco...@li...
> > > > https://lists.sourceforge.net/lists/listinfo/scorch-devel
> > > > 
> > > 
> > > 
> > > _______________________________________________________________
> > > 
> > > Sponsored by:
> > > ThinkGeek at http://www.ThinkGeek.com/
> > > _______________________________________________
> > > Scorch-devel mailing list
> > > Sco...@li...
> > > https://lists.sourceforge.net/lists/listinfo/scorch-devel
> > 
> > 
> > __________________________________________________
> > Do You Yahoo!?
> > Yahoo! - Official partner of 2002 FIFA World Cup
> > http://fifaworldcup.yahoo.com
> > 
> > _______________________________________________________________
> > 
> > Sponsored by:
> > ThinkGeek at http://www.ThinkGeek.com/
> > _______________________________________________
> > Scorch-devel mailing list
> > Sco...@li...
> > https://lists.sourceforge.net/lists/listinfo/scorch-devel
> > 
> 
> 
> _______________________________________________________________
> 
> Sponsored by:
> ThinkGeek at http://www.ThinkGeek.com/
> _______________________________________________
> Scorch-devel mailing list
> Sco...@li...
> https://lists.sourceforge.net/lists/listinfo/scorch-devel


__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com

Well, I definitely hate the name "performExplosion". Produce or Create 
sounds better. 
Let's not hurry with this though. I need more time to think. 
BTW, Alex, I'd love to hear your opinion on this. With all due 
disrespect to your design abilities... you are the smarter one now :)

> Good alternative.  However, wouldn't this generate more classes and code writing than overriding
> performExplosion.  A Hashmap still requires the conversion from objects, but removes the
> dependancy to get all the args in the right order.  I don't know.  They all work as solutions.  I
> still fancy the performExplosion (for those that need it), but I'll implement whichever one you
> want.
> 
> 
> --- Mikhail Kruk <me...@cs...> wrote:
> > You are probably right. It's a bit ugly. I see two ways to work around 
> > this. Either go with your suggestion and path Properties object or 
> > Hashtable object (of Properties are not in jdk1.1) or create a new bstract 
> > class WeaponProperties. Abstract class won't have any methods. 
> > Implementation will have methods like getRadius(), getBlah(), everything 
> > inside will be read only and initialized by constructor. Then weapon class 
> > itself will create an instance of that WeaponProperties class and pass it 
> > to the setOptions() methods of Weapon (setArgument is gone then).
> > What do you think?
> > 
> > > I got the liquid dirt to work with a few tweaks to the NapalmExplosion. (By the way... I still
> > > don't know 1/2 of how things are working in the class.  There are a lot of things in the base
> > APIs
> > > that when I go to them via code they don't explain what they are or used for.... which leads
> > to
> > > more digging and looking to try to understand. However, I understand enought to create this
> > new
> > > class.)
> > > 
> > > Anyway, I started going down the path of handling more than 1 argument...
> > > public void setArguments(Object args[])
> > > The negative with this is that each class will pass in a varying amount of arguments, all of
> > > different types.  It makes it more difficult for the developer when they are coding to
> > understand
> > > what is being used.  This also requires us to case a int to a Integer and then back to a int. 
> > If
> > > you don't mind these shortcomings, then I'll continue to move forward.  At a minimum, each
> > > explosion class that implements this method should describe the input expected as the API.
> > >   
> > > > 
> > > > > > I think I have a better idea. I kind of like the fact that 
> > > > > > produceExplosion is so generic and that weapon class doesn't have to 
> > > > > > implement any methods. The solution I have in mind is to make argument an 
> > > > > > Object isntead of int. For example MIRVExplosion needs really 2 arguments: 
> > > > > > number of particles and radius. Then the object passed to is as arument 
> > > > > > would be an array of two ints. This might introduce some weird relation 
> > > > > > ship between Weapon and Explosion class, but it looks good to me. At least 
> > > > > > at 3am. Let me know what you think about this idea.
> > > > > > 
> > > 
> > > 
> > > 
> > > __________________________________________________
> > > Do You Yahoo!?
> > > Yahoo! - Official partner of 2002 FIFA World Cup
> > > http://fifaworldcup.yahoo.com
> > > 
> > > _______________________________________________________________
> > > 
> > > Sponsored by:
> > > ThinkGeek at http://www.ThinkGeek.com/
> > > _______________________________________________
> > > Scorch-devel mailing list
> > > Sco...@li...
> > > https://lists.sourceforge.net/lists/listinfo/scorch-devel
> > > 
> > 
> > 
> > _______________________________________________________________
> > 
> > Sponsored by:
> > ThinkGeek at http://www.ThinkGeek.com/
> > _______________________________________________
> > Scorch-devel mailing list
> > Sco...@li...
> > https://lists.sourceforge.net/lists/listinfo/scorch-devel
> 
> 
> __________________________________________________
> Do You Yahoo!?
> Yahoo! - Official partner of 2002 FIFA World Cup
> http://fifaworldcup.yahoo.com
> 
> _______________________________________________________________
> 
> Sponsored by:
> ThinkGeek at http://www.ThinkGeek.com/
> _______________________________________________
> Scorch-devel mailing list
> Sco...@li...
> https://lists.sourceforge.net/lists/listinfo/scorch-devel
> 

Good alternative.  However, wouldn't this generate more classes and code writing than overriding
performExplosion.  A Hashmap still requires the conversion from objects, but removes the
dependancy to get all the args in the right order.  I don't know.  They all work as solutions.  I
still fancy the performExplosion (for those that need it), but I'll implement whichever one you
want.


--- Mikhail Kruk <me...@cs...> wrote:
> You are probably right. It's a bit ugly. I see two ways to work around 
> this. Either go with your suggestion and path Properties object or 
> Hashtable object (of Properties are not in jdk1.1) or create a new bstract 
> class WeaponProperties. Abstract class won't have any methods. 
> Implementation will have methods like getRadius(), getBlah(), everything 
> inside will be read only and initialized by constructor. Then weapon class 
> itself will create an instance of that WeaponProperties class and pass it 
> to the setOptions() methods of Weapon (setArgument is gone then).
> What do you think?
> 
> > I got the liquid dirt to work with a few tweaks to the NapalmExplosion. (By the way... I still
> > don't know 1/2 of how things are working in the class.  There are a lot of things in the base
> APIs
> > that when I go to them via code they don't explain what they are or used for.... which leads
> to
> > more digging and looking to try to understand. However, I understand enought to create this
> new
> > class.)
> > 
> > Anyway, I started going down the path of handling more than 1 argument...
> > public void setArguments(Object args[])
> > The negative with this is that each class will pass in a varying amount of arguments, all of
> > different types.  It makes it more difficult for the developer when they are coding to
> understand
> > what is being used.  This also requires us to case a int to a Integer and then back to a int. 
> If
> > you don't mind these shortcomings, then I'll continue to move forward.  At a minimum, each
> > explosion class that implements this method should describe the input expected as the API.
> >   
> > > 
> > > > > I think I have a better idea. I kind of like the fact that 
> > > > > produceExplosion is so generic and that weapon class doesn't have to 
> > > > > implement any methods. The solution I have in mind is to make argument an 
> > > > > Object isntead of int. For example MIRVExplosion needs really 2 arguments: 
> > > > > number of particles and radius. Then the object passed to is as arument 
> > > > > would be an array of two ints. This might introduce some weird relation 
> > > > > ship between Weapon and Explosion class, but it looks good to me. At least 
> > > > > at 3am. Let me know what you think about this idea.
> > > > > 
> > 
> > 
> > 
> > __________________________________________________
> > Do You Yahoo!?
> > Yahoo! - Official partner of 2002 FIFA World Cup
> > http://fifaworldcup.yahoo.com
> > 
> > _______________________________________________________________
> > 
> > Sponsored by:
> > ThinkGeek at http://www.ThinkGeek.com/
> > _______________________________________________
> > Scorch-devel mailing list
> > Sco...@li...
> > https://lists.sourceforge.net/lists/listinfo/scorch-devel
> > 
> 
> 
> _______________________________________________________________
> 
> Sponsored by:
> ThinkGeek at http://www.ThinkGeek.com/
> _______________________________________________
> Scorch-devel mailing list
> Sco...@li...
> https://lists.sourceforge.net/lists/listinfo/scorch-devel


__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com

You are probably right. It's a bit ugly. I see two ways to work around 
this. Either go with your suggestion and path Properties object or 
Hashtable object (of Properties are not in jdk1.1) or create a new bstract 
class WeaponProperties. Abstract class won't have any methods. 
Implementation will have methods like getRadius(), getBlah(), everything 
inside will be read only and initialized by constructor. Then weapon class 
itself will create an instance of that WeaponProperties class and pass it 
to the setOptions() methods of Weapon (setArgument is gone then).
What do you think?

> I got the liquid dirt to work with a few tweaks to the NapalmExplosion. (By the way... I still
> don't know 1/2 of how things are working in the class.  There are a lot of things in the base APIs
> that when I go to them via code they don't explain what they are or used for.... which leads to
> more digging and looking to try to understand. However, I understand enought to create this new
> class.)
> 
> Anyway, I started going down the path of handling more than 1 argument...
> public void setArguments(Object args[])
> The negative with this is that each class will pass in a varying amount of arguments, all of
> different types.  It makes it more difficult for the developer when they are coding to understand
> what is being used.  This also requires us to case a int to a Integer and then back to a int.  If
> you don't mind these shortcomings, then I'll continue to move forward.  At a minimum, each
> explosion class that implements this method should describe the input expected as the API.
>   
> > 
> > > > I think I have a better idea. I kind of like the fact that 
> > > > produceExplosion is so generic and that weapon class doesn't have to 
> > > > implement any methods. The solution I have in mind is to make argument an 
> > > > Object isntead of int. For example MIRVExplosion needs really 2 arguments: 
> > > > number of particles and radius. Then the object passed to is as arument 
> > > > would be an array of two ints. This might introduce some weird relation 
> > > > ship between Weapon and Explosion class, but it looks good to me. At least 
> > > > at 3am. Let me know what you think about this idea.
> > > > 
> 
> 
> 
> __________________________________________________
> Do You Yahoo!?
> Yahoo! - Official partner of 2002 FIFA World Cup
> http://fifaworldcup.yahoo.com
> 
> _______________________________________________________________
> 
> Sponsored by:
> ThinkGeek at http://www.ThinkGeek.com/
> _______________________________________________
> Scorch-devel mailing list
> Sco...@li...
> https://lists.sourceforge.net/lists/listinfo/scorch-devel
> 

I got the liquid dirt to work with a few tweaks to the NapalmExplosion. (By the way... I still
don't know 1/2 of how things are working in the class.  There are a lot of things in the base APIs
that when I go to them via code they don't explain what they are or used for.... which leads to
more digging and looking to try to understand. However, I understand enought to create this new
class.)

Anyway, I started going down the path of handling more than 1 argument...
public void setArguments(Object args[])
The negative with this is that each class will pass in a varying amount of arguments, all of
different types.  It makes it more difficult for the developer when they are coding to understand
what is being used.  This also requires us to case a int to a Integer and then back to a int.  If
you don't mind these shortcomings, then I'll continue to move forward.  At a minimum, each
explosion class that implements this method should describe the input expected as the API.
  
> 
> > > I think I have a better idea. I kind of like the fact that 
> > > produceExplosion is so generic and that weapon class doesn't have to 
> > > implement any methods. The solution I have in mind is to make argument an 
> > > Object isntead of int. For example MIRVExplosion needs really 2 arguments: 
> > > number of particles and radius. Then the object passed to is as arument 
> > > would be an array of two ints. This might introduce some weird relation 
> > > ship between Weapon and Explosion class, but it looks good to me. At least 
> > > at 3am. Let me know what you think about this idea.
> > > 



__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com

I've noticed a couple of times where the colors of the board and the ground made it difficult to
play.  For example, the sand was black and so was the night sky.  Also, There was one where the
color of the red/yellow tanks were near impossible to see on the background color.  Not sure this
was on the list to fix, but just wanted to mention it.

__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com

CVS updated last night.
Added 2 Classes - DirtBall and DirtBallExplosion.
Modified 2 Classes - Weapon and PlasmaExplosion.

Thanks.

__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com

Look fine.

> Please checkout BabyDigger to see if it has any problems.  I pulled it out normally using WinCVS
> and then checked it back in -- without going to/from Unix LF.  It looked like it did a Diff just
> fine.  So, I think it works... but please someone verify this also.  Thanks!

Please checkout BabyDigger to see if it has any problems.  I pulled it out normally using WinCVS
and then checked it back in -- without going to/from Unix LF.  It looked like it did a Diff just
fine.  So, I think it works... but please someone verify this also.  Thanks!

--- Charles McCann <cha...@ya...> wrote:
> 
> I read in a newsgroup that WinCVS handles automatically going from Dos to Unix LF.  So, there
> might be no issue at all.  I will test it out on an existing file to see if this is true...
> probably one of the simple weapon files.
> 
> Thanks!
> 
> --- Mikhail Kruk <me...@cs...> wrote:
> > On Sat, 8 Jun 2002, Charles McCann wrote:
> > 
> > > Is there an easy way to turn the DOS style to Unix style EOL?  Maybe 
> > > load it in VIM or Textpad and
> > > they might have a save as Unix style, right?
> > 
> > I don't know about Textpad, but I'm pretty sure that if you edit it with 
> > Vim it will preserve whatever end lines are there. Same goes about emacs. 
> > You'll probably want to edit files in your IDE (what do you use anyway?) 
> > so you can use a converter. You can get one here 
> > http://www.bastet.com/software/software.html (I didn't test it)
> > 
> > > You'll have to modify your builds to include the new weapon files that 
> > > I added. I didn't include
> > > that file in the zip.  I'm currently not using the makefile since I don't know how to build
> > the
> > > "make" code on my win machine - but I am using it as a reference.
> > 
> > I'll take care of it. Just let us know when you put the DirtBall in CVS.
> > 
> > 
> > 
> 
> __________________________________________________
> Do You Yahoo!?
> Yahoo! - Official partner of 2002 FIFA World Cup
> http://fifaworldcup.yahoo.com
> 
> _______________________________________________________________
> 
> Don't miss the 2002 Sprint PCS Application Developer's Conference
> August 25-28 in Las Vegas - http://devcon.sprintpcs.com/adp/index.cfm?source=osdntextlink
> 
> _______________________________________________
> Scorch-devel mailing list
> Sco...@li...
> https://lists.sourceforge.net/lists/listinfo/scorch-devel


__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com

I read in a newsgroup that WinCVS handles automatically going from Dos to Unix LF.  So, there
might be no issue at all.  I will test it out on an existing file to see if this is true...
probably one of the simple weapon files.

Thanks!

--- Mikhail Kruk <me...@cs...> wrote:
> On Sat, 8 Jun 2002, Charles McCann wrote:
> 
> > Is there an easy way to turn the DOS style to Unix style EOL?  Maybe 
> > load it in VIM or Textpad and
> > they might have a save as Unix style, right?
> 
> I don't know about Textpad, but I'm pretty sure that if you edit it with 
> Vim it will preserve whatever end lines are there. Same goes about emacs. 
> You'll probably want to edit files in your IDE (what do you use anyway?) 
> so you can use a converter. You can get one here 
> http://www.bastet.com/software/software.html (I didn't test it)
> 
> > You'll have to modify your builds to include the new weapon files that 
> > I added. I didn't include
> > that file in the zip.  I'm currently not using the makefile since I don't know how to build
> the
> > "make" code on my win machine - but I am using it as a reference.
> 
> I'll take care of it. Just let us know when you put the DirtBall in CVS.
> 
> 
> 

__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com

> > Is there an easy way to turn the DOS style to Unix style EOL?  Maybe 
> > load it in VIM or Textpad and
> > they might have a save as Unix style, right?
> 
> I don't know about Textpad, but I'm pretty sure that if you edit it with 
> Vim it will preserve whatever end lines are there. Same goes about emacs. 
>
I might be wrong on this, of course, but I am pretty sure that emacs would 
replace the EOL by UNIX style...
at least that's how we achieved compatibility with CVS when developing 
stuff on windows... (btw, meshko, DrScheme will screw up the EOLs as I 
found out :)))

I've added a file named README.developer which will, hopefully, contain 
some useful information in the future.  Currently it has only small 
braindead pciture of our braindead class hierarchy :)

> > Impossible, unfortunately. It can't be static, because it than would be 
> > shared by all instances of the game running in the same JVM, which can 
> > happen if somebody opens up applet in two windows of the same browser. 
> > This would screw up our synchronization based on the same random # 
> > sequence. You could make it non-static publically available object in 
> > ScorchApplet, or ScorchField, but I think I decided again it because that 
> > meant that I would have to pass reference to that containing object 
> > everywhere. 
> > 
> 
> Ah... didn't know applets would do that.  I also didn't know it tied 
> some how into your
> synchronization.  I thought it was more for just getting a random 
> number.  If you don't mind me
> asking, at which class(es) does the synch issues come up for this 
> Random number?

It's not synchronization in the sense of synchronized (rand) { ... }
What happens is that when games starts, server generates a seed. It sends 
it to all clients and they initialize random number generators with this 
seed. Then it is important that every client generates exactly the same 
number of random numbers in exactly the same order. That's how we make 
sure that all clients have the same terrain generated etc.

> > Wait, the only thing that weapon knows about the extending classes are 
> > their names. It's easy to get rid of this: we can use reflection to list 
> > all classes in "scorch.weapons" package which extend Weapon. Then call 
> > getName() on them etc. I'm not sure it's worth the effort. Factory is a 
> > possibility too. If you feel like it, try it. Of course changes to Items 
> > should be symmetrical.
> > 
> 
> Interesting idea.  Might work well.  Sort of has a Module plug-n-play feel.

It might work, might not. There are some issues in Netscape Communicator 
with security and reflection. I don't want to break NC support just for 
that. But if it works it would be quite cute feature -- add weapons 
without recompiling. Useless, of course, in an open source project. But on 
the other hand you will be able to *remove* weapons without recompiling.
 
> > Yes and no. Explosions are not eactly the same as weapons. I guess the 
> > right way to do it is to add a flag to each weapon which would say whether 
> > it can be used for the death sequence. I need to think more about this, 
> > but just moving this to weapon or weapon factory doesn't sound 100% good.
> > Much biggre problems is with Items. ScorchPlayer has a lot of knowledge 
> > about specific item classes.
> > 
> 
> I like the idea of having each weapon know if it can be used in a death 
> sequence.  

Please don't call it weapon, it's explosion. Otherwise it's confusing. 
There might be some problem lurking in there. Ah, I know. All the 
explosion classes take slightly different arguments so to generalize that 
will have to path a bunch of useless arguments to some explosions. For 
example only FireExplosion needs height of tank, only Fire and Laser need 
width of tank and only FunkyExplosion needs rand object.

> I guess I need
> to look at the Items and ScorchPlayer ties more closely.

I though about that a lot. I don't think this tie can be easily broken, 
because unlike weapons, items influence things in environment a lot. 
Things like tracers, parachutes, auto defense can not be self-contained. 
This is a case when design and incapsulation must clearly be sacrificed 
for practicality. 
 

> > I think I have a better idea. I kind of like the fact that 
> > produceExplosion is so generic and that weapon class doesn't have to 
> > implement any methods. The solution I have in mind is to make argument an 
> > Object isntead of int. For example MIRVExplosion needs really 2 arguments: 
> > number of particles and radius. Then the object passed to is as arument 
> > would be an array of two ints. This might introduce some weird relation 
> > ship between Weapon and Explosion class, but it looks good to me. At least 
> > at 3am. Let me know what you think about this idea.
> > 
> 
> Yes... I was thinking of changing the single attribute int to a array 
> or hashmap.  If it was a hashmap, you could do a name value pair.  In 
> either case, I still wasn't sure if there was a need
> to hide the Explosion class.  Here's the benifits/tradeoffs that I see:
> 1) current way - requires less code, increased complexity in the 
> explosion class being called

There is one more benefit: I was thinking of completely getting rid of 
Weapons classes and just turning them into a text file with weapon 
properties. This way people would be able to tweak weapons without 
recompiling. With the current scheme this change is more or less trivial.

> 2) using abstracts - forces developer to implement the child class 
> correctly, more obvious what is
> going on

I'd prefer to stick with 1) really. I think it will look much better if we 
change arg into an Object and stick arrays into it when possible. I don't 
want it to be a Hashtable because in most cases there will be just one 
argument, sometimes two. Hashtable seems to be an overkill, even though 
the idea of having names does sound good. 
I just think that changing stuff which is not broken is almost always a 
bad idea. It's ok to do when the benefit for design/readabilitiy is 
obvious, but when in doubt, leave the lying dogs lie.
 
> Ok.  let me know what you decide and what things you'd like me to do.  
> I'll be working on the
> LiquidDirt until then.  

I don't know yet. Maybe I'll ask you to finish implementing the boot 
player command. When we have that, we can make a new release.

On Sat, 8 Jun 2002, Charles McCann wrote:

> Is there an easy way to turn the DOS style to Unix style EOL?  Maybe 
> load it in VIM or Textpad and
> they might have a save as Unix style, right?

I don't know about Textpad, but I'm pretty sure that if you edit it with 
Vim it will preserve whatever end lines are there. Same goes about emacs. 
You'll probably want to edit files in your IDE (what do you use anyway?) 
so you can use a converter. You can get one here 
http://www.bastet.com/software/software.html (I didn't test it)

> You'll have to modify your builds to include the new weapon files that 
> I added. I didn't include
> that file in the zip.  I'm currently not using the makefile since I don't know how to build the
> "make" code on my win machine - but I am using it as a reference.

I'll take care of it. Just let us know when you put the DirtBall in CVS.

comments below...

--- Mikhail Kruk <me...@cs...> wrote:
> > Refactorings that would simplify the system and make conform to best 
> > practices:
> > 1) Rand - currently, a random number gets set in ScorchApplet.receiveGameSettings.  However,
> it is
> > passed all over every object with no change.  Recommed: static variable in some Util class (or
> > just ScorchApplet).  All other objects requiring this static value would then call
> > .getCurrentRandom() to get the Random object.
> 
> Impossible, unfortunately. It can't be static, because it than would be 
> shared by all instances of the game running in the same JVM, which can 
> happen if somebody opens up applet in two windows of the same browser. 
> This would screw up our synchronization based on the same random # 
> sequence. You could make it non-static publically available object in 
> ScorchApplet, or ScorchField, but I think I decided again it because that 
> meant that I would have to pass reference to that containing object 
> everywhere. 
> 

Ah... didn't know applets would do that.  I also didn't know it tied some how into your
synchronization.  I thought it was more for just getting a random number.  If you don't mind me
asking, at which class(es) does the synch issues come up for this Random number?

> > 2) Weapon acting as a Weapon base class and a Factory.  Recommend: 
> > splitting the effort - create a
> > separate Factory class to handle the creation of Weapons.  However, if 
> > this is done, Item would
> > also have to be modified to remain consistent since it has the same 
> > issue.  (Is it worth the
> > trouble?)  Just that Weapon and Item should not know about the 
> > implementing classes.
> 
> Wait, the only thing that weapon knows about the extending classes are 
> their names. It's easy to get rid of this: we can use reflection to list 
> all classes in "scorch.weapons" package which extend Weapon. Then call 
> getName() on them etc. I'm not sure it's worth the effort. Factory is a 
> possibility too. If you feel like it, try it. Of course changes to Items 
> should be symmetrical.
> 

Interesting idea.  Might work well.  Sort of has a Module plug-n-play feel.

> > 3) ScorchField - knows about specific Weapons and Explosions.  This should be refactored so
> that
> > it is unware of types.  For example, it could call the WeaponFactory 
> > (or just Weapon if we don't
> > do the Factory) for a randomExplosion() (death explosion) and get back 
> > the appropriate Explosion
> > class.  (just saw you had a TODO in there for this also.)
> 
> Yes and no. Explosions are not eactly the same as weapons. I guess the 
> right way to do it is to add a flag to each weapon which would say whether 
> it can be used for the death sequence. I need to think more about this, 
> but just moving this to weapon or weapon factory doesn't sound 100% good.
> Much biggre problems is with Items. ScorchPlayer has a lot of knowledge 
> about specific item classes.
> 

I like the idea of having each weapon know if it can be used in a death sequence.  I guess I need
to look at the Items and ScorchPlayer ties more closely.

> > public class LiquidDirt extends Weapon {
> >         protected static int radius = 50;
> > 
> > 	public LiquidDirt() {
> >                 //to make the design more obvious, the below variables can be obtained 
> >                 //by creating 2 abstract methods in the Weapon class, and sub-classes
> >                 //would then implement them.
> > 		type = SandBomb;
> > 		price = 5000;
> > 	}
> > 
> > 	//make parent class abstract
> > 	//call our Explosion -- only this weapon needs to know how
> > 	public Explosion produceExplosion(Bitmap bitmap) {
> >                 //this removes need of argument variable
> > 		LiquidDirtExplosion expl = new LiquidDirtExplosion(bitmap, radius);
> > 		return (Explosion)expl;
> > 	}
> > }
> 
> I think I have a better idea. I kind of like the fact that 
> produceExplosion is so generic and that weapon class doesn't have to 
> implement any methods. The solution I have in mind is to make argument an 
> Object isntead of int. For example MIRVExplosion needs really 2 arguments: 
> number of particles and radius. Then the object passed to is as arument 
> would be an array of two ints. This might introduce some weird relation 
> ship between Weapon and Explosion class, but it looks good to me. At least 
> at 3am. Let me know what you think about this idea.
> 

Yes... I was thinking of changing the single attribute int to a array or hashmap.  If it was a
hashmap, you could do a name value pair.  In either case, I still wasn't sure if there was a need
to hide the Explosion class.  Here's the benifits/tradeoffs that I see:
1) current way - requires less code, increased complexity in the explosion class being called
2) using abstracts - forces developer to implement the child class correctly, more obvious what is
going on

No real big wins or loses either solution.  It is probably slightly faster (runtime) to create an
Explosion class directly than to instantiate from the name.  It's up to you on how you'd like to
move forward on this.  I personally like to make things more readable in the code.  When I first
looked at the specific weapon classes, I was amazed at how little was in them -- but was also
confused.  The README.Weapon helped a lot though.  I just look at the abstract methods as a built
in readme that is also validated during compile time. :)

Ok.  let me know what you decide and what things you'd like me to do.  I'll be working on the
LiquidDirt until then.  

Thanks.
-Charles



__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com

Great!  I look forward to helping on the project more... and it will make it easier to have CVS
access.

Is there an easy way to turn the DOS style to Unix style EOL?  Maybe load it in VIM or Textpad and
they might have a save as Unix style, right?

I'm not at home right now, so I'm not sure what I typed concerning the REFACTOR.  Usually, just a
note about refactoring something or if I think it might need it.  I'll look when I get home.  I
usually put a TODO in the code if I want to remember to do something important in the future but
not critical/urgent.

You'll have to modify your builds to include the new weapon files that I added. I didn't include
that file in the zip.  I'm currently not using the makefile since I don't know how to build the
"make" code on my win machine - but I am using it as a reference.

For LiquidDirt, I was looking at the NapalmExplosion since it looked so similar.  I was planning
on doing some refactoring to take advantage of the liquid effect.  I'll let you know if I hit any
snags.


Talk to you guys soon!
--- Mikhail Kruk <me...@cs...> wrote:
> OK, everyone should be on the list by now.
> 
> Charles, Dirt Ball looks good. I mean the code looks good, I didn't have 
> time to actually rebuild it. 
> PlasmaExplosion -- the compiler errors where there because this class was 
> abandoned a long time ago. It was written by a guy who doesn't work on the 
> project any more and plasma explosions caused some weird behaviour. 
> There is a REFACTOR comment DirtBall.java, what do you mean by that? 
> 
> Anyways, there is one real issue with your files. DOS style EOLs. 
> Traditionally we keep all the sources with Unix-style EOLs. Changing that 
> would cause trouble because diffs just shows that files are completely 
> different. Please make sure that you convert all files to Unix style EOLs
> before checking them in. Speaking of checking in, I added you to the 
> project so you should be able to check your changes yourself. Welcome!
> 
> Please send an e-mail to this list each time you check anything in. Alex, 
> you too please, even if it's in the server. Of course I'll do the same.
> 
> If you want to do Liquid dirt, you will need to do some refactoring, 
> like abstract out liquid stuff from NapalmExplosion. This might be 
> slightly tricky, I don't know this code, its Alex's. 
> 
> On Thu, 6 Jun 2002, Charles McCann wrote:
> 
> > Done.  DirtBall is here.  Let me know what you think.
> > I fixed PlasmaExplosion so that it won't throw a ton of compiler errors and warnings. 
> > 
> > Also, let me know if you add the changes into CVS.
> > 
> > Liquid Dirt next?
> > 
> > --- Mikhail Kruk <me...@cs...> wrote:
> > > I have no idea. I havn't run server with 1.1.8 for a long time, something 
> > > might not work with it. We usually run server with 1.3.1
> > > It doesn't use any features beyond 1.1 though, because sometimes we run it 
> > > in Kaffe and it works fine in it. 
> > > Most likely 1.1.8 would have worked if you closed the interactive shell...
> > > 
> > > > I am running the server with 1.3 and appletviewer with 1.1.8.  
> > > > Hopefully, you can fill me in on
> > > > the subtilties of why this is so... or what I am missing. :)
> > > > 
> > > > Now, I'm off to look at this weapon class.
> > > > 
> > > > Thanks.
> > > > 
> > > > __________________________________________________
> > > > Do You Yahoo!?
> > > > Yahoo! - Official partner of 2002 FIFA World Cup
> > > > http://fifaworldcup.yahoo.com
> > > > 
> > > 
> > 
> > 
> > __________________________________________________
> > Do You Yahoo!?
> > Yahoo! - Official partner of 2002 FIFA World Cup
> > http://fifaworldcup.yahoo.com
> 
> 
> 
> _______________________________________________________________
> 
> Don't miss the 2002 Sprint PCS Application Developer's Conference
> August 25-28 in Las Vegas - http://devcon.sprintpcs.com/adp/index.cfm?source=osdntextlink
> 
> _______________________________________________
> Scorch-devel mailing list
> Sco...@li...
> https://lists.sourceforge.net/lists/listinfo/scorch-devel


__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com

> Refactorings that would simplify the system and make conform to best 
> practices:
> 1) Rand - currently, a random number gets set in ScorchApplet.receiveGameSettings.  However, it is
> passed all over every object with no change.  Recommed: static variable in some Util class (or
> just ScorchApplet).  All other objects requiring this static value would then call
> .getCurrentRandom() to get the Random object.

Impossible, unfortunately. It can't be static, because it than would be 
shared by all instances of the game running in the same JVM, which can 
happen if somebody opens up applet in two windows of the same browser. 
This would screw up our synchronization based on the same random # 
sequence. You could make it non-static publically available object in 
ScorchApplet, or ScorchField, but I think I decided again it because that 
meant that I would have to pass reference to that containing object 
everywhere. 

> 2) Weapon acting as a Weapon base class and a Factory.  Recommend: 
> splitting the effort - create a
> separate Factory class to handle the creation of Weapons.  However, if 
> this is done, Item would
> also have to be modified to remain consistent since it has the same 
> issue.  (Is it worth the
> trouble?)  Just that Weapon and Item should not know about the 
> implementing classes.

Wait, the only thing that weapon knows about the extending classes are 
their names. It's easy to get rid of this: we can use reflection to list 
all classes in "scorch.weapons" package which extend Weapon. Then call 
getName() on them etc. I'm not sure it's worth the effort. Factory is a 
possibility too. If you feel like it, try it. Of course changes to Items 
should be symmetrical.

> 3) ScorchField - knows about specific Weapons and Explosions.  This should be refactored so that
> it is unware of types.  For example, it could call the WeaponFactory 
> (or just Weapon if we don't
> do the Factory) for a randomExplosion() (death explosion) and get back 
> the appropriate Explosion
> class.  (just saw you had a TODO in there for this also.)

Yes and no. Explosions are not eactly the same as weapons. I guess the 
right way to do it is to add a flag to each weapon which would say whether 
it can be used for the death sequence. I need to think more about this, 
but just moving this to weapon or weapon factory doesn't sound 100% good.
Much biggre problems is with Items. ScorchPlayer has a lot of knowledge 
about specific item classes.

> public class LiquidDirt extends Weapon {
>         protected static int radius = 50;
> 
> 	public LiquidDirt() {
>                 //to make the design more obvious, the below variables can be obtained 
>                 //by creating 2 abstract methods in the Weapon class, and sub-classes
>                 //would then implement them.
> 		type = SandBomb;
> 		price = 5000;
> 	}
> 
> 	//make parent class abstract
> 	//call our Explosion -- only this weapon needs to know how
> 	public Explosion produceExplosion(Bitmap bitmap) {
>                 //this removes need of argument variable
> 		LiquidDirtExplosion expl = new LiquidDirtExplosion(bitmap, radius);
> 		return (Explosion)expl;
> 	}
> }

I think I have a better idea. I kind of like the fact that 
produceExplosion is so generic and that weapon class doesn't have to 
implement any methods. The solution I have in mind is to make argument an 
Object isntead of int. For example MIRVExplosion needs really 2 arguments: 
number of particles and radius. Then the object passed to is as arument 
would be an array of two ints. This might introduce some weird relation 
ship between Weapon and Explosion class, but it looks good to me. At least 
at 3am. Let me know what you think about this idea.

OK, everyone should be on the list by now.

Charles, Dirt Ball looks good. I mean the code looks good, I didn't have 
time to actually rebuild it. 
PlasmaExplosion -- the compiler errors where there because this class was 
abandoned a long time ago. It was written by a guy who doesn't work on the 
project any more and plasma explosions caused some weird behaviour. 
There is a REFACTOR comment DirtBall.java, what do you mean by that? 

Anyways, there is one real issue with your files. DOS style EOLs. 
Traditionally we keep all the sources with Unix-style EOLs. Changing that 
would cause trouble because diffs just shows that files are completely 
different. Please make sure that you convert all files to Unix style EOLs
before checking them in. Speaking of checking in, I added you to the 
project so you should be able to check your changes yourself. Welcome!

Please send an e-mail to this list each time you check anything in. Alex, 
you too please, even if it's in the server. Of course I'll do the same.

If you want to do Liquid dirt, you will need to do some refactoring, 
like abstract out liquid stuff from NapalmExplosion. This might be 
slightly tricky, I don't know this code, its Alex's. 

On Thu, 6 Jun 2002, Charles McCann wrote:

> Done.  DirtBall is here.  Let me know what you think.
> I fixed PlasmaExplosion so that it won't throw a ton of compiler errors and warnings. 
> 
> Also, let me know if you add the changes into CVS.
> 
> Liquid Dirt next?
> 
> --- Mikhail Kruk <me...@cs...> wrote:
> > I have no idea. I havn't run server with 1.1.8 for a long time, something 
> > might not work with it. We usually run server with 1.3.1
> > It doesn't use any features beyond 1.1 though, because sometimes we run it 
> > in Kaffe and it works fine in it. 
> > Most likely 1.1.8 would have worked if you closed the interactive shell...
> > 
> > > I am running the server with 1.3 and appletviewer with 1.1.8.  
> > > Hopefully, you can fill me in on
> > > the subtilties of why this is so... or what I am missing. :)
> > > 
> > > Now, I'm off to look at this weapon class.
> > > 
> > > Thanks.
> > > 
> > > __________________________________________________
> > > Do You Yahoo!?
> > > Yahoo! - Official partner of 2002 FIFA World Cup
> > > http://fifaworldcup.yahoo.com
> > > 
> > 
> 
> 
> __________________________________________________
> Do You Yahoo!?
> Yahoo! - Official partner of 2002 FIFA World Cup
> http://fifaworldcup.yahoo.com