Difference between revisions of "User:Demolishun"

From the Oblivion ConstructionSet Wiki
Jump to navigation Jump to search
imported>Demolishun
imported>Demolishun
Line 15: Line 15:


=== Wild ideas: ===
=== Wild ideas: ===
==== May 9th 2010 ====
Implementing logic outside the engine using Python.
Ooh! Had a wild idea.  Make a mod that allows you to vandalize things in the game.  Paint, smashing things, etc.  Can anyone say, "Life of Brian"?  Of course it would be better if you could recruit some rowdy teenagers to do the dirty work.


=== Current feature being worked on: ===
=== Current feature being worked on: ===
==== June 14th 2012 ====
Plugin for OBSE to realize the stuff I want to do.
Finally getting around to developing a plugin for external communication to Oblivion.  It will allow access to any resources of the computer.  It will definitely add more capabilities for tweaking the game from within and outside the game.
* Plugin for network access.
* Use plugin to attach to external resources through Python.
* Ability to store objects and restore them, or even create new objects.
* Potential for a master server run by groups of individuals to do actual pen and paper role play through the engine.  Note: I am NOT going to write this.  I am going to provides the tools so someone else can.
* Pull data off of websites to affect content in the game.
* Use a database to store relational data that can be persistent between games/characters.  You could potentially use it to meet up with your other character somewhere in the game world.  This could also be used to add persistent gameworld features.
* Create plugins that store items that you can access by other players.
* Control the game externally.


==== May 29th 2010 ====
Let me be clear on the scope of the plugin.
Okay, I implemented the parser because it was not that bad. I made decision to not pre-compile the functions, but I may need to gain speed.  Right now the parser interprets each string every time an expression is evaluated. This may cause slow downs later. I also made it so the parser only runs once every 5 seconds. That should reduce the load quite a bit. I have tried to make things event based as much as possible, but the parser really needs to be run to catch things the events can't.
* It will provide access to the local machine by providing a UDP port on the 127.0.0.1 port.
 
* It will NOT have any kind of security features.
Another feature was detecting a murder of an NPC.  The code I had written did not work properly.  Now I finally got it nailed down.  One issue is that a script on a weapon will not show the NPC in battle if the current strike killed the NPC.  If that happens then it looked like to the code the NPC had been attacked when it was not in battle.  This made it so I was getting murder increments when fighting bandits.  Although, it is possible to murder a bandit (for my code anyway) if they are attacked when not explicitly in battle.  This does not affect the game murder tally, but it does show a character trait of the main character.  I wanted to track the character's honor. I decided to go this route and if it bothers players I may add a switch to change the behavior to never be able to murder those from evil factions.
* I do not recommend allowing external programs to access the UDP port.  Firewall it off and only allow programs on the local machine to access the port.
 
* Use a program to access the port on the same machine that provides any services for getting data external to the machine.  This means use a program that is designed with security in mind and can handle possible external attacks to the machine.
==== May 8th 2010 ====
* Using this approach keeps the code in the plugin very simple and robust.  It will do whatever it does very well and nothing else.  Otherwise you end up never finishing and have a buggy implementation nobody can use.
I am making the decision to bag the parser and use variables to set features on specific effects.  I will document on how to add a new effect by creating a mod.  I will also show how to add the function call for the new feature into the original mod so that extensions can be made without messing with the original mod.  This gives us the full power of scripting and keeps me from doing a ton of work on a crappy parser.  For now I will store variables so the existing features can be tweaked.  I will also allow for storing variables for add on mods too.  This should satisfy anyone's need to expand while not making it unbearable to code.
* KISS is the approach I am taking: Keep It Simple Stupid.  Less is more.
 
Along with these changes I am making the decision to make this mod require Pluggy version 125.  This is because I am lazy, the plugin makes it so much better, and it satisfies a need to make persistence across game characters.  I really like the idea that some things in a new game will be influenced by past actions in a different life so to speak.  Expect weapons and NPCs to be affected.  Won't say how, but they will.
 
=== Past features: ===
==== May 1st 2010 ====
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.
 
==== April 24th 2010 ====
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"
script3="+=#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.
 
==== April 17th 2010 ====
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 21 ==
== Things I would like to see in OBSE 21 ==
Animation triggers that can be tied to events like Sound keys.
Animation triggers that can be tied to events like Sound keys.

Revision as of 01:23, 15 June 2012

What I am working on...

I am working on a plugin for OBSE. It will allow UDP communication between Oblivion and an external app. The plugin will allow for data to be converted to and from JSON messages that will convert to and from oblivion objects. It will also have the ability to launch an external app to connect to the engine and handle more advanced processes like databases, remote resources, and other tasks. The plugin will just be a transport. That will be the scope of the interface. This should allow modders to add significant functionality to the engine without extraneous features.

I am using the boost framework to get a reliable networking code base. I am also using a very mature JSON library to handle parsing of data both to and from the engine. I have just finished the parser and am testing it. I have simple UDP up and running in a thread and I can send and receive data to the engine.

Notes: In order to convert a FormID or RefID number I needed to build a TESForm and set the ID against it. So this is the code needed to do so if you have the ID: 

UInt32 tref;
g_serialization->ResolveRefID(tint,&tref);
TESForm *formref = LookupFormByID((UInt32)tref);

Demolishun 16:32, 14 June 2012 (EDT)


Wild ideas:

Implementing logic outside the engine using Python.

Current feature being worked on:

Plugin for OBSE to realize the stuff I want to do.

  • Plugin for network access.
  • Use plugin to attach to external resources through Python.
  • Ability to store objects and restore them, or even create new objects.
  • Potential for a master server run by groups of individuals to do actual pen and paper role play through the engine. Note: I am NOT going to write this. I am going to provides the tools so someone else can.
  • Pull data off of websites to affect content in the game.
  • Use a database to store relational data that can be persistent between games/characters. You could potentially use it to meet up with your other character somewhere in the game world. This could also be used to add persistent gameworld features.
  • Create plugins that store items that you can access by other players.
  • Control the game externally.

Let me be clear on the scope of the plugin.

  • It will provide access to the local machine by providing a UDP port on the 127.0.0.1 port.
  • It will NOT have any kind of security features.
  • I do not recommend allowing external programs to access the UDP port. Firewall it off and only allow programs on the local machine to access the port.
  • Use a program to access the port on the same machine that provides any services for getting data external to the machine. This means use a program that is designed with security in mind and can handle possible external attacks to the machine.
  • Using this approach keeps the code in the plugin very simple and robust. It will do whatever it does very well and nothing else. Otherwise you end up never finishing and have a buggy implementation nobody can use.
  • KISS is the approach I am taking: Keep It Simple Stupid. Less is more.

Things I would like to see in OBSE 21

Animation triggers that can be tied to events like Sound keys.

Retrieved from "https://cs.uesp.net/w/index.php?title=User:Demolishun&oldid=5315"