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
 
(15 intermediate revisions by the same user not shown)
Line 1: Line 1:
== What I am working on... ==
== What I am working on...Actually it is DONE!!! ==
Developing a mod to tweak weapons.  Yes, vague, but purposely vague.
=== Current feature being working on: ===
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.


== Things I would like to see in OBSE 19 ==
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.
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.
 
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);
[[User:Demolishun|Demolishun]] 16:32, 14 June 2012 (EDT)
 
 
=== Wild ideas: ===
Implementing logic outside the engine using Python.  This is done too!
 
=== 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 address.
* It will NOT have any kind of security features.
* I do not recommend allowing external machines 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.

Latest revision as of 00:02, 16 April 2013

What I am working on...Actually it is DONE!!![edit | edit source]

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:[edit | edit source]

Implementing logic outside the engine using Python. This is done too!

Current feature being worked on:[edit | edit source]

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 address.
  • It will NOT have any kind of security features.
  • I do not recommend allowing external machines 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[edit | edit source]

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

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