Messages

This is extended answer to:
http://ludeon.com/forums/index.php?topic=5610.0

My original answer was ignored:

You must extend thing def in your code with fields you like and define your thing def, not basic type.

for no good reason.

1) If you want to have arbitrary define type, you MUST extend Def.
Classes not extending Def are ignored by database assembler.
Extending ThingDef or any other "second level" defs require to use "Class" modifier, or base type constructor will be used.

2) You dont need to nest your type inside "ThingDefs" - you must define separate category, format is type name + s.
(note, ALL CAPS names will fail)
In other case database assembler will fail to find your def.

In case of "Class" modifier - def must be hosted in "base" folder, if Class points to type not accessable due to any reason - default type will be used, any additional fields will be ignored

Test type:

Code Select Expand


    [EventListener("instance", "entry")]
    public class typez : Def
    {
        public string testvalue = "NOT DEFINED";
        public static typez instance;

        public typez()
        {
            instance = this;
        }

        public static void entry()
        {
        }

        [EventHandler(EventPriorityEnum.LOW)]
        public void testa(GameStartedEvent e)
        {
            Log.Warning(testvalue);
        }

    }

do require Rimgazer API to work.

Def folder will be Defs\typezs\arbitraryname.xml

3) XML def follow same rules as folders do:

Code Select Expand


<?xml version="1.0" encoding="utf-8" ?>
<typezs>
<typez>
<testvalue>REPLACED BY DEFINE</testvalue>
</typez>
</typezs>


Running such mod will show "REPLACED BY DEFINE" on game start.

In order to test code without running game and without usage of API - static initializer may be used.
It will be invoked early (or not invoked if something is wrong).

30 Pawns ever with separate AI each wont choke game.
Limit wont be hard coded, player will be able to alter it from XML files.

And this limit is for storyteller only, it wont spawn any more pawns and will actively try to get rid of existing ones in order to continue story.
It may mark raiders for "one shot kill" or just tell them to leave or spawn other pawns (ever over the limit), this is not hard value - this is recommendation about how game should flow.
Just like current "population" value.

Performance events also possible, if system noticed FPS drop, it may perform actions, measuring FPS is trivial task.
Probably most logical will be to spawn as many pawns as PC can handle without FPS dropping below 40.

Player actions not affected, if you call for help - help will arrive and will spawn over limit, slaves also will spawn if purchased.

But if pawn limit reached by pirate raid, no new pirate raid will start ever if planned, because such event may not decrease amount of pawns on field.
Mechanoids (and other enemy of pirates) still may spawn.

All performance issues i noticed was caused by large amount of pawns (by path find requests that pawns generate to be precise), not large amount of pawn groups.

Anyway everything subject to change, if live ( i have large amount of code on paper )  implementation will cause lags (or other issues) - it will be changed.
If "brainless" pawns wont cause lags ever when spawned in large groups - such events will also happen.

@macrosblackd
Probably i missing something, checked google by "c# proxy" keywords and found no usable code.
Please provide sample or link.

@mrofa
Random lightning bolts that "for undefined reasons" roasted all survived riders after event timer ended or "brainwashed riders that feel no fear or pain".

Storyteller will have full control over events (event system will be used "inside" API via event handler code), if rider mental condition changed to "wandering" - storyteller may simply kill such rider or cancel such change.

I will post implementation of storyteller on sunday.

I already have on paper WIP"Urist McPunisher" storyteller implementation - with full support of all events related to storyteller or incident maker.
By default it will replace implementation of all 3 default storytellers with itself and apply rules that will make him act just like default ones, but with event support.

If specifically selected - custom rules will apply:
System grant to storyteller "currency" based on player actions and stats, unlike current implementation, this value not bound to time or wealth directly.

Doing *bad* things like killing baby boomrats, executing or selling people (or exceeding population limit) will grant storyteller flat bonus, like 1000 points for execution.
All storyteller stats will be *public*, each day going to be marked in history with amount of points accumulated\spared and reasons of point's gain.
Also com console will feature option to "view spoilers" with same data displayed at real time.

Having empty graves attracts *visitors*, unlike events that grant bonus single time and fixed value empty graves gives points every day and additionally multiply other bonuses earned.
So if player want some challenge - he may simply dig large amount of graves, game will provide opportunity to fill them up.
Or capture large amount of prisoners and execute them all at once (probably will cause game over, ever if player very well prepared, executing prisoners is "i want fun" button).

Based on accumulated points and stats storyteller may enter constant siege mod and throw endless small waves of attackers (zombie siege anyone), eventually driving colony mad or just killing everyone.

Or start throwing composite events like sun flare + raid + siege + AI core + animal insanity AT ONCE.
Also it may throw siege 4 times at different corners of map or perform similar actions.

If large amount of points accumulated it may throw every single event at same time, and repeat this every day, but never will spawn 100 pirates on top of your base and never will spawn 20 centipedes from AI core.
If large amount of events are thrown, like siege and raid at same time, they all will be very small, like ~5 pawns and single mortar or single centipede.

No matter how many points accumulated, no more then 30 hostile pawns will appear on field.
If limit is hit - all other events that spawn pawns will be suspended.

Traders and positive events follow same rules, if player executed lots of prisoners - all traders will leave and no positive events will happen as long as large amount of points still accumulated.

Pants are "Buildings" actually, support for building and energy grid is planned.
Tiles, roofs and filth belong to map, support also planned.

very nice, i missed 90x contra style emp grenade sprite.

I will include all required files with setup instruction to git hub and provide task list 23.08.2014.
Currently i have no time to ever open work space.

Currently i am working on API itself ( transaction based event handling and general re factoring to ensure stable work of internals ), currently added events implemented in order to test system and are placeholders.

Planned features, anyone welcomed to help with anything listed:

1) General re factoring in order to place methods to valid types, currently methods are static and placed to random type without any logic.
This will be fixed, everything will be not static and will be placed inside proper type.
Number of types at play will be halved.
Listener type removed completely, handler apply both to methods and types now.

2) Transaction based event handling, not really needed will be used to hone coding skills, actually useful only for debugging, to see what handler did what changed to event.
Will be disabled by default.

3) Custom log with watchdog and exception tracker - mods that trigger exceptions inside handlers or consume too much time to process will be removed from handling list.
All data related to API will be placed into separate roaming log file.
This required for more efficient debugging and overall stability.
Also it will have embedded profiling.
Handlers that managed to block main thread will be instantly removed from list instead of crashing entire game.

4) Def database injection framework.
With re instrumentation config and re instrumentation handlers.
Will work over standard XML defs just like everything else.
Basic setup is sourcedef targetdef and conditionslist.
later will be updated with option to replace base types.

4) Save file IO framework - read and write arbitrary data to save files in order to support custom states of objects.
Also required for runtime defs to work after loading saved game.

As for coding ~70% of events will be around pawns, since all other objects not really interactive and there is nothing to do with them.

Moved randomly - event.
Received order from player - event.
Received order from blueprint - event.
Finished job - event.
Started job - event.
Learn skill (including decay) - event.
Received mood - event.
Lost mood - event.
Mood changed - event.
Damage received - event.
Wound received - event.
Wound healed - event.

I will suggest to pick Pawn class and add event injections placeholders to all possible places.
Due to c# rules all injections must be tested - not every method is virtual and under some conditions ever if method is virtual - base method will invoked and injection wont have any effect.

Also under some conditions methods not invoked at all and must be invoked from other method that invoked from other method (that is not virtual and must be reimplemented and invoked from other method), random color for projectiles costed me 2 hours of debugging due to this.

project file included



[attachment deleted by admin: too old]

You must extend thing def in your code with fields you like and define your thing def, not basic type.

Game load XML in very simple manner, it construct type and set fields of that type to values stored in XML.
If type does not have field - nothing happens.

you are free to assemble such mod self.

Unity layer coding is not hard, pawn type have most fields public and you dont ever need reflection to change stuff.

in this case you will need to force users to replace basefiles of game.

XML is very very limited.

at same time DLL allows to do virtually anything.

dont strip bodies you dont want.

this is soo damn simple.

be warned, classes are decompiled with errors that must be manually fixed afterward.

in case of entire source, it will be huge deal to force users to download mod running from separate exe, and you will need to provide executable for each platform.

micro please.

rightbutton
attack in melee

There is only one tip for modding, and games in general - more does not mean better.

It may be fun to add 100 weapons to your mod, may be fun to add 200, especially if all guns have only difference in single number - damage and everything else is 100% same.
(player will ignore low damage guns and rush to top)

Everything added must be somewhat unique and everything must have some kind of use.

If you added 10 pistols, they all should be special in one way or another.
In other case there is no reason to add 10 pistols.

If your weapons consume ammo, there is absolutely no reason to make unique ammo for every gun.
Energy guns consume energy cells.
Other guns consume unified "bullets".
Larger caliber guns consume more cells\bullets.

In case of "cosmetics" reason, it a lot better to allow player to change "sprite" of armor or weapon by recipes, crafting or other reasons instead of making 100500 guns one for each sprite.

Over complication always bad, it does not make game deeper, it make it slow and tedious.

There are 3 "separate" projects inside provided solution:

Rimgazer API - implements all stuff related to API, does not alter gameflow in any way by it's own.
Defs required for mod to run not yet embedded into project, this is subject to change in upcoming updates.
Basically injections will be performed runtime without any "XML" present in folder.
Rimgazer will feature it's own def re instrumentation API that will allow to process def database and alter it.

Re instrumentation configuration will be "plain text" (actually JSON or XML not yet decided) file placed in same folder as assembly.

If some mod have custom implementation of projectiles (or Pawns or anything else defined by XML) that do support events (or just want to alter flow of things without), it may feature re instrumentation configuration.
That configuration may ship without any defs or assembly.

When native re instrumentation is implemented, system will allow to push custom implementations of native types, in this case it will ask for strict version specific signed type.

It will allow you to write scripts that will replace def "a" content if content equals "b" to "c" at runtime.
This may be used to replace bullet class of all weapons added by specific mod.
In case of native level - replace bullet type itself, this will affect any other type that may extend bullet.

If you want to write your own mod that do handle events - everything you need is rimgazer.dll as reference.
Add it just like unity or rimworld reference and it will work.

If you want to play with rimgazer implementation - you will need all files.

ConsoleApplication1 used to run code from workspace without runing RimWorld.
Testgazer is testing implementation to run code from RimWorld.

You also need native that not yet included, natives will be used to replace type definitions at native level.

Sample specially crafted for this case:
https://github.com/RawCode/Rimgazer/blob/master/Testgazer/Testgazer.cs

1) Current implementation support limited amount of events, more events will be added over time.

2) Class structure subject to major re factoring.

3) When you want to implement something, like preventing skill decay, friendly fire or severe wounds (that permanently cripple colonists).
Or anything else you need to:

a) navigate to https://github.com/RawCode/Rimgazer/tree/master/Event/
b) check subfolders that store event classes (folder structure subject to change)
c) read currently absent comments about when event is triggered and host type of event
d) probably you wont found event you want, in this case you can post request or provide implementation of that event and post pull request

4) If you found event, lets say, you want to spawn lightning at random part of map every 10th tick.
This belong to: https://github.com/RawCode/Rimgazer/blob/master/Event/Game/GameTickEvent.cs

5) You create separate type (class), it should be "public %Name% : extends anything you want this does not actually matters".
Add annotation "EventListenerAttribute" to that class.

Code Select Expand


    [EventListener("instance", "entry")]
    class SampleOne
{}


6) System expected to save state and work in multiple threads, this will severely change annotation and rules later.
Currently only single thing is done - event methods hosted on instance of eventlistener.

7) You can have any constructor for your type, but must wrap that constructor by static public void() method.
Name is that method is second param of annotation

Code Select Expand


        public static void entry()
        {
            instance = new SampleOne(any params you want);
            Log.Warning("Event listener demo is initialized");
        }


instance field is expected to store instance of listener, this is placeholder and will be removed later.

9) event handlers added by public void method that take desired event as only param with event handler annotation.

Code Select Expand


[EventHandler(EventPriorityEnum.FINAL)]
public void testa(GameTickEvent e)


10) If you done everything right - your "testa" method will be invoked every tick in game after all other handlers and have final word on event outcome.

11) Event priority system is WIP, later it will allow full control of event outcome with list of transaction passed around.

Lets say, handler with priority ENTRY set damage to 100, second handler with priority LOW see both original event and list of all transitions, it may cancel transaction done by lower level event or add his own (it may change damage type or any other param).

FINAL is special in invoked two times.

FINAL
ENTRY
LOW
DEFAULT
HIGH
FINAL

When FINAL invoked first time, it may suppress event completely or disable suppression feature but not allowed to see\change event data or transaction list. Also transactions may be disabled (or enabled) some events like "every tick" have it disabled by default.

When ENTRY invoked first time, it can see list of transactions (empty) done by every registered handler, it may exclude handlers from play for specific event instance or change invocation order.
This level wont invoke if transactions are disabled by FINAL or event is suppressed.

When FINAL invoked second time, it may perform final changes to transaction list.

LOW DEFAULT HIGH events do not see "upcoming" transactions and not allowed to suppress event.