[james777]

What's the latest Inferno Build?

[Fury]

http://www.hard-light.net/forums/index.php?topic=66982.0

[FreeSpaceFreak]

The latest stable Inferno build can be found here. The really latest, possibly buggy, cutting-edge Inferno build is in the latest thread in the Nightly Builds or Test Builds forum.

[james777]

The latest stable Inferno build can be found here. The really latest, possibly buggy, cutting-edge Inferno build is in the latest thread in the Nightly Builds or Test Builds forum.

thanks

[Thaeris]

...Off topic, but... 

When is it planned to finally merge Inferno with the main FSO codebase?

[chief1983]

Hopefully soon, no one really has a compelling argument against it currently.

[Kolgena]

What are even the differences between the two currently? I've just heard how you don't want to run missions designed for one on the other, and that inferno's really good at handling large numbers of ships.

[Mongoose]

The original Inferno builds upped the total ships limit significantly from retail FS2, but they had the unfortunate side-effect of completely breaking multiplayer; they also required their own pilot files in a separate location from the standard FS2 ones in order to avoid incompatibilities.  That main issue of multiplayer usage was resolved relatively recently, so like chief1983 said, there's no real practical reason why they can't be used as the standard for builds from here on out.

[Dragon]

I have just one question, would that be possible to up the ship and weapon limit on Inferno builds even more?
For example to some insane number (like 1 000 000 ships and weapons), so no one will have to worry about the limit.
I'm asking, because the right now, the only way to change ship's model is to use "change-ship-class" SEXP, which is a good way to do it, but adding several features requiring this eats ship table slots like crazy. For example, if you would like to introduce ships that use both 4-staged cloaking (WCS seem to have invented this) and ships that change stats in atmosphere (my idea, ships should handle differently in atmosphere), you will have to use 8 variants of each ship that's both atmospheric capable and cloak capable. This is a problem especially if there's an entire faction that for some reason need to have both capabilities on their sitrikecraft and, in some cases, warships.
There are many functions that can be implemented using a "change-ship-class" SEXP and some creative FREDing, but they ussualy can't get implemented on a larger scale due to a ship limit. This also applies to weapons, though to a lesser extent (I'm currently planning to have two wariants of most of them, one for atmo and one for space).
Setting the limits to one million would be a practical equivalent of removing them.

[FUBAR-BDHR]

Short answer is yes.  Correct answer is no. It would cause major issues so I don't see it happening anytime soon.  There are a bunch of other limits that will cause issues if the limits are increased. 

From reading I think the idea is to eventually make those limits dynamic so ships and weapons can be dynamic at some point.  A lot of other things need to be done first so I wouldn't hold your breath.

[The E]

In principle, it would be preferable to have no table limits at all, but I guess that would take a more extensive rewrite of several pieces of severely cthulic code as far as I can tell. Not saying that it can't or won't be done, but it's something that probably won't be done for .11 (or .12).

[Dragon]

That's why I proposed increasing it to enormous value, something similar has been done before, so of all ways of achieving the effect I'd like to get, this one is most likely to happen (in comparision of course, any changes to this seem unlikely to be done for 3.6.11).

[chief1983]

Certain limits affect other limits, so until they can all be dynamified, and the packet code modified to work with dynamically allocated objects like that, it's not going to happen.  Which is why FUBAR answered as he did.

[Goober5000]

Not only that, but you need to balance other considerations such as memory and execution.  Let's say (to pick a number out of the air) a single ship class takes a kilobyte of memory.  Setting the ships.tbl limit to a million would mean that you would need one gigabyte of memory (nearly all of which would sit unused) just to handle ships.tbl.  FSO would be effectively unusable.

Furthermore, like chief1983 said, a lot of limits affect other limits.  That's a special case of the general rule of thumb that everything in FSO has a knock-on effect to everything else.  Coders need to be extremely careful that their changes to one part of the code don't break another part of the code.  We're still cleaning out bugs that irresponsible coders introduced through carelessness back in 2004 and 2005.  (And we've surely added new bugs with all of the changes since 3.6.10.)