Changing Property Prices

[Midnightz]

I think this would be relevant to anyone working on a mission mod that involves offering new or adjusted ways of making $$$ in GTA SA. If this has been covered before, please inform (searched but did not find).

 

I stumbled onto something that troubles me greatly and leaves me with questions like:

 

- Is there a predetermined (hard coded) budget for the entire game? CJ can only potentially make and spend $X?

- Are there predetermined max dollar amounts for separate aspects of the game?

- At what point/in what ways might string limits be an issue in terms of $$$?

 

The original game permits gambling and greatly increases the potential for making large sums of money... money that is never spent because an excess of it is simply not needed to complete the game - right?

 

My mission mod puts additional money into the pot, so to speak - by offering new ways of making $$$ to the player, as well. To put the excess money to good use, one of the things I am doing is upping the prices of all Properties. This should be simple enough or so I thought...

 

I experienced oddities right off so I immediately put aside my mission mod and began working with the original SCM to prevent ANY other potential influences/mistakes.

 

In main.scm, we find the default property values are handled by variables $1653 thru $1684. Cake, just change these numbers and we have new prices... but not quite. To begin...

 

When I changed this property value to:

 

0004: $1656 = 1500000    // SANTA MARIA BEACH HOUSE

 

...it will not display that price w/the property icon but WILL deduct the correct amount of $$$ when purchased.

 

Another attempt:

 

0004: $1679 = 41000      // JEFFERSON

 

...this^ works, shows the correct number in text AND deducts that amount of $$$ when purchased. So maybe there's a char limit to the textual display?

 

Some properties by default can use 6 digits (120,000)... but for some reason, I can't get 6 digits to work - nevermind 7 digits. So I did some testing and discovered some very strange results...

 

If I try this:

 

0004: $1656 = 327675    // SANTA MARIA BEACH HOUSE

 

...that^ is the highest number the game allows for it.

 

How do I know? If I make the number higher, it generates a much smaller number which increases depending on the original number - which gave me an idea... I saw that 327690 generated $10, so I changed it to 327680 and the game generated no number, instead it generated text: "Press blah to purchase property." Weird.

 

So then I tried 327679 and it generated 327675. Whoa. Okay so after even more testing I determined the first dollar value (the ones), in this case 327675, can only be 0 or 5. Anything else will cause it to round up/down.

 

But why is it when you exceed 327675 for the Beach property, will it always display the total # that goes over some kind of limit?

 

What is this limit? Is there a collective total for all property that can not be exceeded? Or is there a total number that each property can not exceed? Or is there a collective total of ALL money (a set budget) that can not be exceeded because in the default game (played normally and without cheats), CJ can never make more than $X?

 

I went ahead and changed ALL property values to higher numbers but stayed just under 327675 and all are working perfectly. However, staying under that amount was never my goal.

 

I think I stumbled on something very important, critical even to the development of any $$$-based mods but I sincerely hope not... please tell me there isn't a hard-coded magic number or some sort of weird textual limitation.

 

Many thanks in advance,

-Midnightz

 

[OrionSR]

Here's a little more info that might help you track down the problem. The value of the property is stored in a dword, I'm fairly sure it is signed. I strongly suspect that any value entered for the property (negative or positive) will be applied to CJ's cash appropriately with a functional range of 1,073,741,823 to -1,073,741,824. (should be -2147483648 to 2147483647)

 

The value displayed apparently needs to go through some sort of conversion to display properly as text. As you mentioned, the last digit is rounded, so lets drop it completely and work with 32767 as a factor of 10 instead of the limit of 327675 you had identified. 32767 is the maximum limit of a signed word. My hunch is that the dword to text conversion isn't using matching variable types and this is leading to the confusing display. I guess the next step would be to create a row of property pickups to test this hypothesis, but since you are working on the project I'll turn it back over to you.

 

BTW, an Asset would need to go through a similar conversion, but the asset's accumulated value is stored in a float.

 

Update: Yep, assets do the same thing. If you place CJ just out of range you can watch the numbers continuously update. I seeded my Pirate Asset with a value of 325000, changed the maximum limit to 10000000, and left the maximum rate of 65535 (too fast). I stood back and watched as the value went over your limit of 327675 and the displayed value rolled over to 0 and started building again. The asset payed out the all the money.

 

And sorry about this, but while I'm thinking about it... Does anyone have any idea how to add money to the current value of an asset using mission codes? These functions are apparently hidden in the engine somewhere.

Edited January 18, 2008 by OrionSR

[Midnightz]

 

I strongly suspect that any value entered for the property (negative or positive) will be applied to CJ's cash appropriately with a functional range of 1,073,741,823 to -1,073,741,824.

Can you share with me... why you suspect that specific number?

 

 

The value displayed apparently needs to go through some sort of conversion to display properly as text.

Great, are we playing "Match this number to this letter" or something along those lines?

 

 

My hunch is that the dword to text conversion isn't using matching variable types and this is leading to the confusing display.

Interesting idea. Hmm...

 

And this limit affects Asset properties too, I see. Thank you for testing and confirming that.

 

 

Does anyone have any idea how to add money to the current value of an asset using mission codes?

Actually, I am glad you asked that - been wondering also.

 

Thanks again OrionSR.

 

 

I'm going to sleep on this, try again tomorrow. I hope some EXE-divers take a look in the meantime.

 

[Seemann]

The EXE-divers for the rescue!

 

The current asset value is stored in the memory twice:

1) in the object structure

2) in the pickup's record.

 

 

The first field holds the money amount to be shown above pickup. It's only 2 bytes (unsigned) in size, that makes maximum value to be stored here of 65535 (uint16 limit). As this value is way too small for some properties, Rockstar uses a multiplier of 5.0 for this value. When game displays the money number, value at this field is multiplied by 5.0 and the result is what we see (that's why the last digit is always 5 or 0).

 

 

.text:00457650     fmul ds:flt_858CDC    ; 0.2 = 1/5.text:00457656     call FloatToInt.text:0045765B     mov [esi+13Eh], ax    ; object struct field = money / 5

 

 

So, as the maximum value is 65535, the maximum money amount we could see before it resets to zero is 65535 * 5 = 327675.

 

 

CJ gets the correct amount of money just because the engine reads the field not in the object's structure, but in the pickup record, which holds the value as a floating-point value in the field of 32 bits.

 

How to break this limitation? I would change that multiplier to 100.0 or 1000.0 to get the limit of 65535 * 100.0 = $6,553,500 to display, which is more than enough. But unfortunately, this multiplier is stored in the variable, value of which is used everywhere in the code, and changing it could crash the whole game. Even more, there's another procedure which also calculates this visible number (just before draws it on screen) and it uses not a variable multiplier but expression:

 

.text:00455B42     movzx eax, word ptr [esi+13Eh]   ; eax = object struct field = money / 5.text:00455B49     movzx ecx, ds:word_8CD5E8.text:00455B50     lea edx, [eax+eax*4]   ; edx = eax * 5 = (money /5)*5 = money

 

 

Yeah, it's possible to change it and break the limit, but it requires careful code editing, and I'm still not sure if it will work on any game version due to possible different memory offsets.

 

 

 

P.S. As for changing the value of an asset pickup, Rockstar just destroys the pickup and creates a new one. I could implement some CLEO opcodes to alter proper memory addresses to change the current/maximum money value/rate, if needed?

 

[OrionSR]

Just a few notes on the number formats. It looks like I slipped a digit in the numbers on my previous post, sorry. The idea here is to enter the hex value in a calculator or spreadsheet, then translate it to decimal. If the integer is signed then the 1st bit is used to denote positive or negative, split the difference for the signed limits.

byte FF 255 -128 127

word FFFF 65535 -32768 32767

dword FFFFFFFF 4294967295 -2147483648 2147483647

 

 

The following data types and structures are used within this article:

 

    * INT8/UINT8 - signed/unsigned 8 bit integer (1 byte)

    * INT16/UINT16 - signed/unsigned 16 bit integer (2 byte)

    * INT32/UINT32 - signed/unsigned 32 bit integer (4 byte)

    * FLOAT - single precision floating point number (4 byte)

 

Interesting. A factor of 5 makes considerably more sense. I couldn't figure out why the value rolled over to 0 instead of negative with the factor of 10 I had assumed.

 

Again with the Topic Highjacking:

 

We (PD and I) are currently using a patch utility to add an initial starting value to an asset, to clean up the GrayZone/Map Fog Array, to increase the nitrous count of any cars in the garage with NOS to 127, and to rename the save. We've been able to find methods to code almost every other modification, including the Zip Blue shorts, and now v2 IPL objects. CLEO is being used for the starting file anyway to save in the Jefferson Alley, so this type of function would definitely fit the requirements of an elegant solution. The current save routine leaves CJ standing facing north; is there any way to change this so CJ faces east (he will always be facing east for this application)?

 

We are building starting files so we have all the control we currently need for adjusting the rate, maximum limit, and other properties of an asset pickup - the current value is the only thing we can't touch. The problem we are having is that our special pirate booty asset doesn't build unless CJ is fairly close, and there isn't any particular reason for CJ to be in that area, so it never pays out very much unless we fill it up at the start of the game. Other assets seem to get updated when CJ arrives in the area (unless he warps straight to the asset), but not the pirate booty. I'm not sure if it's a problem with the remote underwater location or perhaps there is something going on with the standard pickups that I'm not aware of.

Edited January 18, 2008 by OrionSR

[Seemann]

 

Just a few notes on the number formats. It looks like I slipped a digit in the numbers on my previous post, sorry. The idea here is to enter the hex value in a calculator or spreadsheet, then translate it to decimal. If the integer is signed then the 1st bit is used to denote positive or negative, split the difference for the signed limits.

This is well described here.

 

 

The current save routine leaves CJ standing facing north; is there any way to change this so CJ faces east (he will always be facing east for this application)?

The game does not change player's angle (heading) while creating it (after starting a new game or loading save), so it's quite impossible without some kind of hook changing exe code.

 

 

We are building starting files so we have all the control we currently need for adjusting the rate, maximum limit, and other properties of an asset pickup - the current value is the only thing we can't touch.

Why not change this

 

Pickup structure:

  0    float          current asset value

to a pre-defined number, say $10000?

[Midnightz]

 

The EXE-divers for the rescue!

Thank you. I suspected a multiplier was to blame - same for speed values depending on the opcode in use... I'm sure you remember my frustration.

 

You mentioned altering this multiplier but what about possible workarounds... like bypassing it altogether?

 

1. Said multiplier does not appear to affect weapons, clothing, haircuts... edit the shopping.dat file for these and there's no problem. There is a blank "Properties" section in that file. Forgive my limited understanding of how these files play together but would it be possible to utilize this blank space?

 

2. Or code rewrites...

 

0518: $BUY_ASSET_PICKUPS[31] = create_available_asset_pickup 'PROP_4' at $X_PROPERTY_TO_BUY[31] $Y_PROPERTY_TO_BUY[31] $Z_PROPERTY_TO_BUY[31] price $1684  // You cannot buy this property yet.

 

These lines^ are what print the value to screen, yes? Is this multiplier just assigned to $1653 thru $1684 variables or does it execute at only certain intervals (opcodes etc) in the code? Or is it this very line that has a (text) limit? I'm wondering... Can we change the "price $1684" to an actual number like so, "price 2,350,110" or use a completely different variable in these lines without breaking the code?

 

I understand at face value what you've described... I am just trying to see where/when/how it lines up with the SCM code. Thanks for your patience with me.

 

-Midnightz

 

[spaceeinstein]

The price limit is what you see. It doesn't affect anything else in the game other than visual effect. The only way to correct the visual error is to do what Seemann said.

[Midnightz]

Okay thank you spaceeinstein. I just wanted to doublecheck.