Problem: CPU and the 'Entity' output from the Target Finder

[Paper Clip]

I am working on a radar system involving a console screen. I have one problem though, to make it perfect I need to only draw each player once. If it tries to draw the same player more than once, it could leave a trail.

I have tried this method to fix this problem:
a) Create a locator beacon right next to the beacon sensor
b) Target the closest beacon sensor
c) Loop through the next targets until the close beacon sensor is targetted again

But there is a problem with this method. For some reason the majority of times it doesn't loop through all the other players within range before coming back to itself.

Another method I tried was to have the user specify the number of players in the game, but again this doesn't work because if you draw 5 players, it might draw the first player 2 times, and miss a player. Same problem as above.

So what I would like to do is loop through drawing entity id's that it hasn't drawn yet. The problem is I can't use the entity output from the target finder as in input to a Data Port, and if I create a high-speed link for direct memory access I have no idea what to look for because there is no documentation for it.

Anyone have any suggestions?

*note, I can't use the Entity Gates, because the server I am a regular on doesn't have them installed =(

[-=Fox=-]

It almost sounds like your looping though the targets too fast, or the CPU program isn't looping correctly.

Also if your interfacing the Target Finder to the CPU using the Data Port you MAY need to slow down the CPU, it can and will go faster than wire data refreshes, it may be just going too fast.

There is a opcode to slow the CPU down between certain instructions (Like output), its called: IDLE, BP told me that it slows the CPU down for the exact same amount of time it takes for the wire system to reset.

But as far as ID's go, since you can't pull the string data from the Target Finder to the CPU... a wild idea would be to have the CPU generate an ID for each player, since you only draw the players once, you could use a GPS based ID.

Of course you wouldn't be able to pull names or anything string based...

Another solution would be to feed the CPU the number of players, pull the location data and render that on the console screen, if you can get the GPS of the target finder or some object in addition to the players, you could have the CPU automatically detect the number of players in the game.

Once the CPU knows that there are players that haven't been drawn yet, it can skip the ones already drawn and draw those. Of course I have no clue as to the actual zASM/zC code entailed and I'm sure it's quite involved.

Anyways... I hope I've been a little useful :lol:

[Paper Clip]

It almost sounds like your looping though the targets too fast, or the CPU program isn't looping correctly.

Also if your interfacing the Target Finder to the CPU using the Data Port you MAY need to slow down the CPU, it can and will go faster than wire data refreshes, it may be just going too fast.

There is a opcode to slow the CPU down between certain instructions (Like output), its called: IDLE, BP told me that it slows the CPU down for the exact same amount of time it takes for the wire system to reset.

I originally did have the problem about CPU changing targets too fast, but I found a perfect solution for it so that it changes targets as fast as possible:

////////////////////////////////////////////////
// Selects the next target on the target finder /
/////////////////////////////////////////////////
NextTarget:
push eax
push esi
push ecx
push edi

// Save the bearing and elevation of the last target
in esi,0 // bearing
in ecx,1 // elevation
in edi,2 // distance

// Move to the next target
out 0,1
out 0,0

// Loop while not finished changing targets
NotDone:
in eax,0
cmp eax,esi
je NotDone
in eax,1
cmp eax,ecx
je NotDone
in eax,2
cmp eax,edi
je NotDone

pop edi
pop ecx
pop esi
pop eax
ret;

I will double check that it is looping correctly, but I am already close to %100 sure it is because I have a counter which ticks everytime it changes targets and it doesn't loop through every target before returning to the same target again. It seems to be a problem with the target finder.

But as far as ID's go, since you can't pull the string data from the Target Finder to the CPU... a wild idea would be to have the CPU generate an ID for each player, since you only draw the players once, you could use a GPS based ID.

Not a bad idea, but it means two nearby players will be drawn as a single blip on the radar. This might have to be my solution =/

Appreciate the time you put in to your answer!

Would there be a way to figure out the memory structure of the target finder by looking at the LUA files?

[sukasa]

You could use a data port / identity gate combo to know almost exactly when a think() round had passed if you're not already doing that.

[Black Phoenix]

There is a cool CPU opcode, "IDLE". Just call it, and you can be 100% sure at least 1 think loop has passed ("idle" skips all cycles to the end of "think" loop, so it gurantees that wire system will be reset)

mov port1,324;
idle;
mov eax,port4;

[Paper Clip]

Thanks for the replies =)

It doesn't look like there is a way to fix the problem. I will just have to live with the trail problem.