Progress

[cim]

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.

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.

[Norby]

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.

[JazHaz]

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.

[Cody]

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

[Norby]

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.

[JensAyton]

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.)

[Cody]

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

Ooh... 'master' nightlies, eh?

[JazHaz]

Sounds kinky!

[Norby]

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.

[Gimi]

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?

[cim]

"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.

[Gimi]

"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.

[Commander McLane]

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.)

[Svengali]

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.

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).

[cim]

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.