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

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)

Federation Damage Textures.zip [349.36 KiB]
Downloaded 476 times

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'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 .