player_num=(per player cap) and global_num=(global cap)
Where the default value of global_num is player_num*n#teams.
Unit limits
Moderator: Moderators
I still think the best approach is to bundle it into a concept of "supply-style resources" where the existence (or activation) units X/Y/Z contribute to supply resources and the existence (or activation) of units A/B/C consume supply - and more units of classes A/B/C cannot be created (or activated) until more of the resource is created.
To create unit limits you just have one supply-resource per unit (or per group of units) and have the Comm create a contribute a fixed amount of the relevant supply resources.
To create unit limits you just have one supply-resource per unit (or per group of units) and have the Comm create a contribute a fixed amount of the relevant supply resources.
Pixtl, a unit limit and limits by supply are two different things. Supply limit would be handled by a third resource that is occupied while a unit is alive.. take a mod and change the units to give energy storage -1000 each... once you have used all of your energy storage you can build NOTHING... food would work like that.
What this request is asks that there be only X number of Y units. Period. that is all. Please discuss food in another thread, that discussion does not belong in this thread. It is not the same thing.
KDR_11k, that is an interesting thing.... that could actually be done kdr, but it would be limited to that specific group. It would still be better for what pxtl is asking to have a food limit.
Anyway, I digress, So about that unit limit....
What this request is asks that there be only X number of Y units. Period. that is all. Please discuss food in another thread, that discussion does not belong in this thread. It is not the same thing.
KDR_11k, that is an interesting thing.... that could actually be done kdr, but it would be limited to that specific group. It would still be better for what pxtl is asking to have a food limit.
Anyway, I digress, So about that unit limit....
With enough different supply resources, you've got unit limits. That's why I suggest it. A single system that can handle both functionalities - unit limits and supply.smoth wrote:Pixtl, a unit limit and limits by supply are two different things. Supply limit would be handled by a third resource that is occupied while a unit is alive.. take a mod and change the units to give energy storage -1000 each... once you have used all of your energy storage you can build NOTHING... food would work like that.
What this request is asks that there be only X number of Y units. Period. that is all. Please discuss food in another thread, that discussion does not belong in this thread. It is not the same thing.
KDR_11k, that is an interesting thing.... that could actually be done kdr, but it would be limited to that specific group. It would still be better for what pxtl is asking to have a food limit.
Anyway, I digress, So about that unit limit....
somewhere in the code would be
if(limit > used + added)
used += value_for_unit;
carry on building
e.g.
[rx]
{
num = 60;
units = rx79rl, rx79zook, rx79plus;
rx79rl=-1;
say the group is already full and we're going to try build an rx79rl:
if(60 > 60 + -1)
60 += -1;
//build
This means a resource thing can be setup this way with say a house building as a means of increasing group size.
if(limit > used + added)
used += value_for_unit;
carry on building
e.g.
[rx]
{
num = 60;
units = rx79rl, rx79zook, rx79plus;
rx79rl=-1;
say the group is already full and we're going to try build an rx79rl:
if(60 > 60 + -1)
60 += -1;
//build
This means a resource thing can be setup this way with say a house building as a means of increasing group size.
AF, at that point it's the same as a supply system, except that you've changed it so that the variables declare their unit instead of the unit declairs the variables they consume. So then we're in the exact same place. Anyways, the other advantage of a supply system is that you can weigh units differently. Let's say that you want a limit on the number of L3 mechs in AA that you can use - so you do say the Krog consumes 8 L3 supply, the Krogtaar consumes 1, and the Juggernaut consumes 2 - the Gantry produces 4 and the Comm produces 8.
So you have a set of tags. First, your sidedata includes definitions of the supply classes (can be one supply class per unit if you want unit limits). Supply class definitions include name, base amount, whether or not the supply limit is globally-shared, etc. That also includes the gui-handling of it:
always-on - list the Supply level in the form NAME: X/X in the top right,
message - update NAME: X/X when supply changes in the message bar.
when-full - like message, but only when full
hidden - supply level is never shown
Finally, each unit just includes a "consumessupply" with the name of the supply, and a "producessupply" with the name of the supply.
Trivial to use for unit limits, allows weighted unit limits (so a Krog is not equal to a Karg if they are in the same limit-group) adjustable unit limits with new buildings (so your Geotherms increase the unit limits), etc.
See?
After all, a "farm/supply" system will be needed eventually, and it seems like that would be the best way to go about it. Later you can add bindings to script so that suppliers/consumers are on/offable. Do you really want two redundant systems? Aren't the files complicated enough already?
Now, if you think "but that sounds more complicated and harder to implement" - the "groupable" unit limits come out being just as complicated. I'd just go straight-up literal unit limits if you need a simpler system. Just add a single tag to the FBI file for "limit" and do the unit limits per-unit. Simplest system possible. Factory just check's the unit's definition for it's limit before buiding, and skips the unit if limit is reached.
So you have a set of tags. First, your sidedata includes definitions of the supply classes (can be one supply class per unit if you want unit limits). Supply class definitions include name, base amount, whether or not the supply limit is globally-shared, etc. That also includes the gui-handling of it:
always-on - list the Supply level in the form NAME: X/X in the top right,
message - update NAME: X/X when supply changes in the message bar.
when-full - like message, but only when full
hidden - supply level is never shown
Finally, each unit just includes a "consumessupply" with the name of the supply, and a "producessupply" with the name of the supply.
Trivial to use for unit limits, allows weighted unit limits (so a Krog is not equal to a Karg if they are in the same limit-group) adjustable unit limits with new buildings (so your Geotherms increase the unit limits), etc.
See?
After all, a "farm/supply" system will be needed eventually, and it seems like that would be the best way to go about it. Later you can add bindings to script so that suppliers/consumers are on/offable. Do you really want two redundant systems? Aren't the files complicated enough already?
Now, if you think "but that sounds more complicated and harder to implement" - the "groupable" unit limits come out being just as complicated. I'd just go straight-up literal unit limits if you need a simpler system. Just add a single tag to the FBI file for "limit" and do the unit limits per-unit. Simplest system possible. Factory just check's the unit's definition for it's limit before buiding, and skips the unit if limit is reached.
however this system could be expanded to allow multiple setups of this system, and then we would have a basic resource system, all we'd need is resource producers and consumers, and to tie in binds to the different ways of generating resource. Then we can eliminate energy and metal and simply define them here.
I believe it would be better todo it in a seperate file like this than have it in the unit fbi. Afterall arent modders saying it's easier to deal with build menu orders and whatnot if they're defined in sidedata.tdf?
This would require a heck of a lot of changes, changes that would have big affects on the core unit AI and affect how skirmish AI's work depending on how they where built. (ha ha this only affects my stall algorithm).
I believe it would be better todo it in a seperate file like this than have it in the unit fbi. Afterall arent modders saying it's easier to deal with build menu orders and whatnot if they're defined in sidedata.tdf?
This would require a heck of a lot of changes, changes that would have big affects on the core unit AI and affect how skirmish AI's work depending on how they where built. (ha ha this only affects my stall algorithm).
For christs sake get out of this thread you are WAY OFFTOPIC!Pxtl wrote:After all, a "farm/supply" system will be needed eventually, and it seems like that would be the best way to go about it. Later you can add bindings to script so that suppliers/consumers are on/offable. Do you really want two redundant systems? Aren't the files complicated enough already?.
Look neither EE or gundam intend on using food limits. I don't know of a mod that does. You are not currently making a mod. You do not need a food limit. THIS IS NOT A THREAD ABOUT THAT. AF's suggestion and modification of what I asked for is what this thread is about. So no, what you are saying is not right. For christs sake, I do not want unit limits linked to some asinine supply resource. Open your mind.
Code: Select all
[UNIT_LIMITS]
{
[GLOBAL]
{
rx78=2;
alex=3;
guncannon=3;
Xamel=4;
gallop=4;
corebooster=4;
sniperII=4;
Medea=4;
}
[PLAYER]
{
rx78=1;
alex=1;
guncannon=1;
Xamel=4;
gallop=4;
corebooster=4;
sniperII=4;
Medea=4;
}
[GROUPS]
{
groups = powered, rx;
[powered]
{
player_num = 60;
global_num = 60;
units =Powered, poweredrl;
}
[rx]
{
player_num = 60;
global_num = 60;
units = rx79rl, rx79zook, rx79plus;
}
}
}Aaaaaaaaaaaargh, you miss the whole point. Look go post in the food thread that is what you are looknig for. You can be so agrivating sometimes.Now, if you think "but that sounds more complicated and harder to implement" - the "groupable" unit limits come out being just as complicated. I'd just go straight-up literal unit limits if you need a simpler system. Just add a single tag to the FBI file for "limit" and do the unit limits per-unit. Simplest system possible. Factory just check's the unit's definition for it's limit before buiding, and skips the unit if limit is reached.
What Pxtl's saying is that supply resources and unit limits are the same thing.smoth wrote:Look neither EE or gundam intend on using food limits. I don't know of a mod that does. You are not currently making a mod. You do not need a food limit. THIS IS NOT A THREAD ABOUT THAT. AF's suggestion and modification of what I asked for is what this thread is about. So no, what you are saying is not right. For christs sake, I do not want unit limits linked to some asinine supply resource. Open your mind.
He's right.
Unit Limits are a supply resource with a fixed (mod-defined) maximum. Units consume it when built and (as usual) release it when dead.
"Farm" resources are a supply resource with a maximum that some units increase. Units consume it when built and (as usual) release it when dead.
They're the same thing.
What's the problem here?
It's NOT the same thing... by making it a resource it is implied that the limit can be dynamically raised by the player's effort. Again, while that might be indeed be useful to people at some point, that is not what is requested here!
Look, I'll even give a non-gundam example for you: Say we at SWTA wanted to include "hero" units like Luke or Yoda or Vader instead of generic jedi or sith units. We don't WANT the player to be able to build more than one Luke or Vader ever, though for gameplay reasons it'd have to be acceptable on a per-player basis rather than global (so one person can't whore the hero unit). In any case, we don't want players with multiple lukes running around, or even the possibility for it, so a hard limit like smoth is suggesting is desirable.
In this case, there is NO population resource--you get one, period. You don't get a "Force user population" resource bar, or some other absurd bullshit, you just simply get ONE of the hero character and no more.
Now, apply this to Gundams for smoth where he wants to limit certain models to a handful per player, or perhaps the god units from TAK if anyone ever ports that, or certain models of tanks/infantry/planes in AATA/1944, or any other kind of unit which should be hard limited to fit the desired gameplay. It's not the same as a population or food resource, and it should not be thought of that way under any conditions.
Look, I'll even give a non-gundam example for you: Say we at SWTA wanted to include "hero" units like Luke or Yoda or Vader instead of generic jedi or sith units. We don't WANT the player to be able to build more than one Luke or Vader ever, though for gameplay reasons it'd have to be acceptable on a per-player basis rather than global (so one person can't whore the hero unit). In any case, we don't want players with multiple lukes running around, or even the possibility for it, so a hard limit like smoth is suggesting is desirable.
In this case, there is NO population resource--you get one, period. You don't get a "Force user population" resource bar, or some other absurd bullshit, you just simply get ONE of the hero character and no more.
Now, apply this to Gundams for smoth where he wants to limit certain models to a handful per player, or perhaps the god units from TAK if anyone ever ports that, or certain models of tanks/infantry/planes in AATA/1944, or any other kind of unit which should be hard limited to fit the desired gameplay. It's not the same as a population or food resource, and it should not be thought of that way under any conditions.
Um, at the risk of joining this conversation when Smoth is already frothing 
I'd like to see both types of limits.
In NanoBlobs, for example, I always wanted the Demon/Overlord to be a unit that you could only build ONE of. Period. End of story. That way, I could make it ridiculously powerful. That's how it was supposed to work, but it never really did.
And in a perfect world, in Project Two, I'd really like to see classical "harvesting", and have multiple resources available, have unit types that are limited to X number of available "slots"... and have Unique units that can only be built ONCE. After they die, they stay dead. Which, again, would give me a good excuse to make them quite powerful in some way. But, I'd like to see the current, very buggy system fixed first- what we have is very limited, and full of problems which need to be addressed.
[RANT MODE ON]
The resource system is currently very buggy and full of special cases in the current build of Spring.
For example, if you try to give a Commander unit a lot of Storage, it won't start you with 1000 E, 1000 M, and then build towards the large number. Instead, it defaults to 1020 Storage for both resources. And if you make a unit eat Storage, it has several severely buggy areas:
1. It allows Storage to go below zero. Storage, like the current amount, should never go below zero. It should just go to zero, period.
2. It allows units to continue to be built, when there isn't any Storage to support them, but it doesn't allow them to be used. Which is also completely borked. It means, among other things, that AIs will hang, because they will get stuck trying to build units they cannot make any use of, among other things. Instead, what should happen, in my opinion, is that that Build button should no longer be available, and AIs should get some sort of pushback telling them that they can no longer build X unit, so that they can then move on to whatever is next in their queue of available choices.
3. Lastly, it keeps units from firing if they have Energy/MetalUse > 1, even if their Weapons do not require any Energy/Metalpershot. What should happen in my opinion is that units that do not have the resource they need available should stop moving, but should be allowed to fire, if they do not need resources to fire. Instead, they can move, but cannot fire! This is precisely opposite of what should happen, and it really prevents us from having good simulation of fuel vs. ammo considerations in Spring...
4. Oh, and the Resources given to a player at the beginning game set their initial Storage. Yes, we all know that... and that, in my opinion, is a bunch of crapola. Instead, if Resources at Start > Available Storage at Start, then Resources at Start should = Available Storage at Start. Yeah, yeah... then XTA and AA would have to increase the Storage values of the their Commanders. Big whoop. Both of those mods have already lowered the importance of Storage anyhow, since players of those mods obviously don't like having to eat up valuable real estate building more storage facilities. But this game design assumption continues to plague those of us who want to go outside the OTA box with a series of very bad choices.
So, given the facts above... if I make a Demon that eats, say -200000 Metal/Energy Storage... once it's built, every gosh-darn unit I've built, which are all eating Metal and Energy in the default NanoBlobs game design... quits firing, including the Demon... and, last, but not least... even if I make the Demon eat ZERO RESOURCES other than Storage, it still won't fire. Which means that it must be eating resources. Which makes no sense.
[/RANT MODE]
I'd like to see both types of limits.
In NanoBlobs, for example, I always wanted the Demon/Overlord to be a unit that you could only build ONE of. Period. End of story. That way, I could make it ridiculously powerful. That's how it was supposed to work, but it never really did.
And in a perfect world, in Project Two, I'd really like to see classical "harvesting", and have multiple resources available, have unit types that are limited to X number of available "slots"... and have Unique units that can only be built ONCE. After they die, they stay dead. Which, again, would give me a good excuse to make them quite powerful in some way. But, I'd like to see the current, very buggy system fixed first- what we have is very limited, and full of problems which need to be addressed.
[RANT MODE ON]
The resource system is currently very buggy and full of special cases in the current build of Spring.
For example, if you try to give a Commander unit a lot of Storage, it won't start you with 1000 E, 1000 M, and then build towards the large number. Instead, it defaults to 1020 Storage for both resources. And if you make a unit eat Storage, it has several severely buggy areas:
1. It allows Storage to go below zero. Storage, like the current amount, should never go below zero. It should just go to zero, period.
2. It allows units to continue to be built, when there isn't any Storage to support them, but it doesn't allow them to be used. Which is also completely borked. It means, among other things, that AIs will hang, because they will get stuck trying to build units they cannot make any use of, among other things. Instead, what should happen, in my opinion, is that that Build button should no longer be available, and AIs should get some sort of pushback telling them that they can no longer build X unit, so that they can then move on to whatever is next in their queue of available choices.
3. Lastly, it keeps units from firing if they have Energy/MetalUse > 1, even if their Weapons do not require any Energy/Metalpershot. What should happen in my opinion is that units that do not have the resource they need available should stop moving, but should be allowed to fire, if they do not need resources to fire. Instead, they can move, but cannot fire! This is precisely opposite of what should happen, and it really prevents us from having good simulation of fuel vs. ammo considerations in Spring...
4. Oh, and the Resources given to a player at the beginning game set their initial Storage. Yes, we all know that... and that, in my opinion, is a bunch of crapola. Instead, if Resources at Start > Available Storage at Start, then Resources at Start should = Available Storage at Start. Yeah, yeah... then XTA and AA would have to increase the Storage values of the their Commanders. Big whoop. Both of those mods have already lowered the importance of Storage anyhow, since players of those mods obviously don't like having to eat up valuable real estate building more storage facilities. But this game design assumption continues to plague those of us who want to go outside the OTA box with a series of very bad choices.
So, given the facts above... if I make a Demon that eats, say -200000 Metal/Energy Storage... once it's built, every gosh-darn unit I've built, which are all eating Metal and Energy in the default NanoBlobs game design... quits firing, including the Demon... and, last, but not least... even if I make the Demon eat ZERO RESOURCES other than Storage, it still won't fire. Which means that it must be eating resources. Which makes no sense.
[/RANT MODE]
Last edited by Argh on 30 Jul 2006, 01:49, edited 3 times in total.
Um. No, it doesn't. Not at all. Internal implementation versus external interface. There have been numerous suggested mods that use metal/energy to implement this kind of limit. Does this mean that metal/energy are not resources because players in these mods cannot increase them, even though players in other mods can?Gnome wrote:It's NOT the same thing... by making it a resource it is implied that the limit can be dynamically raised by the player's effort. Again, while that might be indeed be useful to people at some point, that is not what is requested here!
Yes, that's a resource. It's a resource that defaults to one that isn't visible to the user as a bar, in a mod that has no structures to increase the resource.In this case, there is NO population resource--you get one, period. You don't get a "Force user population" resource bar, or some other absurd bullshit, you just simply get ONE of the hero character and no more.
Different interface, same code.
But doesnt that mean that a mod where a unit costs 1 metal and there are no metal storage, producers, consumers, just the buildcost, and whena unti dies it gives 1 metal. In thatc ase is metal no longer a rsource?
A unit limit is a resource. It is of a fixed storage capacity, has no production or consumption, and has a cost on build and a production on death.
Here the rx resource has an initial storage of 60. To add storage to this you would add a unit say lik this:
where rxstore is a storage unit that gives an extra 10 storage to the rx resource.
This unit limit system can be implemented. And people can create starcraft-esque supply systems out of it by co-incidence.
However this system provides the necessary infrastructrue to then go on to implement arbitrary resources. Whatsmore, the global caps thing actually makes it even more unusual, because say the global cap was 120 and the player cap was 60, and you had storage untis in a 2v2, you could effectively steal your enemies available unit slots for yourself.
It's also feasable that anti superweapon buildings could take a new dimension in actually rpeventign the superweapons beign built to begin with.
say you had a block on the rx untis liek this:
Building 3 of the rxblock units would make the rx unit totally unbuildable untill those rxblock units where destroyed. But the full 3 cant be built if the enemy or you already have an rx unit, at which point you ca only build 2 and the enemy or you can build 19 more rx units.
Now these other consequences are things I dont remember seeing in starcraft........
Now for an aspect nobodies mentioned. How will people see how much of the unit limit they've used or what it even is. We dont want people saying "I was ingame and suddenly my factory stopped building rx's without explanation"..........
A unit limit is a resource. It is of a fixed storage capacity, has no production or consumption, and has a cost on build and a production on death.
Code: Select all
[rx]
{
player_num = 60;
global_num = 60;
units = rx79rl, rx79zook, rx79plus;
}Code: Select all
[rx]
{
player_num = 60;
global_num = 60;
units = rx79rl, rx79zook, rx79plus, rxstore;
rxstore=-10;
}This unit limit system can be implemented. And people can create starcraft-esque supply systems out of it by co-incidence.
However this system provides the necessary infrastructrue to then go on to implement arbitrary resources. Whatsmore, the global caps thing actually makes it even more unusual, because say the global cap was 120 and the player cap was 60, and you had storage untis in a 2v2, you could effectively steal your enemies available unit slots for yourself.
It's also feasable that anti superweapon buildings could take a new dimension in actually rpeventign the superweapons beign built to begin with.
say you had a block on the rx untis liek this:
Code: Select all
[rx]
{
player_num = 60;
global_num = 60;
units = rx79rl, rx79zook, rx79plus, rxblock;
rxblock=20;
}Now these other consequences are things I dont remember seeing in starcraft........
Now for an aspect nobodies mentioned. How will people see how much of the unit limit they've used or what it even is. We dont want people saying "I was ingame and suddenly my factory stopped building rx's without explanation"..........
I also propose the following:
where the tags default is 1. Lets say all those rx units are a value of 2 except rx79plus, would you rather define the two as the value '2' or the other one as '1'?
Code: Select all
[rx]
{
player_num = 60;
global_num = 60;
units = rx79rl, rx79zook, rx79plus;
default_value=1;
}AF, can you add a stay deadtag in the tdf definition that we are discussing? Arghs unit staying dead thing would also be a nice addition to the unit limit discussion.
No, it isn't egarwaen.
Resources cannot limit 1 gundam per player. If I made it uber and there was some XYZSNAKESONAPLANE resource limit to it then people would exhaust the XYZSNAKESONAPLANE limit to make all gundams and no GMS. I DO NOT WANT that.
I swear...
it is VERY SIMPLE! IT is MOD DEFINABLE... but IS INDEPENDANT OF RESOURCE CONSTRAINTS!
I want players to only be able to build one GUNDAM(RX-78) not matter if they have 1,000,000,000,000,000,000 XYZSNAKESONAPLANE resource.
I DO NOT WANT THEM TO BE ABLE TO BUILD a buiding that WILL RAISE the AMMOUNT of gundams that the player can built it is really very simple. I hate this community.. why is it that you all have to argue every single simple god++++ thing.
IS is that hard to understand!?!?? I DO NOT WANT FARMS.. THIS DOES NOT EQUATE TO FARMS... What you are suggesting is an occupied resource constraint. I could punch someone. I swear. It is funny, I make a post the mod makers get behind me and say hell yeah I want that to.. the the non modders start bitching that it isn't going to work out or that we want the wrong thing. Funny we are the ones making the god*#% mods we kinda know what we want.
-Smoth, loging off for the evening. GOOD DAY!
No, it isn't egarwaen.
Resources cannot limit 1 gundam per player. If I made it uber and there was some XYZSNAKESONAPLANE resource limit to it then people would exhaust the XYZSNAKESONAPLANE limit to make all gundams and no GMS. I DO NOT WANT that.
I swear...
it is VERY SIMPLE! IT is MOD DEFINABLE... but IS INDEPENDANT OF RESOURCE CONSTRAINTS!
I want players to only be able to build one GUNDAM(RX-78) not matter if they have 1,000,000,000,000,000,000 XYZSNAKESONAPLANE resource.
I DO NOT WANT THEM TO BE ABLE TO BUILD a buiding that WILL RAISE the AMMOUNT of gundams that the player can built it is really very simple. I hate this community.. why is it that you all have to argue every single simple god++++ thing.
IS is that hard to understand!?!?? I DO NOT WANT FARMS.. THIS DOES NOT EQUATE TO FARMS... What you are suggesting is an occupied resource constraint. I could punch someone. I swear. It is funny, I make a post the mod makers get behind me and say hell yeah I want that to.. the the non modders start bitching that it isn't going to work out or that we want the wrong thing. Funny we are the ones making the god*#% mods we kinda know what we want.
-Smoth, loging off for the evening. GOOD DAY!
Sure they can. Your mod defines a "It's a Gundam" resource. Your mod specifies that this resource has a maximum value of 1, starting value of 1, and is not displayed to the user. Your mod specifies that an RX-78-2 consumes 1 unit of "It's a Gundam" and gives 1 unit back when it dies. Your mod specifies that no other unit uses or gives "It's a Gundam".smoth wrote:Resources cannot limit 1 gundam per player. If I made it uber and there was some XYZSNAKESONAPLANE resource limit to it then people would exhaust the XYZSNAKESONAPLANE limit to make all gundams and no GMS. I DO NOT WANT that.
Presto. Each player can build at most 1 Gundam. The same system can be used for a "Supply Depot" model. What's so hard about that?
I swear, I wonder if you are trying to goad me on. It is not a resource, it would not be part of the resource implementation. It is something that would be sepperate from the resource implementation. The resources are a NUMERIC this requires an array.Egarwaen wrote:Sure they can. Your mod defines a "It's a Gundam" resource.
NOT A RESOURCE. a LIMIT!Egarwaen wrote:Your mod specifies that this resource has a maximum value of 1, starting value of 1, and is not displayed to the user.
not a RESOUCE! do you have any idea how clunky that is?Egarwaen wrote: Your mod specifies that an RX-78-2 consumes 1 unit of "It's a Gundam" and gives 1 unit back when it dies.
Using the resource structure for this would be overkill plus we still have not abstracted it. Resources are things like metal and energy. It is not that hard to understand that they are handeled differently then the already existing unit limit in spring. The unit limit in spring is not the same as the resource system. What I am requesting is that the unit limit functionality of spring is expanded. Don't bother replying with your presumption about the resource system. I'd bet 10 bucks that the spring unit limit and the resource system are handled sepperately. Then again.. **** it I am shutting my machine off.