An object that can hold 3 integers and 1 string?

08-02-2006, 06:05 AM

Hi there,

As many other people, I am trying to get rid of many of my (not publicly available) gamecache-based systems. I am looking for alternatives for it, and I need any object type that can hold 3 [unsigned] integers and 1 string.

One of my ideas was using a dummy hero's stats for the integer values, and perhaps the string from the hero's "current" order, but i really don't know if you can set any sort of string as order, and effectively retrieve it later.

Any better idea or input about unit's orders ? The string would be my object name, if it helps.

08-02-2006, 07:48 AM

PipeDream

Lightnings are ok but you're limited to 0 to 0x1FFFFFFF (0.0 - 1.0 color limit) and blu has seen efficiency issues at on the order of 1000 objects.
Probably better is rects for 0 to 0x7FFFFFFF at the tiny cost of flipping the sign bit for MinX/MinY.
The verdict is still out on strings + return bug, so you could decide that question as well.
Cameras also work (I think-not tested rigorously) but they have more than you need and the acceptable ranges are somewhat mysterious. However you can set one field at a time which may be very nice for you.
Multiboards have a string but only two integers (row col count) and space used is proportional to rows*cols

The absolute best option with no return bug hell is to use global space. If you don't want to modify CSCache to the task ( I wouldn't ), create an atomic stack allocator for the task, dishing out an index into 4 parallel arrays, three integer one string. If you need more than 8192 in use, spill out into gamecache or use tries to index the bits past #13, at least for the integers.

08-02-2006, 12:54 PM	#3
Vexorian	Items can store 2 integers, the string thing is problematic because of gamecache, CSArrays can hold n integers and also strings, the only problem with strings in CSCache is that they use gamecache, but how much times would you actually read a string ? In your case you better don't store the string but the orderid it is an integer and it would work for more orders that don't have an orderstring.

08-02-2006, 02:59 PM

TheEpigoni

Quote:

Originally Posted by PipeDream

Pipe, in what possible cases would parralell arrays not be a good idea? I've been using parralel arrays with an allocator for about 3 years now in Any map I've made with War3 (Before game cache came about), but I'm curious what reason there would be for using something else in most situations?

08-02-2006, 05:46 PM

Alevice

I really apreciate the effort, but I think I wasn't very clear on what I am looking for (let alone the fact that the most efficient solution seems to be a little above my current level of understanding).

The system I am working with is a calendar. The "object" I want to have is a date.

The date has a Day, a Month, a Year, and a Name (rather than a numerical index for ease of lookup, at least on a hash table/map). The lifespan of these object is actually very short in most cases, so I am not concerned of the amount of date objects that will exist. With the exception of Year, numbers don't need to have a large range (1-30, 1-12), which is why simple integers would suffice.

What i have so far is the following:

My Date Object definition:

function DateObject takes string name, integer day, integer month, integer year returns nothing
    local gamecache gc = DateHandler()
    call StoreInteger(gc, name, "day", day)
    call StoreInteger(gc, name, "month", month)
    call StoreInteger(gc, name, "year", year)
    set gc = null
endfunction

function DestroyDate takes string name returns nothing
    call FlushStoredMission(DateHandler(),name)
endfunction

function GetDateDay takes string name returns integer
    return GetStoredInteger(DateHandler(),name,"day")
endfunction
function GetDateMonth takes string name returns integer
    return GetStoredInteger(DateHandler(),name,"month")
endfunction
function GetDateYear takes string name returns integer
    return GetStoredInteger(DateHandler(),name,"year")
endfunction

function SetDateDay takes string name, integer day returns nothing
    call StoreInteger(DateHandler(),name,"day",day)
endfunction
function SetDateMonth takes string name, integer month returns nothing
    call StoreInteger(DateHandler(),name,"month",month)
endfunction
function SetDateYear takes string name, integer year returns nothing
    call StoreInteger(DateHandler(),name,"year",year)
endfunction

Here is a basic example of its use:

JASS:

    call DateObject("current",udg_CurrentDay, udg_CurrentMonth, udg_CurrentYear)
    call DayProgressing("current")
    set udg_CurrentDay = GetDateDay("current")
    set udg_CurrentMonth = GetDateMonth("current")
    set udg_CurrentYear = GetDateYear("current")
    call DestroyDate("current")

While in appereance it is a little pointless, the name parsing as argument is pretty handy (particularly in those where more than one object is passed as argument) in some other stuff I don't feel like posting because I am that paranoid.

Most (not all, though, but they are small in number) of these objects live that long though.

My reason for wanting to get rid of gamecache is because I don't think i really need it for this, but I can't come up with a better (and almost as equally simple) than this.

Thanks a lot for the replies so far.

08-02-2006, 06:01 PM

Rising_Dusk

For something so global, why not use global variables?
Seriously, if it's a huge system in your map why would you not use a global array for your dates and a global string for whatever you need it to be?
I don't see a need for cache in such an application. (Maybe I'm too naive to see what you mean though)

And I notice you DO use globals in there a bit.
Just update them based on whatever causes day/month/year to increment.

Perhaps Im missing your conceptual use of it all though.
Apologies if this is completely not what you're asking about.

08-03-2006, 12:11 AM

PipeDream

Quote:

Only when you actually need array like behavior (x[5]). This happens rarely. Most of our use is for struct like behavior.

08-03-2006, 01:23 AM

Alevice

Quote: