Difference between revisions of "User:Demolishun"

From the Oblivion ConstructionSet Wiki
Jump to navigation Jump to search
imported>Demolishun
(New page: == What I am working on... == Developing a mod to tweak weapons. Yes, vague, but purposely vague. === Current feature being working on: === Equip and unequip modification of the weapon. ...)
 
imported>Demolishun
Line 2: Line 2:
Developing a mod to tweak weapons.  Yes, vague, but purposely vague.
Developing a mod to tweak weapons.  Yes, vague, but purposely vague.
=== Current feature being working on: ===
=== Current feature being working on: ===
Wow, learned a lot about Pluggy and what can and can't be done.  I also learned something about what can and can't be done is OBSE.  One thing that threw me was you can't convert a Pluggy string to an OBSE string in the 125 version of Pluggy.  To get around this I used StringSetName from Pluggy to set the name on an object.  Then I used GetName to turn it into an OBSE string.  This allows me to get a string with a maximum length of 255 characters out of an INI file.  Good enough for what I need.
The main feature currently being worked on is running a 'script' of sorts from a setting in a Pluggy INI file.  What I am planning on now is creating a stack processor.  This will allow me to create finite stack commands stored in the INI file to manipulate a value.  Here is an example:
<pre>
; in OBSE:
let attackValue += baseAttack + (weaponHits/1000)
</pre>
Okay, that code makes some assumptions like variables being there and stuff.  I can store that string in the INI file, but I cannot execute it.  So to do that I create a stack:
<pre>
; stored in INI file
script0="get#weaponHits"
script1="/#1000"
script2="+#baseAttack"
script2="+=#attackValue"
</pre>
Now the code to parse that and generate an output will take some work.  It will be stored in an array.  The array will be parsed at the appropriate place in the mod script and applied to values stored in StringMaps.  Not as quick as script, but doable to have simple code embedded in an INI file.  The main goal is extensibility and uniformity of implementing features in the mod.  It forces everything to be organized and consistent leading to better more extensible code.  At least that is what I tell myself when getting the brain damage to implement this.
=== Past features: ===
Equip and unequip modification of the weapon.  Drop the weapon and it looks normal.  Pick it up and it is "tweaked".  For this to work the weapon has a script attached to it.  I also developed a spell that will add this script to any weapon.  I was inspired by the OBSE AddScript command, but followed the directions to use a base weapon with the script already, make a clone, and copy the attributes of the weapon to be copied.  So no actual usage of the AddScript command.  OBSE 18 has been instrumental for the features needed to accomplish this.  My favorite feature of this equip/unequip tweak is the 'stack' I implemented to allow detection of what was previously equipped.  I will be creating an article on this later.
Equip and unequip modification of the weapon.  Drop the weapon and it looks normal.  Pick it up and it is "tweaked".  For this to work the weapon has a script attached to it.  I also developed a spell that will add this script to any weapon.  I was inspired by the OBSE AddScript command, but followed the directions to use a base weapon with the script already, make a clone, and copy the attributes of the weapon to be copied.  So no actual usage of the AddScript command.  OBSE 18 has been instrumental for the features needed to accomplish this.  My favorite feature of this equip/unequip tweak is the 'stack' I implemented to allow detection of what was previously equipped.  I will be creating an article on this later.
=== Past features: ===
 
Mostly just learning to script in Oblivion and lamenting that the language is not: C, C++, Perl, Python, Basic, etc.  Really, I am over it, but still.
Mostly just learning to script in Oblivion and lamenting that the language is not: C, C++, Perl, Python, Basic, etc.  Really, I am over it, but still.


== Things I would like to see in OBSE 19 ==
== Things I would like to see in OBSE 19 ==
The ability to run an external command line application like you can when you run 'cmd' in the 'Run' command under Windows.  The ability to parse what is returned could be excellent for interfacing to a huge amount of external tools.  For instance, sqlite, which is a file based database that can be run from the command line.  The interface would be simple: command to run plus args, return whatever the tool sent to stdin in a string_var.
The ability to run an external command line application like you can when you run 'cmd' in the 'Run' command under Windows.  The ability to parse what is returned could be excellent for interfacing to a huge amount of external tools.  For instance, sqlite, which is a file based database that can be run from the command line.  The interface would be simple: command to run plus args, return whatever the tool sent to stdin in a string_var.

Revision as of 02:16, 3 May 2010

What I am working on...

Developing a mod to tweak weapons. Yes, vague, but purposely vague.

Current feature being working on:

Wow, learned a lot about Pluggy and what can and can't be done. I also learned something about what can and can't be done is OBSE. One thing that threw me was you can't convert a Pluggy string to an OBSE string in the 125 version of Pluggy. To get around this I used StringSetName from Pluggy to set the name on an object. Then I used GetName to turn it into an OBSE string. This allows me to get a string with a maximum length of 255 characters out of an INI file. Good enough for what I need.

The main feature currently being worked on is running a 'script' of sorts from a setting in a Pluggy INI file. What I am planning on now is creating a stack processor. This will allow me to create finite stack commands stored in the INI file to manipulate a value. Here is an example:

; in OBSE:
let attackValue += baseAttack + (weaponHits/1000)

Okay, that code makes some assumptions like variables being there and stuff. I can store that string in the INI file, but I cannot execute it. So to do that I create a stack:

; stored in INI file
script0="get#weaponHits"
script1="/#1000"
script2="+#baseAttack"
script2="+=#attackValue"

Now the code to parse that and generate an output will take some work. It will be stored in an array. The array will be parsed at the appropriate place in the mod script and applied to values stored in StringMaps. Not as quick as script, but doable to have simple code embedded in an INI file. The main goal is extensibility and uniformity of implementing features in the mod. It forces everything to be organized and consistent leading to better more extensible code. At least that is what I tell myself when getting the brain damage to implement this.

Past features:

Equip and unequip modification of the weapon. Drop the weapon and it looks normal. Pick it up and it is "tweaked". For this to work the weapon has a script attached to it. I also developed a spell that will add this script to any weapon. I was inspired by the OBSE AddScript command, but followed the directions to use a base weapon with the script already, make a clone, and copy the attributes of the weapon to be copied. So no actual usage of the AddScript command. OBSE 18 has been instrumental for the features needed to accomplish this. My favorite feature of this equip/unequip tweak is the 'stack' I implemented to allow detection of what was previously equipped. I will be creating an article on this later.

Mostly just learning to script in Oblivion and lamenting that the language is not: C, C++, Perl, Python, Basic, etc. Really, I am over it, but still.

Things I would like to see in OBSE 19

The ability to run an external command line application like you can when you run 'cmd' in the 'Run' command under Windows. The ability to parse what is returned could be excellent for interfacing to a huge amount of external tools. For instance, sqlite, which is a file based database that can be run from the command line. The interface would be simple: command to run plus args, return whatever the tool sent to stdin in a string_var.