Oolite Bulletins

cim wrote:

Nothing so fancy here - emacs to edit the source code

I've been meaning to ask.. since you're one of those old-school emacs* fans, have you ever tried playing Elite for EMACS on it?

* (aka the editor that thinks it's an operating system )

Though i could compile, I didn't manage to configure Eclipse to edit objective-c source. It seems the only plugin for this is discontinued.

So i'm currently back to vi
I clone'd and compile'd, i'm beginning to read the code.

Welcome to the Dark Side.

Day wrote:

So i'm currently back to vi

Let the vi vs. emacs wars begin!

Bummer about the Obj-C plugin, though..

Diziet Sma wrote:

have you ever tried playing Elite for EMACS on it?

I think I've mentioned it a couple of times here before.Yes - very useful for a while in the early 2000s when I couldn't find my FFE disk. Interesting trying to navigate with just an adjacent systems list and no map - I expect I'd find it a lot easier nowadays.

@another_commander: you're too kind, my lord.

@Diziet Sma: I tried emacs for 20 minutes to see if I could use it better than vi to work on oolite. But it's hard to go at the same time through a new language, a new editor and a new project... So I'm back to vi :-p , equipped with military lasers.

Ok, as a first way to explore the code, I've looked for the main loop, and put timers around the main methods to see how the time is spent (calls to [Universe update], [OOSound update], OOJSFrameCallbacksInvoke() and [GameView display] in [GameController doPerformGameTick]).
Fun
Total time spent: 113.481s, universe: 8.61834%, sound: 0.0621145%, js: 0.00364207%, display: 91.3015%
Config : oolite at last commit, no oxp, Start new commander

Day wrote:

@Diziet Sma: I tried emacs for 20 minutes to see if I could use it better than vi to work on oolite. But it's hard to go at the same time through a new language, a new editor and a new project... So I'm back to vi :-p , equipped with military lasers.

Aye.. I used micro-emacs some, back in my Amiga days, but if I'm editing in a terminal, these days I prefer vi-improved, aka vim.

Diziet Sma wrote:

Day wrote:

@Diziet Sma: I tried emacs for 20 minutes to see if I could use it better than vi to work on oolite. But it's hard to go at the same time through a new language, a new editor and a new project... So I'm back to vi :-p , equipped with military lasers.

Aye.. I used micro-emacs some, back in my Amiga days, but if I'm editing in a terminal, these days I prefer vi-improved, aka vim.

Yes, it's the one I use

This week-end I coded the ability to change the field of view while in-flight with the keyboard and the joystick (Tested: keyboard, yet to test: joystick).

The coded keys are 'k' and 'l', and the behaviour is similar to "increase thrust" and "decrease thrust". (I didn't use the term "zoom" as I didn't want to confuse any(body|thing) with the scanner zoom).

I can make a patch available if some want it now.

It's working well, great to take screenshots and I think would be a tremendous asset during a dogfight.

My next steps are:
- testing with joystick,
- see if it's integrating well with the scanner,
- making some properties available to oxp'ers,
- gererating a discussion on this would-be functionality and its uses.

So, without further ado, the questions

Would the developers / the community be ok with including such a functionality?
Pro: more functionality is better, Con: it's insanely powerful and not in the original gameplay.

What do you think should be the properties available to oxp'ers?
Those I thought about were "rw:max field of view", "rw:min field of view", "rw:rate of change", "rw:initial field of view", "r:angle", "rw:field of view", "rw: requested field of view", "rw:isEnabled".
The "requested field of view" would be subject to the "rate of change", and the "field of view" would be instantaneous.

What should be the functionality offered in the basic game without oxp?
Full field of view control? Maybe too powerful?
No field of view control? Only enabled via oxp?
An equipment to buy? The result of a mission?
It's possible with this functionality to do a fisheye view, interesting in dogfighting not to lose an opponent, and to do a telephoto, interesting for sniping.

@Day: Do you have a github account? If not, please open one and submit your patch via pull request to the project.

For me, the best utilization of this feature would be via Game Options (slider setting maybe, like the sound volume?) + JsavaScript read/write property under the oolite.gameSettings JS object.

Great job!

Day wrote:

Pro: more functionality is better, Con: it's insanely powerful and not in the original gameplay.

"Not in the original Elite" should never be a consideration. For years Oolite was held back by a vocal minority of players who resisted all improvement by whinging "not in the original Elite", to the point where the ungrammatical "Press Space Commander" still remains because the missing comma was "not in the original Elite".

Wildeblood wrote:

For years Oolite was held back by a vocal minority of a[snip]...

This was totally, totally uncalled for. And let's not get into further discussion on this subject please. Let's stay on the FOV topic.

Apart from that, I agree that "not in original" is not a problem when we are talking about a clear improvement to the game, which is what this feature is.

@another_commander: I don't have a github account, ok I will create one. But the patch is not yet perfect, it will need a code review.

Ok, I'll look into Game Options, it seems a good idea.

And thank you (I really want to have a slider on my joystick to change this while dogfighting >-) )

@Wildeblood: nice to know

@another_commander: I created a github account, forked, commited and submitted a patch through a pull request #126.

This is the current version I talked about, I didn't add yet any improvement.

Thanks for taking the time to do this. At first glance it looks pretty good, now need to try a few tests and confirm it works as expected.

The one thing I am not very convinced with is assigning keyboard controls to it. We are already using too many keys and adding not one, but two keys for the same feature, is something that requires plenty of consideration. Note that this would be the same for any proposed feature, not just the FOV. To that I need to add that, in my personal opinion, this is an option that is suitable as a game setting, not as a gameplay element. In any case, if FOV control is added to the JavaScript interface (and it looks like it can be done without too much hassle) this means that JS frame callbacks can use it and it can be changed on a frame by frame basis, so probably assigning it new controls is not really needed.

Will be back with news from testing soon. Again, great stuff and thanks for your contribution.

Edit: Run quick check, looks very cool but there are a few little bugs. I left my comments on the pull request page on github.