Oolite Bulletins

Posted: **Mon Aug 26, 2013 12:07 pm**

Norby wrote:
I asked for a text entry in HudRequests OXP to make a Logbook OXP, now I missing the documentation only.
If you describe then I put into the wiki and make some OXP.

There's a new boolean parameter for the mission screen config object called 'textEntry'. If it's true, then you get the text prompt and 'choices' and 'choicesKey' are ignored. Whatever's typed there gets passed as the parameter to the callback function.

The ship registry code has a simple example.

Norby wrote:
Antialias is a must-have in any visual game imho, it is worth to backport into the 1.77.1 to get it without compiling. Please port it if it is possible.

It would be technically easy to backport it as it is, but at the moment our priority for 1.77.1 is to get the bugs out so it can be released. Introducing an incomplete and untested feature doesn't really seem to fit with that.

Posted: **Mon Aug 26, 2013 2:45 pm**

cim wrote:
Introducing an incomplete and untested feature doesn't really seem to fit with that.

I think to test a feature widely need to placed into a compiled test version. Before this a few people can test it only, which can be happen in short time, so others with compiler: please test anti-aliasing in GNUStepDefaults.

I can think under incompleteness to one thing only: a switch in the options screen, which can be tested easily after implemented. But regardless of this if the default setting remain off then the introducion can not cause big problems: if a player can turn it on and see a problem then can turn it off also.

Posted: **Mon Aug 26, 2013 3:31 pm**

Norby wrote:
cim wrote:
Introducing an incomplete and untested feature doesn't really seem to fit with that.
I think to test a feature widely need to placed into a compiled test version.

That's what Trunk versions are for Norby. Testing of new features, before they are released to the general public.

Posted: **Mon Aug 26, 2013 3:39 pm**

Any chance this will make it into a trunk nightly build?

Posted: **Mon Aug 26, 2013 4:48 pm**

JazHaz wrote:
Norby wrote:
I think to test a feature widely need to placed into a compiled test version.
That's what Trunk versions are for Norby. Testing of new features, before they are released to the general public.

Yes, I tried to say the same, but cim said that it is currently in the stabilizing phase where we can test the not so new features only. But I will be happy if at least the anti-aliasing can fit into due to it is a low-level feature which theoretically can not make bugs, especially if turned off by default.

Posted: **Mon Aug 26, 2013 8:10 pm**

Cody wrote:
Any chance this will make it into a trunk nightly build?

There’s no such thing at the moment. (Or in future; at some point there will be “master” nightly builds.)

Posted: **Mon Aug 26, 2013 8:50 pm**

JensAyton wrote:
... at some point there will be “master” nightly builds.

Ooh... 'master' nightlies, eh?

Posted: **Mon Aug 26, 2013 8:55 pm**

Sounds kinky!

Posted: **Mon Aug 26, 2013 9:10 pm**

JazHaz wrote:
Sounds kinky!

"Master" is the name of the main branch in GitHub which host the newest sources, I think this will be the v1.79 after the other branches are merged into.

Posted: **Tue Aug 27, 2013 7:30 am**

Are there also plans to update the "Building trunk the easy way" package to "Building Master the Easy Way"?
I can build by using using the github tool for windows to pull the source and then pointing the current "Building trunk the easy way" compiler to the downloaded source folder. However, the result was quite messy with the github tool reporting a lot of files waiting to be committed to the project.

So anyone know a way of redirecting the build to a different directory?

Posted: **Tue Aug 27, 2013 7:47 am**

Gimi wrote:
"Building trunk the easy way" compiler to the downloaded source folder. However, the result was quite messy with the github tool reporting a lot of files waiting to be committed to the project.

So anyone know a way of redirecting the build to a different directory?

That shouldn't be necessary. Ah - looks like the .gitignore file in the maintenance branch is out of date. I've pushed a corrected version now.

Posted: **Tue Aug 27, 2013 7:56 am**

cim wrote:
Gimi wrote:
"Building trunk the easy way" compiler to the downloaded source folder. However, the result was quite messy with the github tool reporting a lot of files waiting to be committed to the project.

So anyone know a way of redirecting the build to a different directory?
That shouldn't be necessary. Ah - looks like the .gitignore file in the maintenance branch is out of date. I've pushed a corrected version now.

Thank you cim. (You shouldn't do that while I'm at work you know

).
Now I have to test to see how it works.

Posted: **Tue Aug 27, 2013 9:09 pm**

cim wrote:
So ... new mission screen feature: arbitrary text entry.

This is so awesome! (And one million bonus points for the casual manner of delivery of this massive feature as a mere vehicle for the implementation of a totally different feature. That's really cool!

)

I've been dreaming about this for a long, long time. Just imagine the opportunities for interactive mission design that comes with this feature. <nearly faints>

<nerdgasm>Now Svengali only needs to write a word parser for CCL, and we can script full-blown text adventures in Oolite.

</nerdgasm>

(And yes, I am fully aware that there already exists a text adventure in Assassins OXP, but its mission choice-based, and therefore very simplistic compared to what's possible with text parsing.) (I am also aware that CCL has contained a keyboard for a long time, but direct text entry is so much more simple and elegant.)

Posted: **Wed Aug 28, 2013 10:54 am**

Commander McLane wrote:
cim wrote:
So ... new mission screen feature: arbitrary text entry.
This is so awesome!

Yes, it is a step forward to more dynamic and interactive screens and I absolutely agree.

Commander McLane wrote:
Now Svengali only needs to write a word parser for CCL, and we can script full-blown text adventures in Oolite.

I am also aware that CCL has contained a keyboard for a long time, but direct text entry is so much more simple and elegant.

When CCL_PhraseGen is done I'm aiming for a dialogue tree system (future music). The CCL_Keyboard may be removed in Oolite v1.80, but it depends on the features for text input, e.g if it's possible to define allowed input characters for the current instance or which chars are allowed at all (wink wink suggest suggest).

Posted: **Sun Sep 08, 2013 5:03 pm**

Svengali wrote:
e.g if it's possible to define allowed input characters for the current instance or which chars are allowed at all (wink wink suggest suggest).

Maybe. Because of the way the text input works at a low level (I just borrowed the function used for save game and system search), there'd only be a very limited number of alternative definitions - it might be more practical to handle it in the processing script by either rejecting invalid input and redisplaying, or stripping those characters out of the data, as appropriate.

Continuing, in addition to steadily going along with the AI enhancements and related features, one of the bits that came up was a need to flexibly specify certain ship roles as being equivalent to each other for a particular purpose. We already do this in 1.77 for pirate victims with pirate-victim-roles.plist, but there are now other roles needing similar treatment. So, there's now a role-categories.plist, which obsoletes pirate-victim-roles.plist (no need to rewrite OXPs - existing files will of course get processed compatibly)

Here's a couple of entries from it:

Code: Select all

	/* Roles used by bounty hunters */
	"oolite-bounty-hunter" = (
		"hunter",
		"hunter-medium",
		"hunter-heavy"
	);

	/* Roles that often attack pirates */
	"oolite-pirate-enemy" = (
		"hunter",
		"hunter-medium",
		"hunter-heavy",
		"interceptor",
		"police",
		"police-station-patrol",
		"police-witchpoint-patrol"
	);

So, if you wanted to add another sort of pirate hunter, you could put your own in, with

Code: Select all

	"oolite-pirate-enemy" = (
		"myoxp-mercenary-protection"
	);

and pirates would react to it in the same way as they do to bounty hunters and police. You can make your own role categories, too.

For those paying very close attention to detail: yes, this file merges in slightly differently to a standard plist dictionary, so the OXP code there does something useful rather than overwriting the standard definition.

Oolite Bulletins

Progress

Re: Progress

Re: Progress

Re: Progress

Re: Progress

Re: Progress

Re: Progress

Re: Progress

Re: Progress

Re: Progress

Re: Progress

Re: Progress

Re: Progress

Re: Progress

Re: Progress

Re: Progress