Staredit Network

Ok, I will explain why you'd ever want to save large amount values when there are hundreds of integer variables(unit's death counter). Most of RPG map has got only one main character. The system saves only one character's stats such as level of character, how many items he carries and so on.. You can't save two character's stats in one variable. If you want to save two character's stats then you have to use two different unit's death counter.

Now what if you want to make some map that is based on Squad-Action like Fallout Tactics? If one character has 30 values to store then the values you have to save will multiply as you increase the size of squad. For example, if there are 6 memebers in a squad then you need to save 180 values. Not only that, if 6 players are going to play then there should be 180 X 6 values in total! That's outrageous amount.


So how can we do it?

We first need to know what variables can be accessed. Ok, we know Starcraft stores unit's HP, shield amount, and other values. But these values can't be set since EUD triggers got disabled. Then what about unit's position? Unit's position can be gained without using EUD triggers, and it has two parameters, X coordinate and y coordinate. So we get one more variable for FREE!

If we want to store 10 boolean values then we would use 1 unit per 1 boolean value, so that we can represent 1 or 0 by unit's existance.


How about number between 0 to 9? In order to save value we can either use different unit to represent different value or we can make space sized 1x10 and put one unit on specific position to represent different value.


What about 0 ~ 99?
We could use same method as storing value between 0 to 9. But this time we have to make two spaces to save different position in number.
We can store first position in number to space1 and second position in number to space2.

What about 0 ~ 999?
Exactly same pattern as saving number between 0 ~ 99. Have 3 spaces and each space saves different position in number.

What about 0 ~ 9999999?
Whoops, it seems we need lots of units to save each position in number.

Following this pattern isn't a good idea. So we'd have 2 dimension rather than having one dimension.

(note: X coordinate and Y coordinate is subjective to position of space. They MAY NOT represent real coordinate in the map.)

We can get x coordinate of unit and y coordinate of unit and x coordinate would save first position in number and y coordinate would save second position in number. Space size would be 10 X 10.

But, since space size if pretty small we can only store 0 ~ 99. What if there is much bigger number than 99? Something like 999999? If we increase the size of space we have wider range of number. So, for example, if the size of space becomes 100 X 100 then we can save number between 0 ~ 9999. Eh? But this would consume too much space!.

You'd have heard about heximal number. It has 16 based digits. I don't how this method could be related to heximal, but it gave me an idea anyway. We divide the space by two and use 2 units. See what happens if we do so. We have same space as before, 100 X 100. But this time since we divided it by two, we have 2 spaces sized 50 X 100. How many possible values can two of 50 X 100 spaces make?

Uh, I need a calculator! 50 X 100 X 50 X 100. Is it? Tell me if I'm wrong.
By using extra one unit, we have increased the range of number to enormous number!

So finally what you need to know is what happens in real system.
(note: This is only simplied version.)

Request (Save 150 at address 00001)
Move the location to specified address.
Convert the 10 digit based number to 50 digits based number.
Put the unit in this address.
DONE!!

Request (Load the variable from address 00001)
Move the location to specified address.
Evaluate the X coordinate and Y coordinate of unit.
Convert the value to 10 digits based number.
DONE!!


By the way, you wouldn't be able to understand this system if you haven't understood the concept of moving location to anywhere you want.

If you have better idea then please let me know because this system consumes 1800 units to store 30 X 6 X 5 variables!



Edit: miscalculation.

I didn't completely understand that.
Please explain to me what exactly this can do. (Store values... Okay... what values, for what?)

Primarily integer values. The reason why you'd use this method is because there aren't sufficient no. of unit death counters, of course, only if you are very greedy like me. And also you have to code extra triggers if you save different value in different unit's death counter. This method is good way to unite those triggers, so that you only need to code one pack of triggers for saving and loading values.


Here is an example.

Let's assume that there are two mapmakers, and they both want to store 10 numbers from 0 ~ 9.

Mapmaker A uses 10 unit's death counters to store 10 values.
Mapmaker B uses method I describe above to store 10 values.


Let's compare the efficiency
(note: This might not totally accurate, but it generally gives you an idea which method is more efficient)

Mapmaker A doesn't need to use any extra units, but he have to make 10 times more triggers than Mapmaker B.

Mapmaker B have to use extra 10 units, but he doesn't need to make any extra triggers.

Why? Because mapmaker A doesn't use any intermediary. Think about this in terms of real life. What would happen if there is no post office? Everyone should deliever their own mail to their recievers.

Hm.. It's pretty hard to explain. I think it would be best if you try both of these methods by yourself and learn the difference through experience.

Have I answered all your questions?

You can completely ignore this method if you never gonna make squad-action based system. Because there are enough unit's death counters you can use.

shoulden't this be in assistance?

No.

Im still not getting what this can be used for, sorry. I understand more than I did before though

no it shouldnt be in assistance cuz hes not asking for help, hes explaining a concept...

Instead of using a seperate value for seperate characters, why not have 1 value to determine the characters, and reuse the same 30 values which each character will use. For example, 1 value will determine character strength. The way you've done it you'll need 6 different units to store 6 character values. But what if you use 1 unit to determine a character? Say a cantina death. One death = char 1, two deaths = char 2 etc. etc.. This way, it'll save triggers, and death counters.

A condition example would look like this
death(currentplayer,exactly,1(first char),cantina);
death(currentplayer,at least, 20,(first value)marine);

And adding to what Mp)Sniper said, you could also use the "players" part of a death counter as well. Such as setting deaths for p1 p2 p3 p4 etc and for each player it means a different thing as well as the number of deaths and the death unit.

Yeah, I have a question. Why would you want to waste map space for this?

Also, what is your algorithm to change coordinate values into integer values and where will this value be stored?

That's what I was thinking but a 10x10 area isn't really that big compared to a 256^2 map for a huge RPG. I'm sure through all that terrain your going to have SOMETHING left.

(Note: This may take several minutes to fully understand. So if you have got something to do, I strongly recommend that you do not read this)



This method should be used only if you are going to use more than 1 character per player to store stats.

Let's say that a squad is made up of 6 members and 5 players are going to play, so you need store all these values.

Player1 - Member1, Member2, Member3, Member4, Member5, Member6.
Player2 - Member1, Member2, Member3, Member4, Member5, Member6.
Player3 - Member1, Member2, Member3, Member4, Member5, Member6.
Player4 - Member1, Member2, Member3, Member4, Member5, Member6.
Player5 - Member1, Member2, Member3, Member4, Member5, Member6.

It's like 30 players are playing!



No. of points you must know

- Player should not be able to select more than one member at a time. Because if player select several members at a time (Not selecting them by mouse), then there will be data inconsistency. Why?


Here is the algorithm. (Very simplified, inefficient and do not cover small things)


Values

Healing potion = marine's death


(note: TEC = trigger execution cycle. Within 6 TECs, system can load any values and modify them accordingly.)


1st TEC

Load the values of Member1 for each player. Values will be modified according to player's action. For example, if player have used Healing potion then subtract 1 from marine's death and save it.


2nd TEC

Load the values of Member2 for each player. Values will be modified according to player's action.

Do the same steps for Member3, Member4, Member5 and Member6 for each player.

So we have interval of 0.6 second before system load the Member1's value again.
You must be thinking why not just do these all steps in one TEC. It's because game will lag if there are so many things to be calculated. So we divide them and don't let game lag.



FYI: Here is the list of actions that takes CPU from highest to lowest.

1. Create Unit - Save value
2. Move Unit
3. Give Unit
4. Remove Unit - Load value
5. Move location


Try this method on small projects then you may understand it quite easily.

Well, then have each character have their own death count. It would be 1x30 characters PLUS the 30 different values instead of 1x30 characters TIMES the 30 values.

I must not know how to count because I see 6 players and 36 members.

Whooops.. My mistake. heh, just fixed it. Thx for noticing it!!