I love Types
Blitz3D Forums/Blitz3D Beginners Area/I love Types
| ||
| Actually that's a lie - although they are really helpful, they can be a right pain in the.... Is there a way to 'access' the Current Instance of a Type? There are commands for Before, After, First and Last but not Current and this is really awkward... |
| ||
This is what I have so far, I need the current target variable (targetentity) to scroll through the instances of 'RadarTargets' Type (depending on whether changetarget$="Forward" or "Back" (sloppy I know, but it's clearer for me!), and then = the Field \TargetEntityHandle
Target_Sorter_First.RadarTargets=First radartargets
Target_Sorter_Last.RadarTargets=Last radartargets
If targetentity=0
targetentity=Target_sorter_First\TargetEntityhandle
EndIf
Target_Sorter_Next.RadarTargets=After radartargets
Target_Sorter_Prev.RadarTargets=Before radartargets
If changetarget$="Back"
temporary=targetentity
targetentity=Target_Sorter_Prev\TargetEntityHandle
If targetentity=temporary Then targetentity=Target_Sorter_Last\TargetEntityHandle
EndIf
If changetarget$="Forward"
temporary=targetentity
targetentity=Target_Sorter_Next\TargetEntityHandle
If targetentity=temporary Then targetentity=Target_Sorter_First\TargetEntityHandle
EndIf
I get multiple errors regarding After & Before must be used with Custom Types, and 'Objects must be a Type Field' |
| ||
| What do you mean by "current?" Do you know how to use For/Each/Next to loop through all the instances of a type? |
| ||
| Yeah, by current I mean if I could do something like:
For CountTargets.RadarTargets = Each RadarTargets
If targetentity=CountTargets\TargetEntityHandle Then ThisInstance.RadarTargets='Current' RadarTargets
Next
So I could then work with ThisInstance\(Fields) A For/Next loop alone is no good, because the 'current target' needs to remain the same, until the call to the subroutine is made, which will change to the next or previous target (and hopefully wrap-around to the Last/First if it reaches the First/Last. Is that any clearer? Sorry if it's a bit confusing. |
| ||
| I'm still not sure what you mean by "current." You're obviously "selecting" the target somehow in order for it to be considered "current;" what exactly are you doing? ADDITION: It occurred to me reviewing your first post that maybe you don't know how to attach a handle to a specific type instance. Like ThisTarget.RadarTargets=CountTargets.RadarTargets, and then use ThisTarget\(fields) outside the loop. I don't know if that is the exact code, but it is something like that. Basically, you have to store the handle to a type instance as a type instance, not as an integer (the normal variable type for handles.) |
| ||
| Okay Il backtrack a little and explain the circumstances (thanks for your patience!) Im working on a spaceship game. When the game is initialised, the 'World' is created with space stations, planets, moons and stars (as Meshes). Each time one of these objects is created, I also make a new Type instance under the RadarTargets Type, for those that can be targetted on the radar. The variable, targetentity is just a variable, but it is equal to the handle of one of these Meshes (This is how the 'current target' is specified). Within the RadarTargets Type, there is a Field called TargetEntityHandle. This is equal to the value of the particular Mesh handle. What the above code should do, is: 1)Check to make sure that if targetentity is 0 (i.e not set or mesh has been freed) then it will default equal to the First instance. 2)Change targetentity to match the previous or next instance 3)If already at the first/last instance, wrap around the list. |
| ||
| Ah - reading your edit: Thanks I was beginning to think that the only work-around maybe to use another Type just to link to it. I'll have a try. Thanks a lot! |
| ||
| Oh, now I think I get what you are doing. I couldn't tell what you meant by "current" but it sounds like you mean the type instance of the currently targetted entity. Give me a minute to whip up some code. |
| ||
Graphics 640,480,16,1 SetBuffer BackBuffer() Global CurrentTarget.RadarType Type RadarType Field entity End Type For i=1 To 10 Step 1 target1.RadarType = New RadarType target1\entity=i Next CurrentTarget = target1 While Not KeyHit(1) Cls Text 10,10,CurrentTarget\entity Flip If KeyHit(205) If Null <> After CurrentTarget CurrentTarget = After CurrentTarget Else CurrentTarget.RadarType = First RadarType EndIf EndIf If KeyHit(203) If Null <> Before CurrentTarget CurrentTarget = Before CurrentTarget Else CurrentTarget.RadarType = Last RadarType EndIf EndIf Wend End This is a complete sample which will run. Left/right arrows to scroll through the types. Naturally you would want the "entity" field of all the types to store actual entity handles, whereas here I'm just storing the numbers 1 through 10, but the general idea is here. The main thing is that you were using incorrect syntax with the After and Before commands (you were putting in the general RadarType and not the specific type instance to go before/after,) plus I declared a global CurrentTarget handle at the top of my code for keeping track of the currently targetted instance (what you were asking I believe.) Oh, and I DO love types (no lie!) |
| ||
| Well, arrayusers newer have such problems. |
| ||
| No, array users have other problems, like the fact that the number of elements in an array must be declared when the array is created and cannot change. And accessing elements of an array is all numbers, whereas types use easy (well, easier) to understand and remember names. |
| ||
| That's great Joe, Thanks again! I had to tweak it a little to make it compatible, but it's really helpful. It's the use of Global CurrentTarget.RadarType That made the difference as you said. I have seen this technique used before, and I remember reading that 'Why Name Types' thread - It's all a lot clearer now! Oh and it works a treat! |
| ||
| You of course need proper planning. If everything else fails, you can do a dual array swap (make an extra array, move the data, redim the old array, and move back the data) in order to get more space. By the way, when you choose between an array and a type, try to calculate how much ram an always large enought array would take, in 99% of the cases, not a lot. |
| ||
| @Malice: Glad to help. Types aren't hard to work with, it just takes a little getting used to the syntax at first. By the way, I just noticed something interesting. I declared CurrentTarget BEFORE I declared the RadarType. I would've expected an error from that, but apparently Blitz is cool with that order. @eBusiness: Don't forget the other issue, the use of cryptic numbers to access elements in an array. Accessing the health of a monster (for example) with "monster5\health" is a lot easier to understand and/or remember than "monsters(5,7)" I suppose you could use named constants in place of the magic numbers, but in that case you'd be doing more work than simply using a type. Oh, and don't forget arrays can only store one kind of data, whereas a single type instance can store integers, floats, strings, other types, etc. I do use arrays occasionally, but pretty much only when the numbers for accessing elements of the array relate directly to the data being stored, such as a bunch of objects arranged in a grid. |
| ||
| Hmmm, I use arrays all the time, I also seem to use grids all the time. Well, anyway, I have never done any kind of check, but I would suppose that arrays are in general faster, or is that wrong? I better do some kind of test before I continue that argument. |
| ||
| @Malice: Glad to help. Types aren't hard to work with, it just takes a little getting used to the syntax at first. By the way, I just noticed something interesting. I declared CurrentTarget BEFORE I declared the RadarType. I would've expected an error from that, but apparently Blitz is cool with that order. I noticed that too, but only when I was importing the code to my own. It had worked in your demo, so I assumed it was something you knew! I guess it's just the way the compiler runs through, probably checks for Type declarations first or something |
   |