Extra linebreaks in strrefs

[Guest Guest_Nythrun_*]

It's one of things that's been buggung me for awhile, and there's a few left that the GTU isn't getting (don't remember what, away from files, sorry )

 

I was planning on doing something like the below to get rid of them locally (code is untested and written on a different computer, you know the drill )

 

<<<<<<<< asdfasdfasdfasdf.duh
>>>>>>>>

COPY ~asdfasdfasdfasdf.duh~ ~check/string_newline_fix.tra~
COPY ~asdfasdfasdfasdf.duh~ ~check/string_newline_fix.tp2~

APPEND_OUTER ~check/string_newline_fix.tp2~ ~~~~~DEFINE_ACTION_MACRO ~string_newline_fix~ ~~~~~

OUTER_PATCH ~dummy_variable_that_lets_us_use_patches_in_an_action~ BEGIN
 FOR ("i1" = 0x1; "i1" < 0x1217a; "i1" += 0x1) BEGIN
SET "append_check" = 0x00
GET_STRREF "i1" ~old_string~
PATCH_IF NOT (~%old_string%~ STRING_EQUAL_CASE ~~) THEN BEGIN
  INNER_PATCH_SAVE ~new_string~ ~%old_string%~ BEGIN
	READ_BYTE 0x00 "check1" ELSE 0xee
	PATCH_IF ("check1" != 0xee) THEN BEGIN
	  FOR ("i2" = 0x01; "i2" < 0x4000; "i2" += 0x1) BEGIN
		READ_BYTE "i2" "check2" ELSE 0xee
		PATCH_IF ("check2" = 0xee) THEN BEGIN
		  FOR ("i3" = ("i2" - 0x1); "i3" > 0x0; "i3" -= 0x1) BEGIN
			READ_BYTE "i3" "check3" ELSE 0xee
			PATCH_IF ("check3" = 0x0a) THEN BEGIN
			  DELETE_BYTES "i3" 0x1
			  SET "append_check" = 0x1
			END ELSE BEGIN
			  SET "i3" = 0x0
			  PATCH_IF ("append_check" = 0x1) THEN BEGIN
				INNER_ACTION BEGIN
				  APPEND_OUTER ~check/string_newline_fix.tra~ ~~~~~ @%i1%000000 = ~%new_string%~ ~~~~~
				  APPEND_OUTER ~check/string_newline_fix.tp2~ ~~~~~  STRING_SET %i1% @%i1%000000 ~~~~~
				END
			  END
			END
		  END
		  SET "i2" = 0x4000
		END
	  END
	END
  END
END
 END
END

APPEND_OUTER ~check/string_newline_fix.tp2~ ~~~~~USING ~check/string_newline_fix.tra~ ~~~~~
APPEND_OUTER ~check/string_newline_fix.tp2~ ~~~~~ ~~~~~
APPEND_OUTER ~check/string_newline_fix.tp2~ ~~~~~END ~~~~~

INCLUDE ~check/string_newline_fix.tp2~

LAUNCH_ACTION_MACRO ~string_newline_fix~

[devSin]

This will happen because the TRA strings have DOS line endings. Any decent text editor should allow you to normalize the line endings (convert all to one variant) for the TRAs and TP2s.

 

Use Unix (LF) line endings when working with WeiDU.

[Guest Guest_Nythrun_*]

Was talking about strrefs in the dialog.tlk (like the tooltip name of those Hobgoblins), not WeiDU .tra files or mods or whatever.

 

There's a good many of these strrefs in the dialog.tlk not mod added stuff which have as many as three trailing 0x0a characters (yes, they end in 0x0a, check your hex editor) - and when it's not a loading hint, it's usually okay (and desirable) to remove them.

 

Hence the scan of strrefs from 1 - 74107.

 

Honestly, thanks for the help - but I don't think you read a word of the post before your reply Don't worry, it won't be going in the GTU in any case and that can stay in its current form, unsatisfactory to all.

[devSin]

Do the trailing line breaks display in-game? (I set every string, so I haven't seen original dialogue strings in years.)

 

IIRC, they did it a lot for descriptions and other "interface" text (to better work with the content area so text doesn't get clipped or can be scrolled further than necessary for improved readability).

 

Honestly, thanks for the help - but I don't think you read a word of the post before your reply

Busted! I do sometimes make an effort to read and understand what people are talking about before replying, but not a lot.

 

In my defense, some of your posts really are so vague that I have no hope of deciphering what you're trying to say; we apparently think about things too differently to just automatically know what's being said.

[Guest Guest_Nythrun_*]

I know for sure that some do display, that some don't display, and for many I have no clue - which is why I thought I'd ask

 

I generally assume that code abides less polysemy than natural language - even when it's written over lunch away from files and contains STRING_SETs appended to the wrong place

[devSin]

I never (ever ever) read the code that gets posted.

 

And here we are.