Notable Improvement Possibilities

[Prsn828]

I finally have VB6 running on vista (somehow).

I looked at the code and these immediately came to mind:

-Smiley mode is 100% broken, and should be removed

-Translocation and amplification mutations exist, but must be fixed before being usable

-Point mutations should be redone so that the result is more random (no casting from number to type and back that would result in lower end values)

-Only nine ties may exist at once, and one of the sections of code for the ties has an incorrect value (might be hard to find again, but there is definitely one in there, I think on tie 3)

-Some of the sysvars don't do anything, while others I think do stuff but are hidden from the user (Not 100% sure about this one)

I know very little VB, so I can't imagine fixing these properly myself, however, I may give it a try.

For those wondering, I am referring to the 2.44.1 code on the repository.

[Moonfisher]

You're going to run into more trouble, the last version that EricL submitted couldn't run leagues propperly and I think it also had IM issues...
I think the best version is 2.43.1L, but Eric never uploaded the source for that version and it's hard to tell which revision it's at...
And yes the sysvars have some issues too... probably related to the poor (Or rather non existant) structure of DB2, I've seen different sysvars get defined to different key values in different areas of the code.
You'll also find that some entire modules do nothing at all, it's just legacy from something someone was trying at some point and never finished, or stuff like that.
DB2 source is NOT easy to work with, and with Eric gone there's noone doing it (And noone willing to take over), so I think if you can fix some of the DB2 issues you'll be very popular
Personaly looking more forward to DB3, and I think I'll join in and help with that at some point... but not right now... kind of in a strange limbo like state these days... got some stuff going on.

[Testlund]

I think you nailed it what the problems are here, with your understanding of the code better than me. I'm still in the testing process, running version 2.43t right now which appear better than later versions, but there's definitely something wrong with mutations and ties.

[Prsn828]

Well, if I just got the compiler running yesterday, and I already have a deeper understanding of the source, then I guess it leaves me with no choice other than to fix it my self.

What I plan to do is take all of Eric's crazy constants that were hard-coded, and replace them with global constants (Once I know how to do that in VB).

Also, I might remove several of the less useful and less functional features, and if necessary redo them from scratch.

Don't expect anything too soon (Certainly not today ), I don't even know how to write VB properly yet (but by the end of the week you can be sure I will be above the level of amateur VB programmer; that's just how I am )

Any disagreements should be stated now, so I don't get too much done before you state your worries (Although I will get started right away).

[Moonfisher]

The current source can access any data from any location, there's no real structure or relations between objects and classes.
Mostly you'll probably want to work from the main loop, wich I think is found in HDRoutines, so you can see when the different modules are put to use.
But you still can't see what's realy going on from there, so to get the full picture you'll probably have to do a lot of digging.
Also rob is short for robot, this actualy threw me off when I was messing with the code  Theres an array with all the robots, and a robot object contains a very large amount of poorly structured data for the robot, helps to take a look at that (This part actualy has some rpopper comments explaining which is what, so it clears up a few things, and raises more questions ;P )
And if you come across an attempt to implement a linked list of robots in there, turns out it's legacy and is never used. (Spendt some time staring at that too)

Other than that good luck, with the lacking structure I recommend using searches to track the vars you need to follow and such...
And ofcourse if you feel like you have WAY too much spare time, then restructuring (Or rather, structuring) DB2 completely would make it a lot easier to work with

Oh and one thing about VB6, it's syntax is pretty straight forward in most cases, but it has some ugly syntax aswell IMO.
No brackets, you end an if with EndIf, you end a for with EndFor, and for some unexplainable reason they felt like breaking their own standard and chose to end a while with WEnd...
Also if you get tired of getting a popup when leaving a line with an error in it then you can actualy disable this, can't remember the name of the feature you need to disable, it's one of those precompiling things.
Also when making changes while your code is running remember that you risk not having initialized vars correctly and that errors you got during your first loop could affect the following ones.
So if your code behaves oddly I definately recommend rebuilding. The whole dynamic interpretter or whatever they call it is a cool feature, but it can also be very unreliable in some cases.

So IMO you got your hands full, VB6 isn't too hard to pick up, but the syntax isn't exactly easy on the eyes, and DB2 has no real structure or dokumentation, so you have a sort of programmers archeology task ahead of you
And thanks for actualy bothering with DB2  I thought everyone had given up by now...

[Numsgil]

My suggestion would be threefold:

1.  Remove any unnecessary files/code bits/widgets.  There's a lot of it from, as was mentioned before, started then abandoned ideas.
2.  You're going to cringe at me saying this, but unit testing would go a long way here.  I have no idea how to set it up for VB, but that was always a lot of the issue: we'd play with code and break things without realizing.
3.  Go through the bug list and try and fix as many as possible.

[jknilinux]

Any disagreements should be stated now, so I don't get too much done before you state your worries (Although I will get started right away).

Thank you very much prsn828; we greatly appreciate your help with debugging. I don't mean to give you more work than you can manage, as I'm already thrilled that DB2 isn't dead, but here's a suggestion:

Could we make the DBcode self-modifying in real-time? I don't know how hard it would be to implement, but I suspect not too difficult, and I believe it'll add a whole new dimension to evolution simulations. Also, according to wikipedia:

In the early days of computers, self-modifying code was often used in order to reduce the usage of limited memory or improve performance or both.

Perhaps, by using self-modifying code, we could make less resource-intensive bots with more advanced behaviors?

Just a thought. Either way, good luck prsn!

[Moonfisher]

I definately love the idea of introducing self modifying code... and from what I've seen I don't think there would actualy be any big technical issues with that.
It would definately allow more interesting evolution I think, and it would also make viruses and cameleons more interesting.
I'm not so sure we'll be able to save resources this way, but it would definately make things more interesting. Was looking at core wars (Never realy got into it, my attention span is extremely limited lately), and there you'll usualy want to constantly modify your code in order to survive. That was probably one of the things that got me interested (That and the use of assembler syntax).

[Prsn828]

Self modifying code should be easy.

Just for clarity though, is self referring to the bot or to the user?  Either way, it can be done quite easily, in fact, I could trick the program into thinking it is a kind of mutation, even allowing it to be tracked

The first thing I am looking at is the ties; I want to make a global variable to determine how many ties a bot may have, rather than the currently hardcoded 9's and 10's (Yes Numsgil, that is right, you can only have up to 10 ties, although we both thought otherwise before :/ )

One problem though; when I ramped the number to 100 there was a small but noticable decrease in simulation speed.  I don't know what to do about this, so I am going to keep it at 10 but use the global variable I made to do that.

Also, there are broken sysvars that will be fixed by the time I am done, so expect DNA to act more like it should.

I also want to fix point mutations so that numbers are random, not normalized and modular.  It should be easy, but as far as I can see, it isn't for some reason.


EDIT:

I am going to look into fixing vision, since some things seem to be invisible when they shouldn't be.

[abyaly]

On the issue of invisibility. I hope you're not going off of the eye diagram that shows up for the selected bot, since that is not accurate.