Messages

People. I had another copy of Stunts 1.1 in the past that didn't do this, but the one I'm using now, I'm pretty sure I downloaded from here, so maybe you can give me a hint. The thing is that, whenever I enter the game, it's always set up to not show any scenery. I can disable it, but my settings are not saved, so if I exit and reenter, I need to change the setting once more. Any way around that?

Hey, guys!  Nice to see you all again here!!
Maybe you don't even remember by now. I was wondering if any of the currently running competitions is a OWOOT, to give it a try. In my times, I used to play on WSC. Not that I haven't been to the forum since, but almost...

Gracias. Ya veré el próximo mes de enviar un mejor tiempo

Sí... y las teclas son más chicas y delicadas... ja, ja....
Creo que para el próximo mes, pasaré las cosas de Stunts a la compu de escritorio... aunque después tenga que estar transfiriendo archivos... pero juego mejor.

Acá ando, aunque ahora jugando desde la compu portátil no es igual de cómodo. ¿Cómo están?

Bueno... he vuelto, por lo menos, por el momento.. y ya mandé mi primer tiempito

Thank you... I'm installing RSSI.... I'll try to figure out how it works. I once used IRC through a web-based interface, but I don't remember where it was.

I've been researching the memory structure of Stunts as it loads and I found the following data. Many of this, you probably have already figured out, but other stuff might be useful:

- Stunts has HDR, DIF and COD files for MCGA, TDY (Tandy) and CGA, but the DIF file is replaced by a CMN file for EGA. All COD files for some reason are about 64K long (though never exactly), DIF files are about 16K and the CMN file is about 128K. This cannot be just a coincidence!  HDR files are unmistakenly EXE headers. They are 30 bytes long, but nevertheless correspond to EXE files whose code starts at byte 512. The space in between does not contain any code update, though. COD, DIF and CMN files are slightly compressed with a procedure that looks like a very basic kind of Huffman. This is exactly the same procedure used for 3D shapes compression, so it is already known, as cars are already being edited!!  The actual sizes of decompressed codes are specified at the second byte of these files and do not match with the size estimate contained in the headers, which is much bigger.
- STUNTS_K.EXE, the crack, is lightly encrypted. The encryption system can easily be removed with UNP. The unpacker will ask for a passcode. First thing I thought worked: it's just "stunts_k". The resulting file is smaller than the encrypted one.
- STUNTS_K.EXE is loaded, keeping its environment MCB and code MCB. On top of it, STUNTS.COM runs, which also preserves its environment, reads the configuration file and loads LOAD.EXE into memory half-manually, apparently upgrading the code depending on the graphics card selected. LOAD.EXE runs. Environment is preserved again. LOAD.EXE reserves a lot of heap and no dynamic memory is allocated for variables. Only one extra MCB is allocated, but it is used to store only the sound driver, which starts at byte zero. If no sound card is selected, PC-Speaker driver is loaded anyway, but is not used. This last MCB takes up all the rest of the available conventional memory, even though it is not necessary.
- I have verified that the data contained in MCGA.COD and MCGA.DIF is not found in memory while Stunts is running. This is a confirmation that the information is compressed.
- Some variables are stored at positions that seem to be also variable respect to LOAD.EXE's starting code offset, even though they are within the same MCB. This is still a kind of mistery to me

Hope it's useful

[I don't even remember how to use an IRC]

Great!  Well, I'll tell you what I'm good and bad with, what I have at hand and what I need to know to be able to help.

- I have always been part of the... uh... "resistance", he, he, against Windows, so I have all these years kept on working for DOS. I'm pretty comfortable to it, although I really like and use Linux as well (I have Ubuntu), but I'm still not as good at it as I am with DOS.
- For real-mode high-level, I've worked with Turbo Pascal, Borland C++ and QuickBASIC. I'm specially comfortable with the last two. For low-level, I understand any assembler, but for writing I'm much faster with FASM. For protected-mode high-level, I've been working with FreeBASIC and I've tried it under Ubuntu too. I would like to improve there as well.
- I know very little about network and internet stuff, so I don't even remember how to use an IRC, but I'm willing to participate there if you tell me how.
- I have (some times intentionally) avoided using object-oriented programming, so I am not familiar with languages that develop exclusively in that area. I am used to programming graphic routines low-level and I know how to access old SoundBlaster cards through ports too. I am used to doing that myself, so I don't know about libraries and I'm inexperienced about loading third-party modules in my code.
- I understand the structure of DOS EXE files and know about opcodes
- I am weak about low-level protected-mode programming

So I hope I can be helpful here. It's very good to have somebody else also trying to unwrap all this code. I've been working on analysing Stunts internal variables to block replay handling and I partially succeeded, except that I found some stuff to be system-dependent. Now that car-editing is already possible, the next step (apart from replay-handling control) would be enhancement of track edition, by allowing variable-size maps and more track objects. We need to isolate the (kind of crazy) pseudo-Newtonian force/collision engine, the track/replay file analysis code and the sound and graphics hook-points. About the sound, I've already been working on that. OK... please let me know how we can get in touch. I can pass you my e-mail and Skype IDs and will be glad to participate in the IRC

My goodness!

Everytime I'm busy for a few weeks, I come back and there's magic going on!  I would be very happy to help!  Time ago, I had been thinking of a method for decompiling the whole Stunts code (mainly LOAD.EXE). I had already UNPacked the EXE and noticed the structure of the HDR, COD and DRV files. Note that the DRV files are the sound libraries, each of them is supposed to be loaded at the beginning of a segment (offset zero) and starts with a series of jumps to each of the sound functions. I am currently working on a project for FreeDOS that should provide a sound API for DOS and enable some old games to have sound again. Stunts is one of my examples of how this can be accomplished, by replacing the DRV files (specially the AdLib one) with patches that redirect the functions to the new API, called CPOS/NSS.
But back to the decompiling... I am willing to help, but would suggest the following:
1- Do not abandon the game support for pure DOS!  This is an opportunity to support the FreeDOS project. Stunts was born a DOS application and it can still be improved with 32bit code without necessarily having to separate from DOS. Make sure any new code can also be compiled to run under pure DOS. I can dedicate to that myself.
2- MASM and TASM are not very comfortable to receive decompiled code because of the way they structure the sources (ASM files)... having lots of required directives. I strongly suggest Flat Assembler: http://flatassembler.net
3- What do you need help with?

Yeah, I expected DOSBox to fail. Of course, this does not mean I'm going to be OK with Vizcacha only working under pure DOS and windows, but it would be useful if you had a live CD of FreeDOS to boot with and try it as well, because with FreeDOS it works on my computer. If it also does in yours, I will know that it's the system only and not the computer which causes the incompatibility.
I have been thinking of changing entirely the way Vizcacha loads the driver. There is a problem with a variable, that sometimes is there and sometimes is not. It's no easy task to hack Stunts. Also, I am concerned with the stunts_k program. I fear it may interfere with Vizcacha, because it does a similar job. In the future, once I get the Vizcacha working, I may try to embed stunts_k into it, to make it more stable.
Another thing: when I run Stunts under DOSBox in Ubuntu, I can't use the arrow keys. I have to activate number-lock and use the letter keys instead. Does this same thing happen to you under Fedora?  Do you know how to solve it? 

Phew... finally, I got Vizcacha working again. I had to rewrite it and now there are so difficulties, but I just sent a beta version to be tested. I'll post the pipsqueak version here probably tonight or tomorrow... it's just I'm not sure it will always work.
I have some things in mind to change completely the way it works, ensuring it will be easy for every system to support Vizcacha. But that takes some time, so I hope this version will do the basic job. If it does work, with a couple of touches, I can turn it into a new full version until I develop the other method.
New Zealand is a nice place. It is very safe!  I'm used to so much insecurity in my country and now I feel much better. There are some problems, though, like everywhere. Most activities are closed quite early in the day, for example. But it is really a very enjoyable thing to be here, as I get to know people from everywhere. NZ is certainly worth a visit!

I finally got a job here in New Zealand and I have been able to buy my new computer!    Now, I have started to work on Vizcacha again. Also, I had the chance to test it in this other computer and saw with my own eyes what was happening. Vizcacha did exactly what you guys reported, so I analysed the code Stunts loads in memory and I found it has a completely different layout depending on the system. I'm surprised that it worked on two different software environments on the other computer.
I have to say, it's pretty hard to do the trick with this variation  , but I wanted to let you know I'm working on it now again and I have already found the addresses. I will post a new test version as soon as I get it to stop crashing 

Yeah, the method can be enhanced easily, to make it safer. What I'm most concerned about now is the fact that it allowing even with the keyboard to access the menu options. It is OK that the replays get signed anyway, because of the way it's programmed. I did test Vizcacha under FreeDOS, DOSBox under Windows XP and pure Windows XP window. Vizcacha worked in the three cases. I am not sure about the last one with Vizcacha 1.1, though, but the Illegal Function Call can be fixed. So the problem is not about the environment, but on how Stunts is being loaded in each computer. I will need write write a probe application that will give you instructions such as "Go to the Continue Driving option now and press ENTER" or "Get into the Options menu now and press SPACE". It appears that Stunts not always sorts the code in memory in the same way. Thanks for testing this.

If you guys have the chance to test Vizcacha, just in case, under FreeDOS, with a live CD, I will appreciate your reporting what happens. Now I have to go back to job seeking in Wellington, New Zealand. It's pretty hard and I've been dropping CVs even in like five cafés!  Once I get a job, I can buy a computer and continue to work. I'm running out of savings now.

Zak, what you tell me is intriguing. The error you're getting must be based on something that does not happen on the computer I was trying Vizcacha from, since I did try the program under XP's DOS emulation. I will need to send you an auto-debug version so that it reports more details on the error, as I cannot generate it from here. Also, I have had to return the computer I had been lent, so that make take some days. In the meantime, please continue to look for bugs or give ideas.
I also realized of a problem while I was about to fall asleep yesterday night. I protected the menus against keyboard action, but not against the mouse!  Please test both separately and tell me what happens, as I can't test Stunts for now. It is very easy to fix this problem, but I need a computer other than at the cyber café. To begin, I can simply get Vizcacha to disable the mouse completely and then with some little more time, I can make a neat protection against menu selection with that device.
It is true. Vizcacha writes the data at the end of the RPL file. Old VC 1.0 would append 30 bytes. VC 1.1 appends a fixed-length 32 bytes field. You can use this info to calculate the RPL time. I left the pipsqueak name not-encrypted on purpose. VC will know if it is modified and will say it is, but if I encrypted with the same code as the rest of the data, the encoding may be easier to make out. That's why I left it visible. Anyway, even if the pipsqueak changes the name, the rest of the data is the important thing, as you know who you receive the RPL from. Still, I can strengthen the encryption system easily. I haven't learnt PHP, but I guess an implementation of VCV only (the verifier) must be easy to accomplish. It would be very important that the decryption code could not be reached from online. I know that is OK with PHP.
What I'm most concerned about is what you say about it always reporting no replay handling was used. I guess what is happening is this: VC 1.1 is running properly and therefore assumes you were unable to use RH. You use Stunts fully with the mouse so you have not even had a problem with VC to do RH. If you tried to do it with the keyboard, you would see you would not be able to. Please let me konw if I'm right. If that is the case, all I have to do is fix the mouse problem.
Thanks very much for testing   I will continue to work on it as soon as I can

[Zak:]

People. Before anything else, here I'm posting Vizcacha 1.1. I have to return this computer today (I borrowed it) and I won't be able to work or run Stunts for some weeks until I get another computer. I will be able to get in touch through e-mail and the forum, though, from cyber cafés. For this reason, yesterday night I worked hard to correct a problem Vizcacha 1.0 had and now I can say it seems to be perfectly safe. If you find any bug, please let me know. What I'm posting is the rays-R version. Please, both TAs and rays-Rs, test it, test it, test it!

Zak:  I will be glad to send you the TA (tournament administrator) version, but I need your e-mail address. I can't post it right here. I don't know if I can send it with a private message here. I'll try to. Otherwise, my secondary e-mail address in the DOC file included with this package and I will post you my primary e-mail address through private message too.

CTG:  I reckon RH racings will never be over. Personally, I enjoy more racing with RH, because it's the way I first learnt to be in a Stunts competition, with Paleke's WSC, but now there will ALSO be true NORH verified tournaments!  As soon as I can get a computer when I can run Stunts again, I will open a NORH+NOSHCT (No shortcut) competition ... but I don't think I'll be good at racing in it... ha, ha

Chulk:  Vizcacha inhibits both Continue Driving and Load Replay options only if you start Stunts from within the Vizcacha system. Only if it succeeds to detect and hook Stunts, any replay saved during the Stunts session will be automatically modified by Vizcacha, adding an encoded signature that can be verified by TAs with an application included in their package. Any further modification on the file will cause the verification to fail. You will notice that, with Vizcacha 1.0, there is a cheat pipsqueaks can do to get RH replays certified, but this is no problem now, since Vizcacha 1.1 uses a different certification encoding and won't accept older certifications on replays!