Unit Name Uniqueness (Full Version)

All Forums >> [New Releases from Matrix Games] >> Command: Modern Operations series >> Mods and Scenarios >> Lua Legion



Message

jkgarner -> Unit Name Uniqueness (5/14/2021 7:23:27 AM)

HI,

I thought I would test what happens if multiple units were created using the same name (and side!) I believe that this should not happen, as having multiple units in a scenario of the same name and side would be confusing to the player, and it is incumbent upon the developer to keep his/her data straight enough to prevent this, however, I thought I would investigate the possibility.

The following is the test code: 
ScenEdit_AddSide({name='USA'})
print('adding furst unit')
local u1 = ScenEdit_AddUnit({side='USA', type='Facility', guid='test unit 1', dbid=2784, 
    name='Generic Unit Name', latitude=19.004100276608, longitude=110.24596193077, }) 
local g1 = u1.guid
print('guid unit1 = '..g1)
print('')
print('adding second unit')
local u2 = ScenEdit_AddUnit({side='USA', type='Facility', guid='test unit 2', dbid=2784, 
    name='Generic Unit Name', latitude=19.002716269866, longitude=110.16686023683, }) 
local g2 = u2.guid
print('guid unit2 = '..g2)
print('')
print('getting unit with side and name:')
local res1 = ScenEdit_GetUnit({side='USA', name='Generic Unit Name'})
print(res1)
print('')
print('getting unit with guid:')
local res2 = ScenEdit_GetUnit({guid=g1})
print(res2)
print('')
print('getting unit with guid:')
local res3 = ScenEdit_GetUnit({guid=g2})
print(res3)

When executed, the code created two distinct units, and both were accessible from lua, ONLY if using the guid in the unit selector of ScenEdit_GetUnit. The first unit ONLY was returned when using side and name in the unit selector of ScenEdit_GetUnit.

I would note that I intentionally used custom guid's and intentionally set them distinct from one another. If you allow the system to set the guid values, then it will generate unique values for you and behave in essentially the same fashion.

If, however, you choose to use custom guid's, and attempt to create a second unit with the same guid as has been previously used, it will fail.

What does this mean?

If you allow the system to generate guids for you, and you use them to access your units, then you can be sloppy about your unit name data. The result will be a confused user, but the system will likely work.

If you choose to use custom guid values, and use them to access the units, then you can be sloppy about the unit names but you MUST track you custom guid usage and guarantee they are unique. Depending upon how your data is configured, this may already be the case (if you use a primary key of this data as the guid) If you use some other data, you have just created a task of equal complexity as tracking unit name uniqueness directly.

If you wish to use name and side, and ignore guid values entirely, then you must ensure that side and unit name pair are unique across all the units you create. In my mind, this leads to the most clarity for the user.

Now you know.[:)]



KnightHawk75 -> RE: Unit Name Uniqueness (5/14/2021 8:48:55 AM)

quote:

If, however, you choose to use custom guid's, and attempt to create a second unit with the same guid as has been previously used, it will fail.

Well of course it fails. [:)]

quote:

If you allow the system to generate guids for you, and you use them to access your units, then you can be sloppy about your unit name data.

yes _Only_ if you always ref guids in your code and never ever need to do a side\name lookup, and it certainly will not be the case for the average user of a little scripting, so it's really bad general advice, lets not encourage sloppy naming, just cause if once can if careful. [:-]

Besides it's not that hard to tack on a fairly random string at the tail of the name when doing mass unit creation etc. 

--5.1 generate basic 8-9char suffix for names. 
function gKH:GetRandomSuffix()
  local a = math.random(65,90); --generate random number from 65-90  {caps}
  local b = math.random(97,122); --generate random number from 97-122 {lower}
  local c = math.random(1000,99999)--generate random number from 1000-99999
  local d = math.random(65,90);--generate random number from 65-90  {caps}
  local e = math.random(97,122); --generate random number from 97-122 {lower}
  return '(' .. string.char(a,b) .. tostring(c) .. string.char(d,e) .. ')' 
end






jkgarner -> RE: Unit Name Uniqueness (5/14/2021 11:23:12 AM)

@KnightHawk,

Most common users think in terms of side and name. While guid look-up may be faster, I believe the system allows side, name lookup precisely BECAUSE most users are more comfortable with that. (This is of course a guess on my part, as I really do not know the intent of the system developers.)

Having name clashes on the same side is simply the result of sloppy data practices. It should not happen, and where it does, as you pointed out, it is easily corrected.

I am very much NOT in favor of bad data practices, including sloppiness in naming. I want each unit to have it's own unique name. I have written an entire library of Lua code that uses Side Name look up partly in an effort to try and force better data practices on the team, but because I intend the library to be used by less technically trained players.

In the data set that I am working with, we do not control the names of the units and many units have the same name. This is lamentable, but I have overcome this limitation by appending an identifiable field to the name to make it unique (similar to your suggestion).

I have been told that this is not acceptable, to remove the extra garbage on the end of the names, and to change all my code to guid look-up.

Well, I was already thinking about switching the code to guid look-up for performance reasons, however, I am told that I must do it BECAUSE the names can not be guaranteed to be unique. It is the latter statement that bothers me BECAUSE it shows intent to be sloppy in naming, and I abhor the sloppiness.

I ran the tests hoping that the system would error out when attempting to create a unit of the same name and side as a previous unit. Only that, I believe, would have compelled better data practices from this lot.




KnightHawk75 -> RE: Unit Name Uniqueness (5/14/2021 12:13:26 PM)

I know you abhor it which is why I was kind of scratching my head at the exercise before you illuminated it more.
quote:

I have been told that this is not acceptable, to remove the extra garbage on the end of the names, and to change all my code to guid look-up.

Form over function I ugess..well that kinda um sucks, but also explains a lot. Hey on the upside at least you'll get some slight perf gains on beefier scenes. :)



jkgarner -> RE: Unit Name Uniqueness (6/10/2021 8:46:51 AM)

FYI: For those that choose to use custom guid values, we have discovered that for units that host other units (like airbases, or carriers) there is a limitation on what characters may be used in the custom guid. We have learned that the guid of these units may ONLY contain numbers, hyphens, and lower-cae letters. While you can use other characters, but for some reason, that unit then loses the ability to host the other unit. Mind you this is in PE 1.15.5. This has not been verified in PE 2 or other editions. As a note, the system auto-generated guids conform to this rather odd requirement, as the system uses hyphens and hexadecimal numbers in (lower-case).



Parel803 -> RE: Unit Name Uniqueness (6/10/2021 3:39:59 PM)

thank you,
with regards GJ



KnightHawk75 -> RE: Unit Name Uniqueness (6/12/2021 3:26:24 AM)

You may also find a couple of classes of items that get auto-generated guids may get certain prefixes with-in their guids. I forget where exactly I noticed it, may have been weapons, or mags and or mounts, or all that sort of got there own prefixes codes(in retail). Like XXXXXX-XXXXAAXXXXXXX for that class of item. Didn't matter much to me at the time cause I was debugging something unrelated but I took note of it at the time as easy way to spot certain items I was looking for in a sea of guids. I don't think it truly mattered from a functioning standpoint and they were all things I couldn't create\control the naming of anyway.



jkgarner -> RE: Unit Name Uniqueness (6/12/2021 10:48:44 AM)

At present, we are only using custom guids for units.



JFuzz -> RE: Unit Name Uniqueness (6/17/2021 11:32:05 AM)

There is at least 1 Lua function which appears to ONLY refer to units by name and not GUID. ScenEdit_SetUnitSide(oldside, name, newside). I haven't tried to refer to units by GUID, but it definitely has problems with multiple units with the same name. Fortunately I just wanted to move all those units onto the same side, so it didn't cause me a problem. But I have now added code to automatically add a number to the end of names for selected units.



KnightHawk75 -> RE: Unit Name Uniqueness (6/19/2021 7:39:38 PM)

SetSideUnit will take a guid= param for the unit, even if it's not documented, but not for a side name param that must be a string and valid side name. Unlike the name param (in most function ) you just can't swap in the guid with the name, have to use it explicitly.

ie:
--note unitname & unit, and side & sidename are synonymous for this command.
SetSideUnit({guid="unitguidhereasguid", newside="strmynewsidehere"}); --ok
SetSideUnit({unitname="strnamehere", side="strnamehere", newside="strmynewsidehere"}); --ok
SetSideUnit({unitname="strnamehere", side="sideguidhere",n ewside="strmynewsidehere"}); --ok
SetSideUnit({unit="strnamehere", sidename="strsidenamehere", newside="strmynewsidehere"}); --ok
SetSideUnit({unitname="guidhere", side="strnamehere", newside="strmynewsidehere"}); --NOT ok as you point out.



Page: [1]

Valid CSS!




Forum Software © ASPPlayground.NET Advanced Edition 2.4.5 ANSI
1.890625