Fleet Operations 3.2.4
Announcements and news by us. Post comments about them here.
posted on June 1st, 2011, 7:37 pm
That wont change, the new place for maps to be saved is intentional
posted on June 1st, 2011, 7:50 pm
Last edited by 086gf on June 1st, 2011, 8:01 pm, edited 1 time in total.
I already know that but could there be a way for me to have maps saved to the main bzn folder? A workaround maybe? An option for us to decide while installing? Something for all of us that already solved this ourselves.
posted on June 1st, 2011, 8:03 pm
if you are required to have maps in your fleet operations programs folder (e.g. when creating a mod) then just move these maps from appdata to the programs directory. Saving files to the programs folder is something that ms recommends not to do since xp or even win2000.
i see your point, i thought about this, too. but i think it has it's advantages to keep custom maps separate from the programs dir. especially if you patch, uninstall or whatnot you do to your fleet operations installation, your custom created maps won't be touched. currently a option to define the saving location to the program files directory is not planned. again, just keep all your custom maps in the user directory, they are 'saver' there anyway, if you create maps for a mod, move them over when you want to release it, then these will be the 'official' maps, just like it is with the fleetops maps in the bzn folder now.
i see your point, i thought about this, too. but i think it has it's advantages to keep custom maps separate from the programs dir. especially if you patch, uninstall or whatnot you do to your fleet operations installation, your custom created maps won't be touched. currently a option to define the saving location to the program files directory is not planned. again, just keep all your custom maps in the user directory, they are 'saver' there anyway, if you create maps for a mod, move them over when you want to release it, then these will be the 'official' maps, just like it is with the fleetops maps in the bzn folder now.
posted on June 1st, 2011, 8:05 pm
if u want your maps all in the program files location then just write a batch file that moves all files from %appdata%blahblahbzn to the bzn folder in the installation directory. then run it any time you download a map.
that way you dont need to worry about moving the files manually. and uac obviously wont be a problem since you have it turned off.
that way you dont need to worry about moving the files manually. and uac obviously wont be a problem since you have it turned off.
posted on June 1st, 2011, 8:12 pm
Personally, I'm still hoping for a single player campaign, whether original, or a port of the old Armada and/or Armada 2 campaigns. Although i don't know how one would account for A1 not needing to colonize planets to take advantage of them while A2 does.
posted on June 1st, 2011, 10:34 pm
CaptJosh wrote:Personally, I'm still hoping for a single player campaign, whether original, or a port of the old Armada and/or Armada 2 campaigns. Although i don't know how one would account for A1 not needing to colonize planets to take advantage of them while A2 does.
they recently integrated megadroid into the team, and he was working on a mod for that sort of thing.
a fleetops campaign that isnt a port of a1/a2 would not involve colonisation i presume. ports would probably change some things. as if u wanted the original campaign you could just play stock
so presumably a port would be similar but not identical. so maybe the crew/colonisation idea would be absent there too.
posted on June 2nd, 2011, 6:40 am
Hi,
nice work - but still wait on an "mod friendly bug free" 3.2.5
Devs have done an good job to bring easy modding of FO real here ....
But have left little bugs.
(modding of dynamic_localized_strings.h WAS prommised in Star Trek Armada II: Fleet Operations - More about extended mod support ! And the dont loading of AI AIPs make it ATM not 100% usable .. but an BIG step in the right direction ! )
But i see many new "mods" popping around that make only few usage of the advantages of this system !
Mods who take only a couple of files as fpq - see realy no "musst doing so" in the packing of this.Make it harder to integrate few lines of an minnimod in self maked/mixed mods - musst first unpack.
(i can see the relevance by an mod of hundreds or more files to distribute as fpq .....)
Mods who take no or only a couple of files with the new "#include" command and overwrite so the most of his files simply - and make the chance bigger to missmatch with new FO versions.....
(and make it again harder to implement in mixed mods or use it in an updated version of FO with other mods parallel)
Regards
R-TEAM
nice work - but still wait on an "mod friendly bug free" 3.2.5
Devs have done an good job to bring easy modding of FO real here ....
But have left little bugs.
(modding of dynamic_localized_strings.h WAS prommised in Star Trek Armada II: Fleet Operations - More about extended mod support ! And the dont loading of AI AIPs make it ATM not 100% usable .. but an BIG step in the right direction ! )
But i see many new "mods" popping around that make only few usage of the advantages of this system !
Mods who take only a couple of files as fpq - see realy no "musst doing so" in the packing of this.Make it harder to integrate few lines of an minnimod in self maked/mixed mods - musst first unpack.
(i can see the relevance by an mod of hundreds or more files to distribute as fpq .....)
Mods who take no or only a couple of files with the new "#include" command and overwrite so the most of his files simply - and make the chance bigger to missmatch with new FO versions.....
(and make it again harder to implement in mixed mods or use it in an updated version of FO with other mods parallel)
Regards
R-TEAM
posted on June 2nd, 2011, 9:16 am
yes, you are right. the fpq files are not a must for mods. they are purely optional and only have advantages if used on big projects.
also, i could have been wrong about the include command in dynamic_localized_strings.h when i wrote this text. despite the #include command is definitively supported by this file, due to the 'special' layout it uses (one translations 'variable') it may be currently impossible to make advantage of it
also, i could have been wrong about the include command in dynamic_localized_strings.h when i wrote this text. despite the #include command is definitively supported by this file, due to the 'special' layout it uses (one translations 'variable') it may be currently impossible to make advantage of it
posted on June 2nd, 2011, 10:24 am
as a friendly side node: you dont have to use FPQ to use a mod module
posted on June 2nd, 2011, 10:27 am
Hi,
Thanks for the answer
This is sad that the usage of #include in dynamic_localized_strings.h is ATM not possible ...
Most mods add things/modify things and so need an new or modifyed Tooltype ... without the usage of this file with the new system - it is only half way ready.
But i think this will be sortet in not so distant future
btw. it is only by me or have the game become more power hungry ? (or less optimized ? ) It stucks even with a couple of ships by scrolling and very more by cloaked units visible (my units ).
Have this before only in later games with heavy explosions visible and many units around ...
Regards
R-TEAM
Thanks for the answer
This is sad that the usage of #include in dynamic_localized_strings.h is ATM not possible ...
Most mods add things/modify things and so need an new or modifyed Tooltype ... without the usage of this file with the new system - it is only half way ready.
But i think this will be sortet in not so distant future
btw. it is only by me or have the game become more power hungry ? (or less optimized ? ) It stucks even with a couple of ships by scrolling and very more by cloaked units visible (my units ).
Have this before only in later games with heavy explosions visible and many units around ...
Regards
R-TEAM
posted on June 2nd, 2011, 11:24 am
Hm, performance in 3.2.4 should be the same as in the past versions, nothing special has been added
posted on June 2nd, 2011, 3:37 pm
Last edited by CaptJosh on June 2nd, 2011, 3:57 pm, edited 1 time in total.
Myles wrote:they recently integrated megadroid into the team, and he was working on a mod for that sort of thing.
a fleetops campaign that isnt a port of a1/a2 would not involve colonisation i presume. ports would probably change some things. as if u wanted the original campaign you could just play stock
so presumably a port would be similar but not identical. so maybe the crew/colonisation idea would be absent there too.
First of all, as I mentioned, a port of the Armada 1 campaign wouldn't use colonization. You didn't have to. You just placed a starbase within a certain radius of a planet and it provided greatly improved crew generation (crew and officers would have to replace tritanium and supplies, as A1 only had dilithium, crew, and officers as resources). Now since FO is built on an A2 core, making colonizable planets shouldn't be too hard for an A2 port to work. Then again, I could probably just drop the A2 stuff in as a mod and it would just work, save that I would really love to have updated graphics for at least planets and moons.
EDIT: Whoops, so I can't just use A2 as a mod. It crashes.
Now an original Fleet Ops campaign could be VERY interesting. Given what the future Admiral Janeway did to the Borg at the end of Voyager, one might even include some Borg faction infighting. I don't know though. It would be up to the Fleet Ops team.
posted on June 2nd, 2011, 4:19 pm
You really need to read the apocrypha section of the guide. Janeway is still in the Delta Quadrant and nothing has happened to the Borg like that.
posted on June 2nd, 2011, 4:21 pm
What guide?
posted on June 2nd, 2011, 4:35 pm
Who is online
Users browsing this forum: No registered users and 24 guests