Hard Light Productions Forums
Hosted Projects - Non-FreeSpace => StarShatter Open Source Project => Topic started by: The E on June 02, 2012, 02:56:32 pm
-
A short list of things and features that I consider to be worth working on. I'll categorize them based in my personal and completely biased estimation of how hard or desirable they are. Please add your own suggestions, but please be aware that at this moment, the only people working on this are me and Echelon9, so don't expect the same sort of turnaround we manage in FSO.
Short term goals:
1. Convert the List and Text utility classes to their STL equivalents (std::string and std::vector/std::list respectively).
2. Make the mission editor more powerful. It already has an event manager, and I think that it may be worthwhile to add more commands there.
3. Sort of related to 2, investigate options to include a scripting language. If at all possible, I want to use a preexisting scripting language like Lua or Python.
4. Create an OpenGL renderer. This is my personal pet project. It's either that, or learning how to DirectX, and I am not too keen on doing that.
5. Use Collada dae as a native model format in addition to the proprietary .mag format used now.
Long term goal:
Make Starshatter cross-platform. I am really going to need help on this, as my POSIX fu is rather weak.
-
...Please add your own suggestions...
Fix the bugs in Starshatter vanilla, of course. :)
Good luck to you guys.
-
Well, yes. Would help if someone could put those on the Google code bugtracker.
-
Will switching to OpenGL fix the z-buffer issues? When I converted the Solaris it wasn't so much z-fighting but rather z-thunderdome grudge match.
-
Depends in what is causing it. Personally, I believe that's caused by Starshatter's stencil shadows, but I am not sure at this point. My main reason for wanting to do an ogl renderer is that I am much more familiar with it.
-
Should this be fused with the "Roadmap" topic, seeing as this is basically the same thread with a different title, or vice-versa?
-
naw
-
Not really, because I want the actual roadmap to be in the very first post, not buried somewhere down on page 1 or 2.
-
One thing that I just noticed is that under the graphics options menu there is an option to increase the max texture size to 4096x4096. I honestly don't recall if that option was there in the stock game or if it has been added by the source code team. The problem though is that if I select that option it causes the game to crash. I was hoping that this could possibly be fixed. The reason is that I've been experimenting with seeing how huge a starship the game can render nicely. If you make a starship that gets much over 25km in length, the textures start to look bad with a shimering kind of shadowy effect. The larger you can make the texture file though, the better it looks. So far I haven't been able to use anything over 2048x2048 so I"m thinking if the larger texture size were permitted without crashing, it might make HUGE starships more feasible.
-
Please locate the file called errlog.txt (should be in your starshatter folder), and post it here.
-
Can't get anything larger than 2048² ? First guess is that you're stuck on an intelgrated or equivalently sucky card.
-
I recall that the 4096 x 4096 max texture size was always there. I'm certain I've also heard that the largest textures used by the game were 2048 x 2048 as well - thus, the higher texture size is an unused development in the retail game for all I can tell. Being unused, it may also thus not have needed to be stable.
Is it possible, Brad, that your settings files have manually been set to read-only? This would override changes made in the GUI settings menu if memory serves me well.
-
Can't get anything larger than 2048² ? First guess is that you're stuck on an intelgrated or equivalently sucky card.
That is very possible due to the fact that I am not at home and am using my laptop which does have a lower end integrated video card. I will have to try it out on my gaming computer at home. Thanks!!
-
I have tried without success to replicate the crash from before. It may have been caused by something else besides setting the texture limit. At this point it looks like on my computer the game is resetting itself to 2048x2048 as soon as I leave the options screen. The video.cfg file has 4096 listed as the max texture, but in game if I go back into options it is set at the lower setting. It could be simply due to the limitations of my laptop. I will be home tomorrow so I can try it on my much better equipped gaming system.
-
If you'd just tell us your computer specs, that would settle the problem.
-
In addition, please post the errlog.txt file.
-
In addition, please post the errlog.txt file.
Its kind of long, but here it is.
[attachment deleted by a ninja]
-
If you'd just tell us your computer specs, that would settle the problem.
Didn't know you wanted them. All you had to do was ask.
[attachment deleted by ninja]
-
Hum. Do I fail at reading SS logs or do they not list the GPU used ? That's something that should be added IMHO.
EDIT: And yeah, I am not good with hardware but from what I quickly googled it doesn't seem that ATI Radeon Xpress can render above 2048² stuff.
EDIT2: Irrelevant to the issue at hand, but ogad, SS uses pcx D:
-
The R300 chip (which this is based on) certainly can't. At least based on the fact that the R420 (which my old X1250 was based on) couldn't.
-
So, uh, where would I put in a request for a feature (or removal thereof)?
It might just be the fact that I haven't been able to get the effects mod installed correctly yet, but the sunglare lens flare was just hideously jarring in the first cutscene for the training campaign.
-
You can turn off the sun glare under video options. For the mod, just enable it under mod config.
-
I have a code request...
Can we prevent a command from registering/executing if the binding for the command has been removed?
The example I have for this is the "self-distruct" command. By default, it's very close to the virtual cockpit binding, and uses virtually the same sequence (it's shift+esc, or cntrl+esc by default - it's been a while and I do not quite remember which). Thus, in combat, you may not be looking at the ketboard and accidentally trigger this function. If the binding has been removed (and none is thus present), Starshatter seems to revert to the default key commands for a function. I think... this is something that should be looked into.
This particular function, even if it is re-mapped to a different keystroke, is also still a danger to the player if he/she does not want to use it. As such, preventing keystrokes from functioning via their default mapping, should all mapping for the stroke be removed, is a good change for all I can tell.
-
That's a rather serious bug.
I would ask you to enter it in the google code bugtracker. Please. Before I have to institute a "bugs not on the tracker do not exist" policy.
Or use the "Reporting bugs in SSO" thread. Spreading bug reports over so many threads does not make my job easier.
-
Aaannd done.
http://code.google.com/p/starshatter-open/issues/detail?id=16
-
Thank you , Thaeris. Encountered this by accident last night. Kind of a rude surprise.
-
The temporary fix is to re-bind it as a keystroke you're very unlikely to hit - I think I tested that to good effect, somewhere on the other side of my keyboard.
-
I have a request concerning flak. Right now if you use the vanilla flak on a weapon it's a fps nightmare. I made a pretty good flak weapon using the sub munition and animation codes but they only work on guided missiles. This causes a lot of countermeasure spamming from the ai and the player is assaulted with incoming missile warnings and each flak shot shows up on radar/hud. Not to mention that flak isn't supposed to follow you around.
Would it be possible to allow sub munitions on unguided weapons? I was thinking this would be the easiest fix. The alternative would be to change the way explosions are dealt with which sounds like a much bigger job.
-
I have a request concerning flak. Right now if you use the vanilla flak on a weapon it's a fps nightmare. I made a pretty good flak weapon using the sub munition and animation codes but they only work on guided missiles. This causes a lot of countermeasure spamming from the ai and the player is assaulted with incoming missile warnings and each flak shot shows up on radar/hud. Not to mention that flak isn't supposed to follow you around.
Would it be possible to allow sub munitions on unguided weapons? I was thinking this would be the easiest fix. The alternative would be to change the way explosions are dealt with which sounds like a much bigger job.
Lag comes from the particles made for the explosion, too many flak and you have hundreds of particles lagging the game. I made explosions use only a few particles and lag went away.
You can make the submunition missile be dumbfire (rocket) so it doesnt trigger counter measures, but making sub munitions be used on normal shots would be better indeed.
-
My thoughts on things to do with the code:
1- Support to use animated sprites for explosions and such like in FS2, particles have many drawbacks in terms of lag. Importing FS2 FX would be awesome.
2- Fix CRASH when 7 or more of ships on your side declare "engaging" at the same time.
3- Sub munitions for normal bolt weapons, and "flak = true" working with it.
4- Holding mouse left click selects multiple fighters at once in Flight Screen (carrier).
5- Implement a "loop" navpoint type with optional "random waypoint", so patrols keep patrolling instead of RTB so early and making more interesting group movements. (player missions should not use them or it can last forever)
6- Code for dynamic campaign strategy AI and movement is really basic, could use more love and complexity. "war production" concept in docs is hardly used in game.
7- Starship groups could move more "in group" instead of rushing individually to their glory or death. (maybe use some tweaked fighter AI formation code?)
8- AI use of quantum jumps to flee would be nice. (quantum jumps in ships def. files would need some tweaking after that)
9- more choices of speed above 1000 m/s in waypoint editing. Fighters really can go faster than that.
10- AI could use EMCOM levels on their own. It is a nice "seek & hide" mechanic not really being used except by the player (witch should be labelled as cheating IMHO)
11- Engineering screen. I still cant get a clue on how much power is used/produced and delivered to ships systems. We need a more clear picture of what is going on with our ships power so we can make it more useful/challenging.
12- Enemy AI declared as threat, keeps like that even if you are out of his sensors range or it is not engaging you, keeping you from finishing the mission without jumping to other sector or landing.
2,7,12 could be labelled as "critical" I would say. The game badly needs those 3 fixed.
-
I tried to make them dumbfire but the sub munition never triggers. You wouldn't happen to know which explosion is used for the flak would you? Is it SHOT_BLAST?
Edit: I think that's a solid list, I'm particularly fond of #1.
-
I tried to make them dumbfire but the sub munition never triggers. You wouldn't happen to know which explosion is used for the flak would you? Is it SHOT_BLAST?
Now you got me. I dont remember how I did it for the dumbfire.
As for explosions, it is Shot_blast. Take care because shot_blast is used in Flak and missile hits. You need an explosion that fits in those 2 roles.
As example this is what I use in explosions def.
explosion: {
type: SHOT_BLAST,
lifetime: 2, //4
// light_level: 500, //2.5
// light_decay: 0.8 , //0.8
// light_color: (255,255,255),
num_parts: 8,//12
particles: "Flak5.jpg" , //"flak4.pcx",
part_speed: 18, //70
part_trail: false,
// part_drag: 40
part_rate: 2.5, //2.5
part_decay: 170, //130
part_scale: 0.1, //0.8
part_bloom: 0.6,//6
sound: "Blast-87-03.wav",
sound_min_dist: 5e3,
sound_max_dist: 20e3
}
(http://FLAK5.jpg)
[attachment deleted by a ninja]
-
Even with those changes to shot blast the flak is still slowing everything to a crawl. Here's my sub munition solution. Maybe you could take a look and see what I need to do to make them dumbfire.
WEAPON
missile: {
name: "flakturret"
group: "FLAK"
target_type: 0x000f00ff
value: 2
ammo: 1000
recharge_rate: 10
refire_delay: 25
salvo_delay: 2
charge: 1
min_charge: 1
damage: 100
lethal_radius: 200
speed: 5e3
life: 10
self_aiming: true
aim_az_max: 1
aim_el_max: 1
min_range: 1e3
max_range: 15e3
max_track: 25e3
carry_mass: 0.54
carry_resist: 2
guided: 1
mass: 0.5
thrust: 3.3e3
drag: 2
roll_drag: 4
pitch_drag: 4
yaw_drag: 4
roll_rate: 1
pitch_rate: 4
yaw_rate: 4
det_range: 5e2
det_count: 10
det_child: "Flakshot SUB"
det_spread: 100
graphic_type: 3, // blob
width: 3,
length: 20,
light: 20,
light_color: (255,255,0),
bitmap: "WeaponEffects/Shot4+.pcx",
flash: "WeaponEffects/Flash4+.pcx",
flash_scale: 3,
sound: "WeaponEffects/EXPLODE1.WAV",
sound_min_dist: 0,
sound_max_dist: 6e3
}
WEAPON
primary: {
name: "Flakshot SUB"
target_type: 0x000fffff,
value: 3,
lethal_radius: 1e3
charge: 1,
damage: 30,
speed: 3e2,
life: 1,
graphic_type: 2, // sprite
animation: "WeaponEffects/Exp20_0004.pcx",
animation: "WeaponEffects/Exp20_0006.pcx",
animation: "WeaponEffects/Exp20_0008.pcx",
animation: "WeaponEffects/Exp20_0010.pcx",
animation: "WeaponEffects/Exp20_0012.pcx",
animation: "WeaponEffects/Exp20_0014.pcx",
animation: "WeaponEffects/Exp20_0016.pcx",
animation: "WeaponEffects/Exp20_0018.pcx",
animation: "WeaponEffects/Exp20_0020.pcx",
animation: "WeaponEffects/Exp20_0022.pcx",
animation: "WeaponEffects/Exp20_0024.pcx",
animation: "WeaponEffects/Exp20_0026.pcx",
animation: "WeaponEffects/Exp20_0028.pcx",
animation: "WeaponEffects/Exp20_0030.pcx",
animation: "WeaponEffects/Exp20_0032.pcx",
animation: "WeaponEffects/Exp20_0034.pcx",
sound: "WeaponEffects/EXPLODE1.wav",
sound_min_dist: 2e3,
sound_max_dist: 20e3,
}
-
Start setting this:
roll_rate: 0
pitch_rate: 0
yaw_rate: 0
so missile has no means to change its direction.Try guided=0 if you didnt already (maybe you did and it didnt work). This wont fix the flare spam though, I remember I only tried this on turret mounted guns for starships.
As for lag I can have 10 guns firing flak at 2 shots per second and dont get lag, maybe its because of the video card.
-
2,7,12 could be labelled as "critical" I would say. The game badly needs those 3 fixed.
Two, seven and twelve have been reported on the Issue tracker
https://code.google.com/p/starshatter-open/issues/list
-
How does the "Escort" command work? I'll order other members of a battle group to escort me in an effort to keep the group together, but if we're already scattered they rarely come closer. Many times I've had them match my speed and orientation - which means they still maintain the same distance from me, even if it's 150km.
I'm not sure if this is a bug or if I'm not using the order correctly. Either way, it makes it hard to coordinate assaults with other ships. I end up using the nav map to plot waypoints to a point somewhere along my vector en route to an unidentified target. It's a process I don't often estimate correctly . . .
-
How does the "Escort" command work? I'll order other members of a battle group to escort me in an effort to keep the group together, but if we're already scattered they rarely come closer. Many times I've had them match my speed and orientation - which means they still maintain the same distance from me, even if it's 150km.
I'm not sure if this is a bug or if I'm not using the order correctly. Either way, it makes it hard to coordinate assaults with other ships. I end up using the nav map to plot waypoints to a point somewhere along my vector en route to an unidentified target. It's a process I don't often estimate correctly . . .
What ship class did you give the escort order to? Each class (e.g. destroyers, frigates, etc.) may respond differently depending on the battlefield conditions. For example: if you order friendly destroyers to form up, and they are already within sensor range of the enemy, then chances are they will override your escort orders and attack the enemy ships instead. Frigates, on the other hand, will follow whatever commands you give them (in most instances).
One of the most frustrating things encountered during custom mission building is a phenomenon known as, wandering AI syndrome. In some instances, AI-controlled ships will simply refuse to follow designated waypoints and drift about aimlessly. Sometimes, resetting waypoints helps - but not always.
-
How does the "Escort" command work? I'll order other members of a battle group to escort me in an effort to keep the group together, but if we're already scattered they rarely come closer. Many times I've had them match my speed and orientation - which means they still maintain the same distance from me, even if it's 150km.
I'm not sure if this is a bug or if I'm not using the order correctly. Either way, it makes it hard to coordinate assaults with other ships. I end up using the nav map to plot waypoints to a point somewhere along my vector en route to an unidentified target. It's a process I don't often estimate correctly . . .
What ship class did you give the escort order to? Each class (e.g. destroyers, frigates, etc.) may respond differently depending on the battlefield conditions. For example: if you order friendly destroyers to form up, and they are already within sensor range of the enemy, then chances are they will override your escort orders and attack the enemy ships instead. Frigates, on the other hand, will follow whatever commands you give them (in most instances).
One of the most frustrating things encountered during custom mission building is a phenomenon known as, wandering AI syndrome. In some instances, AI-controlled ships will simply refuse to follow designated waypoints and drift about aimlessly. Sometimes, resetting waypoints helps - but not always.
Usually either cruisers or destroyers. I love it when there are enemy contacts because the ships will respond to an attack order. Usually my frustration comes from when I've finished off an enemy, the scope is clear, and I see flares of enemy ships outside of sensor range. By that time the group is scattered and I give the order to escort to bring them back as a group so I don't get slammed when I get in range of two Broadswords. I've tried sneaking into sensor range so I can give an order to engage, but usually I'm spotted and the enemy comes after me. Sometimes I can lead them into the ambush, sometimes I get caught and skewered.
I've also noticed when they'll ignore a "Move Patrol" order as well. The only way I can direct any kind of movement is by estimating a waypoint and cancelling their orders. (Speaking of which, there's minor typo in the text order - it says ". . . request mission" instead of ". . . resume mission" - is that even worth a bug report?)
I guess the bottom line is that ship orders need to be more clearly defined. Escort could mean "attack any enemy targeting this ship" or "attack any enemy directly attacking this ship." Here I've been using it more for "Form Up" or "Follow Me" - which might just need to be added to available orders, if possible. Either way, it'd be nice to at least know what the orders actually mean.
-
I haven't tested cruisers, but I do know that destroyers will override any orders if there is an enemy vessel within its attack radius. One workaround that wdboyd implemented was to change the class designation in the .def file to frigate.
It would be a good thing if we knew the parameters that define the various commands and ship classes. One example that comes to mind is the difference between a battleship and a dreadnought. From a modding perspective, it would be very helpful to have a comprehensive explanation that details the differences between the two classes.
-
Could there be a way to allow you to scale coronas in the system.def? Right now the corona stays the same scale if you're orbiting Mercury or if you're orbiting Neptune. It's just an aesthetics thing but I think it would give a sense of scale as the player hops around the system.
-
I'd like to be able to edit the length of the trails and/or turn them off entirely. I'd rather see thruster tails than red lines everywhere.
-
Have made another pass through the PVS-Studio reports in the Starshatter source code. Should help address a few corner case crashes.
-
Wonderful to see the work resumed.
I've held off releasing my massive project because of a simple problem - I gave the capital ship PDWs dispersion. However this means thtat they now usually miss fighters. As a result fighters tend to survive within sensor range of the capital ship (and it is impossible for the player to end mission without jumping out of the sector).
I need one of the following two features (either would be an acceptable solution):
1) Being able to assign proximity damage to capital ship cannons (so that they damage fighters even if they narrowly miss the fighters).
2) Allowing the player to end missions - even if there are enemy fighters within sensor range.
Any improvements to the collision avoidance AI or the AI's ability to engage in turn fights would also be quite valuable.
-
I'll take a look. Mostly for now I've been fixing obvious coding bugs and getting to know the gameplay mechanic a little better.
-
Light_gemini uploaded this to fsmods. I do not typically accept code submissions, because that would just turn into a mess.
So here is the file for further inspection.
It says in the title that it is new bugout code, here is the description:
Code files to make bugout toggleable in ships def files, along with amount of damage needed to trigger the jump. Vanilla game still works the same.
[attachment removed and sold on the black market]
-
can someone post the fighters fix to the starshatter-open svn?
-
Added the following to the Tactical Reference Display in order to reduce clutter:
Ships now have empire listed (new field)
Capital Ships and Fighters split (separate tabs)
Weapons and Armaments split (separate tabs)
Working on: Empire logo buttons will select only ships belonging to that empire. (toggle buttons)
-
https://code.google.com/p/starshatter-open/source/checkout
starshatter open svn don't seem to update from 2013.
i'm glad to you try to update starshatter open.
can you fix main screen ui?
it can't press upper/lower edge button correctly when you use fullscreen mode.
it seem to fix that "not sourse released" build.
http://www.freespacemods.net/download.php?view.838
-
I'll look into it. It is annoying. Three things I want to do with it.
1. OpenGL conversion (so it will work on Macs, tablets and what not)
2. a multiplayer database-driven game. JSON? SQL?
3. removing MAG and replacing it with straight OBJ/MTL files (MAG doesn't NRM, SPEC and OCC maps for some reason) and the 16K Poly limit is annoying.
My Unity3D build is gorgeous, but converting the real code from C++ to C# is a pain.... (can do 1, 2 and 3 easily)
-
Always happy to see interest -- unfortunately development of an active coding community around Starshatter source code has yet to occur. Possibly in part that the FS2Open-related devs also became quite busy with a period of rapid coding improvements to the FS2Open engine (2012/2013 were a good time!).
Perhaps in future there will be renewed interest in SS?
-
At least the game is not lost, i love those forums where some of my favourites games get a second chance =)
-
I finally figured out displaying turrets and guns in the Tactical Display. The ships looked somewhat naked without them.
-
1. Integrating Steamworks in to the code for future Steam release. Pain in the ^^&*&...
2. Continuing to work through bugs
3. Added more native resolutions (1920 x 1080) for example.
4. Adding Occlusion maps.
-
What dev environment are you guys using? e.g can we get it to compile in something like codelite on Windows first then move the project over to Linux once it's building?