Where is stuff?

[subtledoctor]

No no, the regexp wasn't slowing anything down. Where SCS currently does something like this:

ACTION_FOR_EACH spell IN [list of spells] BEGIN
    [apply spell effects to enemy .CREs]
END

...I was trying out something like this:

ACTION_FOR_EACH spell IN [list of spells] BEGIN
  OUTER_SET match_var = 0
  ACTION_IF (~%spell%~ STRING_MATCHES_REGEXP ~%my_regexp%~) = 0 BEGIN
    OUTER_SET match_var = 1
  END
  ACTION_IF match_var = 0 BEGIN
    [apply spell effects to enemy .CREs]
  END
END

That regexp itself is very simple and probably very fast. This could (theoretically) allow SCS to identify and skip the most troublesome spells, saving a lot of time and processor cycles. But alas, the test version I made was not very effective. Either the regexp isn't well-formed, or I chose the wrong spot in SCS' code to try skipping spells. Edited August 24, 2018 by subtledoctor

[Jarno Mikkola]

...

So just 3909 limes that uses a .bat to 168 limes(well, 163) ... that likely manages it differently.

Edited August 24, 2018 by Jarno Mikkola

[K4thos]

So just 3909 limes that uses a .bat to 168 limes(well, 163) ... that likely manages it differently.

 

I have no idea what you're talking about (limes?). You were meant to look for macros that are mentioned in the linked file, not compare whole macros.tph file (which contains tens of different macros and functions unrelated to the linked peace of code, some are not even used by EET main component). What you see in the linked lua file is almost 1:1 equivalent to weidu code mentioned there (literally line by line, that's why it looks so ugly). From what I remeber the only change is using data stored in lua tables instead of weidu associative arrays (and those tables are generated from weidu weidu associative arrays, so it's the exact same thing either way).

 

-------------------

ACTION_FOR_EACH spell IN [list of spells] BEGIN
  OUTER_SET match_var = 0
  ACTION_IF (~%spell%~ STRING_MATCHES_REGEXP ~%my_regexp%~) = 0 BEGIN
    OUTER_SET match_var = 1
  END
  ACTION_IF match_var = 0 BEGIN
    [apply spell effects to enemy .CREs]
  END
END

this is very unoptimized peace of code if you're using it on all cre files. Consider storing

1. in weidu associative array and check if the spell matches via VARIABLE_IS_SET instead of doing the same check tens of times for each cre file. You can find examples in EET macros.tph file how to do it.

 

edit: or just read Mike's explanation: http://forums.pocketplane.net/index.php/topic,29444.msg337277.html#msg337277

 

edit2: btw. if you're interested in matching exact string use STRING_EQUAL_CASE (STR_EQ in short) instead of STRING_MATCHES_REGEXP, since the latter is likely slower due to regexp evaluation.

Edited August 24, 2018 by K4thos

[subtledoctor]

Extremely unoptimized, yes. And not the actual code, but just some pseudocode to demonstrate what I was trying. If it worked, optimization could come later.

 

- SCS alone: 1 hour

- another mod + SCS: 7 hours

- other mod + SCS + this change: 3 hours

- other mod + SCS + optimize this: 2 hours

 

I made up those numbers but they demonstrate what I'm aiming for. Right now we are stuck in the 2nd situation... to get to the 3rd situation would be very nice, optimized or not. Then we could worry about optimization.

 

Frankly a more thorough change is probably called for, and it's heartening to hear that DavidW is looking into it.

 

One idea: since SCS only assigns vanilla kits to enemy .CRE files: rather than blacklisting a small set of files from other mods, it could (effectively) whitelist the .SPL files from the vanilla game, and disregard everything else.

 

Or something really simple like, rather than running through every row of each CLAB table, only consider the first 5 rows. So most or all mod-added kit abilities will be ignored.

 

Like I say, lots of room for optimization. There are many, many ways to skin a cat like this.

Edited August 24, 2018 by subtledoctor

[Jarno Mikkola]

Extremely unoptimized, yes. And not the actual code, but just some pseudocode to demonstrate what I was trying. If it worked, optimization could come later.

 

- SCS alone: 1 hour

- another mod + SCS: 7 hours

Another mod alone: 5 minutes

SCS + another mod: 1 hour and 5 minutes.

 

Guess into which category this intails... player only kit mods... this is because there's no chinece sword men in normal game... but if you insist on pulling all the fighters to be them, then it's going to be a while... as the enemy gets them too.

Aka, there's really no point trying to do all that to SCS, while you could do it via the kit mod itself ... by not targeting the enemy at all. As kit mods are, player's char "optimilazation" aka optional content that can optimize the players char at some benefit... usually at some cost, like worse armor class, worse max hit point or what have you. As there's no point on building a better than fighter base kit that has no penalties cause you'll be punishing everyone except the kitted player char. You do understand that, correct ?

[subtledoctor]

1) Such kit mods do not apply stuff to enemies. They only add abilities and effects to a PC who chooses that kit.

 

2) Likewise, SCS does not apply those abilities and effects to enemies.

 

3) Nevertheless, SCS inspects and evaluates all of those abilities and effects, because there's no way for SCS to know up-front that they are not designed to be applied to enemies.

 

So those mods do not intend the abilities & effects to apply to enemies; and SCS does not intend to apply them to enemies; but still we spend 6+ hours inspecting and evaluating them. Why not just skip it?

 

When I say "there's lots of room to make this more efficient," that's what I'm talking about. Whether we achieve it by having mods communicate to SCS "hey, don't bother with this ability" or by having SCS make some more discriminating assumptions about which abilities to apply to enemies... one way or another it is certainly achievable.

Edited August 24, 2018 by subtledoctor

[DavidW]

Whitelisting is more efficient, I think. (At least for AP_ effects; the overhead for installing those is vastly higher than for GA_).

[Jarno Mikkola]

Whitelisting is more efficient, I think.

Aka skip resources that aren't going to be needed, which is what subtledoctor was trying to do, for example with the prefix "D5", which if memory doesn't skip too much is his prefix. So just show us, where to add resource names that the mod skips and he will be happy.

Or make the resource list, and show us, and so forth. Whateve...

 

He can even add the resourses he wants SCS to skip during his mods install phase, which writes what files to skip to extracted SCS's mod folder's file. ---this is just one way to solve the problem, I am sure there's plenty more and you will probably havethe best... we just need the instructions on how to use it. When you make it.

Edited August 24, 2018 by Jarno Mikkola

[subtledoctor]

Btw one possible way to filter this would be to only apply spells that are in rows of the CLAB__ tables whose first entry is "ABILITY[1-9]"

 

That way it would capture all vanilla abilities & effects, and modders could "opt in" to SCS applying their abilities to the AI by simply appending something like this:

ABILITY      ****        AP_MY_ABIL ****        ****     etc.

...but anyone who wants to exempt their abilities from SCS to avoid slowdowns could append:

MYMOD        ****        AP_MY_ABIL ****        ****     etc.

Edited September 3, 2018 by subtledoctor

[DavidW]

Btw one possible way to filter this would be to only apply spells that are in rows of the CLAB__ tables whose first entry is "ABILITY[1-9]"

 

That way it would capture all vanilla abilities & effects, and modders could "opt in" to SCS applying their abilities to the AI by simply appending something like this:

ABILITY      ****        AP_MY_ABIL ****        ****     etc.

...but anyone who wants to exempt their abilities from SCS to avoid slowdowns could append:

MYMOD        ****        AP_MY_ABIL ****        ****     etc.

But I imagine plenty of ancient kit mods use the ABILITY nomenclature.

[subtledoctor]

Sure, and new modders would have to be educated about how to deal with it. (I imagine a line in the readme would suffice.)

 

It wouldn't be totally optimized, but it would still result in a marked improvement, which is what people are looking for here. And it leaves the door open for modders to "opt in." So it would trade perfection for flexibility.

 

Just an idea that occurred to me. I'm sure you have ideas of your own.