[SA] SCM and ENEX Markers

[deltaCJ]

I've made a new interior for SA and made a set of enex markers. 

Only problem is that when I activate the SCM Mission scripts the enex begins to teleport me to either:

A. Random Locations

B. The interior with no exit (have to kill my self to leave)

or

C. Will just respawn me in front of my custom house...

 

 

I've tried asking around but no luck...

These are the enex lines by the way:

 

2365.8811, -1715.24, 12.78, 357.2756, 2, 2, 8, 2365.8196, -1718.1237, 12.5597, 180.0, 0, 4, "MOTEL1", 0, 2, 0, 24
2255.5789, -1642.8552, 1013.2, 0.0, 2, 2, 8, 2255.5435, -1644.2778, 1013.2, 180.0, 1, 0, "MOTEL1", 0, 2, 0, 24

 

(I named it the "MOTEL1" in case it had something to do with the name; it doesn't.)

 

Please inform me of anything that could be the problem, this is making things pretty difficult.

Edited July 4, 2020 by deltaCJ

[OrionSR]

8 hours ago, deltaCJ said:

Please inform me of anything that could be the problem, this is making things pretty difficult.

Well, it looks like you formed a proper two-way link. Well done. This is a common problem with enex markers. The most likely explanation is that you added your enexes to what would be the appropriate map file for that location and scrambled everything that follows for existing save. There's a reasonably good chance it'll work as expected on a new save, but you'll want to do better than that.

 

If you really want to add new enexes, add them after all other enexes. The save file only maintains a map of the relative links between enexes and their current flags; it can't adjust if the original sequence of enexes is modified. My strategy is to leave my original map files alone, and to create a new folder (data\IPL) for my custom IPL files. Add references in GTA.DAT to your added IPL files. It's a much cleaner process.
 

It's probably worth the effort to get this working for the basic experience of working with enexes - it looks like you're really close. But in the long run you are probably better off switching over to a teleport script. Enexes are notoriously difficult to use and share. Enex mods don't play nice together and can be difficult to add or remove cleanly in an existing save. If you aren't working on a full map mod, or interested in enexes in particular for the experience, I would high recommend another strategy.

 

Teleport scripts are easy to share an remove. The primary requirement is that any entry markers added to mark a door with a bobbing yellow arrow so they look just like a normal enex (ticket booth at airports, for example) must be added and removed as required because there's only 5 total, and standard scripts use a couple.
 

Edited July 4, 2020 by OrionSR

[deltaCJ]

Thanks Orion!

So I was messing around with the entries, and it was like you said place it after all enex entries. At first I did that and it cancelled the problem of me being teleported randomly.

 

But a weird find I found is that ENEX markers are disabled if you use the 

Player.MakeSafe opcode and the enable_streaming 0 opcode

Removing these made my interior work good as new!

 

BTW I am making a total conversion, so save games are not a problem I will keep that in mind though when messing with save games or when my main.scm

But @OrionSR could you tell me what are some things I should watch out for when creating a whole new game? New Missions, Peds and stuff like that what are some commonly found things that I can easily steer away from? (Concerning the main.scm)

Edited July 4, 2020 by deltaCJ

[ZAZ]

1 hour ago, deltaCJ said:

could you tell me what are some things I should watch out for when creating a whole new game?

don't make such big script, especially not with tons of wait times

[deltaCJ]

How so? Like for each mission? 

I try to simplify the code as much as I can. Should I use return ifs and else, instead of the SA SCM way of doing it?

[OrionSR]

First, a couple of more comments about enexes. The max limit is only something like 400, leaving about... 23, iirc, added enexes. There are a handful of standard enexes that can be repurposed without undo conflicts with existing mods. 

 

When trying to add new enexes at the end on existing saves, be sure to save inside, or far away from any burglary houses. The burglary routines will add temporary enexes near CJ whether the mission is active or not, and the temp data in the save will conflict with new enexes. 

 

1 hour ago, deltaCJ said:

what are some things I should watch out for when creating a whole new game?

I don't have experience with creating a "full map" mod. My experience is very much limited to standard games and save files. The farther way your mod is from original the less help I can offer. What is the overall scope of your mod? How much of the original game do you intend to retain?

One thing I've learned by observing how cleo scripts corrupt save files is that it helps a lot if you try to maintain a similar global variable table to the original game. The general rule is to avoid global variables in cleo scripts, but far too many coders ever bother to read the rules, and for good scripts there are always exceptions. Everyone assumes that variables like $player_actor and $on_mission are safe to use - the scripts often can't run without them. Your mod is less likely to run into conflicts if you try to use compatible variable numbers as much as possible.

 

Also, any variable that is named in customvariables.ini gets a little extra protection from corruption from Sanny Builder. When players create undefined custom variables in their scripts Sanny will assign that custom var to the first available undefined variable following the highest numbered variable used in the script. So variables following $player_character, $on_mission, $tempvar_float or whatever are most at risk of being corrupted. You can reduce critical conflicts by encoding critical variables far away from commonly used variables.

 

Consider creating a new Sanny edit mode for your mod. One advantage is you can configure it to compile to an SA folder particularly for your mod, and leave the standard edit mode available for testing on a baseline, standard configuration. You can customize customvariable.ini and other support files to be specific to your mod.

BTW, I've been compiling a list of SA constants for use with Sanny's new constants.txt feature. You might find the documentation useful.

 

 

[deltaCJ]

Oh no haha this isn't a CLEO Script, this is the original SA Map but with a change of pedestrians, cars, vehicles, and storyline.

 

The enex seems to work fine (every once in a while it wont let me leave but most of the time it works flawlessly)

I definitely will keep that in mind though and the SA constants is definitely a bookmark for me.

Thanks Orion and ZAZ!

 

 

[OrionSR]

1 hour ago, deltaCJ said:

Oh no haha this isn't a CLEO Script, this is the original SA Map but with a change of pedestrians, cars, vehicles, and storyline.

Oh, I know, sorry. What I meant was, as the author of a main.scm mod you can increase the compatibility of your script with existing cleo mods if the variables in your scripts are similar to the standard game. It sound like your plans would tend towards compatibility anyway, and if you keep this premise in mind as you proceed you'll have fewer issues later.

For example, if you try to reuse unused standard global variables like DeeZire did for TTDISA you are likely to run into conflicts with cleo script by clever coders that had the same idea about "unused" variable. To make matters worse, I think DeeZire helped document many unused variables leading to an increased chance they'd be reused again.

 

Fortunately, the easiest solution is to let Sanny do the work for you. Simply create custom variable names and Sanny will append the new variables after all standard variables. You don't even need to define them in customvariables.ini. This can be a disaster in cleo scripts, but works brilliantly in SCM. And if your custom variables are stored beyond what normal scripts would access they should be relatively safe from corruption.

 

Added: If a lot of the side activities in your script will be the same as a normal game I can offer a lot of suggestions for tweaking things a little so the game works better. Quadruple insane stunt jumps, bribe over bridge in Palomino instead of hidden inside a building in Doherty, Hunter and Levi both spawn at the airstrip, NRG spawning at bike school, etc. Interested?

Edited July 5, 2020 by OrionSR

[deltaCJ]

Sure! Well at least some side activities will be (Quadruple Insane Stunt Jumps)

Appreciate the help once again!

Edited July 5, 2020 by deltaCJ

[OrionSR]

It might take a while for me to gather my notes. They're spread out across a couple of discord servers and not much use to anyone looking for that sort of information.

 

1 hour ago, deltaCJ said:

Should I use return ifs and else, instead of the SA SCM way of doing it?

I'd suggest coding using high level constructs whenever it make sense to do so. The segments are easy enough to convert by decompiling with Sanny. I have traditionally relied on SCM style coding, mostly because that's how my examples usually appear, and it's generally more familiar to players on the forums. However, thanks to a nice set of high-level examples from ZAZ, I've been creating most of my newer scripts almost entirely with high-level constructs. I've also been exploiting the constants heavily, and even defining my variable types so Sanny can find the proper opcodes for math operations. I have found these scripts to be much easier to build, read and debug than a traditional SCM "show opcode" format. 

[OrionSR]

Quadruple Insane Stunt Fix (ref)

Find

$1304 > 4.0

Change it to

$1292 > 4

To maintain compatibility with standard scripts, use fastman92's clever IEEE-754 trick.

0018:   $HJ_Car_Z_Max > 5.6E-45

Are you in a hurry? I'm considering strategies to document this stuff.

[deltaCJ]

No I am in no hurry, in fact how would I do the stunt jumps from scratch? should I take the code from the original SCM and put it in my script?

[OrionSR]

Sure, but it sounds like you really are starting from scratch and trying to add things back in. Have you considered looked for a stripped main that maintains more of the original scripts? 

 

Another strategy would be to import the script from VCS so you can have perfect flaming quadruple insane stunt jumps, or whatever the standard is, it's been a while since I played.

 

A lot of this very similar to the TTDISA projects. You might learn a few tricks and get some good ideas by examining that example. That's actually where I've buried some of my notes. I need to search through the old records for specifics.

 

Gym Glitch Script Fix

Here's an easy one I remember though - a fix for the gym glitch that prevents players from working out. The problem occurs when the player rolls the hidden in-game calendar over to the next year and suddenly the month is less that before. The untested fix is to change the evaluation to not equals instead of greater than. This bit comes up in several places:

 

Search for:

00D6: if or
001C:   $Current_Month_Day > $GYM_Month_Day_When_Limit_Reached // (int) 
001C:   $Current_Month > $GYM_Month_When_Limit_Reached // (int) 

Replace with:

00D6: if or
803A:   not $Current_Month_Day == $GYM_Month_Day_When_Limit_Reached // (int) 
803A:   not $Current_Month == $GYM_Month_When_Limit_Reached // (int) 

 

[deltaCJ]

I've tried ZAZ Stripped main, but it crashed on me a few times, and it adds EVERYTHING back in when I just want the parachute, and small things. If I disable on External Script though and the whole script crashes

 

Thanks for the documentation!