Page 1 of 2

I s&^*^ck at coding for Oolite

Posted: Sat Dec 14, 2013 8:12 pm
by Zireael
I've successfully modded two games based on Lua and I'm making my own game in Lua, too.

I have loads of little ideas which could improve Oolite experience.

So why can't I make even a simple OXP which spawns flashers?

:twisted: :twisted: :twisted: :twisted: :twisted: :twisted: :twisted: :twisted:

Re: I s&^*^ck at coding for Oolite

Posted: Sat Dec 14, 2013 8:25 pm
by Diziet Sma
Because the learning curve at the beginning is rather steep.. hang in there, it gets easier.. but you've lots of reading and studying of OXPs that are similar to what you want, ahead of you..

Re: I s&^*^ck at coding for Oolite

Posted: Sun Dec 15, 2013 5:01 am
by dertien
hahahaha, I know exactly what you mean :lol:

Re: I s&^*^ck at coding for Oolite

Posted: Sun Dec 15, 2013 11:40 am
by Zireael
The engine trails idea that I can't get to work looks like that:
(warning, pseudo-code ahead as I can't get the hang of JS ifs)

Code: Select all


if this.ship is enemy //IIRC rocks, cargo etc can't be enemy so this solves the problem of excluding them all; also, this ensures that fleeing yellow enemies spawn trails, too
{
//apply spewstrails flag (once per ship)
}
return;
if this.ship has spewstrails flag then
if this.ship is within 10000 of the player //performance reasons
{
ship.spawnOne("enginetrails");
ship.script.enginetrailsposition = ship.position.add(ship.vectorForward.multiply( 100 ));
enginetrail.position = ship.position.add(ship.vectorForward.multiply( 50 ));
enginetrail.orientation = ship.position.rotationTo([0, 0, 1]);
enginetrail.target = ship
//spawn a pair of engine trails (blue flashers) astern every 2 sec; clear up the trails after 30 sec.
}
So as I said, my ifs suck in JS and they are not too good in Lua either.

Heelp!

Re: I s&^*^ck at coding for Oolite

Posted: Sun Dec 15, 2013 4:34 pm
by Zireael
Ok, having more success with another idea. The modded equipment.plist works. The modded shipdata_overrides.plist doesn't.

Here's the last attempt:

Code: Select all

	"adder" =
	{
		max_cargo = 20;
	};

	"adder_player" =
	{
		max_cargo = 20;
	};

	"cobramk3" =
	{
		max_cargo = 55;
	};

	"cobramk3-player" =
	{
		max_cargo = 55;
	};
Help?

Re: I s&^*^ck at coding for Oolite

Posted: Sun Dec 15, 2013 4:38 pm
by another_commander
You are missing an opening curly brace at the top of the code and a closing one at the bottom. The code should be enclosed like this:

Code: Select all

{
    [everything you posted above]
}
Remember to hold shift on next restart.

Re: I s&^*^ck at coding for Oolite

Posted: Sun Dec 15, 2013 4:43 pm
by Zireael
Tried adding the braces already, game complains about "extra data after parsed data" in line 1 char 9.
I've redone the file thrice, that's why it's reduced to cobbie and adder for now for testing purposes.
I've used both ConTEXT and SublimeText 2 and even tried the Plist Editor for Windows, which sucks balls.

Re: I s&^*^ck at coding for Oolite

Posted: Sun Dec 15, 2013 5:03 pm
by another_commander
Assuming you are using the standard trunk nightly without OXPs here, you have the following errors in your plist:
"adder_player" should be "adder-player" (dash, not underscore)
"cobramk3" should be "cobra3"
"cobramk3-player" should be "cobra3-player"

Just copying/pasting the contents of your earlier post and applying the above corrections (plus opening and closing curly braces) makes it all work for me. I am using Notepad++.

If you do have OXPs, disable them temporarily and try the above just to be sure that it works.

Re: I s&^*^ck at coding for Oolite

Posted: Mon Dec 16, 2013 8:01 am
by Zireael
Thanks for the tip. I managed to get it to work.

And now, any way to get the Engine Trails idea to work?

Re: I s&^*^ck at coding for Oolite

Posted: Tue Dec 17, 2013 2:43 pm
by Zireael
I've heard back from Commander McLane and he has presented some ideas on how to improve the Engine Trails idea.
Honestly, I can't draw worth sh*t...

Re: I s&^*^ck at coding for Oolite

Posted: Sun Dec 22, 2013 4:42 pm
by Zireael
Any more ideas about engine trails? Commander McLane has mentioned visual effects instead of entities... how do I code visual effects for Oolite?

Re: I s&^*^ck at coding for Oolite

Posted: Sun Dec 22, 2013 5:11 pm
by cim
[wiki]Effectdata.plist[/wiki] lets you define a visual effect.

system.addVisualEffect(...) lets you add defined effects to the system.

Visual effects have a javascript representation which can be used to modify them.

I was experimenting with this myself a bit before 1.77 was released, to see if there was a better way to get engine flares - here's the not very far I got with it. It works okay - though it's a bit system-intensive - for one ship at low speeds, but it falls apart entirely at injector or torus speeds. Still, it gives an example of how you might add visual effects in about the right place to be an engine trail, though I wouldn't say it was an example of good code.

Re: I s&^*^ck at coding for Oolite

Posted: Mon Dec 23, 2013 12:00 pm
by Zireael
Experimenting with cim's code.

I will hopefully manage to tweak the values so that I have a working tech demo engine trails for normal speeds. :)

Injector speeds are evil :evil:

Re: I s&^*^ck at coding for Oolite

Posted: Mon Dec 23, 2013 7:27 pm
by Mad Hollander
Zireael wrote:
I've successfully modded two games based on Lua and I'm making my own game in Lua, too.
I have loads of little ideas which could improve Oolite experience.
So why can't I make even a simple OXP which spawns flashers?
The external API of oolite is too weak for serious extensions. You have to implement very low level logic and have to struggle through dozens of events. Another thing is that most of the features are hardcoded, i.e. laser characteristics and etc.

look at the railgun or plasma cannon, I gues that can help you.

Re: I s&^*^ck at coding for Oolite

Posted: Tue Dec 24, 2013 7:49 am
by another_commander
Mad Hollander wrote:
The external API of oolite is too weak for serious extensions. You have to implement very low level logic and have to struggle through dozens of events. Another thing is that most of the features are hardcoded, i.e. laser characteristics and etc.
I just want it to be known that I fully disagree with the above statement.

- Scripting in any game is event-based; Oolite is no different to that regard and I fail to see how this could be perceived as a weakness.
- Almost everything in Oolite is not hardcoded, with the (deliberate) exceptions of laser characteristics and 7LY fuel limit. If there are others, please remind me because although I admittedly have not looked at the game code for a while now, I cannot seem to think of any more.
- I have been involved with modding Freespace2 SCP and other games in the past and I can assure you that the scripting API of Oolite is by far the one that offers the most capabilities. I could go as far as saying that Oolite at its current state is more of a space game engine rather than a game and I am not saying that just because I happen to have taken part in its development. Obviously, for someone starting out with scripting in this game, a learning curve is to be expected but that is the case with any other moddable game, too.

The answer to Zireael's question is that it takes time, dedication and study to learn Oolite's Javascript interface, just as it takes time and study to learn how to mod Egosoft's X games, for example. I would be willing to bet that Zireael did not just start coding in Lua one day, there was some learning and reading to do there, too. And the good news is that the interface for Oolite happens to be really well documented in the Wiki, so it's all there, ready for anyone willing to use it, which is more than I can say for other game mod interfaces, for which learning relies mostly on trial and error.