Timetwister SA development

[Demarest]

As outlined here, TTSA development is coming along swimingly. However, the deeper I dig, the more questions I have. The process will be long, so I thought I'd make use of the passing time by posting questions here. I'm sure I've already forgotten a few.

 

Anyways, I firs saw 03D5: remove_text 'M_FAIL' in Vice City. I never bothered to test it, but while testing TTSA, it doesn't seem to work. TTSA will operate through menus obviously and trying to jump back into a menu while mission passed or fail messages are on screen just isn't clearing them despite being instructed to. I've also tried 03D6: remove_big_text 'M_FAIL' and 00BE: text_clear_all with no luck. Does anybody know how to remove that text?

 

This one will probably go without answer, but I'll ask it anyways. Part of TTSA's process is compressing existing code as much as possible. There are some things that are just as easily farmed out. Like local timer deadends. In the mission Big Smoke (first one), there are quite a few spots where the code sits still, waiting for @32 or @33 to reach a certain point. At those points, I was setting a local var and gosubbing to a routine that waited until enough time passed. Whenever I incorporate this method, after the mission is completed, the camera jumps to the cemetery gates and stays there. I've tried releasing the camera, pointing the camera elsewhere, etc. I've tried upper locals (@218), standard locals (@0) as well as declaring either local in the beginning. The gosub chain for speech management runs several layers DEEPER than just the one I'm asking for to run the local wait. I cannot figure out WHY such a thing would happen and have been able to narrow it down to it being a direct result of using this subroutine or not. Does anybody have any ideas as to why this would happen? If you need more info, just ask. Compression isn't important, but I do wish to understand.

 

That's it for now. There are things like gang warfare that I'd like to know how they work. I'm sure with enough time and effort, I can figure it out on my own. But since this is already going to be a multi-month project, I thought maybe DaEllum or others that might have an intimate relationship with that function would chime in and save me some legwork. No worries either way. Thanks to anybody and everybody that helps.

[Bigun]

 

Anyways, I firs saw 03D5: remove_text 'M_FAIL' in Vice City. I never bothered to test it, but while testing TTSA, it doesn't seem to work. TTSA will operate through menus obviously and trying to jump back into a menu while mission passed or fail messages are on screen just isn't clearing them despite being instructed to. I've also tried 03D6: remove_big_text 'M_FAIL' and 00BE: text_clear_all with no luck. Does anybody know how to remove that text?

 

Sorry, I never bothered to test it either. Mission Failed / Passed seems a special text, I don't personally remember anything (in normal playthrough) that removed it ahead of time in the games. If I remember correctly, if you somehow quickly started a new mission it was still there (maybe not in cutscenes) and not disappeared instantly. Seeing as you also tried clear_all_text, it doesn't seem it can be removed.

 

On the compression thing, if the code just sits still waiting for the timers, can't you just do a wait instead? Depends on the situation, but you could just lower the wait if the timer was running before [the check loop]. And if the camera locks up at the same place each time, then it must be the code you're gosubbing to each time that does it. Have a look at it, maybe you missed something. I'm not sure how it can affect only the end of the mission, but that is the only thing that makes sense, I reckon. Does it jump somewhere it shouldn't? Try using a different label to gosub to.

 

 

That's it for now. There are things like gang warfare that I'd like to know how they work. I'm sure with enough time and effort, I can figure it out on my own. But since this is already going to be a multi-month project, I thought maybe DaEllum or others that might have an intimate relationship with that function would chime in and save me some legwork. No worries either way. Thanks to anybody and everybody that helps.

 

You pretty much just need to CTRL+F for 'gang' in space's sascm.ini:

 

076C=3,set_zone %1g% controlled_by_gang %2h% density_to %3h% 076D=3,get_zone %1g% controlled_by_gang %2h% density_to %3d%0879=1,toggle_gang_wars %1h% 08AC=1,hide_gang_war_zone_colors_on_radar %1h%087A=0,  gang_war_in_progress090C=1,hilight_inactive_gang_zone_as_available_for_gangwars %1g%090D=0,hilight_all_inactive_gang_zones_as_available_for_gangwars

 

 

These use info.zon strings, you can open it in notepad, it's pretty straightforward.

 

Also, this is in response to your post in the other topic, there's one hidden tatoo parlor in SA. People found this way before the PC version was released with the hidden interiors glitch by the gym[s?], so I guess it's the same interior ID as them. Do a google search with 'site:gtaforums.com' and then buck in hidden-tatoo or secret-tatoo etc, you should come across some topics. Google search doesn't find new threads by the way, but those threads are ancient anyway.

To change the yellow entrance markers you need to change the enex entries in the IPL file. It's apparently not hard if you know how. I remember coming across a topic with pretty much documentation on that, I'll see if I can dig it up.

 

EDIT:

topic,

SA IPL definitions

Edited August 4, 2006 by Bigun

[Demarest]

Damn fine post, Bigun. Thank you for your help

 

I was thinking maybe instead of a remove text, having a big text created by that thread instead and giving it a ridiculously short time. Like maybe it will override the original text and expire in 50 ms or whatever I use, giving it the illusion of clearing text. Might work...

 

You make a good point on using waits instead of local timer traps. I honestly don't see why you couldn't it would stand to reason that there'd be SOME reason. But if the loop doesn't check for actor/car death, the fact that a simple wait didn't should be irrelevant. Part of the compression obviously involves farming out common and/or recurring activities. In missions, there are tons of is cutscene loaded and is cutscene ended for example. I farmed them out to global gosubs that work perfectly. I thought maybe the fact that I was referring to local timer vars in a global section might be the culprit, but really the game doesn't know/care where the code is when the thread pointer lands there and executes the code. And my other global subs work fine with returning forward into mission code and such, but they don't handle variables. After hours (I am not exaggerating ) of trying to arrive at the solution, I reverted to an earlier version of the code that ran fine. Then the ONLY difference I added was changing

0006: @32 =  0 ;; integer values:INTRO1_123700D6: if  0001B:    500 > @32 ;; integer values004D: jump_if_false £INTRO1_12420001: wait  0 ms0002: jump £INTRO1_1237:INTRO1_1242

^ R*'s original code to

0006: @32 =  0:INTRO1_12370001: wait  0 ms00D6: if  0801B:    NOT   500 > @32004D: jump_if_false £INTRO1_1237:INTRO1_1242

^ which works to

:INTRO1_12370006: @0 =  5000050: gosub ££TTSAWAIT32

...with (something like) the following in MAIN

:TTSAWAIT320006: @32 =  0:TTSAWAIT32B0001: wait  0 ms00D6: if  0801D:    NOT  @0 > @32004D: jump_if_false ££TTSAWAIT32B0051: return

 

 

Do that and a second after the guys are done talking to you and the respect message and victory music plays, the camera would jump to the cemetery. The cemetery IS used in that mission, so I'm guessing there's an explanation. Originally, I had one of the "bunnyjumps" cut out, but not its kill opcode. Also 0925 is said to restore camera to when player was last controllable, though that shouldn't be an explanation. And whatever the explanation is, it shouldn't be impacted by the code examples above, but it was with no other variances taken. I'm mystified.

 

Thanks for the gang info. I figured it was documented and easy to find. I just haven't gotten to that point yet.

 

space indicated that the tatoo shop was fixed. I just tried it and having been there in interior heaven before, I can say it certainly was.

 

An interesting thing I discovered that will help my compression well enough is that if you create_thread and feed the new thread an actor as one of the variables, it can control the actor despite being created by a different thread. Even when the originating thread refers to it with a local. Very cool.

[Y_Less]

Have you tried:

 

 

0006: @32 =  00006: @0 = 500:INTRO1_12370001: wait  0 ms00D6: if  0801D:    NOT   @0 > @32004D: jump_if_false £INTRO1_1237:INTRO1_1242

 

 

The only major difference I can see is the use of @0. And the actor thing is understandable, the variables just hold references, you're just passing the reference about.

[Bigun]

On the camera problem, you may try to just workaround a 02EB (followed with a 0373 if necessary) after the jf in intro1_1237..or somewhere else, as noone is really sure why that problem happens. You could play the mission normally, sniff around the coding where it moves the cam there, whatever. Good luck

[Demarest]

@y-less: Yep. I tried just about everything. Including camera tricks after the fact that ALSO didn't work. It was as if I had tilted the engine somehow.

 

I made it through missions 11- 15 when I really started encountering more advanced ways of compressing the code (MANY thanks in part to y-less). While it was sufficient to just edit the 4 missions, I chose to redo Big Smoke from the start. My first pass was not only more productive that it was the first time (when I was getting that error; the added saving in part to Bigun's wait idea), but my second pass knocked out some 2 THOUSAND bytes more. And I still have at least one more pass to make to further compress it

[Bigun]

Good job. But..

 

Bigun's wait idea

Yarr.

You're talking like I invented that opcode, it's only used in pretty much EVERY mod out there. It's only common sense if you have something like

 

 

:label1_do [email protected] = 0:label2wait 0if [email protected] > 3000jf label2_do stuff_

 

 

..it can be exchanged with a wait 3000. I don't see any point in using code like the above, unless you're checking another condition (like you mentioned is_XYZ_loaded etc) and want it to have a timeout etc:

 

 

:label1_do stuff_request_cutscene 'test';[email protected] = 0:label2wait 0if 0NOT @32 > 3000jf label1if 0cutscene 'test' loadedjf label2_do stuff_

 

[Demarest]

You familiar with those magic eye pics? And how some people focus so hard on them, they can't see sh*t? Well in all my efforts to be advanced, the simple solution eluded me entirely. You were the one that brought it up and each instance cuts down lines and cuts out bytes. I'm sure they looped it for a reason, but don't see that reason. I give credit where credit is due. That's not the extent of your helpfulness, so it's not like I'm saying you're only good for pointing out to use waits

[Demarest]

Well, I've got good and bad news. The good news is I've FINALLY got a lead as to what may have been causing the camera "glitch" before. The bad news is that the mission I'm experiencing it with now has an error in it that I'm having the darnedest time tracking down. I THINK it has to do with returning when there's no more levels to return to or not returning when there's an active gosub. I've been using mock gosubs, so I'm hoping it's an error of mine that I'll be able to spot after reading through enough times.

 

So it's come to fruition once more as a combination of game elements AND my error.

 

The culprit is bunnyjumps (0707 and 0701) and the lock camera opcodes (092F and 0930). I'm not sure if 0925 works exactly as it's labeled also, so verification would be appreciated. Basically, in Drive Thru, when you make it back to the Grove and use the bypass to skip their conversation and then subsequently set the car on fire, causing Smoke to scream and bail, the camera goes wonky once that wav has ended. Which is a clue as to where my error is, though I've looked there several times over.

 

The thing is that it's not JUST my error. If I don't use the Grove conversation bypass set up with 0707, then I experience no such error. So I'd also like to know what all gets cleared and how with the bypass. In original code, this takes place in SWEET3_1338. Even if you bypass, restore camera with jumpcut is supposed to fix this and does at the time. But once I encounter my error, the camera is indeed locked and panning right where the commands at that address would tell it to despite that code having been skipped over. I just had an idea, which is why I chose to write this out anyways. Busy day, but I'll try to keep everybody informed in case it's some sort of discovery (which I doubt).

[DeeZire]

^ I dont know if its any help, but I noticed that a lot of the time in original missions they used the 'is key pressed (return)' opcode to skip certain elements, especially long sequences of audio, rather than using the bunnyjump. Maybe the bunnyjump can only 'skip' certain operation types? Just a thought.

[Demarest]

Sorry if I've left anybody hanging. After MUCH troubleshooting, I came to realize that I was right. It had to do with a bunnyjump not truncating active subroutine layers properly. So when I'd encounter what should've been a mission skeleton ending return, it instead would return the code to somewhere else. I wish more was known about the hardcoded function of 0707 and 0701 to help avoid this problem in the future. I've without trying hit the problem twice now out of the 5 (at the time) missions I had worked with. Luckily, I've learned a lot since then and diagnosing and avoiding the problem should be easier.

 

When I got to Drive-By, my jaw hit the floor. I did my first pass and the mission was malfunctioning. Couldn't figure out why. After a half day, I chose to start fresh. While I didn't make it malfunction this time, the overall coding scheme was unnecessarily riddled with flag checking and other such lack of good coding techniques. So I decided to rebuild the mission from scratch. Took two full days total, but it works. It's some 2500 lines and 14,655 bytes lighter (not including the 300 or so locals I spared and few dozen globals). Not only does it behave as the original, but it's actually more competent, fluid, and functional than the original was. It was fun because the other missions I had done before it taught me a lot and this gave me the chance to apply what I had learned

[chaosislife]

so......how's this going dem? Any news?