SC2Mapster

Does anyone know of any unit catalog fields that could be used to store a string?

I wish to later pull this string with script and decode it to perform some other functions.

I've tried "EditorDescription","EditorSuffix", which both give me errors. Doesn't seem to be any other fields I could potentially use. =/

If they are all stored as text.. I'll just have to find another way around since text comparisons arent possible(?)..

Are you simply looking for a way to store strings for later use?

Or do you want to store them on/in the units?

@MTops: Go

Yeah sorta. I specifically would like to have them stored on a unit or any other catalog type that is capable of storing it.

Rather than keep it in a variable, it gives better control when modifying a string for a specific unit. (Don't have to go digging through code to find the string that matches the unit)

The alternative is of course to store the string with a variable, but I would need to bind a units ID to it, thus if the units ID is changed for some reason, its going to break.

Well, every single catalog value is a string. You can change all values with catalog set value, which you can modify with an upgrade. So just create an upgrade to modify a unit, and you have a list of all available fields. Now sort out all of those, which are of no interest for you (depends on your map, of course), and you have your desired fields (You cannot change description and suffix, it seems, but you can change all sorts of Tactical AI fields - like Tactical AI Function or Tactical AI Channel - which you probably don't use)

This seems to work just how I want it to. But I'm not 100% bought. I'm worried I may be using a field that is critical for some other purpose. What do you guys think?

Note: I'm using this field on a zergling unit. I checked in game, changing this doesn't seem to change the zergling description when I click on a larvae.

Heres the trigger debugger output.

00:00:01.38 Test:Test:Test/Test:Test:Test

This is pretty much what I was looking for, but I'm wondering if there is a better field that could be used.

If you guys are wondering, this is very similar to something I learned with Jass. Effects could be stored as strings and called back using triggers. Since everything was localized it was very manageable.

I am still not sure, what you want to achieve with this. Why not store everything in a data table under the unit's ID? If for some reason the ID of the unit changes, you have just the same problem with your catalogs: You will store the value in another unit's field, when the ID was changed. I don't see any difference.
In fact, isn't a catalog effectively nothing but a data table bound to the object ID and the player?
Also I am pretty sure that data tables are equal to or faster (most likely faster) than catalog functions.

@Kueken531: Go

Quote:

If for some reason the ID of the unit changes, you have just the same problem with your catalogs: You will store the value in another unit's field, when the ID was changed. I don't see any difference.

I'm not sure I'm following this statement. I'll try to describe what i'm trying to do.

Well. Lets say I have a unit, a zergling. For this unit I have a string A:B:C:D:E. Each of these values are parameters for a function.

The function is intended to work universally. That is. it doesn't matter what unit I use. I can easily declare the function inputs via A:B:C:D:E without needing to dig into the script and key it in. Its designed this way to make for easier introduction of new units as development continues.

If data tables are used, whomever is trying to design the unit would have to go into the script and manually add in the value right?

What i'm trying to achieve is a solution that a data editor could easily work with.

I can't really see how changing the units ID is going to break the system if it's done this way?

• Speed is not really a concern as these strings will only be called once per player at the beginning of the game.

Quote:

In fact, isn't a catalog effectively nothing but a data table bound to the object ID and the player? Also I am pretty sure that data tables are equal to or faster (most likely faster) than catalog functions.

This I can't deny. I'm still pretty new with catalogs. I don't know all their ins/outs yet.

So you basically want to add units, which have some kind of individual stats attached to them, and you want to add them in the data editor and make the script read them out, instead of having to change those values in the trigger editor? Well, in this case your method would work. Since you probably won't need to change the value ingame, you can basically choose any field you like. Suffix and description should work just fine.

I would probably prefer a trigger setup in this case, though. However this is purely personal preference. You would just add an easy AddUnitToDatabase(ID,A,B,C,D,E) function and call it in a separate area (like an own custom script object), this way you can find it just as easy as well. At least thats what I use in my map.

Especially if you have many units, you can balance the values much easier, if you have them in a kind of table in the trigger editor.

@Kueken531: Go

Yeah, thats what I usually do :) Just wanted to try something radical here. The table format works for me too. Unfortunately it gets hard to tell whats what when theres too many items. I suppose one of the main advantages is that it doesn't use memory space since catalogs are effectively, as you mentioned, data tables that are bonded to objects.

Only thing is that if we change the ID in the trigger tables, we would have to dig through data anyway to match it up so it doesn't break. Works vice versa too.