Messages

2236

Bugs and fixes / Big Bot Body Shot Overflow

« on: March 17, 2006, 10:10:37 AM »

2.4A.  Haven't checked if it is in 2.37.6.

2237

DNA - General / Venom impact on .fixed

« on: March 16, 2006, 06:33:00 PM »

yea, I kind of figurred that, thus my question.

I like symetry.  I'm not saying change it, but when one thing doesn't work the way all the other things do...

Probably should have posted in the Suggestions forum.

2238

DNA - General / Venom impact on .fixed

« on: March 16, 2006, 06:21:02 PM »

Understand its by design.  My question is why it is the way it is.  Is there some reason it was purposfully designed this way?

2239

DNA - General / Venom impact on .fixed

« on: March 16, 2006, 05:43:41 PM »

.fixed and .fixpos are treated differently than other sysvars today with respect to venom.  For example, if you use venom to overwrite another bots' .myeye, that bot will be confused about how many .eye statements are in their DNA for a period of time dependent upon how much venom was used.  The period of influence is obtainable via .paralyzed and once .paralyzed gets to 0, the effect of the venom wears off and the venomized bot returns to normal.  That is, referencing *.myeye will agian return the correct value.  This happens without the effected bot having to have any anti-venom specific code in its DNA.

It doesn't work this way for .fixed / .fixpos as far as I can tell.  Becuase of the asymetry in .fixpos and .fixed (one is kind of control only, one is kind of read only) when a bot gets fixed due to venom, they will be fixed forever more even after the venom wears off unless their DNA contains explicit instructions to do something about it.

Is this the correct behaviour?

2240

Bugs and fixes / Sysvar Documentation bug

« on: March 16, 2006, 05:04:29 PM »

1) .paralyzed is not listed in the Sysvar Table in the Wiki.

2) If you navigate to the ..paralyzed entry via the .poisioned entry, it incorrectly states that .paralyzed will have value 1 when the bot is under the influence of venom.  In actuality, .paralyzed will be a positive number indicating the number of cycles remaining before the venom wears off.

-E

2241

Newbie / Memory shots

« on: March 16, 2006, 02:36:15 PM »

Elite Said:

Code: [Select]

cond
*.robage 0 =
start
*.paralyzed .memloc store
stop
Shouldn't it actually be:

Code: [Select]

cond
*.robage 0 =
start
.paralyzed .memloc store
stop
?

-E

2242

Bugs and fixes / Big Bot Body Shot Overflow

« on: March 16, 2006, 02:13:34 PM »

Got an overflow at line 97 of Shots.bas in newshot() when a bot with a really huge body shot a -6 shot.   Shots(a).value is defined as an Integer and is being assigned a value exceeding 2^15 in the varible 'val' which is a Long.  Curiously, there was a check for val>32000 lower down in the routine.  Moving in up to check before the assignment should take care of it (I havn't fully tested this - the bug is hard to repro, but so far so good).

New Shots_Module.bas is attached.

-E

2243

Bug reports / Unassigned variable when using InstaWin

« on: March 16, 2006, 10:49:16 AM »

Those be the lines.  In VB 6, the line and column numbers of where the cursor is located are displayed to the right of the standard toolbar.

And she swore she was over 18...  Perhaps I should have said it reminds me of my current marriage.  Oh, hey, did I type that outloud?

2244

Bugs and fixes / Gene Activations in 2.4A

« on: March 16, 2006, 01:43:33 AM »

Well, I managed to make the Genes Activations display work in 2.4A.  The fix is a little involved given the architectural changes between 2.36 and 2.4 with respect to the changes in how DNA is is handled (its amazing what your can learn from poking around in the source).  :blink:

Anyway, I created a new global arrray of booleans which I ReDim and populate in ExecuteDNA() only for the bot with the focus if there is one, then pass this to a slightly modified exchhighlight() which hanldes the gene activation display as before.  I touched Robots.bas, DNA.bas and Module1.bas.

A little involved to post the code snippets in the forum as text, but I've attached the *.bas modules to this post.  I think those three are the only places where I made changes.  You should be able to download them, replace your own in a 2.4A soruce directory and build an exe that works.  Let me know if you have problems, I may have missed a file.  To find my changes in the soruce, simply search for the string 'EricL'.

2245

Bug reports / Unassigned variable when using InstaWin

« on: March 16, 2006, 12:30:06 AM »

Reminds me of an old girlfriend...   :D

2246

Bugs and fixes / Day/night cycle still not satisfying

« on: March 15, 2006, 07:58:09 PM »

Okay, I found this I think.   SimOpts.Daytime is getting set to False when TmpOpts is assigned to SimOpts at the bottom of MDIForm_Load() (line 499 of MDIForm.frm).  Adding the following line right before the assignment (line 499)seems to result in the correct behaviour both for the UI and for veggies.

Code: [Select]

TmpOpts.Daytime = True ' EricL March 15, 2006

2247

Bug reports / Unassigned variable when using InstaWin

« on: March 15, 2006, 06:38:10 PM »

Okay.  I traced Griz's DNALen out of range bug to the function League_Eyefudge in F1Mode.bas.  It adds a fake gene to the end of a bot in F1 mode so that the combatents don't have the same number of .eye statements.  

It's a huge hack (which the author well knew given the comments in the code and the name of the routine -  IMHO, bots should have and use GUIDs for species identification in the future) but the routine as it is is inadvertedly overwriting the end of the DNA and thus removing the tipo = 10, value = 1 at the end of the DNA casuing the run off in DNALen().

Changing lines 538 adn 539 in F1Mode.bas from

Code: [Select]

rob(robotnumber).DNA(t).tipo = 4
rob(robotnumber).DNA(t).value = 4
to the following:

Code: [Select]

rob(robotnumber).DNA(t).tipo = 10
rob(robotnumber).DNA(t).value = 1
fixes that specific issue.  The DNA will now be terminated correctly and DNALen will work properly without walking off the end of the DNA array.

To be sure, there are still a bunch of issues with leagues, but this fixes Griz's crash.

2248

Bug reports / Unassigned variable when using InstaWin

« on: March 15, 2006, 03:21:58 PM »

The function that loads the robots (RobScriptLoad) calls DnaLen to set the length in the rob array when the league table is loaded/created.

I think the bug has to do with reuse of rob array elements.  Working on it...

2249

Bug reports / Unassigned variable when using InstaWin

« on: March 14, 2006, 11:38:52 PM »

In answer to Griz's specific question about running leagues, well, to be honest, I'm not really sure.  I barely understand what a league is!  I'm still a real Newbie, one who can code (can you say 'dangerous'?) but still really quite the DB newbie.  

What I can do is load a sim with a couple of bots and check the F1 checkbox on the 'Restart and League' page and I get the Contest Results dialog with dynamic population counters.  Very useful that, league or no league.  With my little crahs fix, I can press the Istawin button and not crash.  It seems to play a number of rounds though there are still some quirks.  Sometimes Instawin kills the loosing bots but doesn't start another round for example.  But in particular, I have not played around with (nor do I fully understand yet) the other setttings on the page, including the Challenge league stuff.  Will do tomorrow.

2250

Bug reports / Unassigned variable when using InstaWin

« on: March 14, 2006, 11:29:41 PM »

Nums, I'd say you should stay focused on the C++ version.  I'm just filing bugs on 2.4A as I find them mostly because I can I guess, just to have a record of them to make sure they get picked up in the C++ fork (yea, I know.  I expect the value of 2.4A bug reports is marginal for the C++ fork given the magnitude of the re-write but what the hey...).  I'm not on a mission to make anything specific (like leagues) work in 2.4 - just fixing crashing bugs at this stage - though if there is high demand to make a specific feature work in 2.4 that used to work in previous versions, I could probably be of some use there.  

I have a pretty fast machine, so it's pretty easy for me to run things in VB all the time and identify/investigate/fix simple things as/when I hit them.   I don't really have to know the code that well to fix simple overflows and such, not in depth and those who do know it like yourself are IMHO better utilized working on the new architecture and the port.   I certainly don't expect any more 'official' work on the VB fork given the focus on C++ and I'd be happy to share my private VB exe with anyone who can't build the post 2.4A cumulative fixes themselves.  I'd also be happy to spend a little bit of time (ephansis on 'little') making specific functionality work in 2.4A if someone really needs something (I really miss the gene activation form for debuigging bots and may spend some time on that this week) but at some point in the not too distant future, I plan to volunteer to help on the C++ version so I don't want to do too much down level....

So, I do think we want to track 2.4A bugs, expecially crashing bugs, but that doesn't mean you or anyone else has to fix them much less make specific features work.  My vote is to keep the big guns full speed ahead on the C++ port.

If someone is dying for something specific to work in 2.4A, let me know and I can spend some time on it, letting Nums work on the real deal.

-E