Suggestion: WriteRawLine-append without linebreak (NEVER MIND)

Started by GarageGothic, Mon 01/08/2005 08:23:13

Previous topic - Next topic

GarageGothic

EDIT 2: OK, it turned out that the problem was elsewhere. But still, it could be a useful function.

On a suggestion by Gilbot I wrote my own functions to break text files into strings, generate code for them and output them to an external txt file for cut-n-paste. However, using the WriteRawChar function, I'm limited to ASCII values 0-255 even though strings support chars beyond this array (for some reason I don't get the same error messages when reading the chars from the text file).

WriteRawLine currently isn't an alternative as it would add a linebreak after each part of the code, like this:

AddText("
This is the text that we've broken into 200 char units.
");

So I was wondering if it would be possible to add a eFileAppendNoBreak parameter to File.Open (or perhaps an optional parameter for the WriteRawLine command would work better)?


Edit: Also I have a question that isn't part of the suggestion, but related to the same piece of code. When I apply my string breaking tool to very long text files, the game crashes and tells me that the while loop has been repeating 15,000 times or something like that. Is this a real error, or is it just triggered because my while-loop repeats throughout a very long file? If so, is there any way to turn the error message off and allow the code to finish on it's own?

monkey0506

Quote from: GarageGothic on Mon 01/08/2005 08:23:13Edit: Also I have a question that isn't part of the suggestion, but related to the same piece of code. When I apply my string breaking tool to very long text files, the game crashes and tells me that the while loop has been repeating 15,000 times or something like that. Is this a real error, or is it just triggered because my while-loop repeats throughout a very long file? If so, is there any way to turn the error message off and allow the code to finish on it's own?

If the game runs for 150,000 loops without a screen update it assumes that it is hung and exits.  CJ is currently looking into implementing a method to disable this error.  At least he told me he would.

GarageGothic

#2
Ok, so if I put some code in to update the screen (change gui text or similar) once in a while, it would work?

Edit: Nope, it didn't help. But I confirmed that it was a length issue as it worked fine when I split the file into two. It's not a terribly big problem as I could easily do this if I need to break a very long text - I just don't like error messages in my scripts. Thanks for the reply.

Gilbert

#3
Quote from: GarageGothic on Mon 01/08/2005 08:23:13
I'm limited to ASCII values 0-255 even though strings support chars beyond this array (for some reason I don't get the same error messages when reading the chars from the text file).
No, actually strings should only support characters from the 0-255 range. My example spliter treated the file as raw binary, so the bytes will be 1-1 identical to the original abeit to the added texts, etc. Normally, if there're text codes that worked as two bytes (which should not be supported currently by AGS strings currently) the two bytes are to be exported intact as the original, except for rare cases, when the line breaks were added between them, you can however, modify the spliter so it can detect these specific code combinations and export them intact.
Quote
Edit: Also I have a question that isn't part of the suggestion, but related to the same piece of code. When I apply my string breaking tool to very long text files, the game crashes and tells me that the while loop has been repeating 15,000 times or something like that. Is this a real error, or is it just triggered because my while-loop repeats throughout a very long file? If so, is there any way to turn the error message off and allow the code to finish on it's own?

I remember in my post which I posted my example "game", I mentioned about that, and I had an updated version where the codes were in repeatedly_execute(), and didn't use while, so it shouldn't crash.
You can grab that for reference.

I'll try to dig up that thread now.

EDIT: Yeah, check out the old thread, see the "EDIT" part of my post for the updated version. (It now writes ONE line of text each GAME LOOP, and I'd set the game frame-rate to as fast as possible, so you won't need to wait a whole second for every 40 lines written.

GarageGothic

#4
QuoteNo, actually strings should only support characters from the 0-255 range.

Curious, I'll have to look into this and see exactly which char is causing the problem. The content of the string was generated by the 200-char-unit tool, but when I run that code through my linebreaker tool for that specific html page, it fails. I don't see how any "bad chars" could have been added along the way. I'll add a Display(StrFormat("%d", char)) to the code to trigger when the char is outside the 0-255 range.

QuoteI remember in my post which I posted my example "game", I mentioned about that, and I had an updated version where the codes were in repeatedly_execute(), and didn't use while, so it shouldn't crash.
You can grab that for reference.

Crap, I see that now. Thanks. For some reason I thought the edit referred to another part of the code. Ok so at least this isn't an issue.

EDIT: Whoa, I discovered that the problem was entirely different from what I thought. Displaying the ASCII codes, it turns out that I get calls for negative chars like -56 and -103. I must try to locate the cause for this now.  Thanks for the help guys, sorry for bothering you with the wrong problem.

Gilbert

Normally, each character is an unsigned byte, so that shouldn't happen.
However, if you had declared some global variables and imported them into room script, remember that the variable types match those in the declaration.
For example, if there's a "short blah;" declaration and you put the following in the header:
int blah;
strange things can happen, since int type is of 4 bytes compared to 2 bytes of short, when used in teh room, 2 bytes of unexpected junks were added to the variable, that can  screw things up.

GarageGothic

I have yet to track down the problem, but it lies somewhere else entirely. Turns out that the strings I'm reading from are utter garbage (lots of squares and other non-standard symbols), but I'm not sure where they come from.

Edit: By the way Gilbot, where did you find the ASCII codes for CR/LF? Are there other special codes like this?

Gilbert

Carriage return and Line feed are standardized ASCII codes (Standard DOS/Windows text file format needs CR-LF 2-byte combo to end a line, for *nix formats one byte is enough, but i don't remember well, it's probably just CR).
Just google an ASCII table, and it'll be there. For example:
http://www.lookuptables.com/

(Well actually I had to print the CR character frequently when programming for the Apple 2, so its value 13 was perminantly etched into my brain, I had to look from a table the value of LF though).


SMF spam blocked by CleanTalk