So I was at this over 8 years ago here: http://forums.datarealms.com/viewtopic.php?f=73&t=18968
And I couldn't get this to work back then.

I honestly don't know if anybody attempted this after that and succeeded, because I couldn't find anything of the like, or if this is relevant or of any use to anyone.
I also don't know where this urge to come back to CC modding came from but anyway.

I have (questionably) solid results.
Don't mind the sprites they are placeholders, this is a proof of concept.


(disappearing engine flash on the extra engines is me using a cutoff button to shut them off)

This proved to be a real headache, the original method was very complicated and didn't seem to work.
In the original method back then I attempted to manipulate the engines from a script that is run by the hull, i've learned that:
1. .ini attached AEmitters do not show up in MOID view (also MOID view drop my CC to 5fps for whatever reason).
2. .ini attached AEmitters don't even show up while you are in scene editor mode, they only appear after the DS is placed. They do appear just fine in actor editor.
3. None of the attachable accesses hacks (that I tried) seem to pick up these attached AE's.
4. Existence is pain.

Back then, my engine was attached to an attachable wing, this time I tried doing the same thing all over again by attaching the engine directly to the hull and it didn't work exactly the same.
Mind that in this very long time period my understanding of lua and the magic behind it did not improve, nor was it very impressive back then.

Now, I don't know if adding scripts to AEmitters was possible back then, but this was the breakthrough that made this possible now.
I ran a small script off the secondary engine that picks up a button and cuts off the emission and it magically worked.

Next I attempted to access the dropship hull and it's original engines from my attached engines - this method failed for me but this is most likely because i'm bad at this stuff.
So what I did is I ran a script on the hull that access the original engines and stores their "RotAngle" and "Throttle" values in global variables.
After that the script on the attached engines picks up these global variables and applies them and everything magically works.

I've learned from this that "Throttle" is not a read-only value and can be directly modified by using "ToAEmitter(self).Throttle = #;" (# being between 1 (max thrust) to -1 (min thrust)).
I've also learned that copying the throttle value over to my attached engine did not affect the scale of the flash like it does with the original engines so you have no visual representation of min/max throttle.
So while you do get proper throttle on your engines, the flash looks as if you are at 100%.

As you can see, this method does not limit the amount of engines you can slap on you DS, you can add as many as you like.
The limiting factor is the GibImpulseLimit on your hull, so adding more engines without upping GIL will cause your DS to instagib.

So this works nice and dandy but you can't have more than one of these on scene because it uses global values and they get overwritten and all sorts of crazy crap starts to happen. No crashing though.
Another minor issue is that while you are in scene editor and you select the DS (just select, don't place) the console will spam this:



As soon as you place it into the scene the spam stops.
This is actually very weird because in the translucent state prior to being placed, the attached engines are not showing but the script is already running.
If you are in actor editor and select the DS it will spam indefinitely.

I leave this here now in hopes of someone better at lua that me is able to refine this by ditching the global variables or at least making them independent to each DS so they don't overlap.

Here's the code:

Hull

Engine


Here's the .rte


Update:

After further investigation, for the current build, this is the easiest and most straightforward way to pull this off.
To sum it up, emitters attached to anything using "AddEmitter" (using "AddAttachable" crashes game) are handled by CC in a completely different way than regular MOSR attachables.
Thus, they lack IDs and cannot be accessed without ultra complicated lua workarounds. There are many other issues revolving around this whole fiasco besides actually accessing the emitters.
So, the very limited global variable approach is as good as it gets for now. As long as you don't have 2 of these on scene simultaneously you're in the clear.

But,
I have been to the year 3000 and it looks like this.



Cheers.

Hmm, pretty rusty on this stuff but here go some thoughts:
1. Instead of global variables you can use MOSRotating (and child classes) set value: http://wiki.datarealms.com/LuaDocs/MOSR ... tringValue
2. I'd think you can put together some code to make the extra engines' flare scale so it appears to match the real ones. You should be able to find the engine flare by iterating through all the particles and scale them accordingly, or have a script on the flares that finds their parents and scales accordingly (the latter is probably better).

All in all, neat stuff.

I'd like to say "Yes, that might work", but you really overestimate my understanding of this stuff.
When it comes to lua in this game i'm the guy that will make a circle out of squares just because I don't understand how to make a circle with the circle function, designed specifically to make circles. Bleh.

If you could spare a few minutes to test out your theory it'll most likely yield more results than me spending hours in frustration achieving nothing.

I originally (8 years ago) thought to ditch the emitters and attach the engines as regular MOSRs, that way I could access them though the hull, removing the need of global variables.
Then, spawn one of 3 emitters (low thrust with small flash, regular or high thrust with large flash) lua attached to the engines depending on thrust value.
Seemed overcomplicated and I wasn't sure if the forces from lua attachment will apply to the body.
They probably wouldn't, and I wouldn't know how to make them to. But it would probably look nice and functioning, just without the functioning.

Sure, I can take a look at it. Can you pm me whatever rte you have so I can run it directly without having to set things up?

And yeah, there's definitely ways we can make it transfer force and have nice variable strength thrust effects and such. I haven't done any CC stuff in quite a while though, so I'm not sure yet how it'll all work, though from my vague recollections I think it can work well. Either way I'm happy to poke at it and try to figure something out.

Yeah sure, i'll get on it when i'm back from work. Thanks.
I might not have time to get on this today, so i'll probably send it to you tomorrow.

I do have a thought though...
Since my main concern with this is to be able to have more than one of these on screen - is there perhaps a way to do this with tables?

I have a vague understanding of how they work, so wouldn't it be possible to have like, 3 tables, one for counting and two for variables.
So when you spawn one of these, it registers in a table as say, "number 1", and then the throttle and rotation variables get stored in the other tables under "number 1". When you spawn another one it registers as "number 2" and so on.
Then the engines just pull the values from the table according to what number they were assigned.
It will still use global variables but the conflict between them will be eliminated.
Wouldn't this be a simpler way to get this working? Or will this require a script constantly running from another source, like a brain?

This won't help the flash scaling issue though, which would still be cool to have, but I really don't care for it that much.

At some point CC got essentially a cleaner way to do that using the MosRotating SetXValue method I linked above. With this you don't have to worry about the existence of your global table or cleaning it or anything, you can just say engine:SetXValue("key", value) and have everything be self-contained. So it's basically the exact same concept as what you're saying, so you're very much on the right track, just packaged up more nicely.

No rush on it, just send it over or post it up sometime and I'll take a look.

Maxy, may I ask why you are still going at it 10+ years later?

What do you mean why? Because it's the best game ever made, hands down.

It's the only game I ever played that keeps pulling me back in no matter what for 12 years now. Actually more than 12 I think... I recall playing it before joining the forums for a decent period.
Besides maybe Morrowind, but even with that I spend like 2 weeks making the perfect mod build and then maybe sink in 150~ hours into it and quit then repeat after like 5 years.

Even though I pretty much did quit like 3 years ago, but still here I am again. It takes a few minutes to get immersed into and it always delivers.
It's pure straightforward fun, doesn't age and the modding, oh lawdy the modding.

I do wish the forums will spark life again though but CC has life in other places, it's far from dead.

11/10 would play always, perhaps with short pauses in between.



By the way nice to see you still visit this place.
I can probably ask you the same question back, why are you still here after 12 years?