For my 2D game's save/load system, I've run into a very weird and unexplained bug that other users on the forums have not been able to help me with. I've tried everything and I'm wondering if I can get some assistance with it. With this code here, I don't get any errors or load faults, even after ten minutes of it running (it generates 1000 random numbers per frame and at 60 frames per second, 60,000 random numbers get checked per frame):

I now have conclusive proof that the saving to file and reading from file parts are not at fault, considering 60000 random numbers are being checked per second, and that even after 10 minutes of this, not one error occurred. This almost certainly rules out the saving and loading to and from the file as being faulty. I used this piece of code to prove it:

I now have conclusive proof that the saving to file and reading from file parts are not at fault, considering 60000 random numbers are being checked per second, and that even after 10 minutes of this, not one error occurred. This almost certainly rules out the saving and loading to and from the file as being faulty. I used this piece of code to prove it:

Code:

---

function save_bits(num)
{
	var frac;
	var neg;
	
	neg = 0;
	frac = frc(num) * 1024;
	num = int(num);
	
	if (num < 0)
	{
 		neg = 128;
		num = -num;
		frac = - frac;
	}
 
	write_bits[0] = (num >> 14) & 255 | neg;
	write_bits[1] = (num >> 6) & 255;
	write_bits[2] = ((num & 255) << 2) & 255;
	write_bits[2] = write_bits[2] | ((frac >> 8) & 255);
	write_bits[3] = frac & 255;
 
	file_asc_write(file_handle, write_bits[3]);
	file_asc_write(file_handle, write_bits[2]);
	file_asc_write(file_handle, write_bits[1]);
	file_asc_write(file_handle, write_bits[0]);
}

function load_bits()
{
	var frac;
	var num;
	var neg = 1;
	
	write_bits[3] = file_asc_read(file_handle);
	write_bits[2] = file_asc_read(file_handle);
	write_bits[1] = file_asc_read(file_handle);
	write_bits[0] = file_asc_read(file_handle);
	// neg = 1;
	
	if (write_bits[0] & 128)
	{
		write_bits[0] = write_bits[0] & 127 ;
		neg = -1;
	}
	
	num = (write_bits[0] << 14) | (write_bits[1] << 6) | ((write_bits[2] >> 2) & 255);
	frac = (write_bits[2] & 3) << 8 | write_bits[3];
	num = num + (frac / 1024);
	return(num * neg);
}

var test_number[1000]; // used for the random number to write
var loaded_result[1000]; // the number being loaded

function find_faulty_number()
{
	randomize(); // always randomized numbers
	var valid_number = 1; // used for the loop to identify a bad number
	var invalid_number; // copies the number that didn't load or save properly
	var array_index; // array index for the massive array
	
	while(valid_number == 1) // keep looping until an invalid number is found
	{
		file_handle = file_open_write("faultynumbertest.log"); // open file for writing
		
		array_index = 0; // reset array index
		
		while(array_index < 1000) // writes 1000 random numbers
		{
			test_number[array_index] = random(50000)-25000; // get a random number
			save_bits(test_number[array_index]); // write the random number
			array_index += 1; // increment array index for another round
		}
		
		file_close(file_handle); // close file so it can now be read from
		file_open_read("faultynumbertest.log"); // open file for reading to compare
		
		array_index = 0; // reset array index
		
		while (array_index < 1000) // reads the outputs
		{
			loaded_result[array_index] = load_bits(); // read from the file
			debug_test = loaded_result[array_index]; // used in a panel to identify a faulty number, if one occurs
			
			if (test_number[array_index] != loaded_result[array_index]) // if not exactly matching
			{
				valid_number = 0; // an invalid number has been found
				invalid_number = test_number[array_index];
				display_error(14); // shows the load error
				break; // terminates this loop
			}
			
			array_index += 1; // if still valid, continue loading it
		}
		
		file_close(file_handle); // close file so the write, read loop can repeat
		
		wait(1); // wait to prevent "endless loop" errors
	}
	
	debug_test = invalid_number; // copy so I can see it in the panel to write it down
	sleep(5); // long delay to write value down
	debug_test = test_number-loaded_result; // the difference between the test number and the loaded result
}

on_j = find_faulty_number();

---

I messed around with the "25000" part being subtracted and used several different numbers and let it run. No matter what I use there, no error ever occurs. Then, when I use my special encryption algorithm, there's one error every 30,000 or so numbers checked and it's causing me problems. With nearly 2500 objects being saved, it takes only a few saves before an error occurs. The exact same formula is used. I don't want to give the encryption formula out to anyone, except Conitec themselves and I'm wondering if you'd help look into it. I've got several test cases and examples available. Sometimes the encryption formula never errors, but at other time, it does and I'm unable to explain the cause.

Edit: I've tried all sorts of methods to get it to work. File_var_write doesn't write fractional values properly so that's out of the question (plus it's not secure either). Game_save is either all or nothing and won't work with the free edition and you can't pick and choose what gets saved (and dynamically), plus it doesn't allow custom file extentions so game_save is out of the question. The last option I have is file_asc_write, of which there are no problems with (and I've extensively tested it), other than it not being entirely secure. To solve that, I made my own encryption algorithm to "encrypt" (or "hide") the stuff so it can't be modified as easily.

Edit #2: The difference between what is read from the file and what I actually get is always 64. The result saved in the file is always 64 less than that of what the encryption formula gives. Every time it doesn't produce identical results, there's always a difference of 64 in the exact same way. I cannot explain why it happens. The error occurs with the exact same number each time as well for one particular setting for the number being subtracted or added (42,000 seems to produce faults with -0.184 as the faulty number and 28,000 causes faults as well with -0.122 as the faulty number, but 25,000 doesn't, all subtracting). The faults seem to occur with small negative numbers, but sometimes even small positive numbers.

I'm afraid I won't have the time to look into your encryption formula.

I see that you're using file_asc_write, which excludes rounding errors by writing fractional numbers into the file. The fact that the difference is 64 should give you a hint, your algorithm seems to have a problem with bit #6.

If you know a critical number that is wrongly encrypted and decrypted, single step through your algorithm and check in which line the problem happens. Usual bugs in encryption algorithms are sign errors when a part of the number becomes negative. Debugging is faster when you don't write or read from a file, but just feed the output of your encrypter into the decrypter.

Well, since the number at fault each time is always the same and always causes the exact same difference, a monster of a clue, I can test this quite well.