Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: WMCoolmon on June 11, 2006, 04:41:11 am
-
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.
-
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
-
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 %).
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 (infact 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.
-
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:
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.
-
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
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.
-
You're trying to draw the subsystem object, which doesn't actually have a __tostring operator...Try swapping
gr.drawString(mn.getShipByIndex(1)[j],200,20*j+100)with
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.
-
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]
-
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.
-
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 (http://www.hard-light.net/wiki/index.php/Scripting_API#General_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.
-
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))
¨à=: 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]
------------------------------------------------------------------
-
Fixed that, and subsystem indexing/subsystem weapon handles.
-
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.
-
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?
-
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.
-
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.
-
i thought the code was getting away from "standard resolutions" :D
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.
-
i thought the code was getting away from "standard resolutions" :D
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. :)
-
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.
-
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.
-
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.
-
Well as far as I'm concerned, all scripting screen coordinates should be in absolute coordinates and if they aren't, it's a bug.
I doubt I'll have it fixed by 3.6.9 release, though, the branching thing has been an utter pain in the ass to work with. Before I commit anything more to that branch I need to set up another dev environment for it, I've tried having a separate branch on my HDD and it hasn't caught one completely by-itself difference in lua.cpp. I've already been yelled at for not test-compiling, after fully testing and test-compiling changes, because I let that one little bit slip through when I committed to the 3.6.9 branch.
-
no need to rush with the scripting on my account though, i can only do bits ant pieces of what i wish to accomplish with it so far. made some intresting discoveries, like how to get a working mouse cursor on your hud. but i couldntget it to do anything cool like control a turret or point and click targeting. i thought about using render to texture to put a pong game on one of the screens in one of my fighters, and theres actually enough stuff to make it work too. but my real objective for today was to replace the lead indicator and reticle with a moving reticle like the kind used on 50s fighter planes. i managed to get an automatic target selector working and a cool little reticle which would be placed over the automatically selected ship. it doesnt lead yet, just sits on top of the target. i guess i can use it for beams :D. to make it lead i need a number of factors, player and enemy position and velocity vectors (wich i could figure out how to get), and the velocity and range of the player's weapons (which i could not find). that having failed i tried to animate it so it would return to the center when it didnt have a target and would move over to the target when it had one, but it wasnt very good and resembled something i did in highschool with vb. il have to take a crash cource in trig to get that to look smoother. i liked wat i accomplished even if it was practically nothing.
-
I doubt I'll have it fixed by 3.6.9 release, though, the branching thing has been an utter pain in the ass to work with.
Have you been making changes to both branches simultaneously, or have you been changing one branch and patching the other?
The latter is a much better method IMHO. If there's a bug in 3.6.9, I fix the 3.6.9 branch, patch the main branch, test both, and commit. I haven't found it hard.
What sort of problems have you run into?
-
any chance we cant get a way to take a render from a camera object? i want a turret boresight camera to render to texture so you can have a screen in a virtual cockpit show you what your turrets looking at.
*edit
just incase you coders are woried that scripting is underused:
http://www.hard-light.net/forums/index.php/topic,40912.0.html
-
:bump:
So sorry about that... but i again encountered something where i need a little help...
Do these two really function? If they do what is the proper syntax for them...
sd.playGameSound()
sd.playInterfaceSound()
When i use those i get no errors at all but neither do i get any sounds either.
I tried all these
sd.playGameSound("7_yes",0,100,0)
sd.playGameSound("7_yes.wav",0,100,0)
sd.playGameSound(7,0,100,0)
-
:bump:
So sorry about that... but i again encountered something where i need a little help...
Do these two really function? If they do what is the proper syntax for them...
sd.playGameSound()
sd.playInterfaceSound()
When i use those i get no errors at all but neither do i get any sounds either.
I tried all these
sd.playGameSound("7_yes",0,100,0)
sd.playGameSound("7_yes.wav",0,100,0)
sd.playGameSound(7,0,100,0)
i think you got to use a sound.tbl numerical reference, rather than a wav file.
also has anyone managed to get gr.drawCurve() to work?
-
You have to specify the filename of a sound in sounds.tbl, sound indices won't work.
drawCurve, direction must be 0-3 for now.
-
il try that one
-
You have to specify the filename of a sound in sounds.tbl, sound indices won't work.
OK, i tried that it after i added the the sound i wanted to the sounds.tbl and it works very nicely :yes:. I wanted to play speech things during the mission with scripts like automated background process to create both randomized event triggered (enemy death/missile launch etc.) and background chatter type radio noise. And now it even functions properly :D
-
BTW I added the Speed variable to the weaponclass, along with a few other of the easy-to-implement variables. Pending testing, it and some other values will go into post-3.6.9 CVS.
-
that comes in handy for something im working on.