Important Message

You are browsing the archived Lancers Reactor forums. You cannot register or login.
The content may be outdated and links may not be functional.


To get the latest in Freelancer news, mods, modding and downloads, go to
The-Starport

Apologies... Shield issue is NOT fixed.

The general place to discuss MOD''ing Freelancer!

Post Sat Sep 17, 2005 7:30 pm

Apologies... Shield issue is NOT fixed.

My bad, folks. That was my gosh-darn custom SUR for the Liberty Cruiser. It works most of the time with missiles. Heck, it works most of the time, period.

But hey, I've discovered something halfway useful from all of this:

1. Not declaring a specific death_fuse is not a good idea. Dunno why fighters don't have severe problems, but with the larger ships, this is a serious problem. I'm fixing every fighter in the game to use death_comm until I have a better idea. I have a feeling that this is because a Fuse can call for a Damage_Group to behave in various ways. The Li_Cruiser, which has a custom SUR that I'll get around to making a little bit more perfect before releasing the next version of the Toolkit ... doesn't have any Damage_Groups except for Root. Silly me, I didn't pay attention to this, and was wondering why the ship cause CTD upon death over and over again. Problem solved.

2. Something is darn well calling out ship collision mesh names, whether or not the INIs are. Having done an exhaustive search, I am pretty darn certain that these names are in the SURs. Hence Anton's getting rid of the Damage Groups via FLModel Tool ... also gets rid of these bugaroos. So... if I want to eliminate Simple and Collision_Group entries (which I do, because these are a big part of the problems with Shields and Big Things)... I have to make all SURs behave in standard ways. Now that I have a better idea what I'm dealing with, I'm pretty sure I can deal with this issue.

Basically... my end goal here is to eliminate Simples. While Simples are cool in that they allow various sub-groups of a model to be progressively destroyed, they're very un-cool in that they make a ship a collection of hitboxes, which is one of the reasons why Missiles and other things with area effects have been so problematic. Gonna fix that stuff for good now. Next version of Toolkit will have FL capships that behave themselves, react to missiles correctly, and generally act like they should, I hope. I'll fake the break-off parts with Shatter, I hope... at least I *think* that will work. If not, I'll have to seek another solution so that people will still get to see bitz splattering about when ships die.

Post Sat Sep 17, 2005 7:47 pm

Aha...

Comm_Death still works even after SURs are "consolidated", but I no longer get errors from Spew indicating that FL is still looking for Collision Groups. Heh! So I get my cake and eat it too, it appears, so long as I don't give a hoot about being able to shoot off people's sub-parts. Ships still shatter just fine...

I don't really care about blowing things off- it was never a very useful part of the gameplay, and that feature of FL has ended up being more abusive than not in MP, given that a clever player can/will "burn off" parts of their ships and reduce their target profile and greatly reduce their vulnerability to Missiles in exchange for Hardpoints anyhow. Cool. Now I've just gotta run FLModel Tool on every single SUR that will behave itself. Unfortunately, that doesn't include everybody, because certain SURs do not resize appropriately, because they were assembled in very large sections and don't scale correctly

Post Sat Sep 17, 2005 8:29 pm

Sounds interesting.

Post Sat Sep 17, 2005 9:53 pm

<shrugs> it's just some random blather while I'm getting some of the deeper core things sorted. Toolkit 1.3 is getting nearer and nearer to "done"- I've begun fixing all of the docking issues for Big Things, have sorted out my final strategy for Missiles, and am debating with myself about re-doing the balance formulae so that people who want to build things that are fully game-balanced and in tune with the Toolkit's concepts can have a little more flexibility in their approach.

The major issue is how Shields should work... I'm still thinking this over. I don't want ships that can carry multiple Shields to be able to mix the types of Shield. This is very easily solved from an execution point of view, by setting up three Levels to correspond with the types and then limiting the Hardpoints to certain Levels depending on type. But I may want to make things even messier, so that there are more specific things that game designers could do within a balanced schema that would allow them to, say, make a dedicated military Fighter with Flicker Shields, high recharge, decent manueverabilty, OK armor and no Cargo to speak of, a Freighter with 4 Heavy Shields and very little in the way of Armor, just enough Energy to keep Shields recharging during combat, and plenty of Cargo, etc., etc., etc. The current balancing formulas work just fine so long as one doesn't want to do certain things- basically every improvement to base stats is reflected in detriments elsewhere. I'm thinking that I can expand on this, and let game designers try out a system where they can trade manueverability for other traits, and put Power on the table as a variable that can be "bought" with lower turn-rates and acceleration curves. It'd be nice if I could get the balancing system to neatly balance out for large warships, although the changes to Docking are probably going to make that issue moot anyhow.

Not that this matters, per se, to anybody but me. But if I'm going to change something like that, I like to think it through very completely before executing it, since I'll have to document it and explain why I've changed things around again, when the current system approximates DA's original balance concepts very nicely and works just fine for anything lighter than Gunships.

Now that I have a final idea as to how things with Big Turrets should work, I'm going to take another long look at the place of big ships within a game-balanced FL world, and see how I can make them work, both for SP and MP. 1.1's balance for the capships included was very ad-hoc, so I'm hoping to get things tightened down, now that I'm not quite as busy with basic implementation chores, like writing custom ShipDealers (and their THNs) for every single Base in the game.

Currently, I'm thinking that they're going to get major changes to their gameplay, so that they don't really resemble what they are in stock FL, and have a much more distinct role, so that there's a real point, in clan battles, in having mixed forces. Gotta get the SUR issues completely sorted out first though, so that players can deal with them properly.

Post Mon Sep 19, 2005 4:44 am

maybe completely rubbish - but anyhow:
if it's possible to link the mounted shield to the lock/unlock of jump holes it would be possible to offer a ReReRe-Freighter-shield (RemoteRoughRegion). You must unmount it before you can come back from borderworlds into the House Companies territory.

Such a special shield could enhance game play for freighters in addition to more dynamic commodities. It's highly risky to get to the lowest-price-highest-profit-bases. But it is even more risky to travel from the last accessible Borderworld base back to Bretonia/Rheinland/Kusari - without that special shield

Just an idea

Post Mon Sep 19, 2005 11:02 am

K, the collision boxes and parts of ship. Each part of the ship is named in the cmp file and has a coressponding section in the sur file. This i suspect is what calls out the names and causes spew if you kill the subgroups with ModelTool... A tool is in planning to rename sections in surs on Louva's request from some time ago for the SDK. If i get a sane method working i'll post it.

+++ out of cheese error - redo from start +++

Post Mon Sep 19, 2005 11:40 am

@Anton:

That wouldn't much change things, insofar as what I'm doing is concerned. I'm trying to eliminate this factor from the SURs, because it's what's screwing up a lot of the new game balance I'm trying to achieve anyhow. What I really need, honestly, is a working SUR exporter that's not quite as persnickety and allows me to use a named, contiguous mesh for the shield SUR... so that I don't have to worry about huge radii in the resulting spheres, like I do now.

FLModel Tool is letting me fix most of the problems- the only areas that are of real concern ATM are SURs that contain multiple centerpoints, and do not resize properly, just like their CMP brethren- those I'm rebuilding the hard way.

@Zazie:

That's an interesting idea, but if you've never played the Toolkit Mod... um, I'd play it first. Just trust me on this- Freighters, while perfectly able to hold their own in combat, aren't exactly risk-free in the "hinterlands" of the FL universe. The improved AI and rebalanced ships make manueverability a big factor, and a freighter captain who treats their ship like a tank is likely to get in big trouble, fast Freighters in combat should be used like they were in Vanilla- which is to say that you need to take full advantage of Engine Kill if you're going to live.

The changes that I am contemplating for the rebalancing formulae will, if anything, heighten this balance. Players who want a Freighter capable of combat will either have to use Heavy Shields and hope that the combat is over before their Shield goes down, or use Normal Shields and hope that they don't get munched by enemies with a better damage curve. About the only really good option for Freighter pilots who want to get in fights with players will be as "missile boats", with heavy Shieldbusters, where the larger ammo capacity will let them have a pretty good chance in 1 v. 1 duals. The current balance actually works pretty well for Freighters, and they're already forced to accept that they simply aren't manueverable enough for any dogfighting. Again, if you haven't played 1.2, then a lot of this isn't going to make much sense...

Post Mon Sep 19, 2005 2:30 pm

I like destructible subparts - i think you're throwing the baby out with the bath water if you're going to eliminate every simple and collision group

Post Mon Sep 19, 2005 2:46 pm

<shrugs>

Modded ships don't have them, and nobody complains. And nobody will complain if Capships have properly working Shields, either- and this is the only way to go about this, since we don't have a SUR export utility that will export a set of named Groups yet, let alone a method of ensuring that it works properly with the CMP Exporter 0.3's ability to export Subgroups. As it is, I'm going to have to make custom SURs for every Capship and Gunship in the game, which is going to be a royal pain in the rear, lemme tell you.

I'm going to be the first to say that this solution isn't perfect, but I don't see any real alternatives. People want shielded Capships, because RepairDroids don't seem to work no matter what we do with them, which means that the only way that Capships would ever be able to really act like Capships was by raising their hitpoints and Nanos to absurd amounts- the amount of damage/sec a ship at the high end can pour out is staggering.

If RepairDroids worked, then I could go that route, but that's not an option. I don't have any other ways around this issue that I can think of at the moment, and I want this solved for the next version of Toolkit, because it makes introducing real parity between modded ships and FL ships a going proposition. This version of Toolkit, which I really think will be the last, is pushing the frontiers of what FL can do in a very large number of areas. Believe me on this- it's really pushing into a lot've ground that nobody else has even looked at much yet. I'm not sure it's going to make everybody 100% happy, but I dunno what else to tell ya- I had to make some choices here, and given the stark limitations I have to work around, I think people will be pretty happy with the results.

Post Mon Sep 19, 2005 3:56 pm

well there you are, nobody complains so its not worth doing actually there should be a way to do subgroups with welded surs by just creating a fuse that blows off one wing & then the other,or weapon hardpoints in the case of ships without wings.it just seems a great injustice to DA's hard work at making ships that take _real_ damage to go and remove it all for the sake of uniformity. optimistically, we'll have both vwire and sur export some day and modders who don't make model subgroups will be looked at as lazy =)

i don't understand why everyone wants capship shields, they're always much less effective than the armor underneath

Post Mon Sep 19, 2005 7:55 pm

The part about shields vs. armor isn't true, at least in stock FL. Shields take half the damage armor does. And that's part of why it's a big deal.

While I do agree that:

A. Someday it may be possible to build ships with full Simple entries.
B. It's quite possible to build a modular ship with things the way they are now, except that it may have some issues with modules blowing off and leaving Weapons intact (long story there, don't feel like explaining it in detail, but basically what you're talking about could be done).

I don't think it's all that desireable. Why?

1. The methods by which damage is transferred from Subgroup to the Root of FL game objects are why the stock missiles, which had fairly realistic blast radii were so unbalanced. In Toolkit 1.2, I fixed this issue, but now that I've gone through things again, I feel that I made Missiles completely worthless except at the high end.

2. Because of the way the Subgroups and the SURs interact, area-effect weapons would not effect Shielded targets above the radius size, whether or not the SUR had a functioning Shield SUR included (which is yet another issue).

3. As I've alluded to previously... the Subgroups in the CMP determine which bits and pieces are left behind after an explosion... not the SUR Subgroups, which apparantly are mainly there for hit-detection. IOW, you can have one without the other.

So... basically the only thing that's missing is having the ability to blow off specific areas of a model with detrimental effects to the ship's functionality as a game object. OK, so that's cool, but is it worth all of the disadvantages? My answer is no. Especially since we cannot replace the Subgroups and make things work with large-scale detailed objects.

IOW, I'd be fine with your POV on this if I had fully-compatible SUR and sub-object support. But I don't. In fact, I have to deal with building custom SURs, which is a royal pain, if you want them to work 100%. Or I could try for sub-modular ship design, which would increase my dev times by quite a bit with few other advantages. Or I could just standardize everything so that it all matches up for once, and have stock FL ships that still break up into pretty chunks when dead, and look fine when dying, but otherwise don't have the same functionality.

As I've said earlier, it's all about hard choices. I believe that since I'm already pushing into all sorts of other new areas for a FL mod, I might as well hit this one too. If people don't like it... they can undo the changes fairly easily. But I have a feeling that people will very quickly get used to the changes, and when I'm done with the Fuses, they'll look about as good as the originals, I suspect.

Post Mon Sep 19, 2005 8:16 pm

One thing I haven't noted for the record: I have not tested this yet, but will get to it tomorrow... I am going to see if we can have [Simples without [Collision_Groups. That'd make it possible to rebuild various Fuses, give each Capship more interesting death animations, and basically clean things up to some degree, and fake a great deal of FL's interesting bits. In short, I'll see if I can make most of the "cake" available to people if I can. The different Damage Objects, btw, have their own SURs, so this can, at least theoretically, result in some interesting things happening. More when I have tested things in code and proven/disproven the concepts- for now, the "slate" is cleaned up so that I can rework things again.

And please believe me when I say that I am not terribly happy having to cut things this thin. I know that what I'm working on will probably get used as a development kit for future mods, so I don't want to take things away that are valuable if possible- I am always in favor of choices that increase designers' freedoms.

But while "we might be able to do X in the future" may be true, I have to deal with what we can do now, and what I've learned about the deeper issues of FL's engine. It has an amazing number of things that you can do with it, but it also has some pretty severe limitations, and some of the features are actually pretty problematic, like the LODs, which have turned out to be more detrimental to total performance than helpful. Now that I've turned them off or tuned them to work much better, FPS is a lot less of an issue than previously, because there aren't so many load/unload operations going on all the time that require HD access (sadly, for whatever reasons FL doesn't make use of all available RAM to swap game objects, even if you tell it to pre-load CMPs).

Post Tue Sep 20, 2005 1:41 am

of course I played the Toolkit - I was giving you some feedback for tweaking the sharting ship
My idea was never to be capable for combat with a freighter.

The changes that I am contemplating for the rebalancing formulae will, if anything, heighten this balance. Players who want a Freighter capable of combat will either have to use Heavy Shields and hope that the combat is over before their Shield goes down,

That was it. But it would be a new concept if some special equipment is only usable in certain zones (though I do not know if it can be done).

FL has the problem that in MP trading is rarely an option. If freighters can be equipped with First-Class-Equipment and if the price for commodities are more attractive (than actually) in some remote areas then a freighter run could attract one or more players in MP.
Additional challenge: this special shield must be unmounted before the gates/holes back from Borderworlds open again.

Post Tue Sep 20, 2005 2:00 am

Well, sure you could have weapons/shields/whatever that locked you out've certain areas. You could have Factions scan for certain equipment... and if you had it, they'd demand that you dropped it, just like any other items they scan for. So far as I am aware, any Good can be scanned for. So if you armed Jumpgates with powerful weapons and had them scan for "uber-shield no. 31" or something, then sure, they could deny you access to certain areas... by blowing you up

That's ... more-or-less... why I started working on the Toolkit in the first place. The objective has been to gradually get things really refined so that modders can jump right in and start adding fun features like that immediately, instead of reinventing the wheel to make things like Power Upgrades, or code all of the FL ships into their mods for the thousandth time. And that's why, when I've thought it was appropriate, I've just left all of FL's stock gameplay alone. Missiles are a very special case, which unfortunately has led me to other parts of the core FL design.

There are a few other areas like that that I've been exploring for the next version, and they've all involved making some choices about what I'm going to do with fundamentals. This whole situation with Capship Shields and Missiles in general has been really irritating, because it's an area where DA really didn't do a very good job, and left some fundamental inconsistancies in their design which are very difficult to address without annoying somebody. But I'll feel like a dork if I don't put properly-balanced missiles into the game design- I've fixed so many other balance issues that it'd be a shame not to take this area on and get things resolved.

Edited by - Argh on 9/20/2005 3:01:36 AM

Return to Freelancer General Editing Forum