Ship turrets & energy

Post by **Kaks** » Wed Oct 07, 2009 7:22 pm

By the way, the reason NPC's don't have shields: there's a lot more NPC's as players, and figuring out which side of the ship has been hit can be quite slow (and wrong. until recently we had a bug that in some circumstances caused the player's front shields to be shot from the back - and viceversa - without actually touching the shields that should have been hit by the enemy's laser.

It's a lot faster to just check if a laser hits an NPC without having to calculate both laser's direction and the exact way the NPC is facing. As we (well, mostly Ahruman) make Oolite faster, we might just be able to fit in the extra calculations. As Commander says, the extra energy in NPC ships is there to protect them just as having a front and rear shields would.

JensAyton · Post by **JensAyton** » Wed Oct 07, 2009 8:00 pm

Kaks wrote:
By the way, the reason NPC's don't have shields: there's a lot more NPC's as players, and figuring out which side of the ship has been hit can be quite slow

I’m sorry, but you just pulled that out of your bum.

An additional dot product and less than per laser hit (post collision detection) would be a truly negligible cost. While I can’t read Giles’s mind, I assume the reason Oolite does it that way is that Elite did it that way, and Elite did it that way a) because they had to trim handfuls of instructions wherever they could, and b) because the game was biased in favour of the player.

Post by **Kaks** » Wed Oct 07, 2009 8:11 pm

I painfully sit corrected, sir!
On the plus side, it's a very good thing that I haven't touched that part of the code, otherwise I would have probably made it really, really slow...

Screet · Post by **Screet** » Sat Oct 10, 2009 7:40 pm

Back to the topic:

I've just modified my own version not only to drain energy with each turret shot, but also to include a "turret on/off" switch. I still have to figure out wether there's additional things required to make the key customizable...

As that did work, I also did make the players MASC switchable

When I understand the opinions on this thread, it's not liked everywhere that turrets do use energy,but several people are interested in an on/off switch, is this correct?

If so...should I continue to test this and then tell some dev the modifications required for the switch, or should those who want to have the switch modify their private build files accordingly?

Screet

CptnEcho · Post by **CptnEcho** » Tue Oct 13, 2009 2:59 am

Screet wrote:
If so...should I continue to test this and then tell some dev the modifications required for the switch, or should those who want to have the switch modify their private build files accordingly?

Screet

Both?

wildstar · Post by **wildstar** » Fri Dec 04, 2009 3:53 am

i think having options is always a good thing.

we live in a world where we get to choose with caffeine or decaffeinated with sugar or with substitute sweetener etc etc

i found it really strange that the game never had (unless i am totally ignorant and blind) options to set game difficulty settings npc ai's to passive normal aggressive or vicious & game difficulty easy normal hard extreme...
etc

i think the game would be awesome if it had more configuration switches

some people will scream NOOOOoo for whatever reasons but i believe more options is the right way to go. it broadens the target market for users who will want to play and continue playing.

btw where r the joystick/gamepad configuration and mouse config/sensitivity settings and how about the option for it to work in windowed mode? these r good options we or many of us i am sure would enjoy

being able to define turret functions in this game would be another good thing since there are no doubt people who will want to have turrets both npc's and player owned while at same time there will be those who wont want them in the game or at least not available on player owned ships. and with that setting the aggressiveness of the turrets might be a good option or even how accurate they r. however aggressiveness/accuracy settings could be easily defined by the general game settings (ai's r passive agreesive etc novice in accuracy or dead accurate etc etc with...)

many of the settings could be tweaked with general game settings.. eg setting npc's to aggressive might mean they r more likely to chase you till fuel runs out or even follow u though witchpoints... while settings game to easy versus difficult could be the difference of an npc being destroyed with 1 shot versus 5 .. all settings i think make sense. the easy normal difficult hard like game settings can also cause markets to be more or less profitable and or upsettings for a player.... the list goes on n on...

of course from a programmers perspective which i am not as i can only speculate and assume this means more work for someone who isnt getting paid and probably has a full time job or two as it is. i checked the dev logs and i see things mentioned a couple yrs ago still at 50% more or less some not even at 1% so i know it must be overwhelming at times...

im no programmer but i can test things and if that helps i am available.

i been still trying to figure out how these turrets work. from my point of view they r needing a make over in the way the player sees them. if they r plasma cannon like in damage are they this way cosmetically? maybe they should be if they r not? it would add to the effect seeing our military lazers hit while the enemy ship just barely avoids a plasma cannon burst from the assisting turret LOL. then i would also like to see these turrets automatically engage oncoming missiles from npc's isnt that what the npc's turrets do? can we just simply give our ship this ai and have the said ai be turned on n off with some free keymappings?

im full of ideas but realize that the oolite programming back end is limited in resources of time and man power but if i can be of any help testing stuff i am here for ya all. i will continue to try to grasp how the turrets are being interpreted by the game engine and thus what limitations there are imposed because of the current hard-coded lines while also trying to figure out what can be modded and improved upon via oxp/js and hopefully eventually come up with a idea how to make these changes globally for all to enjoy or NOT depending on their config choices.

oh with that id like to close with one question... would oxp additions versus core game code changes be slower? better put r js script codes in oxp's given much less cpu cycles than the game code itself? eg a oxp defining a ships speed versus the game itself hypothetically if that is even possible.?

thanks!

Post by **another_commander** » Fri Dec 04, 2009 8:22 am

wildstar wrote:
i think having options is always a good thing.

we live in a world where we get to choose with caffeine or decaffeinated with sugar or with substitute sweetener etc etc

i found it really strange that the game never had (unless i am totally ignorant and blind) options to set game difficulty settings npc ai's to passive normal aggressive or vicious & game difficulty easy normal hard extreme...
etc

i think the game would be awesome if it had more configuration switches

The game is built on the old Elite, which had no difficulty settings. Assuming that such settings are introduced, this would require a major rewrite of AIs and internal game structure and at the end it would just make the game more "arcadey". I agree it is nice to have choice, but this may not be applicable for every game and in my opinion Oolite is a game where this does not apply, simply because of the style of gameplay.

some people will scream NOOOOoo for whatever reasons but i believe more options is the right way to go. it broadens the target market for users who will want to play and continue playing.

It is definitely nice to know that as many people as possible are enjoying the game but at the end, when it comes to new features it is always a matter of value of features versus time required for implementation and in this case the time required is a pretty high value. Plus, there is no such thing as a "market" for Oolite, the game is free to play and develop upon.

btw where r the joystick/gamepad configuration and mouse config/sensitivity settings and how about the option for it to work in windowed mode? these r good options we or many of us i am sure would enjoy

Joystick settings are saved inside .GNUstepDefaults, found in <OoliteInstallDir>/oolite.app/GNUstep/Defaults and you can set them in the Joystick Configuration screen under Game Options. This option is enabled by default in the case a joystick is detected on startup, disabled otherwise. Mouse in windowed mode will be a possibility in 1.74, but it will not be an option settable from in-game, because mouse control in a window is not officially supported. You will need to tweak the .GNUstepDefaults file for it to be activated.

being able to define turret functions in this game would be another good thing since there are no doubt people who will want to have turrets both npc's and player owned while at same time there will be those who wont want them in the game or at least not available on player owned ships. and with that setting the aggressiveness of the turrets might be a good option or even how accurate they r. however aggressiveness/accuracy settings could be easily defined by the general game settings (ai's r passive agreesive etc novice in accuracy or dead accurate etc etc with...)

many of the settings could be tweaked with general game settings.. eg setting npc's to aggressive might mean they r more likely to chase you till fuel runs out or even follow u though witchpoints... while settings game to easy versus difficult could be the difference of an npc being destroyed with 1 shot versus 5 .. all settings i think make sense. the easy normal difficult hard like game settings can also cause markets to be more or less profitable and or upsettings for a player.... the list goes on n on...

Again, it is a matter of value of features versus time required etc. This is not to say that it cannot or will not be done, but given that we are aiming for a stable release in the realtively near future, it is inevitable that at some point we will have to draw a line and stop adding new features. However, if anyone can submit a full patch that does all of the above, we will be more than happy to test it and if nothing gets seriously broken, it might be considered for inclusion in the mainstream.

then i would also like to see these turrets automatically engage oncoming missiles from npc's isnt that what the npc's turrets do? can we just simply give our ship this ai and have the said ai be turned on n off with some free keymappings?

You have this already in 1.73.4. When a missile is fired against your ship, you can press Shift+T and it will be automatically targeted, without you having to line up with the cross-hairs. This was implemented as an assist for turrets and was deliberately done so that player interaction is required for the turrets to disengage their previous target and lock on the incoming missile. Doing this automatically would be a) confusing, because you may actually not want to disengage your current target and b) unnecessary automation. We always try to keep in mind that this is a game meant for fun. The player must do something when a missile is fired against their ship. If all was done automatically, that would be way too easy, wouldn't it?

im full of ideas but realize that the oolite programming back end is limited in resources of time and man power but if i can be of any help testing stuff i am here for ya all. i will continue to try to grasp how the turrets are being interpreted by the game engine and thus what limitations there are imposed because of the current hard-coded lines while also trying to figure out what can be modded and improved upon via oxp/js and hopefully eventually come up with a idea how to make these changes globally for all to enjoy or NOT depending on their config choices.

As I said earlier, all ideas are welcome. Not all can be possibly implemented, though. Some do find their way in the code (like Shift+T or mouse control in window), but others have to wait in queue. Anyone who can work out a patch that makes any of these queued ideas a reality is welcome to submit it and we will happily test it as required. We have had already cases like this (off the top of my head, I can recall Frame's extremely-useful-for-testing station.dockPlayer() method, which was proposed, implemented as a patch by Frame himself, tested and is now mainstream, as a good example).

oh with that id like to close with one question... would oxp additions versus core game code changes be slower? better put r js script codes in oxp's given much less cpu cycles than the game code itself? eg a oxp defining a ships speed versus the game itself hypothetically if that is even possible.?

In practical terms, I do not think there is a noticeable difference in speed. The game gives the player a very open engine, with almost all of its aspects exposed for modding. So I would say that if you are interested in adding new features, it would be a good idea to first check the existing documentation for OXPing to see if what you want to do can be already implemented as an OXP. If it can, go ahead with it. If not, then you can always ask for an internal code implementation and your suggestion might go in, if feasible.

splunkjamma · Post by **splunkjamma** » Fri Dec 04, 2009 9:39 am

ClymAngus wrote:
A) Enabling on/off for player turrets so they don't use up all their energy shooting off rounds, like some strange huge plasma space wanking machine.

I Lol'd

ClymAngus · Post by **ClymAngus** » Fri Dec 04, 2009 10:02 am

Sorry I like viseral imageary, it grabs the attention.

http://www.youtube.com/watch?v=5w_DqhpM ... re=related

wildstar · Post by **wildstar** » Fri Dec 04, 2009 11:46 am

ClymAngus wrote:
Sorry I like viseral imageary, it grabs the attention.

http://www.youtube.com/watch?v=5w_DqhpM ... re=related

hehe yeah they was clever how they did that. maybe we need one of those in oolite... probably wouldnt be hard to model one in wings lol i just got wings for linux but im clueless atm.

Website · Post by **DaddyHoggy** » Fri Dec 04, 2009 1:07 pm

wildstar wrote:
ClymAngus wrote:
Sorry I like viseral imageary, it grabs the attention.

http://www.youtube.com/watch?v=5w_DqhpM ... re=related
hehe yeah they was clever how they did that. maybe we need one of those in oolite... probably wouldnt be hard to model one in wings lol i just got wings for linux but im clueless atm.

Have you tried this tutorial? http://www.oolite.org/old/cyoship2/

wildstar · Post by **wildstar** » Fri Dec 04, 2009 1:43 pm

first off i would like to thank you very much for answering all those questions i asked. i know its a lot and i know i have more. so much to learn and yeah i been reading through a lot of forum threads so no doubt you will see some old threads bumped here and there.

i know how difficult some changes can be and how long some can take depending on what it is. stability is always of great importance and size of added code along with the idea of maintaining the added codes compatibility. i was a mod in ace of angels AoA www.aceofangels.com and it was an awesome game but we witnessed a lot of bug fixes / updates between new versions and then when new feature releases would come out many times things got broken. i think there were some moments when say 6 new features added 12 bugs fixed and 2 old features broken due to new bugs. it was crazy but the guys worked hard and made a very enjoyable game for all.. all being the target market not so much as in for $ but interest. when i say target market u have an idea of who is going to enjoy your product or service or in this case a game be it for sale or free.

right now i think oolite's greatest target market are those who grew up playing elite. check out eve a game thats been around for a while too as a more prettier version of elite complete with a thriving and complex economy. people get on there and pay 15 bucks a month to mine all day or whatever thay want. but it is not a moddable open source game. like wow it is proprietary protected IP but of course they have revenue to pay programmers which is obviously not the case here. the ones in charge of the programming are not getting a dime and probably paying out of pocket for server expense.

i am not suggesting oolite be like eve or any other game. but i did want to throw out some ideas and see what kind of reception they would get and for what reasons if not and it is all understandable. i am not a worthy programmer to be able to offer ability to make additions to the game code at this time. i wish i did. and maybe i will learn a few tricks here and there. i think i might be able to build packages for different linux os's though from source. i have some limited abilities there compiling and and even repackaging as rpm deb etc

another_commander wrote:
The game is built on the old Elite, which had no difficulty settings. Assuming that such settings are introduced, this would require a major rewrite of AIs and internal game structure and at the end it would just make the game more "arcadey". I agree it is nice to have choice, but this may not be applicable for every game and in my opinion Oolite is a game where this does not apply, simply because of the style of gameplay.

well i kinda agree here with you because it is not a hard game nor a too easy game so it could very well sit well as it is however most noobs (like me) get frustrated exploding every time we bump into something. shouldnt there be some warning some alarms some damage first not just kaboom u r dead? there should at least be some time to hit the escape pod. even while tumbling out of control with no damaged systems. for the seasoned players maybe they dont want that kinda realism and so this is where settings like i mentioned could change the way events are handled.

some people will scream NOOOOoo for whatever reasons but i believe more options is the right way to go. it broadens the target market for users who will want to play and continue playing.

another_commander wrote:
It is definitely nice to know that as many people as possible are enjoying the game but at the end, when it comes to new features it is always a matter of value of features versus time required for implementation and in this case the time required is a pretty high value. Plus, there is no such thing as a "market" for Oolite, the game is free to play and develop upon.

when i think about the idea of expanding or broadening the target market what i mean is making the game a bit more attractice/interesting for others of other ages like how about a 15 yr old who has time on their hands and learned c / c++ last year and knows it well enough to get interested in the game and start adding to it in a way appreciated by others. imagine a few of these kids programming for no other reason other than to help out as we all want to in the oolite community.

kids r usually the ones with much creativity and getting a bunch of them interested in the game could mean hard core ships with new hard core missions and awesome tectures and models etc.. i seen what they can do but as it is i would be there are no kids playing this game at this time. i know most of them would rather play wow. but i know there are some out there who cant play wow cuz their computers r old. hehe. mines getting old Oo. im 41 im guessing most of us are between 35 and 45 ?

btw where r the joystick/gamepad configuration and mouse config/sensitivity settings and how about the option for it to work in windowed mode? these r good options we or many of us i am sure would enjoy

another_commander wrote:
Joystick settings are saved inside .GNUstepDefaults, found in <OoliteInstallDir>/oolite.app/GNUstep/Defaults and you can set them in the Joystick Configuration screen under Game Options. This option is enabled by default in the case a joystick is detected on startup, disabled otherwise. Mouse in windowed mode will be a possibility in 1.74, but it will not be an option settable from in-game, because mouse control in a window is not officially supported. You will need to tweak the .GNUstepDefaults file for it to be activated.

thats so strange. i not understanding why the mouse doesn't work in windowed mode while in combat but only full screen. however once you are docked you are able to click on things in the menus such as F2 F3 F6 F7 menus...

now that would be 2 different mouse modes while in combat that would be usable. one would be to operate ship and another mode would be an alternate mode to click on things such as enabling disabling features / equipment and selecting which missile to use. the alternate mouse mode would need an interactive hud though. obviously some additional code.

but if full screen can use mouse then theres no logical reason that widowed mode can not use mouse unless this game is run as a vm (virtual machine)?
i had experienced something like this in virtual box earlier versions where you had to alt or control click or such into the window for the vm to take over the mouse after which point it wouldn't release mouse past window boarder unless you pressed right control key or something like this. while in full screen mode it auto matically assumed mouse control.

and yeah i found the joystick wow doh right there in front of me. guess i need a joystick though LOL

being able to define turret functions in this game would be another good thing since there are no doubt people who will want to have turrets both npc's and player owned while at same time there will be those who wont want them in the game or at least not available on player owned ships. and with that setting the aggressiveness of the turrets might be a good option or even how accurate they r. however aggressiveness/accuracy settings could be easily defined by the general game settings (ai's r passive agreesive etc novice in accuracy or dead accurate etc etc with...)

many of the settings could be tweaked with general game settings.. eg setting npc's to aggressive might mean they r more likely to chase you till fuel runs out or even follow u though witchpoints... while settings game to easy versus difficult could be the difference of an npc being destroyed with 1 shot versus 5 .. all settings i think make sense. the easy normal difficult hard like game settings can also cause markets to be more or less profitable and or upsettings for a player.... the list goes on n on...

another_commander wrote:
Again, it is a matter of value of features versus time required etc. This is not to say that it cannot or will not be done, but given that we are aiming for a stable release in the realtively near future, it is inevitable that at some point we will have to draw a line and stop adding new features. However, if anyone can submit a full patch that does all of the above, we will be more than happy to test it and if nothing gets seriously broken, it might be considered for inclusion in the mainstream.

then i would also like to see these turrets automatically engage oncoming missiles from npc's isnt that what the npc's turrets do? can we just simply give our ship this ai and have the said ai be turned on n off with some free keymappings?

another_commander wrote:
You have this already in 1.73.4. When a missile is fired against your ship, you can press Shift+T and it will be automatically targeted, without you having to line up with the cross-hairs. This was implemented as an assist for turrets and was deliberately done so that player interaction is required for the turrets to disengage their previous target and lock on the incoming missile. Doing this automatically would be a) confusing, because you may actually not want to disengage your current target and b) unnecessary automation. We always try to keep in mind that this is a game meant for fun. The player must do something when a missile is fired against their ship. If all was done automatically, that would be way too easy, wouldn't it?

umm no it woudnt be TOO easy cuz i think there r times that this wuld come in handy. i still dont get when how where the chaff is used. is that automatic? but i see your point there WOULD be times you wouldnt want automatic handling of missile intercept by turrets and why the point of reinforcing the idea to have such switches in the game for the combat player. btw i just not finding the shift T anywhere in the keyconfig.plist to assign it to something else.

OT: currently docked with a GRS BUOY Factory Oo looks pretty cool!!

im full of ideas but realize that the oolite programming back end is limited in resources of time and man power but if i can be of any help testing stuff i am here for ya all. i will continue to try to grasp how the turrets are being interpreted by the game engine and thus what limitations there are imposed because of the current hard-coded lines while also trying to figure out what can be modded and improved upon via oxp/js and hopefully eventually come up with a idea how to make these changes globally for all to enjoy or NOT depending on their config choices.

another_commander wrote:
As I said earlier, all ideas are welcome. Not all can be possibly implemented, though. Some do find their way in the code (like Shift+T or mouse control in window), but others have to wait in queue. Anyone who can work out a patch that makes any of these queued ideas a reality is welcome to submit it and we will happily test it as required. We have had already cases like this (off the top of my head, I can recall Frame's extremely-useful-for-testing station.dockPlayer() method, which was proposed, implemented as a patch by Frame himself, tested and is now mainstream, as a good example).

oh with that id like to close with one question... would oxp additions versus core game code changes be slower? better put r js script codes in oxp's given much less cpu cycles than the game code itself? eg a oxp defining a ships speed versus the game itself hypothetically if that is even possible.?

another_commander wrote:
In practical terms, I do not think there is a noticeable difference in speed. The game gives the player a very open engine, with almost all of its aspects exposed for modding. So I would say that if you are interested in adding new features, it would be a good idea to first check the existing documentation for OXPing to see if what you want to do can be already implemented as an OXP. If it can, go ahead with it. If not, then you can always ask for an internal code implementation and your suggestion might go in, if feasible.

thanks thats exactly what i am trying to figure out. i been looking at tons of oxp codes the ai's plists etc and at the resources folder etc trying to get a good idea how things work before i go off and try to do anything major. i am glad this is a friendly community and the game itself is really amazing compared to the original elite. i have the original elite on the c64 here on my ubuntu using vice. so theres something i can offer up to all that i can easily access the elite if need be for any reason.

thanks again so much everyone has manage to make me feel quite welcome. much appreciated and much respect!

wildstar

Post by **Kaks** » Fri Dec 04, 2009 1:55 pm

You might also want to talk (well, ok, send a pm) to Lestradae. The main aim of his OE project is to add all sort of stuff to Oolite!

Post by **another_commander** » Fri Dec 04, 2009 2:41 pm

wildstar wrote:
i not understanding why the mouse doesn't work in windowed mode while in combat but only full screen. however once you are docked you are able to click on things in the menus such as F2 F3 F6 F7 menus...

I think the problem is more practical rather than technical. If you use mouse control in a window, it is very easy to click outside the window, at which point the game loses focus. This is especially easy during combat (trust me, I do it all the time

). The alternative of capturing the mouse cursor inside the window is not one that I would consider attractive. So for now, we have the mouse control available in full screen, where it is not possible to click outside. If you want, you can download a nightly build (found here) and edit .GNUstepDefaults by adding this line inside the section named "oolite":

Code: Select all

"mouse-control-in-windowed-mode" = YES;

Then, after saving and restarting Oolite, you will be able to activate mouse control in window mode and see how it plays for you.

btw i just not finding the shift T anywhere in the keyconfig.plist to assign it to something else

I knew I was forgetting something

OK, you can add this line inside keyconfig.plist:

Code: Select all

key_target_incoming_missile		= "T";

or whatever key you want to assign. Thanks for catching that.

wildstar · Post by **wildstar** » Fri Dec 04, 2009 3:03 pm

DaddyHoggy wrote:
wildstar wrote:
probably wouldnt be hard to model one in wings lol i just got wings for linux but im clueless atm.
Have you tried this tutorial? http://www.oolite.org/old/cyoship2/

thank you no doubt this will come in handy as my first step to understanding how to use wings. i built many things in secondlife and used maya and blender but all my things i tried to make turned out looking like a frog in a blender Oo so i need to take some time and learn step by step obviously hehe.