[WMCoolmon]

List of changes from current CVS:

- Added prefixes to some mprintf() calls
- Updated waypoints
- Added bm_is_valid function
- Added cfread_lua_number function
- Added strextcmp
- Removed dependency on any external media files
- Various un/signed casting fixes
- More conditional scripting support
- Better Lua debugging
- Reworked low-level Lua code
- Regrouped Lua libraries, added FS2 filesystem support.
- Animated nebula poofs
- All weapons are checked for collisions, even if nothing is done
- Fixed hud-toggling with freecamera
- Implemented batchers for all particle types
- Added per-shipclass debris settings
- Added fully settable particle emitters for impact and damage spews
- Added $Detonation radius, detonates weapon at X radius from target

Not including changes that I missed in looking over the diffs.

Please test this build. It'll be a lot easier to sort out bugs now, than six months down the line. I'm also looking for feedback on the scripting setup. And, er, any of the other half-dozen addtions. Some of the stuff - like debris speed, and particle spews - I imagine will be handy to quite a few people.

http://fs2source.warpcore.org/exes/latest/C12172006.zip

Code: [Select]

$Impact Spew:
   ;;Used when ship collides with something
   +Texture:  ;;Texture or animated texture for particle
   +Relative Position: ;;Position relative to collision point (vector)
   +Relative Velocity: ;;Velocity relative to ship (vector)
   +Relative Normal: ;;Direction particles are emitted from (vector)
   +Normal Variance: ;;How spread particles are from the center. From 0-2, I think.
   +Min Radius: ;;Smallest particle radius
   +Max Radius: ;;Largest particle radius
   +Min Speed: ;;Slowest particle
   +Max Speed: ;;Fastest particle
   +Min Lifetime: ;;Shortest particle lifetime
   +Max Lifetime: ;;Longest particle lifetime
   +Min Particles: ;;Smallest number of particles to emit
   +Max Particles: ;;Largest number of particles to emit
$Damage Spew:
   ;;Same as impact spew. Used when ship is shot.
$Debris:
   +Min Lifetime: ;;Smallest time that debris will last
   +Max Lifetime: ;;Longest time debris will last
   +Min Speed: ;;Slowest that debris will go
   +Max Speed: ;;Fastest that debris will go
   +Min Rotation Speed: ;;Slowest that debris will spin
   +Max Rotation Speed: ;;Fastest that debris will spin

weapons.tbl

Code: [Select]

$Detonation Range:
$Detonation Radius: ;;Distance from target that weapon will automatically blow up
;;Shockwave stuff
scripting.tbl (*-sct.tbm)

Code: [Select]

#Conditional Hooks
$Mission:
$Ship:
;;...
$On Collide Ship:
$On Collide Asteroid:
;;...

$Shipclass:
;;...
$On HUD Draw:
;;...

;;And so on.
#End

A full list of conditions and actions can be found in scripting.html, which is included in the ZIP and can also be generated for any build with scripting via the -output_scripting command line parameter.

[Goober5000]

- All weapons are checked for collisions, even if nothing is done

Eh?  What exactly does this mean?  Won't it harm optimization?

[taylor]

- Implemented batchers for all particle types

Also be aware, that is something which will have to change later.  I've had new batching and rendering code for particles done for months, but it's not good enough so I never committed it.  That's not to say that you shouldn't commit your change here (might even be helpful for the new code), but don't be surprised if it's all totally ripped out and rewritten in 4-5 months.

In order to blend with all other effects properly, a global batcher with new state switching code needs to be used instead of a particle subystem renderer like what we have now.  This needs to handle all effects: particles, fireballs, weapon effects, thrusters, etc., in a single spot so that everything can be properly sorted, blended, and rendered optimally.  I started something like this a while back, and added OpenGL point sprite support to it for much simplified code and much improved performance, but it will be a while before I get to work on that again.  Plus, I'll need to coordinate with Bobboau on it to make sure that it will actually work like I intended, and so that he approves of it.

[WMCoolmon]

- All weapons are checked for collisions, even if nothing is done

Eh?  What exactly does this mean?  Won't it harm optimization?

Yes, exactly why I chose to mention it. However, it's difficult to allow people to script in collisions between weapons that aren't even checked for collisions. I am very much against adding in a flag to toggle it, since it would require specialized knowledge to use the hook, that would only serve to later trip people up. So I decided to bite the bullet and see what the effects would be if I removed the laser-skipping restriction altogether; for lasers, it only has to do a check for the radii.

- Implemented batchers for all particle types

Also be aware, that is something which will have to change later.  I've had new batching and rendering code for particles done for months, but it's not good enough so I never committed it.  That's not to say that you shouldn't commit your change here (might even be helpful for the new code), but don't be surprised if it's all totally ripped out and rewritten in 4-5 months.

In order to blend with all other effects properly, a global batcher with new state switching code needs to be used instead of a particle subystem renderer like what we have now.  This needs to handle all effects: particles, fireballs, weapon effects, thrusters, etc., in a single spot so that everything can be properly sorted, blended, and rendered optimally.  I started something like this a while back, and added OpenGL point sprite support to it for much simplified code and much improved performance, but it will be a while before I get to work on that again.  Plus, I'll need to coordinate with Bobboau on it to make sure that it will actually work like I intended, and so that he approves of it.

Doesn't sound like it'll be a problem, but thanks for telling me.

[bycutza]

i can't download the file (nor any other file from the server) because my computer doesn't connect to  fs2source.warpcore.org .... i told a friend to connect to it and it still didn't work...
my IP is 85.204.128.61..
any idea why it doesn't work? thank you.

[Nuke]

does this mean i can use my scripted railgun effect without a massive slowdown?

[WMCoolmon]

i can't download the file (nor any other file from the server) because my computer doesn't connect to  fs2source.warpcore.org .... i told a friend to connect to it and it still didn't work...
my IP is 85.204.128.61..
any idea why it doesn't work? thank you.

That's odd...perhaps the DNS was changed recently, and it hasn't updated for you. The IP of the warpcore.org server is 82.165.252.33, although that won't get you to the fs2source subdomain.

does this mean i can use my scripted railgun effect without a massive slowdown?

Not knowing anything about it, I can't say.

[Bobboau]

rather than enableing all colisions, you could always check a colision if either object has a script to run.

[bycutza]

i can't download the file (nor any other file from the server) because my computer doesn't connect to  fs2source.warpcore.org .... i told a friend to connect to it and it still didn't work...
my IP is 85.204.128.61..
any idea why it doesn't work? thank you.

That's odd...perhaps the DNS was changed recently, and it hasn't updated for you. The IP of the warpcore.org server is 82.165.252.33, although that won't get you to the fs2source subdomain.

do you know any mirrors for downloading the files? (at least the mediavps files)? 10x...

by the way i told another friend to download the file and it worked:) (still quite large to send on messenger)..
my first friend has the same ISP as me (the same gateway, also), while my other friend has another ISP

oh and if you're talking about my DNS, there is nothing wrong with the servers

[WMCoolmon]

rather than enableing all colisions, you could always check a colision if either object has a script to run.

*sighs* Yeah, that is probably true. Although Conditional Hooks aren't stored directly in the object(s); that would add a lot of complexity. Instead, they're stored in one global array that the conditions are iterated through and checked for.

There's a lot that could be done to optimize them, but each time would make them more difficult to work with (on a lower level) so for now I'm crossing my fingers and hoping it doesn't come back to bite me in the ass soon. If it does, I'm fairly certain that in the end it works out to being more efficient to invoke the interpreter to check whether to execute every hook. (Hopefully around the time that spare CPU time starts getting scarce is when somebody starts looking into multiple cores usage.)

i can't download the file (nor any other file from the server) because my computer doesn't connect to  fs2source.warpcore.org .... i told a friend to connect to it and it still didn't work...
my IP is 85.204.128.61..
any idea why it doesn't work? thank you.

That's odd...perhaps the DNS was changed recently, and it hasn't updated for you. The IP of the warpcore.org server is 82.165.252.33, although that won't get you to the fs2source subdomain.

do you know any mirrors for downloading the files? (at least the mediavps files)? 10x...

by the way i told another friend to download the file and it worked:) (still quite large to send on messenger)..
my first friend has the same ISP as me (the same gateway, also), while my other friend has another ISP

oh and if you're talking about my DNS, there is nothing wrong with the servers

I never said that there was anything wrong with the servers, just that they may have been out-of-sync.

Regardless, if you can't get your connection working properly, you're probably better off asking in the FSUP forum. Last time I tried to mirror the mediaVPs someplace, I lost my free 1&1 account because the bandwidth usage ballooned.

[IPAndrews]

Can I just really, really politely please suggest that you keep a close eye on the effects of this weapon collision change. There are some newer mods and campaigns that put a lot of firepower into the air. I'm working on two of them and I'm also thinking about what is probably your flagship mod/campaign at the moment BTRL. Not a good idea to hit it in favour of a scripting system that few people know how to use (unfortunately).  No offence intended guys and esp Goober. We all owe a lot to you guys. Grovel, grovel .

[bycutza]

ok thanks...i'll ask someone on the official site's forum    :

[WMCoolmon]

ok thanks...i'll ask someone on the official site's forum    :

It's not used as much as the FSUP (FreeSpace Upgrade Project) forums. They're the home of discussion for the MediaVPs; this forum is only for discussion of the EXEs.

Can I just really, really politely please suggest that you keep a close eye on the effects of this weapon collision change. There are some newer mods and campaigns that put a lot of firepower into the air. I'm working on two of them and I'm also thinking about what is probably your flagship mod/campaign at the moment BTRL. Not a good idea to hit it in favour of a scripting system that few people know how to use (unfortunately).  No offence intended guys and esp Goober. We all owe a lot to you guys. Grovel, grovel .

Alright, let me take a step back here and make something clear...

I released this build so that people could use it to test things. Ordinarily, I wouldn't mind answering questions and so on about the features. However, I can only really postulate; I have no way of knowing whether or not something is 100% sure going to work on somebody else's system, with their own, different configuration. The best way for them to do that is simply to use the EXE to run whatever it is they want to test. That's a process that will probably take 10 minutes, for the most part, less time than it took to build the EXEs and upload them to an FTP. Certainly less time than it took to code and test the features in the first place.

I'm not even going to try to be responsible for testing every feature on every campaign of every mod. If people are unwilling to spend any time to test this build with their mod, then I won't feel any remorse when they discover, six months down the line, that something in this build is causing their mod fatal problems. I gave them the opportunity to test it, find problems when the code was still fresh in my mind. I really can't do any more than that.

So...warning appreciated, but if I didn't know that in the first place, I wouldn't have bothered to mention that in the initial post.

I can code in the optimization to make people feel better, but at this point, I'm not sure that would serve any real purpose. I've got no definite sign that virtually anybody working on one of the aforementioned other mods and campaigns cares at all about this build. That's not very encouraging. I don't feel like writing features for someone who expects a purely one-way relationship with no communication whatsoever.

EDIT: To answer the other part of your post, for the moment, BTRL doesn't have any official missions completed that are large-scale enough to measure any significant change in the weapons collisions.

[karajorma]

I usually test stuff after it hits CVS anyway but BtRL has been keeping me extra busy the last couple of weeks.

Biggest problem with testing this build is going to be that due to the scripting changes it's going to complain something chronic about scripting.tbl. I suppose I can disable that for the duration of any test.

[Nuke]

i finnally have time to play with scripting again. first i was trying to get some old scripts to run in 3.6.9 offitial, some stuff like my lead inticator and hudpong i got working again. but those are already obsolete by this build. so be patient while i re-learn how to use scripting. anyway i managed to get the first few lines of my lead code to work before i come to a prob i dont really understand.

Code: [Select]

player = mn.Ships["Alpha 1"]

if player ~= nil then
target = player.Target
end

if target ~= nil then
if target.Position:getScreenCoords() ~= false then

it gets to about there and gives me this

Could not find index 'Position' in type 'object'

Code: [Select]

------------------------------------------------------------------
ADE Debug:
------------------------------------------------------------------
Name: (null)
Name of: (null)
Function type: (null)
Defined on: 0
Upvalues: 0

Source: (null)
Short source:
Current line: 0
------------------------------------------------------------------


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

1: Userdata [object]
2: String [Position]
------------------------------------------------------------------

now i know you changed some of the usage and after scanning through the scripting.html and other lua resources im still stumped. seems that a position value does exsist in the object but im not really seeing how to get at it.

[WMCoolmon]

Well first off, handles should never ever be nil, regardless of whether they're set or not.. This is because the lua interpreter will panic if it tries to index a nil variable; short of recoding the interpreter itself, there's no way to change that. To check if a handle is valid, use the :isValid() function.

However, even in that case, you shouldn't be getting that error. getScreenCoords should fail, but it shouldn't cause an error. That's also a native variable to the object class, so it shouldn't be a problem with inheritance. Have you gotten any other errors for object member variables?

[Nuke]

first off i think i accidently clipped the first line off that error, first line was:

Could not find index 'Position' in type 'object'

secondly im not getting the thing with the :isValid() function. from what youre telling me, am i correct to assume that i should substitute

Code: [Select]

player = mn.Ships["Alpha 1"]

if player ~= nil then
target = player.Target
end

with

Code: [Select]

player = mn.Ships["Alpha 1"]

if player:isValid() then
target = player.Target
end

well that was enough to get in game. it still crashes, but i only updated 2 lines so far. that might have been the whole thing i was doing wrong. im gonna have to keep debuging the script to see what else is wrong. il get back to you on wether or not something is wrong with the code.

*edit*

ok my scripts working good. only other problem was that i had to change target.Velocity to target.Physics.Velocity. now that i figured this stuff out  i can probibly torture test the scripting system a little better.

[WMCoolmon]

Yeah, that's correct. It will also make sure that the ship hasn't died or departed, basically it's a safe-function that should tell you if anything's wrong with modifying the object's variables.

Although as I've said before, things in scripting shouldn't just _crash_. They should give you some kind of error message. If they don't, it's a bug. Debugging is already enough of a pain with the inadequate Lua debug tools...

[Nuke]

ok one more thing, when i try to use +override: true on the hud, i get this

Code: [Select]

Error parsing HUD override

------------------------------------------------------------------
ADE Debug:
------------------------------------------------------------------
Name: (null)
Name of: (null)
Function type: (null)
Defined on: 0
Upvalues: 0

Source: (null)
Short source:
Current line: 0
------------------------------------------------------------------


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

1: Userdata [Audio]
2: Userdata [Base]
3: Userdata [Controls]
4: Userdata [Graphics]
5: Userdata [CFile]
6: Userdata [Mission]
7: Userdata [ScriptingVariables]
8: Userdata [Tables]
9: Userdata [Testing]
10: Function
------------------------------------------------------------------

however if i click no it goes back to the game and runs without a hitch. is this a bug ore does it indicate a case of bad scripting

[WMCoolmon]

Well, as near as I can tell from testing, this is the result of some stupid Lua move whereby the "return" statement no longer works as it used to. Because I was using it for the +Override: statements, they're pretty much disabled right now. That is something I can hack together a fix for easily enough.

I think. (Crosses fingers)