Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Test Builds => Topic started by: WMCoolmon on May 03, 2005, 01:37:59 am
-
Edit: Updated, since apparently I wasn't fast enough in posting this. :doubt:
Edit 2: If you've been having crashes in release builds that can't be resolved in a debug build, I've included the .map file with this build so that we can find out where the error occured based on errorlog.txt. Not that I've had much luck reading them myself...but it'll hopefully help.
http://fs2source.warpcore.org/exes/latest/C20050502.zip
New armor syntax:
#Armor Type
$Name: Reflective
$Damage Type: Light missile
+Calculation: Multiplicative
+Value: 3.5
+Calculation: Additive
+Value: 20
$Damage Type: Laser
+Calculation: Multiplicative
+Value: .5
#End
ships.tbl
$Hitpoints
+Hull Repair Rate
+Subsystem Repair Rate
[b]$Armor Type: Reflective[/b]
weapons.tbl
$Name: Subach HL-7
...
$Damage
[b]$Damage Type: Laser[/b]
Valid calculations are "additive", "multiplicative", "exponentional", and "exponential base"
Medals are dynamically allocated; basically, this means you can have more or less than the retail FS2 number. However, I don't guarantee they'll work properly until Multiplayer and pilot files are updated. If you have fewer medals they should work, more medals, data on those over MAX_MEDALS (basically, the old number of medals) will be lost.
Booleans (ie yes/no valeus in tables) now support the following languages:
- English
- German
- French
- Spanish
- Latin
- Klingon
Added to the website.//redmenace
-
Oh, it's a new build... ;)
I hope we can find te bug.
-
Hmm, okay, I just tried the armor system and it doesn't seem to be working properly... no parsing errors, it just isn't being applied. :sigh:
Well, at least you guys'll have the Klingon bools to play with. ;)
Edit: Ahhh...this line might be needed. :p
DamageTypes.push_back(adt);
Edit: Thanks to the Colossus' destructive armor, I just wiped it out with a Subach HL-7. :p
Edit 2: New build zip added. Also, I added a "cutoff" value; any damage less than the value will be discarded. But note that operations are performed in sequence; if you do a cutoff and then an additive of 20, the weapon will do 20 points of damage.
Hopefully I can get Bobb's expression system working with this, that'll give much more in the way of flexibility.
-
Originally posted by WMCoolmon
Booleans (ie yes/no valeus in tables) now support the following languages:
...
- Latin
- Klingon [/B]
Eh. Well. Romans, chruchmen and space vikings eh? Oh well.
-
It's a pity that it doesnt support the one most common language on teh internet: tpyolish!
-
No longer CTD's on loading bars ! Excellent work.
On the side note, I cant hear any briefings anymore.
-
Oh, right, these builds use OpenAL for sound. You should get the latest drivers (http://developer.creative.com/articles/article.asp?cat=1&sbcat=31&top=38&aid=46) here, hopefully we'll be switching over to OpenAL in the future so that the same code will work under Linux and Windows.
-
Is the armour code already being used in existign campaigns?
-
I got this with TBP 3.2 Beta on startup
Assert: si->data != NULL
File: e:\cvs\fs2_open\code\sound\ds.cpp
Line: 930
Call stack:
------------------------------------------------------------------
fs2_open_C20050502_d.exe 0075c3fe()
fs2_open_C20050502_d.exe 0075d474()
fs2_open_C20050502_d.exe 0090b0f5()
fs2_open_C20050502_d.exe 00882a73()
fs2_open_C20050502_d.exe 006a3d7c()
fs2_open_C20050502_d.exe 00855dcd()
fs2_open_C20050502_d.exe 006a29e9()
fs2_open_C20050502_d.exe 008563ec()
fs2_open_C20050502_d.exe 006a5946()
fs2_open_C20050502_d.exe 006a5b3c()
fs2_open_C20050502_d.exe 00ad2877()
kernel32.dll 7c816d4f()
------------------------------------------------------------------
-
Also while trying to open the tech room while contiuing a pilot in the middle of the campaign with all the vps, except mv_cell.
Error: Can't open file <>
File:.\model\modelread.cpp
Line: 1643
Call stack:
------------------------------------------------------------------
------------------------------------------------------------------
-
No, hmm, interesting. :p
No - no campaigns are currently using the armor system, I don't think anyone's understood it. I'm thinking I'll hook it into Bobb's expression system, but I need/want to understand the system more completely to add a special 'weapon' property. I also want to try and at least come up with some sort of way of handling syntax over the different systems that this is being used in (HUD, Armor, Materials). Generic items like "ship" and "weapon" could mean the weapon the material's being applied to, or the weapon that is impacting a ship, or the currently selected weapon of a ship. The system _needs_ to be easy to understand and documented properly for anyone to be able to use it. (It'd be nice if we could define groups of variables to allow, and then use an output like -output_sexps (Which is in this build, btw) to show what variables are available to people, without having to go to the trouble of updating the wiki by hand)
Hmm - I ran into that problem some as well, I'm not sure if it's b/c of OpenAL or making the sounds list dynamic. Although it is fairly reproducable for me.
Interesting - that damn techroom bug has plagued me for the last few months, but I've never been able to reproduce it myself. This is (hopefully) the cause, and it looks like it's trying to load the file called ""...probably why it's having trouble. :p
-
Exponential base should probably be renamed quadratic.
-
you'll note in the variable system it no longer gets passed a ship or an object but a data structure containing all sorts of instance specific data, you can add stuf like weapon info (impact angle for instance, I think would be very usefull). now I think :object: would be prety obviusly the ship getting hit, you can add an additional weapon_object if you want, but I'd think it'd be best to kep the number of available variables to a minimum, to allow expression portability.
within the material system :object: will always refer to the object getting drawen, any weapon feild you make for this will not be used in the material system, because the armor system is dealing with two objects it will nesisaraly need a second object somewere.
as far as HUD's concerned, :object:==the ship you are viewing from. :object.target: == the object targeted by the object you are looking from (we could recurse the object parseing code).
it might be a good idea to bring this up in the internal and have a full discusion about it. the game variable aspect is the 'freshest' component.
btw I am planning on makeing a specal derived class for handeling subsystems.
-
Originally posted by redmenace
I got this with TBP 3.2 Beta on startup
Assert: si->data != NULL
File: e:\cvs\fs2_open\code\sound\ds.cpp
Line: 930
Call stack:
------------------------------------------------------------------
fs2_open_C20050502_d.exe 0075c3fe()
fs2_open_C20050502_d.exe 0075d474()
fs2_open_C20050502_d.exe 0090b0f5()
fs2_open_C20050502_d.exe 00882a73()
fs2_open_C20050502_d.exe 006a3d7c()
fs2_open_C20050502_d.exe 00855dcd()
fs2_open_C20050502_d.exe 006a29e9()
fs2_open_C20050502_d.exe 008563ec()
fs2_open_C20050502_d.exe 006a5946()
fs2_open_C20050502_d.exe 006a5b3c()
fs2_open_C20050502_d.exe 00ad2877()
kernel32.dll 7c816d4f()
------------------------------------------------------------------
I'm getting this too, only when I use a debug. When I try the release build, I can get as far as the pilot select screen. As soon as I commit on a pilot, CTD. I have encountered something good though. Even though I can only get to the pilot select screen, this far is enough to tell me that this build supports ogg for interface sounds... I can hear it. Too bad I can't use it to test if effects and voice files play in mission.
Also, I tried just running straight FS2 and it ran with no problems. I played a mission, but oddly enough the sounds (effects & such) seemed a bit muffled. Could this have something to do with the OpenAL implimentation you mentioned? Would installing that app you linked improve this somewhat?
-
Well, vanilla FS2 is rock solid stable for me with all the media vps save music.vp.
Unfortunately, I'm having the capship beam issues again - particularly, in 'slaying ravana' the vasudan destroyer or vette or whatever it is isn't firing it's beams on the ravana, making this mission considerably harder.
I'd expect "Their finest hour" would be completely broken too.
-
Bah! Friggin' turret code... *goes off to try and fix it again...one...last....time.*
-
Originally posted by WMCoolmon
Booleans (ie yes/no valeus in tables) now support the following languages:
- English
- German
- French
- Spanish
- Latin
- Klingon
i take it you were bored :D
while your messing with the turrets ad gatling turret compatability please:D
-
Must...resist...urge...to rewrite...turret code.
-
LOL *YOU* get to change what you want! *pouts* :D
-
Well, if I rewrite the turret code, it'll be more neatly coded but probably behave differently and break backwards compatibility.
Although I'm not 100% sure that'd fix it. :blah:
The problem is that some turrets acquire targets just fine; others simply don't. I set up a debugger display to show me what all the turrets on a given ship were doing, on two Deimos Corvettes attacking a Hathepsut, none of the turrets were firing.
That being said, maybe it's something related to the big only flag or enemy mask...
-
I can verify this even with Blaise's Derelict, with the mission with the gorgon cannon, it never fires. Any capship with beams refuses to fire on corvettes and other ships. Antifighter beams work ok but that's it.
Retail FS2 campaign, same thing, capship beams just dont fire on other large ships
-
Things I've noticed:
In their finest hour, the Sathanas doesn't fire on the big C. The collosus, on the other hand, has no trouble at all opening fire on the Ravana that jumps in.
None of the other GTVA ships in the mission use their beams - the two cains do fire theirs, and the lillith is as trigger happy as ever.
-
its mostly a matter of beems having a range disperportional to ship size. beam cannons on the back of my 11km long ssj dante cannot hit a ship flying above the forward arms. when looking at a big ship you kinda over estimate the distances between them. pit a ravana and a hecate in a broadside to brodside beam fest at maximum effective beam range, and you couldnt fit any other destroyer between them.
-
^Too bad thered only be one beam firing in that case (i think)
Anyways, in their finest hour i never had any of the GTVA ships but the C use their beams, so is this normal or was i using a fubar build?
-
The turrets don't seem to be working properly, still. :doubt:
-
In another example of horrible FREDDING, the caps in 'Their Finest Hour' don't use beams. Because, you know, they're only saving the human race, why worry? :rolleyes:
Say it with me - 'The Freespace campaign is perfect how it is'. :)
-
I once saved the colossus and capella by only disabling the beam turret on that lilith, it slid right past the collossus and to the capela star where it presumably interfered with the subspace wave...
Sathanii 43: Danm lilith n00b!!!
-
hey, armor makes sence now :D
-
Whatever happened to the idea of using an SCP approved standard mission for testing every possible thing........... >_> .....
......we really need to decide on ONE mission that really pushes the SCP's code to the limits in all aspects (graphical, SEXp, everything).........but i digress. I haven't had much trouble (YET) with this build.
For now.
-
For the past few builds, I've been getting some very strange activity when using Direct 3D. I'll post these in mantis if you wish. Put simply, I've described a problem somewhere else where my texture memory would drop to 0, then the game would start to freeze up. Well, it's now doing the same thing even with a boatload of available texture memory. I've been using the same exact flags as I have been on previous builds, using a fairly fresh install of FS2, have all my mods seperated into thier own folders, and have a fresh re-installation of my video drivers.
-
Originally posted by redmenace
I got this with TBP 3.2 Beta on startup
Assert: si->data != NULL
File: e:\cvs\fs2_open\code\sound\ds.cpp
Line: 930
:bump:
Any new developpments on this? Getting a fully OGG-supportive build that works with TBP is crucial to testing for said team. This one works with all oggs, but the crashing prevents its effective use.
-
yes please fix the tech room bugs and the other issues. I will give you whatever support you need.
-
Any chance of a FRED build that won't yell at me for using armor?
-
Originally posted by WMCoolmon
Well, if I rewrite the turret code, it'll be more neatly coded but probably behave differently and break backwards compatibility.
Although I'm not 100% sure that'd fix it. :blah:
The problem is that some turrets acquire targets just fine; others simply don't. I set up a debugger display to show me what all the turrets on a given ship were doing, on two Deimos Corvettes attacking a Hathepsut, none of the turrets were firing.
That being said, maybe it's something related to the big only flag or enemy mask...
i think i fixed the turret problems. check the aiturret.cpp diffs
http://fs2source.warpcore.org/cgi-bin/cvsweb/cvsweb.cgi/fs2_open/code/ai/aiturret.cpp
-
I'll test it when I get the chance.
-
Please try it out soon. The beam bug is literally the only thing making me use 3.65 instead of your recent builds, and being able to have proper missile lock-on recticle support at 2048 would be a great boon
-
I don't think the beam bug is related to the turret code, WMC. I noticed it when playing Derelict before all your stuff got committed.
It happened on several missions, but the most noticeable was one of the last few missions when you're guarding the GTVX Gorgon Cannon. It fires in 3.6.5, but it stops firing in later builds. I'm guessing the bug was added very soon after 3.6.5 was released.
-
Would it be possible to determine which is the first released build that carries this bug? If yes, we could at least check CVS changes around the date of bug's introduction and see if it is possible to find out its exact causes.
-
Originally posted by Goober5000
It happened on several missions, but the most noticeable was one of the last few missions when you're guarding the GTVX Gorgon Cannon. It fires in 3.6.5, but it stops firing in later builds. I'm guessing the bug was added very soon after 3.6.5 was released.
Ah... so I'm not crazy after-all.
-
I can hardly test TBP with any build... Most of the newer builds just crash.
Looks like I have to get back to build testing. ;)
Perhaps we even need another code freeze until the bug is fixed...
-
Originally posted by Goober5000
It happened on several missions, but the most noticeable was one of the last few missions when you're guarding the GTVX Gorgon Cannon. It fires in 3.6.5, but it stops firing in later builds. I'm guessing the bug was added very soon after 3.6.5 was released.
I traced through the fire-beam sexp in the gorgon cannon mission. It gets to beam_ok_to_fire() in beam_fire() then bails since the cruiser is outside of the fov of the turret. then again, when i check the turret fov, it says 0.
-
...
Okay, so why is it different? Is this the same thing as Bobboau's fire-through-hull fix? That better not have been added back in again...
If the turret fov is 0, though, that's rather odd. Can you checkout the CVS from 3.6.5 and step through that code?
-
could it be that there's a problem with the subsystem copying methods? the thing with beam_fire() also is that its completely independent of the AI system, hence why you can have two beams fire at once out of different turrets.
-
Originally posted by Goober5000
...
Okay, so why is it different? Is this the same thing as Bobboau's fire-through-hull fix? That better not have been added back in again...
If the turret fov is 0, though, that's rather odd. Can you checkout the CVS from 3.6.5 and step through that code?
actually the true fov is cos-1(0)=90, so that fits.
results
365
=============================
- aim_dir {...}
- xyz {...}
x -0.00291909
y -0.0317455
z -0.999492
+ a1d 0x0012b85c
- turret_dir {...}
- xyz {...}
x 0.00158776
y 0.286144
z -0.958185
+ a1d 0x0012b880
vm_vec_dotprod(aim_dir, turret_dir) = .94
.94 > 0 so beam fires
current codebase
===================
- aim_dir {...}
- xyz {...}
x -0.0110746
y -0.0243270
z -0.999643
+ a1d 0x0012b86c
- turret_dir {...}
- xyz {...}
x -0.0441259
y 0.957293
z 0.285733
+ a1d 0x0012b890
vm_vec_dotprod(&aim_dir, &turret_dir) -0.308430
-.3 < 0 so beam doesn't fire.
turret_dir is waaaay off. The only thing that modifies it in beam_ok_to_fire() is beam_get_global_turret_gun_info(), which calls ship_get_global_turret_gun_info(), which then calls:
ship_model_start()
model_find_world_point()
model_find_world_dir()
vm_vec_normalized_dir()
ship_model_stop()
if any of those have been modified since then, thats probably your culprit. of those i can easily rule out vm_vec_normalize_dir() since thats far more wide reaching. model_find_world_point()/dir() also seem to be unlikely to cause this.
i also did some CVS checkouts by date, March 1st was ok. April 1st wasn't
edit5: hey i think i found it
http://fs2source.warpcore.org/cgi-bin/cvsweb/cvsweb.cgi/fs2_open/code/model/modelread.cpp.diff?r1=2.58&r2=2.59&f=h
probably explains why turret_dir in the old code had the y&z components swapped and negated
edit6: yea that worked. thats too much work for a 2 line bug :blah:
-
Good Job
-
****.
Guess that's what I get for not booting that out when I noticed it got added in by accident. My apologies. :blah:
-
Hey, excellent work, Phreak. :) Thanks. :)
Well, WMC... at least your prediction was accurate. It's two months later. :p
What do you guys think of releasing 3.6.6 at the beginning of June?
-
You spoke to soon.
-
Originally posted by Trivial Psychic
Any new developpments on this? Getting a fully OGG-supportive build that works with TBP is crucial to testing for said team. This one works with all oggs, but the crashing prevents its effective use.
Fixed. Not sure how I missed that one during testing, likely found it but it got over-looked in the original commit. When using OGG files si->data should be NULL so the Assert() was just in the wrong place. I'll commit the fix later today.
-
Originally posted by taylor
Fixed. Not sure how I missed that one during testing, likely found it but it got over-looked in the original commit. When using OGG files si->data should be NULL so the Assert() was just in the wrong place. I'll commit the fix later today.
:dizzy: :dizzy: :dizzy:
:wakka:
Thanks man! While I'm thanking Taylor, I might as well thank Goober for the list of recently fixed bugs on Mantis, including the dock jumping with the Chronos, and the string variables with arguments. And of course, thanks to PhReAk for the turret AI fix, and WMC for... welll, coding... and, well, just... THANKS TO ALL YOU CODERS FOR DOING WHAT YOU DO, FOR ALL OF US!!!
Next thing we need is a new build to make use of these fixes, hint, hint. ;7
-
Yeah. I just got about 10 mails from Mantis with resolved bugs so cheers Goober :D
-
You're welcome. :)