[WMCoolmon]

I _know_ that I've missed some bugs, and I'm pretty certain that there are some handy features that could be implemented.

So if you want something in scripting before 3.6.9, or have a bugfix, you should be asking ASAP.

[Wanderer]

Hmm... for starters

i) Functional subsystem handle
For example
mn.getShipByIndex(1):getNumSubsystems() still returns zero (in test mission the ship with index 1 was vasudan cruiser, Mekhet)
mn.getShipByIndex(1)["gunturret-0"]:getName() returns 'laser cannon'
mn.getShipByIndex(1)["gunturret-0"].Target returns numerical value instead of an Lua object

ii) Setting hitpoints to zero (0) with scripts do not destroy the object.
Instead i get ship with minimum hitpoints and all subsystems at 0 %

iii) Sometimes with ts.createParticle (especially if 'tracer' option is enabled) various 2d effects (impact explosions, impact particle spews etc.) get centered to global 0,0,0 instead of the correct position.

Then one another... when browsing the fs.log files i noticed that all.. well atleast missiles.. have their specific ID tags like the classic line Frame 1208: Weapon #146 CHASING cmeasure #264... So if that weapon ID value is unique (the mn.getNumWeapons() wasnt over 80 at that moment) it might be nice to use that value if some permanent scripted effect is to be attached to a weapon effect

[Wanderer]

I doubt no one is actually using scripting yet in any released form so i might two oddities/problesm that i have encountered...

Trying to modify ship velocity is act of futility. If the new velocity vector is paraller to the vector into which it is to be added it doesnt do a thing. However if its perpendicular... it works... Oddest thing is that if its 45 deg angle ship moves at very high speed along that exact vector. Odd changes in velocity change are 'fixed' by turning engine off in FRED (setting engine subsys to 0 %).

Code: [Select]

mn.getShipByIndex(2).Velocity = mn.getShipByIndex(2).Velocity + ma.newVector(0,0,80)
Attempting to do the same with position resetting seems to function like a dream but it has a huge problem included. Collision code is partially broken if the set position is used ( this is not suprising). However this makes things like capship roll scripts rather difficult to perform as the roll has to be really slow to prevent collisions from getting too badly screwed.

[WMCoolmon]

Hmm... for starters

i) Functional subsystem handle
For example
mn.getShipByIndex(1):getNumSubsystems() still returns zero (in test mission the ship with index 1 was vasudan cruiser, Mekhet)
mn.getShipByIndex(1)["gunturret-0"]:getName() returns 'laser cannon'
mn.getShipByIndex(1)["gunturret-0"].Target returns numerical value instead of an Lua object

Fixed in CVS

ii) Setting hitpoints to zero (0) with scripts do not destroy the object.
Instead i get ship with minimum hitpoints and all subsystems at 0 %

Added kill function (Fixed)

iii) Sometimes with ts.createParticle (especially if 'tracer' option is enabled) various 2d effects (impact explosions, impact particle spews etc.) get centered to global 0,0,0 instead of the correct position.

Haven't looked into this.

Then one another... when browsing the fs.log files i noticed that all.. well atleast missiles.. have their specific ID tags like the classic line Frame 1208: Weapon #146 CHASING cmeasure #264... So if that weapon ID value is unique (the mn.getNumWeapons() wasnt over 80 at that moment) it might be nice to use that value if some permanent scripted effect is to be attached to a weapon effect

Would you be able to do what you're saying by comparing two handles and seeing if they're the same?
IE:

Code: [Select]

shipA = mn.getShipByIndex(1)
shipB = mn.getShipByIndex(1)
if shipA == shipB then
It's easy enough to hand out the object's signature, but it seems like more user-friendly methods can be used for now...network stuff would want that, though.

(Velocity and collision problems)

Haven't looked into this.

[Wanderer]

With taylor 20060614 build... The ship:kill(ship) works otherwise nicely but the death takes some 20 seconds from triggering the event to the actual destruction with a fighter.. During which time the fighter is spinning wildly and also amount of hitpoints is dropping but the drop starts as very fast but is steadily slowing down.. that is i can still keep the fighter targetted (no brackets though, but with HUD targetting view) despite it being 'destroyed'. If triggered on player you get to the 'death screen' to watch your ship rolling in the screen until 20 s has passed even if some one tries to shoot them or hitpoints being set to 0 simultaneously.

EDIT:
I also tested the subsystem things and found something odd... With

Code: [Select]

for j=1, mn.getShipByIndex(1):getNumSubsystems() do
   gr.drawString(tostring(j),100,20*j+100)
   if mn.getShipByIndex(1)[j] ~= nil then
      gr.drawString(mn.getShipByIndex(1)[j],200,20*j+100)
   end
end

I get numbers running from 1 to 17 on the screen but nothing else. So it seems like regardless of the j value it returns nil.

[WMCoolmon]

You're trying to draw the subsystem object, which doesn't actually have a __tostring operator...Try swapping

Code: [Select]

gr.drawString(mn.getShipByIndex(1)[j],200,20*j+100)with

Code: [Select]

gr.drawString(mn.getShipByIndex(1)[j]:getName(),200,20*j+100)
EDIT: I'm not sure why the ship:kill() function is doing that. I have an idea, but I need to test it out (And the turret variables) before I put my changes in CVS.

[Wanderer]

Yeah i tried that already.. The point is that instead of getting - as expected - an error concerning of an attempt to pass userdata (such as subsystem object) as string i get an error meaning (imo) that there arent any subsys (nil warnings).

With the line you are offering i get non-debuggable lua error. Nil value stuff without any Lua stacks.

EDIT: I can (sort of) get around of that problem by using direct subsystem names instead of numbers like ["gunturret-0"] instead of [j]

[WMCoolmon]

You shouldn't have to, though. I did find a silly little bug with that function, IIRC, it may not have gotten committed, or something else may be going on. Guess I'll add that to the two other things.

Something to mention about createParticle, the function is technically in testing, awaiting an overhaul of the particle system. I'm not sure if I should leave it as-is, or if I should change the parameters, or have some kind of object-oriented methodology...also, whether or not it belongs in the 3D graphics or mission library is something I've been idly switching back and forth between. On the one hand, a 'particle' only has a graphical existence. On the other hand, they have to be manually rendered anywhere outside of a mission, and their actual function is incredibly simple.

I don't know why collision and velocity are working. My guess is that velocity is because of some interference with the physics system. Freespace uses a bizarre combination of physics, and I don't think I've expanded everything into scripting yet. It might be prudent to re-do the way I've done that as well, in case something else uses the same physics format as the "object" type. At any rate...

There are some 4 key fields to velocity. Velocity, desired velocity, maximum acceleration, and maximum velocity. There's also something called "damping" involved, that I don't fully understand. But essentially what FS does, is it attempts to change velocity (m/s) match the desired velocity (m/s) at a rate of maximum acceleration (m/s/s). It may automatically set desired velocity to maximum velocity, but I can't say for sure; I haven't looked at the code enough.

All that means is that at the point that things reach the physics code, the desired velocity and velocity must be the same or the physics code will attempt to change it. There's a physics flag for weapons that forces a constant velocity codepath, but that hasn't been extended into scripting yet. That may actually be the best solution for scripted velocity in most cases, as it would make the physics code adopt a 'hands off' policy for objects and just move them by whatever Velocity is set to.

[WMCoolmon]

I'd also like to ask, are there any last changes people think would be useful, or beneficial in the future, for 3.6.9. Not so much as bugfixes, but ways of making the interface easier to learn, or generally more intuitive/consistent, or simply more useful. (ie integrating two functions that would almost always be used together, or changing an argument type to one that would be more commonly used.) It'd be nice to have some feedback on the documentation - I used a few different styles of defining function arguments and return values. However, it's much easier to go back and change the documentation - or fix bugs - after 3.6.9, than it is to change the interface and break mod support.

When I say "Changing an argument type to one that would be more commonly used", a good example is shipclass:renderTechModel() 's rotation parameters. All three of these are in %. However, those fields could also be specified in radians, degrees, or all three (X/Y/Z) could be replaced by an "orientation" object. That object, in turn, could be called a "matrix" (as it is in the code, and to go with vectors). I called it "orientation" just because I thought it made it more instantly understandable. (There is some oddity under the hood, to allow individual angles to be accessible with pitch, bank, and heading while still maintaining the speed of a 3x3 matrix, but in use it's mostly an integration of how the codebase uses a matrix)

Consistency in documentation could also be extended to function names. I've tried to stick to a general set of conventions (see "For scripting:"). I don't think that that set really needs to, or should be changed at this point, unless it's been very annoying or there have been serious problems with it. However, after 3.6.9, I'd like to change existing function and library names as little as possible, so that mods will have a stable base to work with.

[Wanderer]

This is something that is probably more due to my own stupidy than an actual bug...

I cant seem to be able to load animations (.ani or .eff) with gr.loadTexture (atleast) when using it with ts.createParticle function

gr.loadTexture("blast_0005") gives me texture (as blast_0005.dds is texture)
gr.loadTexture("exp05",true) gives me nothing (exp05.ani).. or something that lua stack claims to be boolean

That is this thing fails
ts.createParticle(ma.newVector(0,0,0),ma.newVector(0,0,0),1,1,"bitmap",-1,false,gr.loadTexture("exp05",true))

Code: [Select]

¨à=: Argument 8 is an invalid type 'Boolean'; type 'texture' expected

LUA Debug:
------------------------------------------------------------------
Name: createParticle
Name of: field
Function type: C
Defined on: -1
Upvalues: 1

Source: =[C]
Short source: [C]
Current line: -1
------------------------------------------------------------------

LUA Stack:
------------------------------------------------------------------

1: Userdata [vector]
2: Userdata [vector]
3: Number [1.000000]
4: Number [1.000000]
5: String [bitmap]
6: Number [-1.000000]
7: Boolean [0]
8: Boolean [0]
------------------------------------------------------------------


[WMCoolmon]

Fixed that, and subsystem indexing/subsystem weapon handles.

[Nuke]

make getScreenCoords() take your screen resolution into account, it always returns coords for a 1024 x 768 screen, rather than whats being used, which throws off hud gauge rendering.

[Wanderer]

Good catch! I only mainly run in 1024 x 768 & in window due debugging and other reasons so i have missed this one totally. If you dont mind could you add the stuff to the wiki entry ( http://www.hard-light.net/wiki/index.php/Script_-_Velocity_Indicator )i made for that script?

[Nuke]

you mean throw in the 2 lines i posted in the other thread to make it resolution independant? i can but it wouldnt be nessiscary if they fix the function.

[taylor]

It doesn't return 1024x768 resolutions only, it returns standard resolutions only.  That being 640x480 based coordinates if you are using a resolution less than 1024x768, and 1024x768 based coordinates if you are using a resolution higher.  Now that shouldn't be a bug (by regular coder logic) since the rest of the game assumes that you are always using a standard resolution and then converts it only when it needs to.  The problem is that the rest of the scripting functions appear to operate in the reverse, assuming that everything is the exact resolution/size/position that you are requesting.  So which is the bug?  Ask WMC.

[Nuke]

i thought the code was getting away from "standard resolutions"
well this is wmc's thread i was hoping hed read it. still its rather ineffietient to call gr.getScreenWidth() and gr.getScreenHeight() to convert the coordinates in every frame when it could be handeled by the internal functions at a much faster rate.

[taylor]

i thought the code was getting away from "standard resolutions"

All of the artwork and layout is still a "standard" resolution though.  We just make sure to translate all of that to non-standard values when it's shown on the screen.  We can support non-standard resolutions all we want, but we'll never actually be rid of "standard" coordinates for anything.

[Nuke]

still i think the purpose of the function would better be fulfilled if it gave actual coordanates instead of standards, or maybe output in percent of width. executing scaling code on a frame by frame basis seems a little redundant. you can thusly remove 2 function calls, 2 multipluies and 2 divides from your script.

[WMCoolmon]

Sounds like it just needs a call to the gr_resize_pos function. I didn't notice it because I fixed & tested that function in 640x480.

I'd rather do everything in absolute coordinates, so mods have the option of using an interface that scales how they want it.

[Nuke]

it would be nice. i could understand using the standard resolutions, if there werent 2 of them. like if i have a gauge thats gameplay critical, and if its faster in one resolution than in another it seems abit unfair. extra script needs to be written to compensate. if i had one set of screen coords to worry about, absolute or otherwise, it would really make the whole thing easyer to work with.