Questions here: an inquiry thread! [Updated Sep 15th, 2014]

Discuss and distribute tools and methods for modding. Moderator - Grognak
sleepz8
Posts: 73
Joined: Thu Feb 04, 2016 11:25 am

Re: Questions here: an inquiry thread! [Updated Sep 15th, 2014]

Postby sleepz8 » Fri Feb 19, 2016 6:19 pm

Hmmm, could someone tell me how to make and use custom beam colours? (or point me to a tutorial) I can't work out how to use anything other than red :L
User avatar
stylesrj
Posts: 3644
Joined: Tue Jul 08, 2014 7:54 am
Location: The Shrike
Contact:

Re: Questions here: an inquiry thread! [Updated Sep 15th, 2014]

Postby stylesrj » Fri Feb 19, 2016 9:20 pm

Add this code to the blueprint of the beam (for best results, put it under cooldown. That's where I found it on the bio beam.)

Code: Select all

   <color>
      <r>0</r>
      <g>0</g>
      <b>0</b>
   </color>
User avatar
Jimli_
Posts: 81
Joined: Sat Feb 20, 2016 1:16 am

Re: Questions here: an inquiry thread! [Updated Sep 15th, 2014]

Postby Jimli_ » Sat Feb 20, 2016 1:21 am

stylesrj wrote:blueprints.xml or dlcblueprints.xml

Copy an augment from there and change names around. Or look at Captain's Edition and the "dummy augments" used like the Teleporter Disruptor or the trade goods.

If you want to edit existing augments... disregard that and go look in those .xml files and change the values around.


Thanks for the info. This is me(theDoomBox) with a new username, BTW.
ImageImageImage
sleepz8
Posts: 73
Joined: Thu Feb 04, 2016 11:25 am

Re: Questions here: an inquiry thread! [Updated Sep 15th, 2014]

Postby sleepz8 » Sat Feb 20, 2016 10:05 am

stylesrj wrote:Add this code to the blueprint of the beam (for best results, put it under cooldown. That's where I found it on the bio beam.)

Code: Select all

   <color>
      <r>0</r>
      <g>0</g>
      <b>0</b>
   </color>

Sweet, thanks! Works well :)
sleepz8
Posts: 73
Joined: Thu Feb 04, 2016 11:25 am

Re: Questions here: an inquiry thread! [Updated Sep 15th, 2014]

Postby sleepz8 » Sat Feb 20, 2016 9:21 pm

Another question. I'm trying to make a healing beam using <persDamage>-15</persDamage> but it doesn't work! It pierces the shields and starts fires (like I want it to), but doesn't heal any crew health. Does this only work on bombs or am I doing something wrong?
Thanks in advance :D
User avatar
stylesrj
Posts: 3644
Joined: Tue Jul 08, 2014 7:54 am
Location: The Shrike
Contact:

Re: Questions here: an inquiry thread! [Updated Sep 15th, 2014]

Postby stylesrj » Sat Feb 20, 2016 9:30 pm

I think healing only works for bombs. The healing beam was tried before and it just doesn't work.

See if it works for lasers or missiles though. I can't remember if that was still fine and it's just beams that don't do any healing.
sleepz8
Posts: 73
Joined: Thu Feb 04, 2016 11:25 am

Re: Questions here: an inquiry thread! [Updated Sep 15th, 2014]

Postby sleepz8 » Sat Feb 20, 2016 9:35 pm

Gah!! Probably should have checked BEFORE making animations >:( Any ideas what I could use them for :D?
https://www.dropbox.com/s/f6uybx7fi2e3dep/healbeam.png?dl=0

EDIT: re-purposed it as a poison beam. Strange how it can do positive crew damage but not negative.......
sul
Posts: 121
Joined: Sat Jan 30, 2016 4:22 pm

Re: Questions here: an inquiry thread! [Updated Sep 15th, 2014]

Postby sul » Mon Feb 29, 2016 7:27 am

Guys, I have a very technical question on events. Do you have some tricks to simplify the structure of big-complex events, to avoid overloading ?

So I got into writing events for fun, and I made some huuuges structures. For example a browser similar to the one of the Mod testing environment:
viewtopic.php?t=22613
When I test some of them (at first beacon), the game takes forever to charges, or even freezes. It is not that the events have tipos (I checked several times), they are just too huge to load. I am so sad my browser was fun :(

First some definitions so we agree (and you can correct me):
- An event is a"XML tree". It can loosely look like that for example (sorry for the extra dots):

......................|-->event2-->event3-->event10-->event11-->event12-->event13
event0-->event1--|.........................................................|
......................|-->event4-->|-->event5-->-->|....................|----->|-->event8
......................................|...................|-->event7-->event6-- >|
......................................|-->event6-->-->|............................|-->event7

- The event tree starts from a root (event0), with possible branches (for example event0-->event1), bifurcations (event1-->event2 or event1-->event4), regroupments (event5-->event7 and event6-->event7), etc. The most important rule is that you can never loop back to a former event.
- Bifurcations (|) in particular can be either be "selected" or "random". For a selected bifurcation the player chooses next event through a choice list, while for random bifurcations the next event is randomly picked from an eventList.

Now a complex event can have a huge XML tree structure, which is too heavy to load. With respect to that, I found that:
- Branches are not costly. This makes sense as you just browse unique events.
- Selected bifurcations are EXTREMELY COSTLY. I observed that on a tree having selected bifurcations with something like 2-8 choices, each calling 2-8 new choices, regrouping eventually, etc: it wasnt too complex, but still it simply didnt load. The Mod testing environment is a milder example where that happens.
- Oddly enough, random bifurcations are NOT COSTLY AT ALL. I observed that on a tree with a random bifurcation having like 50 random possibilities (branches were regrouped just afterwards), that was repeated like 200 times, it just works like a breeze (its the mod SCRAMBLE on my page).

So my questions are :
- Is there some tricks to make "selected bifurcations" more lightweight ?
- Why are "selected bifurcations" much more costly than "random bifurcations" ? It shouldnt necessarily be the case, that just puzzles me.
- All those finds are from messing around with the code, but maybe there is a proper XML documentation you can redirect me too.
User avatar
kartoFlane
Posts: 1479
Joined: Mon Jan 14, 2013 10:20 pm

Re: Questions here: an inquiry thread! [Updated Sep 15th, 2014]

Postby kartoFlane » Mon Feb 29, 2016 3:04 pm

Ad Q1:
None that I'm aware of. Maybe making shallower event trees, but that doesn't really help your problem, I guess :P

Ad Q2:
Possibly it could be caused by the way FTL loads events, I guess. The currently accepted theory is that FTL preloads all possible event paths during loading (which is why we can't have event loops), but I suppose they're stored in some kind of compressed form. Once you actually get to a point where the event path might potentially be activated (ie. choice in an event), it might be transformed into an expanded format that, say, contains the complete game state after the event actions have been performed. And maybe child events of that one event. So if you have an event with 8 choices, you have like 8 gamestates you have to keep in memory, which might somehow exhaust the preallocated memory, I guess...?

It's pure theorycrafting on my part, to be honest I've no idea why anyone would ever program a game in such a way, instead of having events apply the changes after they're actually selected by the player. Also creating events on-demand instead of preloading them makes much more sense IMO. Even assuming such an inefficient way of handling event data, it's still pretty unlikely that it'd be capable of exhausting memory, but that's the only reason I could think of.

Ad Q3:
XML docs won't help you here, I think. If FTL passes the initial loading screen, then it successfully parsed all XML files. What happens after that stage is completely up to the game.
Superluminal2 - a ship editor for FTL
sul
Posts: 121
Joined: Sat Jan 30, 2016 4:22 pm

Re: Questions here: an inquiry thread! [Updated Sep 15th, 2014]

Postby sul » Tue Mar 01, 2016 1:39 am

kartoFlane wrote:Ad Q1:
None that I'm aware of. Maybe making shallower event trees, but that doesn't really help your problem, I guess :P

Ad Q2:
Possibly it could be caused by the way FTL loads events, I guess. The currently accepted theory is that FTL preloads all possible event paths during loading (which is why we can't have event loops), but I suppose they're stored in some kind of compressed form. Once you actually get to a point where the event path might potentially be activated (ie. choice in an event), it might be transformed into an expanded format that, say, contains the complete game state after the event actions have been performed. And maybe child events of that one event. So if you have an event with 8 choices, you have like 8 gamestates you have to keep in memory, which might somehow exhaust the preallocated memory, I guess...?

It's pure theorycrafting on my part, to be honest I've no idea why anyone would ever program a game in such a way, instead of having events apply the changes after they're actually selected by the player. Also creating events on-demand instead of preloading them makes much more sense IMO. Even assuming such an inefficient way of handling event data, it's still pretty unlikely that it'd be capable of exhausting memory, but that's the only reason I could think of.

Ad Q3:
XML docs won't help you here, I think. If FTL passes the initial loading screen, then it successfully parsed all XML files. What happens after that stage is completely up to the game.

Thanks kartoFlame for that detailed answer, it is very helpful. So that means the FTL code is kind of quirky I guess, no documentation except from trial and error. Now I have this random though that it is REGROUPING selected bifurcations that is actually costly, which means you could actually build a complex tree if you avoid it (but it is a challenge). I will try that next and see how it goes.
Edit: kartoFlame, so after several tests I can confirm this at least: regrouping selected bifurcations is what is extremely costly (regrouping random bifurcations is not). I made a huge tree (20mb of text, procedurally generated using linux bash) without it, it has all the other features (selected bifurcations, random bifurcations, regroupment of random bifurcations, etc) and works like a charm. If you regroup selected bifurcations only once in that tree than it overloads.
Last edited by sul on Thu Mar 03, 2016 7:44 pm, edited 2 times in total.

Who is online

Users browsing this forum: No registered users and 22 guests