thelegendaryblah

im currently polishing the program (refactoring some junk codes and working more on the look of the interfaces) as well as setting up my web server for download/autoupdate settings i will probably do some work on my patcher later in the afternoon. should be done by tonight and it will be released tonight (or maybe midnight next morning) as an open beta period for a week in this section of the forum (addon development), if everything is running ok and no serious bugs are found, then i will release it offically over at the tools and applications section. man i am feeling lucky, havent ran into any roadblocks and a lot of code from my old program (omni tool 1.0 source) are migrating very well into OMNI 2.0. only problem i had to deal with was my algorithm involving sorting out "poorly foldered" mods, but that was solved easily when i went "screw it" and just rewritten that whole part from scratch EDIT: i will probably do it on a future release, right now i just want to concentrate on getting my predefined set of goals completed

right now, nasa could track space junks with sizes down to 1 cm with its telescopes and space junks with sizes down to 10 cm with its lidar/radar, are you seriously suggesting that when lasers became practical as weapons, we would not have sensors better than what nasa have right now? anyway, i was under the assumption that the combat must be space-to-space or at least under long distances in vacuum because lasers really only shine when there's a vast distance to cover. the best modern lasers we have are about an order of magnitude less powerful that the balistics weapons we have of the same scale with huge energy consumption issues, but of course this will definitely change when capacitors became better and better and maybe even phase out batteries

working on a new control type that should be better than the plain old listview or treeview the one on the left (i hope) is clearly better/more intuitive this is all work in progress so everything is probably subject to change/modification i currently am thinking of implementing a way to allow mods posted in the forums to be downloaded as well (since the spaceport is currently such as mess), but that will have to be sorted out and probably wont be a feature for my initial release, i could probably implement auto update for mods downloaded from the forums as well, by checking the author's thread for any updates, we will see man it is very hard to aviod feature creep, on your first release, lets hope my program come out alright

i see, so you are suggesting an actual system for space combat (at least as far as lasers are concerned), but i still dont see how one could hit the enemy's emitters reliably the thing is, the enemy is trying to hit your whole ship whilst you are trying to hit a very small fraction of their ship, as stated from my previous post, the margin of error for one's aim increases as the engagement range increases due to light's travel time. since this thread is about countering, this would mean that the enemy would most certainly engage in such a range that the margin of error is good enough for a beam to reliably hit an enemy ship, but not precise parts of an enemy ship. i agree with you for the first part, indeed there is no stealth in space because ships are hot and space is not, a simple IR lidar or something similar would detect anyting in a very long range. however, this is precisely why i do not agree with the second part. i would suggest that because space is so un-stealthy, all ships will always be shown on lidar anyway, in other words, all ships are always being targeted by any other ship anyway. the act of being painted by a targeting/detecting system would not warrent anything to do with an incoming attack. this is actually very practical because the multiple emitters could share the same capacitor bank for power (you suggested pulsed lasers so i assume its capacitor powered/fed) as explained on my second point, the onboard computer probably wont know its being targeted until it's being hit, regardless, rolling after being first hit is still a good idea anyway as stated before, i dont see any reason why one could reliably hit any of the enemy emitters reliably when an emitter is so much smaller than an entire ship indeed, i agree with you completely on this, but i still feel that the limiting factor is engagement range, i feel that lag due to light's travel time is still the big limiting factor over here you are correct, the emitters are indeed the weak link, but remember that you only cant armor the lenses when you are firing, when you are not, you could hide your emitters behind shutters we should probably keep in mind that we are dealing with varying wavelengths over here, unless your lasers have a similar wavelength as the opponent's lasers, the enemy's lense will not amplify your own laser, the lense might even act as a mirror for your laser at worst also, if you are familiar with a laser cutter, then you will known that it works by reflecting the laser beam of one-large-stationary emitter off of a series of moving mirrors to hit a specific location. if the opponent's laser is something similar to modern-day laser cutters, then this combined with what i said above regarding wavelengths means that even if you magically hit one of the enemy's "emitter", it would probably just break a mirror that could be easily replaced all being said, your system does have some advantages over my suggestion of some sort of smoke grenade, for example, your system allows for retaliation whilst my "mirror powder smoke grenade" means my own counterattack would be as ineffective as the enemy's attack (unless my smoke grenade allows a certain wavelength through). i just dont see the point in setting up such as complex system like what you suggested, i feel it would be more practical to just roll and shoot back with your own large-arse laser if you wanted to retaliate maybe some variaty of a moving armor would work well? maybe a series of "shields" strapped to rails on your spacecraft that could move itself? this would be easier than rolling your whole spacecraft depending on the (armor:ship mass ratio)

why even bother with feasability when it isnt even practical to start with? jupiter has a lot of "fuel", but it also have a **** ton of radiation (not to mention jupiter's bad weather), which would require rediculus amounts of radiation shielding for both the station itself as well as ships going to the station, this made it very impractical to atempt to colonise any gas giants, perhaps an underground base on one of jupiter's moons would be more practical i think if humanity were to colonise any significantly large part of the solar system, it would be the astroid belts as there are plenty amounts of water (in the form of ice) for breathing, fuel, hydroponic farms and drinking. the astroid belt does have its own problem like solar radiation/solar storms, but we could always hollow out astroids and build bases in them for shielding. the only "unsolvable" problem with living in the astroid belts would be electricity problems and that could still be solved with nuclear reactors. by the way, there are also iron rich astroids, so they could be used to build stuff (not as good as titanium or aluminium, but still)

don't you think it it would be way too hard to implement such a system and way too easy to counter it? to implement such a system, you would have to first have lasers that could fire way faster (loading time I mean, not fire rate), then you need to put those lasers atop a turret that could aim really quickly (quicker than the opponent's laser to fire, then you need to put those turrets all round your ship to cover every blind spot, and even then, you would still need sensors powerful and quick enough to check all possible angle for an attack and then relay commands for your turrets to shoot before the enemy even fired, isn't this kinda hard and expensive? and to counter it, the opponent simply has to put a shutter on their laser emitter, and open the shutter just before they fire so that your sensors won't be able to pick it up And let's not forget that we are in space, it's a long distance and the engagement range would be at least a few light second, so that means your quickest possible time to response would be: detection time+ distance * 2 (your laser has travel time too) and mentioning light delay issues, if the enemy is moving around, you won't even be able to hit the place you aimed for precisely, The enemy's laser emitter would simply be too small a target to possible hit due to physical restrains of the laser's travel time (light speed does not mean instant hit in space)

they are using monomethyl hydrazine and dinitrogentetrioxide for its fuel maybe they should use udmh/n2o4 instead, uudmh is slightly more stable than its monomethyl brethren and many major world powers with space faring capabilities used UDMH/N2O4 at first (the russians and the chinese, the americans do not count since they started off with alchohol in the V2 which they stole when they took von braun)

the problem with all the heatsink posts is that a laser is very focused (high energy:surface area ratio), unless your spacecraft is made out of super conductive materials, the point being focused on will be destroyed first because the heat builtup at the place being hit cannot distribute the heat quickly enough. hence, any "passive" (armour) defenses would be mediocre at best and should be left as backup and the problem with the mirror posts is that lasers have varying wavelengths, hence we need a different type of mirror for any different type of laser, since you could only cover one part of your ship with one type of mirror, this made mirror armour unviable i propose an active system for defense in the fom of a "smoke" grenade loaded onto a small missile/canister. the smoke canister would be filled with a variaty of small particles of "mirror dust" (for different wavelengths) for refracting the focused beam into a much less focused beam, some of the beam would be absorbed by the mirror particles and some of the beam that came out would then proceed to completely miss the spacecraft whilst some of them would be spread out to hit the whole spacecraft's outer shell to distribute the heat evenly the smoke canister would be released around the spacecraft when it is going into battle(or expecting an attack) the following picture describes what i mean black denotes the ship blue denotes the smoke particle released by the smoke grenade/missile red is the laser

nice, i always loved to hate java (man how much i hate JVM!), took 3 java classes in college and stoppped right there (they were called CS1A, CS1B and CS1C in my college). i never got over the performance issues before java implemented JIT for your question, i have to break it down into 2 parts to explain it i take it you mean the .bat file that is supposed to be ran. OMNI cannot handle anything fancy like that, nor could it handle other similar things such as the KSP multiplayer server (the client is fine though), i just dont see any way in implementing things like that into the program. maybe it is something i could work on in the (probably distant) future if a mod overwrites any existing file, the existing file is backed up, the mod loading stack does the mod loading dynamically. if a mod that is supposed to overwrite a file was removed, the "overwritten" file would be returned from its backup location, this works for multiple mods as well (for example, a lot of mods uses the toolbars plugin .dll for its GUI) EDIT: it is worth noting that unfortunately this method of mod loading takes up more space than just doing it by hand since it would be inevitable for duplicate files to show up, but i guess no one really cares nowadays about storage anyway

people will also probably appreciate it if they could know more about you, maybe you could tell us more about yourself, like what skills/skillsets you have for making mods (programming experience, 3d modelling experience, texturing, stuff like that) people tend to like to follow competent people, so show them you are competent so that they will follow you. however, if you have absolutely no experience in modding, then perhaps you should try make a few simple mods by yourself first to gain some experience/skill (to be honest, if you do not have much experience with unity or at least c#, then it really is best to just request/suggest your idea to other modders) try think of it this way, why would the other modders need you on their team? you need to provide a reason for other modders to want you on their team, or else, why should they even care about you?

that is a good idea, i will implement that as an option that is enabled by default on a side note: the spaceport is currently down, development had to stop for now, i hope it get back online soon, i also heard news of a spaceport 2.0 that is coming soon, that kinda makes me sad since i would have to redo all the interfaces for the HTML code

hello keio, im glad you are interested, here are my answer to your questions in part: there is a setting for updates to either disable updates completely, notify the user and ask for permission to update, or just update automatically for the "too many tabs problem, i think i will problably add a ~12 character limit to the tab texts, by the way, the whole thing is resizable so it shouldnt be too much of a problem. and yes there is a page of installed mods for quickly accessing them so you could quickly re-open them from there, but there is no "recently closed tabs" like the ones in firefox or opera yes basically there is a WeBrowser control in the background, this works for getting all the mod names, informations and whatnot, but unfortunately, the big red download button on a kerbal spaceport page is a css button, hence, i ID the HtmlElement of the button in the page and then invoke("submit") it, then catch a WebBrowser.Natvigating event with a handler and get the uri from the EventArgs, that uri would be the download link. i use .net to write this program, so there's WebClient.DownloadFileAsync which is relatively easy to implement if you are familiar with any of the visual languages(visual c++, c#, vb.net)

thanks for the response everyone, 80% of the program is actually already finished (turns out HTML and CSS phrasing isnt that hard after all), now im mostly working on old code refactoring/optimising (this was a derilict project i left behind a year ago before the forum migration) and managing errors for certain exceptions (interfacing your program with a website is no child's play!), to clarify, i feel this is more of a tool instead of a mod, but i guess its close...

it works with other mods downloaded from else where as well and yes there are options to disable/enable any feature

update: some friends desided to suddenly have a surprise visit, that means no coding for me until the weekend, i am sorry but i will have to push back the release date for a few days update 2: friends have finally went away, i have resumed coding KSP Omni Tool 2.0[Currently in development] ETA: 25th March for initial release KSP Omni Tool is a tool for managing, installing and auto-updating mods, it is basically like app store for KSP the biggest feature of OMNI is it's seamless integration of Kerbal Spaceport, this allowed several features: - Automatic mod updating - Easy installation of Kerbal Spaceport mods - app store-like experience when browsing for mods with OMNI of course the tool also supports other mods downloaded from elsewhere as well as already installed mods OMNI essentially could do most things (if not every!) other mod managers could do but more! (if you haven't guessed yet, automatic mod update is my big selling point) some eye candy: for full rez image see here when you browse to a mod, this is what you get it couldnt get simpler, just click on install and you are done! (and have i mentioned? the mod auto updates!) Features -works with any version of KSP -easy one click install for both the mod manager itself and mods -simple and easy to use mod management features (add, remove, rearrange, rename and so on) -works with most zip archive formats (including: zip, rar, 7z, tar.gz, anything) -auto detects preinstalled mods and adds them to the mod manager -auto updates mods installed from kerbal spaceport -auto updates the OMNI client -seamless integration of kerbal spaceport, what you can find from kerbal spaceport, you could find here -intuitive experience when browsing mods -mods could be queued for download and install -OMNI utilises multithreading, hence it should be much quicker when downloading and installing mods -and many more small features around the place Technical Things Omni: -development began on the 13th of March 2014 -is written in VB.NET, hence it requires the .Net framework 4.0 -handles the mod browsing and mod installation in an OOP manner -deals with file compression/decompression by implementing 7zip, hence it should be faster and more efficient that most other mod managers out there -is multithreaded, the program itself should run faster than anything out there here's a time lapse at 50000% speed of me coding, the video is condensed from 26 hours of pure coding time to 2 something minutes Some dev notes -03/22/2014: found a minor memory leak problem when opening new tabs, turns out my IDisposable implementation wasnt spot on, it was swiftly fixed and i will check my memory levels in the future to prevent the same from happening FINALLY: this program is still a work in progress! everything here is subjected to change, there are no downloads over here yet, check out the ETA at the top of the page