The textures on the Romulans ships in the Fleetyard have been lightened to help with that dark look in the 3D engine. If you found a way around the dark ship issue I will plan to return the textures to normal.

All done for the first pass.

Textures i use are not the greatest but I'am no artist. Also there is still the problem of the texture over shotting the triangle edge but i can look to fix that later perhaps.

Here is a short vid.

http://www.youtube.com/watch?v=9ZPZREOUg9Q

Regards Wolfe

looks absolutely fantastic!

what again is the prob with the triangle?

As you can see the texture overuns the triangle on the shield mesh ever so slightly at the top left.

I may fiddle around with the number of polygons in the mesh to see what effect it has.

Regards Wolfe

Is there a way to wrap the texture around the shield? Models have the texture wrapped around them afterall. Perhaps you need to treat the shield itself like a model?

Looks nice. I also looks like that too dark to see issue is gone?

seems like it ken.

@other effect: totally negligible to me . Next: Hull explosions and wrecking ship meshes .

I mean if it's only visible that close, it's okay. about those hull and wrecking effects, are these possible in Irrlicht without having to create special meshes for it?
Edit: Seems like mesh deformation isn't part of Irrlicht: http://www.devmaster.net/engines/list.p ... d=28&sid=0 (scroll down, horde3d for example has it)

Some links on the topic: http://www.gamedev.net/community/forums ... _id=444597
http://www.beosil.com/publications.html with http://www.beosil.com/download/Meshless ... _SIG05.pdf and http://www.beosil.com/download/mdbosm_s2005.avi

Yes but there is a downside. The reason the problem is gone is i have turned off beam lighting nodes. It seems that graphics cards only account for 8 light nodes and begin to cull them when more the 8 are created.

As I used to attach light nodes to the end and beginning of each beam this quickly filled up and the 'Sun' light node was culled therefore everything went dark.

So we miss out on the nice effect of point lighting created by the beams for now, there is somewhat of a solution but it has not been implemented in Irrlicht.Net

Regards Wolfe

I don't know if they would be any use to you, Wolfe, but i've attached a zip file with the damage textures for the Starfleet ships and a Starbase from Starfleet Command 2. Even if you can't actually use them for the final models, at least you've got something to play whilst you get the hull damage code working. If you need more, let me know. SFC2 has individual damage textures for each of the ship classes for the 8 playable empires in the game (The United Federation of Planets, the Klingon Empire, the Romulan Star Empire, the Gorn Confederacy, the Hydran Kingdoms, the Lyrans, the Mirak Star League, and the Interstellar Concordion) plus the unplayable Orion Pirate Cartel. (Not the green skinned Orions, the Orion Pirate Cartel is supposed to have been a renegade part of Starfleet that broke away when the Federation formed)

In the new video I noticed a much smoother camera movement. The first video had a more abrupt movement which did not please the eye that well as the last one. Have you implemented a camera movement smoothing algorithm or was it just your hand?

Recording and running the demo at once can effect how the demo plays, therefore you should discount any jittering to that. I haven't made any changes but the first video was recorded with FRAPS the other with Camstudio so that might explain the differance.

Also the quality is less on Camstudio compared with FRAPS.

Regards Wolfe

I didn't mean jittering, it was more about the nice "rotation" effect of the camera when you select another ship. After you selected a ship and press right click and move the mouse to change the camera angle, that specific camera movement is not that smooth as the other movement. What I mean is, that mouse-induced and -controlled camera movement has no "time buffer" or "smooth response" or "mouse sensitivity" if you know what I mean. It would be nice if the camera repositions itself with some sort of small lag between my mouse movements and the rotation on-screen.

I see what you mean, the selection camera 'Pan' is more numerical and simply zooms in and rotates at a fixed rate with some dependance on elapsed time. While mouse camera moving simply looks at the direction the mouse is moving and integrates that into movement of the camera at a fixed speed aswell.

It is old code and needs to be looked into again some time.

Also on a side note I'am running out of ideas of what to add lol , please feel to pipe in any and all thoughts and suggestions you might want added to the engine.

Currently i was looking into doing some of the AI as it is CPU intensive and will give a heads up of what we can add and leave out later on so we don't kill the CPU/GPU everytime you run a combat demo .

From the 15th Dec to Jan 7th I may also not have access to a computer with the source files so won't be able to code however i can research and plan any ideas you guys might have, along with perhaps writing this paper i've been tasked with at Uni lol .

Regards Wolfe

I've got an interesting one: Rewriting it in C++

I think once we reach completion, it'd be the time to start porting it for bote.

Things I'd like to have in the engine (if they aren't already in it ):

• small stats at a right or left hand toggable menu sidebar (much like in botf, but not that big) with number of (still) participating ships versus number of destroyed ships. Maybe even mean hit efficiency but that's not that important.
• mouse wheel zooms in and out of the battlefield (I think that one is already implemented but I'd to fire the engine up to check that so I just write it in here in case it isn't)
• (if we want to implement that) Fleet morale status (affecting acceptance of orders in battle and sudden retreat without retreat order; maybe useful when fighting with minor race ships like the Ferengi as allied partners and while you are in control of their ships they can possibly start to deny orders and flee if odds are bad or many Ferengi (for example) ships have been lost during battle)
• small overview map toggable at one of the corners of the screen that shows complete simplified overview of the battle scene with all ships shown as colored dots on it, much like a radar or something like that. It should be possible to click on the oval overview radar and select a region where the camera automatically positions itself on (smooth movement as when selecting a ship). maybe even selecting a ship to center on via the radar.
• upper, lower, forward, left, right and backward shields as in differentiating shield power to certain areas on the ship's surface. Much like in Klingon Academy or I think also in BC and SFC. Did Armada have non-unified shields? It would make the z-induced homeworld style movement more effective since you could force a ship to turn its better-shielded side towards the enemy. AI decides about shield rechargement distribution and reallocation (has certain max flux speed) depending on where the most enemy firepower is concentrated on or an enemy firing at your ship is currently located.
• "ultimate" control over a single ship as in flight simulator like movement with + and - as increase and decrease speed, strg/right-mouse-click to fire torpedos, shift/left-mouse-click to fire phaser banks (you need a small togged menu where the weapon reload status is visible), tab to switch between targets, t to mark the nearest target in sight and the mouse as direct flight control stick (like a joystick; as in Strings' Defiant game). After you've given all initial orders to your fleet it would be the perfect immersion to just take over one single ship, let the AI do the rest and fight your way through the battle. And when your ship is destroyed you just take over the next one. Also while in this mode, you could send orders or help calls to your fleet to help you or protect your flank or concentrate fire on your target. Also, when you think a new set of general strategic orders is needed you can jump out of ship control mode and enter normal mode and do your job there. I think this specific feature would make the game really unique.
• Camera movement fixed on ship AND target so when you have the camera move with your ship, it should autorotate so the enemy ship=target always stays in focus

You'd probably scream if I told you all of the suggestions for further improvements that i've got so I think it would be better for your sanity if I didn't mention them. It would be more appropriate to put them in the old BOTF5 thread anyways, so you can imagine the sorts of things i'm talking about.

More along the lines of reality, a useable BOTF-style interface would definitely be the next thing to consider adding in my mind. You might want to speak to Mike about using the interface templates from Supremacy. You'll want to also make sure the interface is customisable so that it can be easily ported for BotE and to allow it to be moddable as well.

...



SFC had six shield arcs, but they were on the 2D rather than 3D plane. You had the front, front-port, front-starboard, aft, aft-port, and aft-starboard shields - there were no dorsal or ventral shields.



Ships in Armada had a single set of shields just like BOTF did. A hit from any direction caused damage to the entire shield - and if the shields are depleted then the entire hull was vulnerable until the shields recharged.

In SFC, if you had any spare energy you could transfer it into shield reinforcement, allowing them to take more punishment or recharge faster. Whilst I think this would be too complex for the combat system, a six or even eight-shield system would be a nice addition in my mind. Again this might still be too complex/realistic though.

I'd be for dorsal and ventral and leaving out the front- and aft- starboard and -port sides if we implement this. Sure an AI can somehow be written to take control of shield rechargement, maybe also an AI that tries to concentrate fire on shield parts that are less strong than other within angular reach, but when more than 100 ships are clashing in battle I presume we will get severe performance problems. It would just be something for really small-scale battles. In larger scale battles, I'd turn off that feature.

I mean we have the lamdba thus the point where the beam impacts so dividing up the ellipsoid into 6 areas should be easy. Visualizing weakening shields on one of those parts could also be possible somehow by turning off lighting of that part. Shield energy reallocation and deliberate weak shield area targeting could be more of a problem.

If it's too big a problem then don't go with it. I just mentioned it coz it was an idea related to the shields. SFC is a really complicated game (Which is why I love it), but that makes it the total opposite of BOTF in many respects. The control interface especially would be the biggest challenge. It's easier to just forget about it. Fleets with hundreds of ships are more important.

I'd keep it simple - at least for now if not permanently - single shields. No quadrants.
I'd also DOUBLE the hull value of all ships

Since you guys are so good at maths and algorithms, maybe one of you would like to help me by modifying the A* (a-star) pathfinding algorithm so that it supports multiple possible endpoints (and returns the shortest path to the nearest endpoint). If you could add support for multiple starting points, that would be even better, but I'm not sure how much more computationally intensive it would be.

Multiple end points? Why would you need one. You start, you end. What plans have you got in mind Mike? Matress is intrigued...

Multiple endpoints are important for reaching a certain territory in shortest time, for example if you're stranded then the ships should auto-move to the nearest home territory square or the AI when attacking should move from their territory to the nearest enemy system in their territory so multiple starting points are also needed to determine the gathering point of the AI's attacking fleet.

well it ain't that much killing performance, guys over here have done it too: http://search.cpan.org/src/TELS/Graph-E ... -star.html . They just added all starting points to the open nodes list and for the calculation of Length L they took all end points into account and then the one with the smallest number. For source code implementation I think downloading the source there and having a closer look will do the job.

Oh, I hadn't thought about that. I just assumed the game would cancel the existing waypoints and generate its' own one in such cases.

yes, exactly what it does (lets leave out waypoints for simplicity and look only at starting and end point). But you need to determine the starting and end point first. This is naturally done by the A* algorithm since it determines the shortest route from point A to point B. You could say now that if you know your point B already (like a specific enemy system the AI has as a target) you could call the algorithm as often as you have starting points on the galaxy map and take the shortest route as your common starting point (=gathering point) for all your attacking fleets. But instead of calling the algorithm a hundred times, you can just set all those squares in the open nodes list and let the algorithm calculate it at once. Gives a little more performance in the end.

In the case where you have a fixed starting point (like an AI fleet that wants to retreat to home territory in the fastest possible way) but lots of possible endpoints, you first determine all borderline sectors of your territory (because only those make sense as target system, i.e. the inner systems are already too far into your own territory) and let the algorithm check length to all those sectors at once and always pick out the nearest one in each step of the algorithm. Will lead you quickest to the nearest home system. Of course you could call the algorithm again for each possible end sector separately and calculate the shortest route and afterwards compare all route lengths and take the minimal one but it would cost performance.

Could you add funky "Parameters" into each path, for example you keep track of current enemy strength in each map cell / square + also perhaps past enemy ship numbers etc.

This way when you calculate mutliple paths you can have it so that it chooses a target which has the least or perhaps most chance of intersecting enemy ships.

Regards Wolfe

such parameters might disturb route planing a lot, for the AI as well as for the human player. Sometimes you just want to attack an enemy force on the way and your algorithm draws a way around the enemy force/fleet in the middle which you need to correct by setting specific waypoints then which is extra-work.

so there are cases where you want confrontation. The pathfinding algorithm should always find the shortest way regardless of enemy ship concentration (which can btw. vary from turn to turn at long distances). A better way to tell the AI to intersect fleets on the way would be one or two additional waypoints in interesting sectors (beware of course that fleets can move so don't make too many waypoints deferring from the target), i.e. separate path enemy fleet danger evaluation from pathfinding.

what always should be a parameter are anomalies where ship speed is reduced, set to zero or where black holes suck ships in. These black holes are static factors that neither move nor increase or decrease their strength (okay, minus better shields and stuff), so these can be evaluated. In such cases it won't be much annoying to manually change course through the anomaly if you wish so since the obstacle is a static definable one for the player and not a dynamic one like enemy fleet strength. You can have a look at the bote source code in CStarMap class and the CalcPath function there. We already have implemented anomaly-bound weights to the algorithm.

Pathfinding algorithms have many potential uses other than navigating terrain. In this case, I'm looking to use it for the AI in determining what to build based on lowest cost (shortest path). That's where multiple endpoints come in handy. If the AI determines it needs 150 energy to build a level-3 shipyard, there are a few paths it could take--build wind turbines and upgrade to advanced turbines, build fusion plants, etc. Each is a different endpoint. Cost would be calculated based on production time, potential reallocation of labor, etc.

The question in this case is if the shortest path is also always the smartest path. In case where the AI decides to build additional fusion plants as shortest path it will mean costly reallocation of workers and when the next energy hungry building is calling, you might need to upgrade the plants to get the needed energy but then this would mean also to upgrade these now unnecessary additional plants which a human player would normally scrap or never have built in the first place and instead have upgraded those in the first place although it would have cost a little more back then.

I don't know how SirP circumvented this problem but I think it'd be worth a look since the BotE building algorithm ain't that bad .

Like I said, the cost would be computed based on a number of factors, and reallocating labor from a higher priority production category (like Research or Industry) would result in a significantly higher cost, particularly because that reallocation will continue to affect your colony's production levels for a while. But if there are no "free energy" structures available, no non-critical structures that can be disabled, and the AI thinks it really, really needs some destroyers ASAP, then it might choose a path with labor reallocation. Regardless, that path does need to be considered, which is why the pathfinding algorithm with multiple endpoints is perfect for the job .

While generating a path, the AI might also determine that the local population will exceed the available food production, so it may need to inject a farm into the build path between the energy structures and the shipyard. Thus, each node in the path will need to include a snapshot of the colony's current (projected) stats so that the proper "next" nodes can be generated.

cost calculation will actually be the most tricky part. it would depend on how fast (in number of turns) you want a given projected state. say we there would be only one path that achieves a certain goal in 3 turns. Several other less expensive paths would lead to the same result but take 1 more turn (say for example the case where upgrading takes slightly more time than building 2 new energy structures). Of course each path comes with its needed turns in his stats, but setting sensible rules for when to dismiss a path according to its time consumption and then to actually compare differences in path costs in relation to the time difference could be non-trivial .