[SteaVor]

In case you were unsuccesful in getting hold of my last update (20090908), it differed from the 20090906 one in that I had slightly modified the script to drop the superfluous extra "Label" in each label (i.e. I replaced all occurrences of "LabelLC" with "LC" etc.) and renamed MASTERLCEXTRAS1 to MASTERLCEXTRAS.

Other than these cosmetical changes I had tried to implement a more accurate method of calculating the crusher reward, taking into account the the class and the health of the vehicle crushed.
I'm posting the code here in case it's not included in the files you're using.

Notes:
1. This should yield fairly accurate results.
2. It's still in Mission Builder format, sorry.
3. Take note that the labels and jumps don't the "Label" inside the label.
4. This replaces the code beginning with :(Label)CCGetStuffInIt up to and including the :(Label)CCCrushing label

CODE

:CCGetStuffInIt 0001: wait 250 ms 00D6: if 0   0038:   $CCHaveCar == 0 004D: jump_if_false ££CCGetStuffInIt 053E: $CCCraneCar = get_random_car -1 in_area 801.63 57.8 814.0 63.3 00D6: if 0   8038:   NOT $CCCraneCar == -1 004D: jump_if_false ££CCGetStuffInIt 00D6: if 0 00B1:   car $CCCraneCar 0 ()in_cube 801.63 57.8 5.0 814.0 63.3 9.0 004D: jump_if_false ££CCGetStuffInIt 0004: $CCHaveCar = 1   0007: 13@ = -90.0   :CCCalculateRewardByVehicleClass  ;; vehicle class and car health used as modifier for reward 0007: 1@ = 70.0                  ;; reward base value used for all models not listed below 00D6: if  26                      ;; poorfamily 0137:   car $CCCraneCar id == #ESPERANT 0137:   car $CCCraneCar id == #IDAHO 0137:   car $CCCraneCar id == #MANANA 0137:   car $CCCraneCar id == #MOONBEAM 0137:   car $CCCraneCar id == #PEREN 0137:   car $CCCraneCar id == #RUMPO 0137:   car $CCCraneCar id == #STALLION 004D: jump_if_false ££CCCalculateReward2 0007: 1@ = 30.0 0002: jump ££CCCalculateFinalReward :CCCalculateReward2 00D6: if  23                      ;; worker 0137:   car $CCCraneCar id == #BOBCAT 0137:   car $CCCraneCar id == #MULE 0137:   car $CCCraneCar id == #PONY 0137:   car $CCCraneCar id == #YANKEE 004D: jump_if_false ££CCCalculateReward3 0007: 1@ = 45.0 0002: jump ££CCCalculateFinalReward :CCCalculateReward3 00D6: if  25                      ;; taxi / normal / moped 0137:   car $CCCraneCar id == #TAXI 0137:   car $CCCraneCar id == #CABBIE 0137:   car $CCCraneCar id == #MRWHOOP   0137:   car $CCCraneCar id == #PATRIOT 0137:   car $CCCraneCar id == #FAGGIO 0137:   car $CCCraneCar id == #PIZZABOY 004D: jump_if_false ££CCCalculateReward4 0007: 1@ = 55.0 0002: jump ££CCCalculateFinalReward :CCCalculateReward4 00D6: if  26                      ;; richfamily / motorbike 0137:   car $CCCraneCar id == #BLISTA 0137:   car $CCCraneCar id == #KURUMA 0137:   car $CCCraneCar id == #LANDSTAL   0137:   car $CCCraneCar id == #ANGEL 0137:   car $CCCraneCar id == #FREEWAY 0137:   car $CCCraneCar id == #PCJ600       0137:   car $CCCraneCar id == #SANCHEZ 004D: jump_if_false ££CCCalculateReward5 0007: 1@ = 85.0 0002: jump ££CCCalculateFinalReward     :CCCalculateReward5 00D6: if  25                      ;; big 0137:   car $CCCraneCar id == #BUS 0137:   car $CCCraneCar id == #COACH 0137:   car $CCCraneCar id == #FLATBED 0137:   car $CCCraneCar id == #LINERUN 0137:   car $CCCraneCar id == #SECURICA 0137:   car $CCCraneCar id == #TRASH 004D: jump_if_false ££CCCalculateReward6 0007: 1@ = 100.0 0002: jump ££CCCalculateFinalReward :CCCalculateReward6 00D6: if  25                      ;; executive 0137:   car $CCCraneCar id == #BANSHEE 0137:   car $CCCraneCar id == #CHEETAH 0137:   car $CCCraneCar id == #INFERNUS   0137:   car $CCCraneCar id == #SENTINEL 0137:   car $CCCraneCar id == #STINGER 0137:   car $CCCraneCar id == #STRETCH   004D: jump_if_false ££CCCalculateFinalReward 0007: 1@ = 115.0 :CCCalculateFinalReward                               0227: 2@  = car $CCCraneCar health;; used as modifier for reward   008F: 2@ = integer to float 2@       0017: 2@ /= 1000.0                ;; max health is 1000, so we need to divide by this factor 006B: 1@ *= 2@       008E: 1@ = float 1@ to integer     0001: wait 3250 ms                ;; synchronize movement of magnet and lid :CCCloseLid 0001: wait 25 ms 00D6: if  0 0033:   0.0 >= 13@ 004D: jump_if_false ££CCCloseLidDone 000B: 13@ +=  1.0;; floating-point values 0453: object $CClid set_rotation 13@ 0.0 0.0 0002: jump ££CCCloseLid :CCCloseLidDone     0004: $IS_CAR_CRUSHED = 1 0453: object $CClid set_rotation 0.0 0.0 0.0 0004: $IS_CRUSHER_CRUSHING = 1 00D6: if 0 0256:   player $PLAYER_CHAR defined 004D: jump_if_false ££CCCrushing 00D6: if 0   0057:   player $PLAYER_CHAR 0 ()in_cube 801.63 57.8 5.0 814.0 63.3 10.0 004D: jump_if_false ££CCCrushing 0222: set_player $PLAYER_CHAR health_to 0 0006: 0@ = 1;; disables reward :CCCrushing ;; actual crushing process - move object etc. ;018D: 3@ = create_sound <placeholder for sfx00452> at 804.73 60.3852 7.09806 0006: 4@ = 0;; switch used to alternate between left and right 0006: 5@ = 2000;; time span for shaking until vehicle is destroyed 0006: 6@ = 5  ;; determines speed of shaking "anim" 0006: 16@ = 0     0050: gosub ££CCShakeLoop 00A6: destroy_car $CCCraneCar 0006: 5@ = 1000;; time span for shaking after vehicle is destroyed 0006: 16@ = 0 0050: gosub ££CCShakeLoop   ;018E: stop_sound 3@             ;; end of crushing, give reward if player wasn't killed in the crusher 00D6: if 1 0256:   player $PLAYER_CHAR defined 0039:   0@ == 0 004D: jump_if_false ££CCLiftLid     0109: player $PLAYER_CHAR money += 1@

This post has been edited by SteaVor on Saturday, Apr 17 2010, 14:56

[Craig Kostelecky]

Thanks for the update. It's integrated into my code and I'm about to test it.

[SteaVor]

Great, let me know whether it works the way it should.

For clarification of the "fairly accurate" bit:
- as far as I could deduce by testing, the III EXE doesn't add a random element into the equation, so I didn't either. I tested about 15 different combinations of models and health states and always got results that were very close to the III results.

I've made the base reward depend on the vehicle classes, but I didn't verify whether all of the models would yield the same results in III and LC, but as mentioned above the models I did use for comparison gave pretty accurate results.
After all it was only supposed to be the first try at getting more accurate crusher rewards and it's definitely better than the placeholder "let's add up model id and health" approach.

[Craig Kostelecky]

Close is plenty good enough. Especially since money in GTA3/LC is pretty meaningless.

I did add a couple of lines to the code, although I wasn't sure if it was necessary. It just sets 1@ to 120.0 if the vehicle being crushed is any other vehicle that's not specifically mentioned above in the code. That way if someone enables a Vice City car (or crushes the General Lee) it should still work.

Maybe that was factored in there somewhere, but I didn't see it in the short time I looked.

[SteaVor]

I had added a default / fallback value of 70.0 in the code, just above the first model check:

CODE

0007: 1@ = 70.0                 ;; reward base value used for all models not listed below

[Craig Kostelecky]

Silly me. By the way, did you mean to remove this line from the end of that code (just before the player's given money)

CODE

00A5: 1@ += 2@

It seems like with that removed they only get the value of the class of the car with nothing taken into account with the health of the vehicle.

[SteaVor]

Do you really get the same amount of money with a new and a damaged car of the same model?

I think the player should get (health/1000) * (base reward as determined by class) as reward, so the class-dependant part of the reward is in fact the maximum reward which you'd get if you brought a vehicle in mint condition to the crusher.
The corresponding calculations should all happen inside of CCCalculateFinalReward, although I cannot guarantee that this is indeed the latest version of the code as I produced and tested it, I just know it's the latest published version of the code. If it doesn't work as intended it would be the engine rounding all the fractions of the health up to 1, but that should only happen with integer variables (which is why I needed to convert the health value to float in the first place.)

The line I removed at the end was the only line dealing with calculating the reward before I had decided to change the reward calculation: health and model id are added up and used as final value for the reward. That's what my modifications were supposed to replace, so this "bogus/ placeholder" line should indeed be removed.

[Craig Kostelecky]

Yup, you're right. After reading the code, that's what is happening. I'm still a little rusty at scm coding, but getting back into it.

The crusher works well, when the car is actually picked up. For some reason, the crane only comes down if the car is in just the right place (and that place is not in the middle of that rectangle). So that's something I want to fix. The problem I was having with the crusher was I wasn't waiting long enough after stopping before getting out. We were using the is_player_stopped_in_rectangle opcode. I switched it to simply is_player_in_rectangle and it now picks up the cars even when you exit it quickly.

Hopefully I can get the files I have together for a Beta 3 release in the next few days. That way anybody can test what's happening. There's just one more thing I want to add to the scm before I get everything together.

This post has been edited by Craig Kostelecky on Saturday, Apr 17 2010, 22:04

[spaceeinstein]

Another light bulb lit up in my head: A workaround for the Lift Bridge alarm sound! This is just a test code. You have to edit the coordinates and radii to make it more authentic.

CODE

:SSVBRIDGE 03A4: name_thread 'SSVAUD' var 0@ : float 1@ : float 2@ : float 3@ : float 4@ : float 5@ : float 6@ : float end 0@ = -493.0 // sound x pos 1@ = -631.0 // y pos 2@ = 53.0 // z pos 6@ = 1.3 // radius - the smaller the number, the farther you can hear, up to minimum of 1.0 while true    wait 50    if        player.Defined($PLAYER_CHAR)    then        if            00F5:   player $PLAYER_CHAR in_sphere 0 near_point 0@ 1@ 2@ radius 400.0 400.0 400.0        then            0054: store_player $PLAYER_CHAR position_to 3@ 4@ 5@            3@ -= 0@            4@ -= 1@            5@ -= 2@            3@ /= 6@            4@ /= 6@            5@ /= 6@            3@ += 0@            4@ += 1@            5@ += 2@            018D: 7@ = create_sound 40 at 3@ 4@ 5@        end        wait 1558 // twice the duration of sound        018E: stop_sound 7@    end end

This will create an alarm at the Staunton end of the bridge. The alarm can be heard very far away. I'm practicing on this new way of coding. It seems more efficient than the traditional way of SCM coding.

This post has been edited by spaceeinstein on Wednesday, Apr 21 2010, 18:17

[SteaVor]

Ohh great, I was just about to begin coding something similar to your code, actually.

EDIT: The duration of the sound is between 779 and 780 ms*, so a wait 729 should work well.


* 10136 / 13000 = 0,77969230769230769230769230769231

EDIT2: Sorry for the confusion space, I've got too many tabs opened in my browser...

This post has been edited by SteaVor on Wednesday, Apr 21 2010, 18:01

[spaceeinstein]

Don't worry about it. Somehow the numbers still result in overlap of sound occasionally. Maybe the exact duration of sound isn't correct.

[SteaVor]

The duration (779.7 milliseconds) should be correct, but the SCM loop isn't guaranteed to be executed in the exact same time span.

Did you really mean to put the "WAIT 779" in the code? That should read "WAIT 729" instead, shouldn't it?

[spaceeinstein]

Sorry, it was my mistake. The time between the creation of the sound to the destruction of the sound should've been the duration of the sound, not minus 50. The 50 happens before and after the sound doesn't exist. The overlapping sound problem still exists at both 729 and 779, though. Even using wait 0 instead of 50 didn't solve the problem.

EDIT: Using twice the length of time (1558) seems to minimize the effect of occasional overlap. The code is now updated. My ear is full of ringing now.

This post has been edited by spaceeinstein on Wednesday, Apr 21 2010, 18:19

[Craig Kostelecky]

Awesome! I LOVE the changes you've been making space.

[spaceeinstein]

Thanks

Here are more fixes.

Silence the Sneak:
Find

CODE

:LabelLC06D000

Remove above (along with the comment)

CODE

jump @LabelLC06D04A

Replace below

CODE

03D0:   wav 1 loaded

with

CODE

83D0:   not wav 1 loaded

This fixes the apparent infinite loop that occurred in that code.

Ammunation Uzi pickup:
Find

CODE

0213: $UZI1 = create_pickup #UZI type 1 at 735.5 -400.75 21.1875

Replace with

CODE

0213: $LC400 = create_pickup #UZI type 1 at 735.5 -400.75 21.1875

Find

CODE

0215: destroy_pickup $UZI1 0213: $AMMUNATION_UZI_PICKUP = create_pickup #UZI type 1 at 735.5 -400.75 21.1875

Replace with

CODE

0215: destroy_pickup $LC400 0213: $LC400 = create_pickup #UZI type 1 at 735.5 -400.75 21.1875

This should fix the double Uzi pickup at Ammunation but I haven't test it thoroughly yet.

About that 041C workaround, there's a potential glitch that can happen similar to the Marco's Bistros sound error. To prevent that, just change all "wav 1" to "wav 2" in that thread. It might conflict with the Lift Bridge audio but since the audio events are not near to each other, this problem might not arise. About the Securicar passenger's audio, the code only applies to the person while he is on foot. The code did not control his audio while driving so it was a hardcoded feature in III. I don't know if it's worth it to create a workaround to that.

EDIT: I just wasted a few hours changing "Don't Spank Ma Bitch Up" and "Drive Misty for Me" to understand this different style of coding. It makes reading the code much more easier but the conversion process is very long. I don't know if it's worth replacing the original code with. It functions exactly the same as the old code.

This post has been edited by spaceeinstein on Friday, Apr 23 2010, 15:28

[spaceeinstein]

I think there's a problem with the "Radio" thread. It is forcing all vehicles to tune into a permanent radio station. Was it meant to happen only while in Delorean mode? And a small fix for the Delorean code:
Find

CODE

:TIME_4102

Below it, fix the "if" to "if and".

And here's a list of checkpoint elevation fixes, though in no particular order so you might need to search up and down.

Find (there are two of them)

CODE

018A: $FRANK2_CHECKPOINT2 = create_checkpoint_at 1194.0 -827.0 -100.0

Replace with

CODE

018A: $FRANK2_CHECKPOINT2 = create_checkpoint_at 1194.0 -827.0 16.82

Find

CODE

018A: $LC7996 = create_checkpoint_at 927.0601 -1099.38 -100.0

Replace with

CODE

018A: $LC7996 = create_checkpoint_at 927.063 -1099.375 16.86

Find

CODE

018A: $LC7136 = create_checkpoint_at 1110.75 -796.688 -100.0

Replace with

CODE

018A: $LC7136 = create_checkpoint_at 1110.75 -796.6875 16.82

Find

CODE

018A: $LC7996 = create_checkpoint_at 921.5601 -1099.25 -5.6875

Replace with

CODE

018A: $LC7996 = create_checkpoint_at 921.563 -1099.25 16.8675

Find (2 of them)

CODE

018A: $FRANK3_CHECKPOINT1 = create_checkpoint_at 1194.0 -824.0 -100.0

Repalce with

CODE

018A: $FRANK3_CHECKPOINT1 = create_checkpoint_at 1194.0 -824.0 16.82

Find (2 of them)

CODE

018A: $FRANK4_BOAT_CHECKPOINT = create_checkpoint_at 230.25 -678.375 -100.0

Replace with

CODE

018A: $FRANK4_BOAT_CHECKPOINT = create_checkpoint_at 230.25 -678.375 6.79

Find (2 of them)

CODE

018A: $THE_CROOK_FACTORY_CHECKPOINT = create_checkpoint_at 870.69 -789.188 -100.0

Replace with

CODE

018A: $THE_CROOK_FACTORY_CHECKPOINT = create_checkpoint_at 870.69 -789.188 19.66

There's something I didn't expect when I tried to use the original models for A Drop in the Ocean. I changed (there are 6 of them)

CODE

-139 (BRIEFCASE)

to

CODE

#FLOATPACKGE1

And the package has a halo, just like the weapons do. I had thought only weapon pickups have the halos. For pickups of that floats, the halos don't float with the object so it's suspended in the air. So either revert to the original workaround or remove the halo through the exe.

The Dodo in A Drop in the Ocean seems to be incredibly weak. I just smacked into it with my helicopter and the Dodo burst into flames.

This post has been edited by spaceeinstein on Friday, Apr 23 2010, 16:05

[Craig Kostelecky]

If you went through the work to convert some missions I'll take that updated code, even if it doesn't change the way the game is played. And I agree that's much easier to read.

Regarding the radio code: all of the new DeLorean code was written by bluespace88 at the BTTF Hill Valley forums. I couldn't wrap my head around all of that code, so I just included it all. I think you can even time travel in the DeLorean if you can find a way to activate the time circuits. I believe they did that with an asi file in the version I used. The radio code was necessary to keep the audio constant as the DeLorean switched. In my original code, it was simple enough that the radio didn't switch, but in their code (which looks awesome!) the radio does switch. The radio station isn't a permanent one, but just the last station that was tuned to. There is a minor bug in there which skips the mp3 channel which I plan on fixing.

Also, the new DeLorean code is only activated when in debug mode, or after you hit 100%.

space, if you think any of that code should be changed, you have my blessing to alter it. I just thought it was really cool to have the tires animate when it started flying and to be able to fly forward as well. The subtle effects that they figured out really impressed me and I asked him if he was okay with me including in this mod and he said yes.

Boy, that sure turned into a ramble.

And I'm not even sure if the health of the plane can be controlled. I haven't looked at that code in a while.

[SteaVor]

QUOTE (Craig Kostelecky @ Apr 23 2010, 18:56)

The radio station isn't a permanent one, but just the last station that was tuned to.

At first I also thought it was only meant for the DeLorean transition and was about to fix it to make it apply only to that situation, but after some minutes of playing I actually began to appreciate that the current code emulates San Andreas in that it prevents the radio station from changing randomly every time I switch vehicles.

This post has been edited by SteaVor on Friday, Apr 23 2010, 17:13

[Craig Kostelecky]

QUOTE (SteaVor @ Apr 23 2010, 12:09)

but after some minutes of playing I actually began to appreciate that the current code emulates San Andreas in that it prevents the radio station from changing randomly every time I switch vehicles.

Yeah, it does that. But it does it at the expense of the mp3 channel. From what I can tell, you cannot use the set radio opcode to the mp3 station. So if you cycle through the options, you cannot listen to your custom mp3s. I do not like that. Maybe I'll just scrap the radio thread and deal with it switching in the DeLorean.

[Craig Kostelecky]

I fixed the crash with the emergency crane. It turns out we don't have to do anything to the exe at all. We just had to load the #BONUS icon before creating the pickups. I also added that code to both IE garages to be safe. I tested the EV crane with both IE garages completed and I did it several times without a crash. I've also uploaded an update package with most of space's work added to mine. Get it in the download thread.