Unit limits

AF · Post by AF » 30 Jul 2006, 02:39

You mean so that whena unit dies it doesnt take add the same value as when it was built?

aha I see now, such a value would be zero, infact you could use negative values to make it even more valuable to keep your untis alive.

Code: Select all

         [rx]
         {
             player_num = 60;
             global_num = 60;
             units = rx79rl, rx79zook, rx79plus, rxstore;
             default=1;
             rx79zook_dead=0;
             rx79plus_dead=-1;
         }

here building 30 rx79zook's and blowing them up would leave you with only 30 storage out of the original 60. Is that what you itnended?

Now the extra oenI added rx79plus_dead=-1. That would mean that when the rx79plus dies it not only takes away the slot it originally filled, it takes away another free slot too.

So if you make 15 rx79plus untis and they get destroyed, then 30 of the original 60 slots become unusable, making ti much more important to keep them alive.

And should you want to do the opposite and have a positive value larger than 1 the available group size could become bigger.

AF · Post by AF » 30 Jul 2006, 02:44

oo people posted while I was typing.

Smoth for all purposes sake, limit and storage are interchangeable. The limits thing uses an array, but the resource thing would use a very very similar array that works in exactly the same way.

The 2 systems can very very very easily be reconciled into a single system, as the things they're representing are sooo similair.

However I believe that the unit limit system must be implemented first before it's abstracted into an abstract resource system.

Egarwaen · Post by **Egarwaen** » 30 Jul 2006, 02:47

smoth wrote: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.

Or, y'know, one resource per limit. For example, if you wanted to limit Gundams, Big Zams, and Zakrellos, you'd define three different resources, one per limit, with the same characteristics. Or, for a Homeworld mod, you'd define "fighter", "corvette", "destroyer", and "battleship" resources. For a Starcraft mod, you'd define three different resources for farm types. For a Warcraft II mod, you'd define a single resource for farms.

Why is this in any way worse than your suggestion? How does it cause more work for the modder? I don't see it.

AF wrote:The 2 systems can very very very easily be reconciled into a single system, as the things they're representing are sooo similair.

However I believe that the unit limit system must be implemented first before it's abstracted into an abstract resource system.

All hail AF, God of Clarity and Cookies.

Snipawolf · Post by **Snipawolf** » 30 Jul 2006, 02:48

Wiki "Limit"

to limit (third-person singular simple present limits, present participle limiting, simple past limited, past participle limited)

Infinitive
to limit
Third person singular
limits
Simple past
limited
Past participle
limited
Present participle
limiting

To restrict; not to allow to go beyond a certain bound.
We need to limit the power of the executive.
I'm limiting myself to two drinks tonight.

Wiki "Resource"

resource (plural resources)

Singular
resource
Plural
resources

Something that one uses, especially in manufacturing of goods.
(slang, sometimes deragatory): personnel.

Wiki is all knowing, damnit!

Apparently resources are used, and need to be replaced....

In this case gundams ARE the resources and a limit is how many can be built... Got it?

AF · Post by AF » 30 Jul 2006, 02:50

Thats a little bit well......

Lets stick to unit limits.

A resource system would have a basic system at it's core which is 99.999999% identical to this unit limit stuff so please wait till unit limits are implemented and tested then lets see how we can extend unit limits into resources, because right now its getting us nowhere and forcing this thread down into flames.

Snipawolf · Post by **Snipawolf** » 30 Jul 2006, 03:12

Objection!

http://objection.4camp.net/go.php?n=514446

SwiftSpear · Post by **SwiftSpear** » 30 Jul 2006, 04:59

It doesn't matter what the definition of "limit" is compared to the definition of "resource". All that is relevant is how similar the code would look from one system to the other. The same code could likely be used for both, so there's no reason to unnecessarily code it twice when we can just make a single robust system and have modders patch into it calling it's usage "resources" or "limits" or "metal" or whatever the hell they want.

We can call the code whatever we want and it will still work the same way. We'll call it the apples system, and it will manage both resources and limits in a similar mod defined manner and everyone will be happy.

Aun · Post by **Aun** » 30 Jul 2006, 05:01

Although unit limits could probably be implemented a lot more easily than custom reources...

Argh · Post by **Argh** » 30 Jul 2006, 05:32

So if you make 15 rx79plus untis and they get destroyed, then 30 of the original 60 slots become unusable, making ti much more important to keep them alive.

Yes, that's the ticket. We could have attrition controls. Imagine this- you'd have Tech One units that could be built forever... Tech Two that would slowly but surely be removed from play, unless you built the appropriate structures/units/cookies... and Tech Three that could be built at a reasonable price in terms of time, and was quite powerful... but was only available once, or only in very limited numbers... +100...

Egarwaen · Post by **Egarwaen** » 30 Jul 2006, 06:01

And as Argh's amazing mind points out, the more generic the system the better.

KDR_11k · Post by **KDR_11k** » 30 Jul 2006, 07:28

I'd say unit limits and ressoures should be implemented independently. Sure you could emulate one through the other but it puts the mod developer through a lot of unnecessary hassle. Keeping the concepts separate would also make it easier to read a mod's data files since you'd know ressources are actual ressources and not just hacks for something else. Most programming languages implement both a for and a while construct although they are completely interchangeable, they exist to make the code easier to type and read.

Ressources need to be checked for production and use, they fluctuate quickly and it would require special case behaviour to make Spring understand that a ressource that acts as a limit won't be replentished if it just waits long enough (and that it shouldn't allow the player to even start constructing more than N of these units).You'd also need to change the current ressource system a lot as there is no way* to make sure the player has exactly the required amount of a ressource left.

With a limit Spring knows that it's not going to go up soon so it could skip the build order, it knows there's no fluctuating current value to keep track of and it could add a "requires 3/60" line to the description that mentions the limit use and the currently free slots. All the stuff mentioned here could be done with a separate limit system (use on death, global limit, farms).

*=Actually you could make one nanobit cost exactly as much as you want the unit to cost but that requires a lot of calculation since you can easily end up with it costing a bit more. Also it's hackish and might break if any futue revision changes the nanobit rate.

Egarwaen · Post by **Egarwaen** » 30 Jul 2006, 16:58

KDR_11k wrote:they fluctuate quickly

Read AF's posts, my posts, and Argh's posts. The only possible response to this (and the rest of your post) is: no, they don't.

Again: we're not just saying "use metal" or something. We're proposing that modders be allowed to define custom resources. Using these for unit limits is no more complex than unit-limit-specific code and significantly more flexible, as it supports very complex schemes with very simple syntax.

Oh, and you could still get that nifty display thing from it if you wanted.

AF · Post by AF » 30 Jul 2006, 17:22

I knwo you're all eager for an abstract resource system, but that is a huge udnertaking and we need to take smaller feasable steps.

Lets talk about unit limits now and ingore the abstract resource stuff, then later on we can use the unitlimits as a foundation for abstract resources. But only after unit limits has been implemented.

So please no more talk of abstract resources.

KDR_11k · Post by **KDR_11k** » 30 Jul 2006, 18:01

Egarwaen wrote:Read AF's posts, my posts, and Argh's posts. The only possible response to this (and the rest of your post) is: no, they don't.

Again: we're not just saying "use metal" or something. We're proposing that modders be allowed to define custom resources. Using these for unit limits is no more complex than unit-limit-specific code and significantly more flexible, as it supports very complex schemes with very simple syntax.

Oh, and you could still get that nifty display thing from it if you wanted.

The engine still has to know if it's a limit or a ressource so it knows it needs to cancel production. Also it needs to use all of the necessary limit ressource in one frame instead of over the course of the construction so you don't end up with two half-finished units each taking up half the limit and neither factory realizing only one of them can finish. Also you need to implement a feature that allows a unit to produce a ressource for its owner when it is removed from play (i.e. even when reclaimed by an opponent). The other way is to use the ressource storage limit as the actual number but that wouldn't prevent players from putting multiple units into production at the same time and it wouldn't allow different regains upon death.

To make that work for limits you'd need more changes than just additional ressources.

j5mello · Post by **j5mello** » 30 Jul 2006, 18:20

AF wrote:I knwo you're all eager for an abstract resource system, but that is a huge udnertaking and we need to take smaller feasable steps.

Lets talk about unit limits now and ingore the abstract resource stuff, then later on we can use the unitlimits as a foundation for abstract resources. But only after unit limits has been implemented.

So please no more talk of abstract resources.

Read the above. Did you read it? Good now do what is says.

Freder · Post by **Freder** » 30 Jul 2006, 18:24

Wasn't there a bug that actually limited few units to only 100? Maybe by combining that 'ex-bug' with the parser that only sets the values everything is already there? I don't know about the grups, but that would be the first step as it would implement the limits/restrictions on single units (ALEX, Apsalus?

).

AF · Post by AF » 30 Jul 2006, 18:39

KDR, I have all that sorted out but I dont want to talk about it or show what I have untill unit limits is implemented and its time to talk about resources.

smoth · Post by **smoth** » 30 Jul 2006, 22:50

just wanna say that kdr nailed what I was trying to say on the head with the post he made:Sat Jul 29, 2006 11:28 pm

AF, how hard/time consuming would this patch be?

The unit limit would only need to be updated on create/death correct?

AF · Post by AF » 30 Jul 2006, 23:01

Yes only on death/creation. I'd say simply making a class something like this:

Code: Select all

class CLimits{
public:
    CLimits();
    ~CLimits();

    void Creation(const UnitDef* ud); // unit created (nanoframe)
    void Destruction(const UnitDef* ud); // unit destroyed

    bool CanBuild(const UnitDef* ud); // Can another one of these be built?

    int GetAvailable(const UnitDef* ud); // how many slots ae available?
    int GetUsed(const UnitDef* ud); // How many slots have been used?
    int GetSlotNum(const unitDef* ud); // How many slots does this take?

);

Then call it in the appropriate places, I'm sure you've thought more about how it'd actually get implemented.

The setup uses data available to AI's too so the class could be directly copy pasted into a Skirmish AI for testing.

smoth · Post by **smoth** » 03 Aug 2006, 03:26

so, anyone looking into this?

Spring RTS Engine

Unit limits

Ex-Bug