dev/user/beta tester moddability

wow...

just wow...

I'll go out on a limb and say 70-80% for sure...

really....is that all....c'mon....make it more than that

100% would be like making SC into FEAR...

You won't be able to modify the core of the game (I haven't looked around in te files) but you will be able to change almost all visuals, such as planets, planet size, ships, stars, ect.

I don't think you can modify the way phase lanes are built, or how AI reacts.

but for sure you can modify the ship limit.... *crosses fingers*

You can modify any aspect of ships, including weapons, armor, speed, turn, attack behanviour, cost, time to build, command points needed, ect.

You can easily look around in the files, which you'll want to do.

The ModMeter says 22.534%, rounded off.

Seriously, there's not really a way to measure it. You can do a lot, more than enough for a basic mod now, and you will (from what I've seen/heard) be able to do pretty much everything needed for a mod (as opposed to a whole new game using the engine) once the Forge Tools are out.



Interesting question. If I remember correctly, the ship count was locked in some sort of hex variable that could be messed around with. Not certain about that though.

In another popular thread here, it was pointed out that the max count is easily modded in the gameplayconstants file. Full instructions are included but it's really nothing more than opening it with notepad.exe and changing 2000 to 10000000 or whatever crazy number you want

Ah! Thanks, I guess I remembered it as a little more complex than it really is.

As what was said the core of the game itself isnt modable, and a few things are hardcoded like the gravity well properties (you cant have more than 1 planet/object in a single gravity well), but mostly everything else is changeable.

The best way to find out is to look at the files themselves. Open em up in wordpad, and explore them. Many of the entrys are pretty self explanatory. The only exception to this now is the model files. We will have to wait until the mod tools, or a 3rd party model viewer/editor (which is in work in another thread) is available to edit those.

final release will be different, im holding out for multple planets in a grav well.

dont hold your breath.

as schod said, its already been said there wont be more then 1planets per grav well

what about for beta 4 allowing you to set the phaselanes back from any star to any star to certain stars to certain stars?

You can do this already if you like.

thank you very much guys....youve helped....i cant wait till it comes out feb. 1st....yes its really feb 1st

howwwwwwwwwww

Keep in mind, I have not tested anything out in SOASE. I've looked through the files before, but I don't know how SOASE defines collision boxes (telling units what to avoid)


Method One (Use this method if SOASE render collision on shape of each individual object)
I'm not sure (and don't count on this being true) but you could easily make a model like this.
--
O o

O = big, center planet.
o = 'orbiting planet'
--
I don't know if SOASE supports planets having it's own animation (for example: The moon spinning), since SOASE rotates the planets with a variable.

The good thing about the game engine turning the planets, is it turns the ENTIRE model. That means, that the moon is orbited also, in a way that's very realistic to the way the earth's moon resolves around the earth (one side is always facing the earth; always).
The plus side: I THINK SOASE renders clicks based on the objects shape, so clicking the moon MIGHT have the same effect as clicking on the planet.

The bad side: It might be the opposite; SOASE might draw a 'clicking' box around all the objects in the model file, normally used for easier clicking on smaller objects. This would make it very fun selecting units that are between the moon and the planet.

The bad side: I'm not sure how SOASE targets planets. Perhaps it attacks the center of the model file (center in the model editing program) and when the bullet hits a object belonging to the model, it explodes (which would be easier on the engine, since planets vary in shape and size). Or, it might pick the center of all the objects (aka: If you have the planet and moon far apart, it will pick the center to 'attack'), which would look very stupid.


-------------------------------------------
Method Two (use this if first method doesn't work, obviously)
In SOASE b3, there are sometimes asteroids around the planet.

The astoids themselves are either many, individual asteroids strewn around randomly, or are part of a single file.

If it's individual asteroids, than you can probably modify how many asteroids, rotation speed, ect for each one.

If it's a single file, than this just made it alot easier.



Switch the asteroid file with a 'planet' file. The planet won't rotate, and I don't think it will have collision (since it would be stupid to do so, waste of resources since they're outside of the gravity well) and might 'glitch' with interspace lines. (lines going through the moon, making a bad effect)

Some games use a collision box, or sphere in a separate file with collision data, a duplicate of the model itself as the collision mesh, or the visible model itself as the collidable object.

Homeworld 1 uses a separate data file (the MEX file) for collision, hardpoint, navlight, and other data.

Homeworld 2 uses the duplicate model method for collisions. That is in the mesh file as a separate group. This method by the way is VERY expensive poly count wise, because you have literally doubled the poly count your "visible" model. That method is basically 2 identical models in 1 file (more if you count the lod mesh's). This explains why HW2 can get so damn laggy even on todays high end machines. For every model visible on the map there is an invisible "clone" of that model. A 5000 triangle model really means its 10,000 triangles.

In some games the visible model itself is treated as the collideable object. Like in Starfleet Command, Bridge Commander, and Nexus. IMO this is the most effective, and efficient method.

I haven't seen how a Sins mesh is built so i cant answer how collisions are done here. I can only speculate. In Sins it does seem that all the collision data is in the mesh file, and that the model itself is the collidable object. Looking at the ship movement behavior supports this theory. Ships bump each other around literally by contact. Where as in games with a collision box like Homeworld 1 there would be a "gap" or an area slightly larger than the model where the object being bumped into would react long before the ships actually touched each other.

I know that ramble doesnt really answer your question, but it may help you figure things out until the dev's are allowed to give out factual info.

Well, as far as I can tell, the collision is done on the ships shield model first, which is in another .mesh file. Once the shield is done, it uses the ship model itself to do per triangle collision.

are build times moddable

yes

wahooo....lol.....build 300 kol battleships in like 3 seconds...lol...i'd win easy...thoguh it would work for them too huh.

play that against multi's fleet

sure...lol....their all scout frigats anyway...lol