Posts for qFox

1 2
16 17 18
24 25
Experienced Forum User
Joined: 4/25/2004
Posts: 615
Location: The Netherlands
I dont remember getting those errors. Are you sure you've got the entire thing and running the right make (and I dont have a clue about that stuff either ;) ? The make wasnt a real problem for me. Getting there was the harder part, especially not knowing SDL wasnt required in windows and trying to install it anyways... sigh.
qfox.nl
Experienced Forum User
Joined: 4/25/2004
Posts: 615
Location: The Netherlands
sorry, my bad.
qfox.nl
Experienced Forum User
Joined: 4/25/2004
Posts: 615
Location: The Netherlands
That's the whole point of pruning really (without preprocessing). It would be easier to have 1800 save-states and use a recursive tree climbing algorithm, pruning all the brances once a sollution/bad result has been determined. This will prohibit the code from computing a lot of duplicate inputs.
qfox.nl
Experienced Forum User
Joined: 4/25/2004
Posts: 615
Location: The Netherlands
... I just POSTED the source, HELLOHO. So hush. If Bisqwit is still hosting this site on his own line then I can surely understand he's not willing to be a download source for anyone. He'll probably generate enough traffic the way it is already. The source I posted was the original last source released by Luke, including the missing files, provided by nitsuja. They compiled on windows, if you follow those directions (skip the SDL part in windows though). Can't say much for linux, but it probably should compile as well.
qfox.nl
Experienced Forum User
Joined: 4/25/2004
Posts: 615
Location: The Netherlands
Nice head-math there Bis ;) My two cents (or so). I won't repeat earlier comments about it all so just my approach to it, if I were to tackle it... Design a path, obviously this by itself is a great challange. But this itself could already be computed! Put the entire zelda map into memory, somehow mark the areas you need to visit and the items you require for these areas. Compute the number of frames you need to move from one frame to another for all general ways (this can pose as a model for most rooms). Compute paths and take the one with the least frames. The next part requires some manual inputs because I don't think it's really feasible to build a bot that can do something like going to the inventory and switch to an item when you need it to. In other area's, there sometimes is just a straightforward fastest route (walking forward without hitting anything or turning or pausing anywhere to go from left to right is obviously as fast as possible) and no computation is required. I actually think this goes for most of the non-dungeon "mini-instants", as someone called it (I think this is a good term actually). The computation comes into play with the dungeon instants where you need to clear the room to move on. Here you can let the bot compute away, using the random approach to cover most of the "tree" (you don't really have to brute force things to find a local minimum you know) and perhaps looking a little bit closer at the best local minimum, if desired. In any case, for luck manipulative purposes, compute a room, remember the best x (5 or 10) results and move on. Compute the next room for each of the x remembered results, and remember the best y results (where x == y). Repeat for as long as you can. The problem may arise in money. Perhaps the gambling cave can help here (possibly brute forcing that part to manipulate luck since the number of paths are slim, buttons are pressed to influence luck and there's only one "highest" price. When the highest price is gotten you can continue, accepting the loss of frames, to manipulate luck, is acceptable here I think.) Alternatively you can accept the loss of frames to kill and take the loot but this complicates things highly, using the cave may be far more easy... Anyways, bla. The last real post was almost a year ago. The link Hoe posted is dead (looked interesting...). Was anyone having any progress in this project at all? Did anyone even try? What were the results?
qfox.nl
Experienced Forum User
Joined: 4/25/2004
Posts: 615
Location: The Netherlands
Link to source, as long as it lasts: Lukes 0.98.16, april 21, fceu source The missing rar file contains the make files and stuff, they were not included in the file Luke released (because they were probably not changed). Nitsuja sent them to me. Have fun
qfox.nl
Experienced Forum User
Joined: 4/25/2004
Posts: 615
Location: The Netherlands
What changes were lost? Luke's version is currently the last version, and also (I think) the version anger and baxter are working with (check whether it's the 21 april release and not the 19 april release, although i'm not sure what the changes are, the 21 april release is the last release he dropped). Anything changed to that project won't remove anything else. My basicbot modifcations are easily ported, and are currently no longer applicible to Luke's code anyways. I haven't seen other modifications to the last source, so...
qfox.nl
Experienced Forum User
Joined: 4/25/2004
Posts: 615
Location: The Netherlands
Hm after typing a nice and carefull response and pressing the wrong button, here's a less carefull response. Running at lower speed is about the same as holding the frame advance key at 100%. If the latter works, "holding a key" can not be the issue (would have been my first guess). You may just have to do the first, hold the frame advance key at 100% (apparantly, at least that works). I know I can't fix the issue, I don't know anything about those parts of the code. It is possible that it's an OS issue concerning the input of more programs at one time or something.
qfox.nl
Experienced Forum User
Joined: 4/25/2004
Posts: 615
Location: The Netherlands
Ok I've worked on it some more. In the process I had to move to VC8, because that seemed to be the only way to edit the GUI. As a result I had to work with the source of the SF project, since I could not get Luke's code working in VC8. The result is a unstable release with a pretty stable bot. I'm sorry about that. If you want to compile the stuff yourself you can download the sources from sourceforge. Linux users don't need to bother for the bot, I've been told the GUI is windowns only. I will try to create a crossplatform GUI in the future, but right now I simply don't know how. That said, here is the new binary for BasicBot 0.2.1 The emulator is rather shakey at the moment (for instance, dont turn off sound... ;). The bot seems to work pretty good though, so as long as you don't try anything odd with the emulator yourself, the bot should work fine. Changes are below. It'll be the last release for a couple of days at least. Don't know when I'll have the time to work on it again, but I will. As said before, this is _not_ an official release! It's meant to test the bot and get feedback, bugreports and perhaps wishes FOR THE BOT... --
Changelog 0.2.1:
Built binary is the work in progress at fceultra.sourceforge.net
No guarantuees are made that any of the other stuff actually works. In fact, I'm quite certain most of it doesn't.
This is not an official release! It's a test-release intended to test the Basic Bot part of the program, and only that.
You have been warned.

- Change - Commands  - ')' now also resets hexmode and negmode.
- Change - Source    - Updated the source to no longer supply arguments that I threw out the previous time.
- Change - Source    - Cleaned up comments, commented entire document.
- Change - Source    - Removed several redundant pieces of code.
- Change - Commands  - Removed ram().
- Change - Behaviour - Previously, the goal would be reached if the result of the "end when" line would be greater then a random number between 0 and 1000 (there was actually a chance for it to be impossible to reach its goal: when that random number was 1000). I don't see the added value of the random part, you either reach your goal or you dont. If I hear any protest this can be put back in easily.
- Fixed  - Commands  - "stop" now works.
- Fixed  - Errors    - All errors now stop future attempts (until the run button is pressed again).
- Change - Source    - Used defines for max frames, codelength and resultwindowsize. Now we can easily change these limits.
- Change - Source    - Changed several ints to bools, when they were used as such anyways.
- Change - Behaviour - Clears debug when starting.
- Change - Source    - The code lengths are currently set to 1k each. I've changed this to one variable (hardcoded), however this would mean paying attention to loading older files. Especially if we're to decreasing this size. Size will be increased in the future.
- Added  - Errors    - New error introduced: 1004. Thrown when the occurences of '(' is not the same as the number of ')', same for '?' and ':'. The characters () and :? always need to be pairs. The code does not explicitly check proper nesting (yet...), but I think that's done implicitly by parsing.
- Fixed  - Behaviour - Negative numbers work, prefix 'n' does too. Something like "n5+6 echo" shows 1, "n5 -1" shows -6. I forgot that C has signed numbers :D
- Added  - Commands  - Added memw(n), which reads two bytes from the memory: ((mem(n)<<8)+(mem(n+1))), memh(n) and meml(n) read half a byte (a nibble) (they (value&0xF0)>>8 and value&0x0F the values before returning). Note that the memh() will also return values 0-15. Is there anyone who thinks memi() for 32bit numbers is really usefull?
- Added  - Commands  - Added j and k. j returns the loopcounter of a nested loop, k returns teh loopcounter of a nested loop inside a nested loop.
- Change - Commands  - You can now nest loop() twice, so you can do: "5 loop(i loop(j loop(k echo)))". Any more loops will still result in 1002. To check: "rc(10) 5 loop(5 loop(5 loop(5 ac(10)))) c(10) echo" should be 625 (5x5x5x5).
- Change - Errors    - Error 1002 is now thrown when nesting loops 3+ deep.
- Added  - Commands  - Added value. Completely transparent, like a nop/noop (no-operation). Can be used to use in iif's (1?500:value). Note that "value echo" is the same as "echo", value doesn't change anything, just improves readability. It is accepted as number though (unlike echo).
- Change - GUI		 - Redesigned it a little bit. Still not quite the way I want it though.
- Added  - GUI		 - Refresh button. When the bot is running and you want to change parameters to see whether it improves, you can change the code in the GUI and press refresh. The bot will then refresh its internal code with the GUI.
- Added  - GUI		 - Botmode button. Toggles "external mode" on/off.
- Added  - GUI		 - Added some more information. It shows the score of the last attempt. There is a debug section and an error section. The averages for score and tie1-3 are shown next to them.
- Change - Source    - Had to change to vc8, because I know no other way to change the GUI. As a result I can no longer compile Luke's old code, but am stuck with the SF project files. They work, but may be even more buggy.
- Added  - Commands  - Added "lastbutton", or "lb" short, which returns the button pressed in the previous frame. This will not work for the last frame pressed before the save-state, so at the first frame, this value is always 0.
- Change - Behaviour - BB can now compute up to 2k frames (was 1k). I intend to enlarge this number greatly, but need to check out possible memory issues before I do.

Known issues:

- Player radiobutton is not selected on load. Has no effect on the code, player 1 is set by default.
- External input button starts with "toggle" instead of its state.
- External input button text will not be updated if the external input is toggled anywhere else (currently impossible, but hey).
- Check button is disabled because it's too much code now, and will be much easier to do later.
- Load behaves like update: when the code is running and you hit load, it will put these values to the memory and the GUI. This is a designflaw, but you'll have to live with it.
- Hexmode/Negmode issue remains the same, except for ')', as mentioned.
- Old botfiles, for whoever has them anyways, will load except for the extra2 field. You'll need to paste this into the one field.
- All fields still max out at about 1k, will be enlarged in a future release.
- Code does not check for the presence of an argument for functions. If no argument is present, it will take the value 0.
qfox.nl
Experienced Forum User
Joined: 4/25/2004
Posts: 615
Location: The Netherlands
Maybe. But it has to be said that chess isn't a big game. Sure, we perceive it as "endless possibilities", but in the end it's nothing compared to games like GO, for which there is not enough time and space to brute force solve it.
qfox.nl
Experienced Forum User
Joined: 4/25/2004
Posts: 615
Location: The Netherlands
And that EXACTLY what basic bot does and is going to do. It already can do the button stuff, press or not press buttons or whatever. It is going to be able to compute a part (x frames) so many times, take the best result, then move ahead x/2 frames and start over. That's the main idea at least, and I think it will perform rather well, asuming you've coded your bot correctly :)
qfox.nl
Experienced Forum User
Joined: 4/25/2004
Posts: 615
Location: The Netherlands
Ok, maybe I was wrong in terms of planning the route... :)
qfox.nl
Experienced Forum User
Joined: 4/25/2004
Posts: 615
Location: The Netherlands
It might not be a bad idea to let a bot try and optimize some room fights... Rooms are kind of small, and making the wrong decisions gets you killed fast (means the end of an attempt) so I think something could spring from this... Just a thought. If someone will give me the rom addresses for dying, weapon A and B, position and possibly some worldview, I can probably whip something up in terms of a botfile. Zelda may be one of the most spoken subjects here so this data is bound to be checked out by several people :)
qfox.nl
Experienced Forum User
Joined: 4/25/2004
Posts: 615
Location: The Netherlands
I doubt a death will be allowed for this game. The resets are kinda annoying, but having never played teh game I don't know how long those cutscenes last. Run doesn't seem very attractive to people who never played it. Don't get me wrong here, but there's not a whole lot of room for improvement in matters of speed if you never fight (are you ever forced to?) and take the optimal route (is the route static, like, do you have to pick up the items in order etc?). Anyways, any game deserves a speedrun, so go for it. But please, no dying :)
qfox.nl
Experienced Forum User
Joined: 4/25/2004
Posts: 615
Location: The Netherlands
Hm, seems I've missed this topic. I just released a new version that improves the Basic Bot code by Luke for FCEU. Just for the record; even though writing a universal bot for any game is not a task to be taken lightly, I think the Basic Bot design shows it's not infeasible. Jus for another record; it is indeed impossible to try every possible route for a game from beginning to end. Even on the NES with "only" 8 buttons, the number of possibles are extremely high. No computer can currently compute that, I wonder if ever. That said, these bots are not entirely useless in this field. Bots will try anything you wouldn't. Sometimes making a stupid move is faster. Also, there are several machine learning algo's you might wanna take a look at. I've got a lot planned for FCEU. As for a standalone application, can't help you much there. Faking keyboard input sounds like the best shot to me since memory addresses can change with every update. You can also design a general principle and implement it in the popular opensource emulators yourself. This task should not be too hard, once decided on the principles. As for FCEU, I'm planning on expanding the current "scripting language" (that's what it is really). I want the parser to turn the code into bytecode, to be fed to a interpreter. This should increase performance greatly (as it's currently just parsing the string over and over again ==== slow!) When that's done I plan on implementing some basic machine learning algo's. Clustering, evolutionary algo's, pathfinding algo's, stuff like that. The main idea I have right now is to let the bot try for x frames, x times. Each time advancing x/2 ahead. This will cause to get a quick optimization for short area's combined. Another thing I want to try is to have it a range of values for some variable. Try x times, and pick out the value that scored best. Then keep trying this number and repeat the idea on another variable. This way you should be able to get a local peak rather fast. Combine the both two methods and I think you can relatively easy get a run computed. Note that this does mean you need to know what certain rom addresses are. Keep in mind that for the bot, you're just messing around with numbers.
qfox.nl
Experienced Forum User
Joined: 4/25/2004
Posts: 615
Location: The Netherlands
Ah so that's how. I was wondering how they'd record that. I've been searching for some kind of interface (how do they do it on television shows?) for the DS to a computer, but none seem available. A proper DS emu is a matter of time. It will be hard to play normal with a mouse and a keyboard though... And I'll be you'll see them coming with pen support :) I have a feeling it's still gonna take quite some time before some steady recording emu's will be available though.
qfox.nl
Experienced Forum User
Joined: 4/25/2004
Posts: 615
Location: The Netherlands
Oki... I've been working on Basic Bot and increased robustness of the parser. The binary can be found here. Except for the about window, the ONLY change was made to the Basic Bot code. I can't fix bugs, I can't add stuff. Heck, I can't even modify the BB dialog right now :( Anyways, a changelog was included. I have a lot of plans for the Basic Bot, but probably won't have much time the coming days. When I have something new, I'll post it. The source code (basicbot.c and basicbot.h) will be uploaded to the SF fceu project, as soon as the main guy comes back online etc, so you can check it in the repository later. Anyways, please feel free to test the current code. All commands stayed in, includes some changes (read changelog). Mainly fixed some huge bugs in parsing. The about window tries to make clear that it's not a new version except for BB. PS. Not only did I not fix/add anything else, I didn't even look at the other code. It's simply the last sourcecode Luke released, with a modified BB. Somehow I did not need the SDL libs to compile it (is that a Linux thing?).
qfox.nl
Experienced Forum User
Joined: 4/25/2004
Posts: 615
Location: The Netherlands
I got it to work, with some more from nitsuja. For other people who like me have little knowledge about the compiling part, make files, and all that but who want to give the source a try in Windows: Install the MinGW (I used MinGW-3.1.0-1.exe). Install the msys (I used MSYS-1.0.10.exe). Tell the post-installer of msys where you installed MinGW, seems to be case-insensitive. Skip the SDL part (is this only required for Linux perhaps?) Install zlib (in msys, follow the tutorial) (I used zlib-1.2.3.tar.tar). Download Luke's last source (21 april 2006). This release is not complete as it's missing the make files and a bunch of other files I know little about, so you need an older source-package to fill this up (Luke didn't touch these files so that's probably why he didn't include them). Go to the root of the directory with those older files, it should contain a directory "src" with Luke's source files. Run: "windres -o src/res.o src/drivers/win/res.res" Run: "make" The exe will appear in the src dir. You can verify the operation worked properly by running the exe and looking at the date in the about box. Should be only a few seconds ago ;) And that should be it. Thanks a lot, now I can start debugging a little :)
qfox.nl
Experienced Forum User
Joined: 4/25/2004
Posts: 615
Location: The Netherlands
Yep, there are definately some leaks and limitations that need to be addressed.
qfox.nl
Experienced Forum User
Joined: 4/25/2004
Posts: 615
Location: The Netherlands
Hm can anyone please confirm that the last source is actually complete? It seems to be missing a few definitions, but that could entirely be my problem. I've not yet got it running, but I downloaded dev-cpp as that seemed to be "the" IDE to go with right now. It at least includes packages for mingw and zlib. I can't seem to just import the entire directory structure of the source though. Maybe I'm not looking good. But anyways, some of the variable names don't show up in any of the files (like BotInput[] in BasicBot) so that's why I'm wondering whether it's complete :) Damnit, I want to compile it :/
qfox.nl
Experienced Forum User
Joined: 4/25/2004
Posts: 615
Location: The Netherlands
Ok, here's where the outdation might kick in. What do you do after this? Because the only file available on the website now is SDL-devel-1.2.11-mingw32.tar.gz (and not .9). Is it possible something changed slightly? I tried putting it in home btw, no luck either. What exactly do you execute once in the SDL directory? The files in the root of that dir for the .11 release are: [.] [..] [bin] BUGS [build-scripts] COPYING [docs] docs.html [include] INSTALL [lib] Makefile README README-SDL.txt [share] [test] WhatsNew Other then that, I've followed the tuorial to the letter :/
qfox.nl
Experienced Forum User
Joined: 4/25/2004
Posts: 615
Location: The Netherlands
Ok I've been messing around with the Basic Bot (fceu 0.98.16) and came up with the following rom information (all hex):
0024 - 0025 = input flags?
002E = horizontal position (proving the game is 255 units or positions wide)
0035 = direction. 00 = forward. FF = backward
005D = how high up in the air... offsets at 0 when on the ground, moves up/down by 2. you can fire when this value <= 2 going or staying down. once jumping, you have one frame to fire.
0065 = airborne (0=no, 1=yes)
007c = 0A means uncontrollable...
0083 = some kind of count down when fired, doesnt seem to impact gameplay... start at 28 every shot
0092 = new life state: 0 = starting game (reset) / nothing (just alive), 224 = gameover, 128 = unmoveable (like coming onscreen new game) until 0, 112 = dying until 128
00A8 = some kind of forward position
00C0 = see 00A8
00D0 = distance of current shot. you can not fire when this is >0, and it reaches 0 before the last shot leaves the visual range. gets reset immediately when hitting an enemy.
00D9 = something about height as well, but offsets at 181 when on the ground and decreases as you go up. there are more addresses like this one in the 02xx range
00E0 = number of lifes
0603 - 0608 = (value-0x30) is score, xxxxxx, where 100's = 0606, 1000's = 0604 etc. when the counter ticks at 999900, 0607's lowbyte turns to 9 as well (only time ever). after that no increments are possible. game doesn't use the 0608 lowbyte, but you can set them all to 9 to get the game to show 999999 as score :) what the 0x30 represents I can't tell.
06C0 - 070F = indicates land, where "you" seem to be on 070D E or F and 06C0 is at the horizon. only lowbytes are used, E means land, 4 means gap.
For some testing, I've come up with the following code. The code is ok, you have to remember that the optimization factor in this game is rather high (although I don't know how high relative to other games...). This means that there are far more possible ways of doing things then you can test. The only code that doesn't seem to work is not shooting while in the air. I'll fix it later, it's not very important (but my second tie is the negative number of times b-button was pressed).
// dont shoot while in the air or when your-shot-counter is not 0
// rc(5) (mem(x00D0) = 0) ? 500 setcounter(5) : 0 (mem(x005D) > 2) ? 0 setcounter(5) : 0 c(5)
rc(5) 
(mem(x00D0) = 0) ? 500 setcounter(5) : 0
(mem(x005D) > 2) ? 0 setcounter(5) : 0
c(5)

// jump when approaching a gap
(mem(x06FC)=20) ? 1000 : 0

// if left last time, high chance of left this time
// 300 setcounter(3) c(1) ? 800 setcounter(3) : 0 c(2) ? 0 setcounter(3) : 0 c(3)
300 setcounter(3) 
c(1) ? 800 setcounter(3) : 0
c(2) ? 0 setcounter(3) : 0 
c(3)
// same for right, except if left was pressed _this_ frame, right is also not pressed.
// 300 setcounter(3) c(2) ? 800 setcounter(3) : 0 c(1) ? 0 setcounter(3) : 0 left button ? 0 setcounter(3) : 0 c(3)
300 setcounter(3) 
c(2) ? 800 setcounter(3) : 0
c(1) ? 0 setcounter(3) : 0
left button ? 0 setcounter(3) : 0
c(3)
// needs this extra code
// rc(1) rc(2) (0 < left button) ? 1 ac(1) : 0 (0 < right button) ? 1 ac(2) : 0
rc(1) rc(2)
(0 < left button) ? 1 ac(1) : 0
(0 < right button) ? 1 ac(2) : 0

//for the above, we want to range the number from 750 to 950
//this alternates between 750 800 850 900 and 950 every 5 frames.
750 + ((attempt % 5) * 50)
//700 800 900
700 + ((attempt % 3) * 100)

// count number of times b was pressed
((bbutton>0) ? 1 ac(0) : 0)

// score
(ram(x0606)-x30)+
((ram(x0605)-x30)*10)+
((ram(x0604)-x30)*100)+
((ram(x0603)-x30)*1000)

// dying
(mem(x0092) != 0)
In case you haven't noticed, the line of code "commented" is what you can copy/paste into the input boxes. For your lazy convience here's the botfile :) It stops an attempt when dead or after 300 frames (play with it yourself). It maxes the score, breaks ties depending on how many frames long this attempt is, second tie depends on number of times b-button was pressed (fewer=better). Third tie is my debug-echo, currently shows what probability the left/right buttons get when pressed previously. Let this run AFTER you get the gun. It can not yet jump large gaps, I have yet to determine when it's safe to release A, as this doesn't seem to be as static as the moment you need to press it. I'm having trouble figuring out the collision detection system. I think there are a few ranges dedicated to this, but the numbers are so jumpy that it's not so easy to figure out as the stuff above. If anyone wants to lend me a hand here... Note that due to the implementation of this bot, the more code you have, the slower the thing gets. I intend to improve this myself (going to parse the input once and convert it to bytecode, which should show dramatic increase in performance...). Also, you can't turn off visuals, but the program runs faster if you minimize the main window.
qfox.nl
Post subject: Compiling FCEU on windows
Experienced Forum User
Joined: 4/25/2004
Posts: 615
Location: The Netherlands
Ok, I've followed the steps listed here but I think they are a little outdated. I've downloaded everything, the MinGW binary isn't available for the current version, but I downloaded the previous version (MinGW-3.1.0-1.exe). I also got all the other files. Installing mingw and mysys was no problem. Make-ing the SDL libs is though. When I try "make install-sdl prefix=/mingw" I get the error "make: *** No rule to make target 'install-sdl'. Stop." and I'm at a loss now. I don't know how to fix these "make"-problems. Also, "./configure" doesn't work, shouldn't that at least work? He can't find it at all right now... Thanks in advance.
qfox.nl
Experienced Forum User
Joined: 4/25/2004
Posts: 615
Location: The Netherlands
You are right, it's unlikely that it'll be ok the first time. I've ran through the evaluate code. C has been far too long ago for me and I don't know the rules about pointers and strings anymore, so I decided not to mess with them at all. I do believe I fixed a bug or two. I changed a designflaw, you should now be safely able to nest iif's, and anything else (except for loop(), that is another matter). Luke's code does not handle iif's properly, as far as I can see. I've added three commands: sc: which is short for setcounter, uses the same code echo: which should echo the current value to the textarea on the right, but probably won't yet since I've never done GUI stuff in C and I worked in a text-editor, so I don't get the errors the compiler would fish out. stop: should do the same as pressing stop, but again, probably wont. I added a quick error message so you now know when you made a syntactical error (finding out what and where is your job, for now). From now on, you can only use spaces, any character it does not know or expect is considered an error. I changed a few variable names and commented all over the place (all my comments are prefixed with my name). I did not change anything below the evaluate function. When an error occurs, unpredictable results can happen. The "there is an error, cleanup!" code is not there yet. Other then that... I think the code should work fine. Nitsuja could you help me by pointing me to a nice small C IDE for windows that shows syntactical errors out for me? Perhaps even with code-completion so I can mess about with the GUI stuff as well. I'm just a Java coder... basicbot.c (zip) pastebin
qfox.nl
Experienced Forum User
Joined: 4/25/2004
Posts: 615
Location: The Netherlands
Great! Unfortunately my last post made little sense with the actual code. It seemed that the parser still has certain limitations, like not being able to bracket if?then:else properly (return value will be something... but not what you'd expect). Fortunately, it's only the evaluate function that needs to be re-written. Like he comments himself "//horribly hacky, not meant to be a real expression evaluator!". Maybe I'll put some work on this over the weekend. But I'll need somebody else to compile the thing for me... Any takers?
qfox.nl
1 2
16 17 18
24 25