[Mass Detector]
Have a function that would return the ammount of mass that the scanner had feedback for. Example: 5 fighters, and a gunship, would return 8. (fighters have 1 life, gunships have 3, therefore, (fighters)5*1 + (gunships)1*3 + (cruisers)0*10 = 8
Perhaps the bigger ships, (cruiser, and maybe gunship) would be able to get ship information out of this.
[Target Tracking]
I think the tracker should be seperate from the scanner. You would be able to decide when to aquire a new target to track.
ex: on_scan { if (not(target.life)) {target.aquire()} }
[Functions]
I think it would be nice to be able to define functions other than the built in ones.
[Interrupts]
current interrupts: on_scan, on_idle, etc.
During the course of the game, I think it would be nice to enable/disable interrupts, and be able to define the functions that they would execute. Ex.:
on_detect.disable()
if (not(code.get)) {on_scan.set(fighter.on_scan) }
if (code.get) {on_scan.set(fighter.recon_scan) }
Another useful function would be no_interrupt, yes_interrupt. This would enable a ship to start a calculation, and finish it without having anything interrupt it.
Orson
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
>Have a function that would return the ammount of mass that the scanner had
>feedback for. Example: 5 fighters, and a gunship, would return 8. (fighters
>have 1 life, gunships have 3, therefore, (fighters)5*1 + (gunships)1*3 +
>(cruisers)0*10 = 8
This is possible.
The life points will probably be increased (at least *10) for more subtle damage.
Should it return the current amount of life?
eg if a cruiser has 6 life points does that count as 6 or as 10?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I Like this idea, as long as it is not modifying Target in any way (except .Life).
If this is added, do we need the scanner-array? I think so.
If it should return life, the scannership could check wether it'
s force is big enough to kill the mass...
If (Math.Greater(ShipCount.Get,Scanner.Mass)) {
<Kick Ass :)>
}
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
>I think the tracker should be seperate from the scanner. You would be able to
>decide when to aquire a new target to track.
>ex: on_scan { if (not(target.life)) {target.aquire()} }
Yes good idea. (It's spelt acquire I think.)
Implies Target.UnLock()
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I disagree, I think the target should be acquired automaticly if there is not Target.Lock command in On_Scan. This is partially becausse of backwards compatible. If the Target.Acquire is added, the old fleets will never acquire a target, pluss, in most cases, people would want to acquire the target(s) anyway, so it just means we will run out of instructions faster.
<cost is 2 for return + 2+2+2+2+2+2+2 (operations) + 2+2+2+2+2+2+2+2 (read variables)>
fighter.on_idle
{
< ... >
if (math.less(user.distance(status.x,status.y,target.x,target.y),500))
<cost to call is 2 (call) +2+2+2+2 (read variables)>
< ... >
}
Note with this implementation it always costs more to call a function than to write out the code.
How much is this a bad thing?
It makes short functions expensive but doesn't affect long functions so much.
(The added costs are 2 call, 2 return [optional], cost of reading the arguments,
inside the function, the arguments are (private) variables - more expensive if they were literals [numbers] in the call.)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
>current interrupts: on_scan, on_idle, etc.
>During the course of the game, I think it would be nice to enable/disable
>interrupts, and be able to define the functions that they would execute. Ex.:
>on_detect.disable()
I agree there needs to be a way to switch behavior.
How would the extra event handlers be declared?
Just inline?
fighter.recon_scan
{
<...>
}
What happens if an undefined value is set for an event?
on_scan.set(math.random(10))
This would make it harder to debug fleets,
what new debug functions can be added to help?
(A single-step debugger is planned but that will take time.)
>Another useful function would be no_interrupt, yes_interrupt. This would enable
>a ship to start a calculation, and finish it without having anything interrupt
>it.
Well event handlers are never interrupted. There is an implicit
Status.DisableInterrupts() <at the start of every event>
Status.EnableInterrupts() <at the end of every event>
It would be useful for long events if you could enable interrupts
during the event and remain responsive
but it makes it much harder to debug a program.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
[Mass Detector]
Have a function that would return the ammount of mass that the scanner had feedback for. Example: 5 fighters, and a gunship, would return 8. (fighters have 1 life, gunships have 3, therefore, (fighters)5*1 + (gunships)1*3 + (cruisers)0*10 = 8
Perhaps the bigger ships, (cruiser, and maybe gunship) would be able to get ship information out of this.
[Target Tracking]
I think the tracker should be seperate from the scanner. You would be able to decide when to aquire a new target to track.
ex: on_scan { if (not(target.life)) {target.aquire()} }
[Functions]
I think it would be nice to be able to define functions other than the built in ones.
[Interrupts]
current interrupts: on_scan, on_idle, etc.
During the course of the game, I think it would be nice to enable/disable interrupts, and be able to define the functions that they would execute. Ex.:
on_detect.disable()
if (not(code.get)) {on_scan.set(fighter.on_scan) }
if (code.get) {on_scan.set(fighter.recon_scan) }
Another useful function would be no_interrupt, yes_interrupt. This would enable a ship to start a calculation, and finish it without having anything interrupt it.
Orson
>Have a function that would return the ammount of mass that the scanner had
>feedback for. Example: 5 fighters, and a gunship, would return 8. (fighters
>have 1 life, gunships have 3, therefore, (fighters)5*1 + (gunships)1*3 +
>(cruisers)0*10 = 8
This is possible.
The life points will probably be increased (at least *10) for more subtle damage.
Should it return the current amount of life?
eg if a cruiser has 6 life points does that count as 6 or as 10?
I Like this idea, as long as it is not modifying Target in any way (except .Life).
If this is added, do we need the scanner-array? I think so.
If it should return life, the scannership could check wether it'
s force is big enough to kill the mass...
If (Math.Greater(ShipCount.Get,Scanner.Mass)) {
<Kick Ass :)>
}
>I think the tracker should be seperate from the scanner. You would be able to
>decide when to aquire a new target to track.
>ex: on_scan { if (not(target.life)) {target.aquire()} }
Yes good idea. (It's spelt acquire I think.)
Implies Target.UnLock()
I disagree, I think the target should be acquired automaticly if there is not Target.Lock command in On_Scan. This is partially becausse of backwards compatible. If the Target.Acquire is added, the old fleets will never acquire a target, pluss, in most cases, people would want to acquire the target(s) anyway, so it just means we will run out of instructions faster.
Vidar Braut Haarr
AmigoSoft Productions
folk@popmail.com
hmmm
how do you return a value?
how do you call from the program?
how do you pass arguments?
how much should it cost?
Some suggestions:
user.distance_squared(x,y,tx,ty)
{
return(math.add(math.mult(math.sub(tx.get,x.get),math.sub(tx.get,x.get)),math.mult(math.sub(ty.get,y.get),math.sub(ty.get,y.get))))
}
<cost is 2 for return + 2+2+2+2+2+2+2 (operations) + 2+2+2+2+2+2+2+2 (read variables)>
fighter.on_idle
{
< ... >
if (math.less(user.distance(status.x,status.y,target.x,target.y),500))
<cost to call is 2 (call) +2+2+2+2 (read variables)>
< ... >
}
Note with this implementation it always costs more to call a function than to write out the code.
How much is this a bad thing?
It makes short functions expensive but doesn't affect long functions so much.
(The added costs are 2 call, 2 return [optional], cost of reading the arguments,
inside the function, the arguments are (private) variables - more expensive if they were literals [numbers] in the call.)
>current interrupts: on_scan, on_idle, etc.
>During the course of the game, I think it would be nice to enable/disable
>interrupts, and be able to define the functions that they would execute. Ex.:
>on_detect.disable()
status.disable(on_detect)
status.enable(on_detect)
status.getstate(on_detect)
status.setstate(on_detect,state)
>if (not(code.get)) {on_scan.set(fighter.on_scan) }
>if (code.get) {on_scan.set(fighter.recon_scan) }
I agree there needs to be a way to switch behavior.
How would the extra event handlers be declared?
Just inline?
fighter.recon_scan
{
<...>
}
What happens if an undefined value is set for an event?
on_scan.set(math.random(10))
This would make it harder to debug fleets,
what new debug functions can be added to help?
(A single-step debugger is planned but that will take time.)
>Another useful function would be no_interrupt, yes_interrupt. This would enable
>a ship to start a calculation, and finish it without having anything interrupt
>it.
Well event handlers are never interrupted. There is an implicit
Status.DisableInterrupts() <at the start of every event>
Status.EnableInterrupts() <at the end of every event>
It would be useful for long events if you could enable interrupts
during the event and remain responsive
but it makes it much harder to debug a program.