December 22, 2024, 14:36:53

Author Topic: The ExecList?  (Read 19436 times)

Offline Hyperion5

  • Recruit
  • *
  • Posts: 14
  • Karma: 0
    • View Profile
The ExecList?
« on: April 01, 2010, 05:55:13 »
Hi guys, first post.

Okay, just got the go ahead from Arparso that this is ok. summary:

Alright, the execlist that we keep hearing about while modding is the core rules set by HD for the game, basic ai, objects behaviors, rules, etc. No one has ever been able to find it, but we've all logically guessed that it's in the .exe file, you'd of course be right, the exe contains all the base data to start an application, but it can contain more as evidenced by nexus: the actual game exe is about 4 MB, way too big to just be directx, the engine, and resource links, also in there is the .ini file that creates the root rules, the ones that load with the game.

Everyone thinks that an .exe is encrypted, actually it's more like an uncompressed zip file, marked .exe so that windows knows to read it to run it as an app, also true is that extracting that exe is illegal, but there's a solution thats perfectly legal for what we need: to read whats in the .ini. DirectX and the game engine can't be read in this state, they're unable to be read by a common read program being different formats, and those advanced programs would hate what they get.

But the .ini file is just a specially marked .txt file- any notepad like program (not rich text editors) will display gibberish DX and engine files, but the ini will come out (mostly) as plain text! Using freeware Notepad++ for .txt reading (word wrap off) i can open nexus_DX9.exe to read all the key rule names and parameter set names, and using logic, how they work.

there's nothing illegal with just reading the exe as a txt, it's legal as long as we don't decompile or alter the exe (so you can't edit anything here, wrong place to edit) with the mod tools HD gave us full sanction to use their ruleset, they just didn't tell us about the script syntax i found in there (because it could break your game if your not careful).

(cont next post: what i found and what to do with it)

Offline Hyperion5

  • Recruit
  • *
  • Posts: 14
  • Karma: 0
    • View Profile
(No subject)
« Reply #1 on: April 03, 2010, 00:04:51 »
Okay, what i have found so far is mostly just names, but careful observation of their location and surrounding syntax gives away what most of them do.

First few thousand lines are gibberish, that's the DirectX and Engine data, but near the 14000's i found the .ini file(s), which has to be stored as text to work:
         
Everything on this list can be overridden, BUT NOT HERE! anything you want to change you have to overwrite in your consts.ini or mod_consts.ini and elsewhere

i read these in notepad++ so i can give you page lines (with word wrap OFF) past these lines are what's in the file (rules and such), until you hit the next line i marked

REMEMBER, READ but DON'T EDIT this file! DO NOT try to decompile this exe! read only!
         
Code: [Select]
some important parts: (, <%name %>, , )

13925 to 13997 I see all of the GFX rules in here

14136 %sSTATE %s This is the folder that sets how long a 'tick' is
14139 %sMACHINE "%s" Looks like where all the machine operators keywords are stored, along with the text for machine operation error messages
14157 %sTAIRACE %u The Racial AI base parameters, like in the Tactics Folder
14191 %sTAIUNIT 0x%08X AI behavior params for fighters, commandos etc.
14193 %sTGATE 0x%08X Looks like the Wormhole behavior
14219 %sTDEVICE 0x%08X looks like device behavior constants, the ones all commandable objects use
14229 %sTGROUP %u %u Group AI and commands
14269 %sTSHIP 0x%08X Ship AI and commands
14336 %sTIMER All the device params you find in tacticstypes.ini
14427 %sMISSION %u Scripts for making missions and relevant error messages
14442 Relations Lots of stuff, NPC stats, crew, various trigger events. I see the rules here
for all the different object interactions (damage, energy, etc.)
14804 .ini files end here i think

i'm not familiar with this specific syntax used in this file, but i can tell that this is what people have been looking for,
i'll see what i can find in here and give insight as i can. maybe even try at a program that can reference all the game commands with descriptions and help generate specific syntax.

Offline Hyperion5

  • Recruit
  • *
  • Posts: 14
  • Karma: 0
    • View Profile
Modders *READ THIS PLEASE* Exec list commands need help testing
« Reply #2 on: April 03, 2010, 07:49:07 »
Okay, remaking the post so it's more what i was trying to say,
I've been looking over what I've found so far:

%s = State Strings. yeah, Arparso's definitely right here

%u = Universal (at least i think so)

%d = Dialog (Images, I see a lot of these attached to buttons so i'm thinking GUI)

%G = Integer (Whole number)

%1G = T/F Integer (1/0, On/Off)

%.0f (thats a zero) = Float value (Decimal number)

0x%08X = Create Point (As in a new nav point, hardpoint, etc.) on an XYZ grid wait, definitely not, i think it's actually a set memory address value for certain things, hmm, this one will be hard to mod if you want to change it.

And to explain what i was talking about previously: this list seems to hold the definitions of various script effects:
EXAMPLE USAGE: *not actual script* just potential application once we learn more about it, i forgot to go back and add that, this is where i started to confuse people previously.

%sNewDeviceType %G %G %G = would create new device param with 3 integer values

%sNewHardPointType 0x%08X = would create new hardpoint on xyz (relative to another object or on the map)

But as Arparso had said, these wouldn't make the string in and of themselves (at least not out of the execlist).
several commands are in this file, some look unused, some look like commands we knew about, but not the syntax of. Definitely worth checking.

That's better

Offline Mularac

  • Lieutenant
  • ***
  • Posts: 531
  • Karma: 11
    • View Profile
(No subject)
« Reply #3 on: April 03, 2010, 15:39:31 »
This is all very interesting indeed, but there's something that I couldn't quite understand, what's the usage of this? what can we do with it if we can't edit it?

Offline Hyperion5

  • Recruit
  • *
  • Posts: 14
  • Karma: 0
    • View Profile
(No subject)
« Reply #4 on: April 03, 2010, 18:11:31 »
We can't, but there might be a workaround,

Now correcting myself from my previous horribly bungled post:

When Nexus loads data, it opens up all the relevant .ini files in order, this order begins within the Nexus_DX (8 or 9).exe, since everything in there is the backbone of the whole program has to be in there to function. when i looked at it, i found what appears to be the execlist (or at least the commands of that list) in the exe

Like the consts.ini file, there's also a mod_consts.ini file. there's a possibility that we can find a similar way to add data to the exec list, possibly using the language i found inside the exe and i could use help with testing that theory.

There, a much better post.

Offline Hyperion5

  • Recruit
  • *
  • Posts: 14
  • Karma: 0
    • View Profile
(No subject)
« Reply #5 on: April 03, 2010, 18:15:57 »
By the way, has anyone tried to read the Nexus_DX9.exe in notepad/notepad++ yet? you'd probably see what i mean more clearly if you read the parts i pointed out.

Offline The Old Dragon

  • Ensign
  • ***
  • Posts: 362
  • Karma: 6
    • View Profile
    • http://
(No subject)
« Reply #6 on: April 03, 2010, 22:25:41 »
Well, I tried but I must be doing something wrong as what I get is very different to what you pasted.
I d/l notepad++ (thanks for bringing this to my attention. Once I get used to it, I think it'll help with my scripting) but the only option I get is to 'edit' the dx9.exe with np++. Am I looking at this wrong?
Better to look the fool by asking, then prove them right with ignorance.

Offline Hyperion5

  • Recruit
  • *
  • Posts: 14
  • Karma: 0
    • View Profile
(No subject)
« Reply #7 on: April 03, 2010, 23:49:42 »
yeah, notepad++ the right click command is called 'edit', that is the right command

sorry, i said 'open' so people wouldn't think i actually meant changing something, don't change, just open and read

inside it's gonna look like gibberish at first, but on the left side of the screen should be numbering marking the page line, with word wrap off, scroll down to the numbers i told you about, those are the markers for different command types, it'll make sense after a few seconds of reading

Offline Arparso

  • Administrator
  • Lieutenant
  • *****
  • Posts: 558
  • Karma: 14
  • I can see you...
    • View Profile
    • http://arparso.de/nexus
(No subject)
« Reply #8 on: April 04, 2010, 02:09:06 »
Sorry, I still don't quite get, what you're trying to accomplish here. What execlist.ini are you're talking about? There's no such file in Nexus or inside the nexus_DX9.exe ... at least I didn't find any reference to that.

Quote
A rule or object stored in exec list can be Overwritten if that same command is placed in the consts.ini file:

If in execlist there is: %sDeviceParam % %

And also In consts: %sDeviceParam % % % //Nexus will choose THIS value, since it overwrites the exec list one
That doesn't work. You can't "invent" new keywords, since Nexus will just crash telling you about "not an identifier" or "invalid keyword", depending on where you put it. If you somehow managed to do what you just said, please provide a working example or a more accurate explanation.

Quote
I know it seems similar to normal # rule inserts, but they do distinctly different things once you get down to loading data into RAM:

1. %s values are stored as a sort of 'temporary database' in active memory, not as a string of script like # commands - which means %s files can hold a lot more data in less space, and # scripts can call on a shared %s script databases, reducing overall drain of processing and ram
2. %s values divide into tables, different tables can be loaded as necessary, while tables you don't need for the coming mission can be dropped from active memory (in the first missions of main campaign, shields aren't used, the object databases for shields weren't loaded for those missions, they weren't needed, saving processing capacity) # rules stored in rule files ALL have to be loaded
3. adding a %s value to a device just adds that value in the collective data table for that device type, adding a # file to do the same thing creates an extra process tree, wasting a lot of capacity.

Conclusion:
the game made using just # scripts could have worked, but it would several times larger on the hard drive, and require a LOT more RAM and CPU capacity. as well as limited mechanics

using % scripts as well changes that
First of all, #-values aren't rules or scripts... they're constants. They actually represent numerical values the game uses internally, but which aren't comfortable to work with for the human reader or developer. E.g. if you're writing:
SetRelation(#race_player, #race_NTF, #UREL_ENEMY);
then the game's script interpreter actually replaces all #-constants with their proper numerical values before processing the line:
SetRelation(1, 2, 2);
The game offers these constants just to make scripting easier and introduces a lot of default constants in consts.ini as well as registering shipclass and device names as constants (among others), so you can refer to those by using the #-syntax instead of having to write the actual SHIPCLASS' number every time, for example. As I said: constants aren't rules, nor are they scripts.

Second: what do you mean by %-script? How do I write it, where do I place it and what does it do? Such a script type doesn't appear in any of the game's script files, to the best of my knowledge.

And third: Where did you get this information about how the game stores what? Just by looking at the binary .exe file?

****************************

As far as I can tell, these sections in nexus_DX9.exe simply contain a collection of different strings telling the game how to parse the various .ini and script files. It seems to me, %s simply means: "here comes a string", followed by the actual string, e.g. DamageDevice %G, where %G actually represents the data type expected after a DamageDevice keyword (in this case, a float representing the devicedamage of the weapon). See other examples like Color %G %G %G %G (color with RGB and Alpha values), NumStars %u (number of stars in system, expecting an unsigned integer value) or Mesh "%s" (mesh of the celestial, expecting a string in double quotes).

That may help us understanding the script and/or ini parser better than before and may help us find undocumented properties we didn't know about, but I don't really see a way to change any of that without breaking the .exe.

Offline Hyperion5

  • Recruit
  • *
  • Posts: 14
  • Karma: 0
    • View Profile
(No subject)
« Reply #9 on: April 04, 2010, 04:03:15 »
Wait a sec,

Okay it looks like i got far ahead of myself on certain things and have been confusing a lot of other people, sorry guys, my fault.
I'm looking back now and i see i messed up big time, I've been mixing up the story as a result.

First off, in this thread, I've been pulling info off info out of text information from the text inside the .exe, I think i made that clear.
at first i was just looking for commands and such and figured to share, i now realize i blundered, i didn't find the magic %'create value' in and of itself, and i certainly didn't mean to say that's the correct language to use to use it. I now see why it looks like a claim to that.

God what i said became gibberish, %script? your right Arparso, i didn't do anything like that. Let me clean what i said up on that area of the thread. So it remotely makes sense.

Apologies for confusion

Fixed, more or less.

Offline jstubbles

  • Petty Officer
  • **
  • Posts: 169
  • Karma: 2
    • View Profile
    • http://www.ivassago.com
(No subject)
« Reply #10 on: April 04, 2010, 19:11:07 »
How are you getting such high page values?? With word wrap off, I'm only seeing 8312 lines in the DX9 exe file. Your line numbers go over 14,000. Doing a manual search for any of those variable names doesn't come up with a single thing.

I just see lots and lots of this:

Code: [Select]
ŠFlmÏÎ,®›#s²¡Z€ñƒÅ‹ R“VÈ9ð‰ÇiD"|Έù
:} ûgUe½ "±‹ÑÁêùáÊ«äð kç@ýèŒL«›žÚÐj åÑ;òs|J!º H4Òw
ž”%DTÖ¡ÿ1…PÐœẨ(?ÞS«è‰êƒâ@I‹ñõ¿D+Â’ò±“ÊYqsQÊEi›Ç.2W‹Î0ÈÁTéŒÊ&;ñ|©g±sú ԍULʘÂ,TùN¼¤3$ÁŒsÆá‡ì!éÅ<àG
3ÉÍGÂ‰D‚r

Offline The Old Dragon

  • Ensign
  • ***
  • Posts: 362
  • Karma: 6
    • View Profile
    • http://
(No subject)
« Reply #11 on: April 04, 2010, 22:13:51 »
I'm seeing more or less the same thing from dx9.exe (no 'plain' text, only those special characters), but I've got 40326 lines!
Better to look the fool by asking, then prove them right with ignorance.

Offline Hyperion5

  • Recruit
  • *
  • Posts: 14
  • Karma: 0
    • View Profile
(No subject)
« Reply #12 on: April 05, 2010, 01:27:57 »
hmm, not entirely certain why you guys can't see it...

what version of notepad++? i'm using v5.6.8 unicode

on XP 64 default settings for just about everything, just set the view colors for less white
I do have the hex editor plugin, but it's off, i'm not using it to read this, since that plugin is still a little buggy

wait, is your computer reading as ANSI? that's what i'm using, don't know if that would affect it
there's also a setting to read as an MS INI document, but i'm just reading it as text

Language drop menu > M > MS INI, if your using defaults

DurText is the first phrase on line 13925 that's legible, followed by gfx info below it

Description: %s is where i began to find text on line 14082, followed by everything else

other than that, i'm not sure what the difference is between our systems, sorry :S

Offline Hyperion5

  • Recruit
  • *
  • Posts: 14
  • Karma: 0
    • View Profile
(No subject)
« Reply #13 on: April 09, 2010, 04:20:52 »
any luck reading it guys?

I'm trying to record all the text that appears to be related to any modding script, but i only have so much free time, exactly what they all do will probably need trial and error to find out.

I'm starting to believe that at least some of the 'nul' (or binary, depending on how you view them) values adjacent to the specific scripts may actually correspond to different memory addresses inside the game that script may influence, if this is true, i suspect it could be easier to create certain script types that already use in game mechanics and values - and harder for those that aren't already there. (such as by copy/pasting the binary code do influence/read those addresses, once we ID their purpose, if we can) but that's strictly speculation on my part, especially since i still can't see any actual commands that would add scripts in that way, again needing experimentation to find them.

I've also been looking into adding more hard-points to the stock game mechanics - i think i found something somehow related:

DS->LockIndexBuffer

followed by various parenthesis data, such as:

(Indices, 0, 0, (void**)&I, 0)

DS i assume meaning a command to DarkSun (the game engine Nexus uses, for those just learning) and LockIndexBuffer - i'm just shy of certain this means a cap on the size of a certain data table - there's several uses of this command with different sets of parenthesized values following.

If we can find a way to switch the correct buffer off (or better, set the size to accommodate more values) we could probably be able to add more hard-points to ships. I think the buffer allows/limits more memory addresses to the default amounts in this case. I tried to explain how that would roughly affect memory addresses in the game earlier, but in my haste, i botched it sounding like a know-it-all, I'll try to explain it again sometime soon.

in the meantime, i'm looking at some scripts i've found that could be useful for certain mod requests i've seen, one in particular:

%sChargeTime %G

I'm assuming this is used to set a specific amount of time before a device can be used rather than energy buildup, possibly how long it takes for a ship's hangar doors to open and similar effects?

Other things: I also was poking around the mod forums and found a request for a weapon charging effects, and how to implement weapon charge effects by interrupting weapon firing. naturally i can't find that thread now that i have an idea, so I'm just gonna put it here so i don't forget, I'll move it once i find that thread again:

I don't think you actually want to halt the charging process of weapons for an animation (charge glow, etc) a more elementary solution i should think would be to trigger the effect whenever the device exceeds a pre determined level of Energy is charged instead.

I think the value you'd want is simply called 'reserve' an object value i've only seen mentioned while searching the exe. EnergyIn seems just a preset level of the reserve value that triggers said weapon (or even other effects probably)

try setting a script (i'm guessing in subroutines, but wherever it works) that when your weapon reaches reserve value (that would have to be under the EnergyIn value to work properly) it will begin to display , like a glow at the beam point of origin, until reserve goes below reserve.

Offline Arparso

  • Administrator
  • Lieutenant
  • *****
  • Posts: 558
  • Karma: 14
  • I can see you...
    • View Profile
    • http://arparso.de/nexus
(No subject)
« Reply #14 on: April 09, 2010, 12:48:36 »
Quote
DS->LockIndexBuffer

followed by various parenthesis data, such as:

(Indices, 0, 0, (void**)&I, 0)
Can't really comment on most of the other stuff (not much free time right now), but just wanted to mention something:

LockIndexBuffer most likely refers to a Direct3D call and has nothing do with weapon hardpoints. An IndexBuffer is a list of indices pointing into a VertexBuffer holding the 3d mesh information. It is used to tell the the graphics card how to connect all the vertices, that make up the 3d model. Usually three consecutive indices make up a triangle, so IndexBuffer entries of {2, 3, 0} inform the graphics hardware, that vertices 2, 3 and 0 in the VertexBuffer together form a triangle.

Concluding that, locking the index buffer is a purely graphics related call to Direct3D and should have nothing to do with weapon hardpoints or gameplay at all.

Offline Hyperion5

  • Recruit
  • *
  • Posts: 14
  • Karma: 0
    • View Profile
(No subject)
« Reply #15 on: April 09, 2010, 21:05:37 »
Quote
LockIndexBuffer most likely refers to a Direct3D call and has nothing do with weapon hardpoints. An IndexBuffer is a list of indices pointing into a VertexBuffer holding the 3d mesh information. It is used to tell the the graphics card how to connect all the vertices, that make up the 3d model. Usually three consecutive indices make up a triangle, so IndexBuffer entries of {2, 3, 0} inform the graphics hardware, that vertices 2, 3 and 0 in the VertexBuffer together form a triangle.

Concluding that, locking the index buffer is a purely graphics related call to Direct3D and should have nothing to do with weapon hardpoints or gameplay at all.

True of course, and I'm in agreement for the most part, but as i said, this parenthesized information is one of several variants i see following that script, they may all affect D3D, but i'm just trying to be certain that's true for all of them before i write them all off as that.

Also, there's several different areas that mention similar terms, i'm fairly sure that this or one of the similar scripts i see may affect the maximum ship slots, exactly which I've yet to be certain. Has anyone else been able to read some of the stuff I've been looking at? Notepad++ or any other program for that matter, since this is mostly done on free time for me, and i have difficulty with some parts still.

heh, forgot to quote, srry Arparso (I need to quad proofread or something) fixed now.

Offline EmeraldReporter

  • Specialist
  • *
  • Posts: 50
  • Karma: 0
    • View Profile
    • My Wordpress Blog
Re: The ExecList?
« Reply #16 on: August 31, 2011, 04:51:36 »
.
Producer & Scriptwriter / N:TJI Community Podcast