Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[madk]

Alright, I know how I can make this work now.

So I've got basic (untested) support for subgroups. But there are so many tags without subtags that there are multiple of (PREFSTRING,  ARMOR, etc.) that can't be handled in UristMod.

I came up with a perfect and beautifully simple solution:

addafter command.

It adds a given token after a specified existing token! Fabulous.

[Star Weaver]

Wow, sorry about my incoherence the other day, I wasn't paying much attention to what I was saying or something  .

The caste and position tags have another level of trickyness: what if I want to delete a position -- what should happen to all the tags it sorta-contains?

(The sorta-containment is a ripe source for confusion; say, in an ENTITY after POSITION:MCHAMMER, the tag DUTY_BOUND will apply to McHammer but something with no position relevance like WEAPON:WHIP will still fall through to affecting the ENTITY )

Perhaps something like this could be generally useful:

Code: [Select]

include ENTITY:MOUNTAIN
between POSITION:MAYOR and POSITION:.*
remove .*
scope all
remove POSITION:MAYOR

You could do the same scope limiting with before and after tags too, if you also made scoping move the 'insert position' ... This example would just neaten the order of the output file, but I could see "before first CASTE" or "after last USE_MATERIAL_TEMPLATE" being useful. Heck, "first" and "last" as prefixes to search patterns in general might be useful .

Code: [Select]

include OBJECT:ENTITY
select PREMITTED_REACTION:.*
after last PERMITTED_REACTION:.*
append PERMITTED_REACTION:MY_THING
append PERMITTED_REACTION:MY_OTHER_THING
select inverse
at top
append PERMITTED_REACTION:MY_THING
append PERMITTED_REACTION:MY_OTHER_THING
select *

Hm, let's see if I can find a way to use something close to your syntax to solve some other problems I've had...

This is to change the native metals and such to something that isn't considered both a stone and a metal in its unsmelted form. I had to do something I found unobvious in uristmod or it put the new template at the bottom, overwriting the specifics and making them all appear as blank-wall "METAL" in the game.

Code: [Select]

include OBJECT:INORGANIC
select IS_STONE
select USE_MATERIAL_TEMPLATE:METAL
delete USE_MATERIAL_TEMPLATE:METAL
at top
append USE_MATERIAL_TEMPLATE:METALROCK
select *

This is to apply a tanmod variation to scaled creatures; you need to take 10-ish lines of body details which contain remove_materials and use_material_templates and replace it with two or three lines about variations, and they really need to be right where the original lines were. I couldn't even reliably delete everything required with uristmod.

Code: [Select]

include OBJECT:CREATURE
select USE_MATERIAL_TEMPLATE:SCALE:SCALE_TEMPLATE
between inclusive BODY_DETAIL_PLAN:STANDARD_MATERIALS and BODY_DETIAL_PLAN:VERTEBRATE_TISSUE_LAYERS:.*
remove .*
# Scope still active so tokens will be appended in place of the area that has been deleted
append APPLY_CUREATURE_VATIATION:SCALED
append APPLY_CURRENT_CREATURE_VARIATION
scope all
select *


This is my most pipe-dream example that uses as many crazy features as possible, to automatically achieve something I've done by hand:

Code: [Select]

include OBJECT:INORGANIC
select USE_MATERIAL_TEMPLATE:METAL
deselect IS_STONE #filter any unfixed native metals
duplicate INORGANIC:%ID%_FIBER # %ID% = name of found object
# From this point we're modifying the duplicate
remove ITEMS_*
append ITEMS_SOFT
append WAFERS
modify VALUE, {%ID%:VALUE} + 2 # Reference to token of other object, math?!
# tabs indicate template for create?
create REACTION:EXTRUDE_%ID%
    [NAME:extrude fiber from {%ID%:STATE_NAME_ADJ:ALL_SOLID} bars]
    [REAGENT:%ID%:NONE:NONE:NONE]
    [PRODUCT:100:15000:THREAD:NONE:%ID%_FIBER]
# this is not a proper reaction. i don't have access to one that works now ^_^
# i have no idea how this part would work prpoerly:
include secondary ENTITY:MOUNTAIN
after last PERMITTED_REACTION
append PERMITTED_REACTION:EXTRUDE_%ID%

I hope this post is less scatterbrained than the last one; I'm really just sort of working what (I think) you'd need to be able to do to achieve things.

[madk]

Whup, new post.
I think I have it covered now. The one thing is that I'll need to allow the scripter to remove chunks of tokens and not just individual ones. I do have a very good idea of how to accomplish this, though. (and it won't be too difficult) And suprisingly, I think that pipe-dream example is going to be pretty easy just once I add in the object handling commands (which I'm only putting off because they're just plain easy - a few lines of code.)

Your example scripts are exactly what I need to get my mind working on what needs to go in. I would certainly appreciate it if you make some more. My own example scripts are how I'm coming up with everything I have so far. XD

Expect an unstable release soon; I need to find out what else should be added.

Here's the gist of how it all works at the moment:


Selection is kinda complex, but it gets the job done spectacularly.


Basic selection

INCLUDE adds all objects in memory that meet the argument's requirement into memory.
EXCLUDE removes objects from the current selection which meet the condition, and
SELECT removes objects from the current selection which do not meet the condition.

The characters "*" and "#" are wildcards. # is any character (D#G would give you DIG, DOG, DUG, etc. for example) and * is any charater(s). (*FOX would give you FOX and SQUIRRELFOX.)

Token modification

APPEND adds a token to the end of an object. Be careful with its usage, as it could possibly cause an addition to apply only to the last caste defined.
REMOVE removes a tokens that have an exact match to what you typed. No wildcards here. (yet)
CHANGE allows you to modify the arguments of all the tokens in the selection with the same key name to what you specify.
ADDAFTER* adds a token immediately after all occurances of the specified token in your selection
ADDBEFORE* you get one guess.
ADDFIRST* puts it at the very top of the object data.
REPLACE* replaces all instances of one token (this including arguments) with another.

* = not yet implemented

Object handling

*none of these are implemented yet
CREATE creates an entirely new and blank object.
DELETE deletes all currently selected objects.
COPY creates a new object with the same contents as an existing one.
CHANGE would be used to change a PLANT to a CREATURE, for example.

Program flow

*none of these are fully implemented yet
EXISTS { (...) } only does this if there is at least one object in the current selection
!EXISTS {} only executes if there is nothing in the selection
SINGLE {} executes if there is a single object in the selection
!SINGLE {} executes if there is more than one object in the selection.
FUNCTION {} defines a function, the main purpose here is just readability.

Advanced selection

CONTAINER defines a "container".
SET defines a container's contents as everything currently selected.
The contents of containers can be included/excluded/selected just like other conditions. It's difficult to explain, but it makes your most intricate plans for selecting objects become reduced to a few simple lines of script.








So, what was the point of that? Here's the point: am I missing anything? And no, I have decided against caste/subgroup support. Every object type's subgroups work differently and there are so many different ones it's just impractical. Modders are going to have to make do with addafter, addbefore, and addfirst.









Oh, and here's an example I made for myself as a reference that shouldn't be too hard to understand.

Code: [Select]



container CONTAINER:SELECTION_DEFAULT

function FIX PET_EXOTIC {
  set CONTAINER:SELECTION_DEFAULT
  include CREATURE
  select PET_EXOTIC
  addafter PET_EXOTIC | PET
  remove PET_EXOTIC
  exclude *
  include CONTAINER:SELECTION_DEFAULT
}

function FIX MOUNT_EXOTIC {
  set CONTAINER:SELECTION_DEFAULT
  include CREATURE
  select MOUNT_EXOTIC
  replace MOUNT_EXOTIC | MOUNT
  exclude *
  include CONTAINER:SELECTION_DEFAULT
}

function NoExotic {
  set CONTAINER:SELECTION_DEFAULT
  FIX PET_EXOTIC
  FIX MOUNT_EXOTIC
  exclude *
  include CONTAINER:SELECTION_DEFAULT
}

function MAKE DEER YELLOW INSTEAD OF BROWN {
  set CONTAINER:SELECTION_DEFAULT
  include CREATURE:DEER
  single {
    replace COLOR:6:0:0 | COLOR 6:0:1
  }
  include CONTAINER:SELECTION_DEFAULT
}


NoExotic
MAKE DEER YELLOW INSTEAD OF BROWN


I need a select-only thing, that combines exclude * and include [X].

[Star Weaver]

Cool. I'll go over my current pile of uristmodded junk and see if I can find anything else that needs reproducing, proabably tomorrow when I have acces to it again.

[madk]

Humm... I think I need to rewrite a large portion of my code, it's getting messy, adding a lot of things that have to work independently from the foundation code, since I hadn't planned ahead for them.

And I leave for a trip in a few days.

Bah, I can do it, if I set my mind to it.


But I need your help planning. Is this all good for data handling?

Strings:
- # for wildcard charaters, * for any number of wildcard characters. I'd add the ability to make something like D*G in addition to the provided D#G example, that would also, in addition, do stuff like DOOG. (I can't think of a fitting word, sorry XD)
- I realized that I really need variables to handle keeping things coordinated. There'll be several commands to assign them to be an object's type, name, or the arguments of a given token. Then, to inject them into a string, you'd but %(variable name)%.
- Arithmatic is easy enough.

Chunks:
- can be an object from the raws or a chunk of strings. String chunks could be compared and handled just as strings could.

[bdog]

Wildcards are good but wouldn't regex be better?

Code: [Select]

Select D[UI]GWould select only DIG or DUG (no DOG)

Also if you're going to make functions make them so they could take arguments (at least one)

Code: [Select]

function SET_TO_VEINS ( stone ) {
  Include Inorganic
  Select [stone] # arguments in [] for to make things clear?
  Single { # to make sure theres exactly one stone...
    Select ENVIROMENT_SPEC:(.*)
    Each {
      reg_replace "ENVIROMENT_SPEC:(.*):(.*):(.*)" "ENVIROMENT_SPEC:\1:VEIN:\3"
    }
  }
}

SET_TO_VEINS( GYPSUM )
SET_TO_VEINS( JET )
SET_TO_VEINS( MAGNETITE )

# also function with result?
function GET_DROWDUR( plant ) {
  Include PLANT
  Select [plant]
  Select GROWDUR:(.*)
  return "\1"
  # or maybe
  # reg_return "GROWDUR:(.*)" "\1"
}

Include PLANT
Select PLANT:(.*)
Each {
  if ( GET_GROWDUR( \1 ) == 300 ) {  # if statement? why not ^^
    replace GROWDUR:300 | GROWDUR:600
  }
}
Just my 2 cents, anyway good idea keep up good work ^^

[madk]

huuuuuuargh

Trying to handle multi-line strings as variables is a nightmare.

Also, functions with arguments can be improvised using variables, and making a parser that recognizes user function arguments is not easy. No function arguments, I don't think. Sorry


Oh, and here's something I conjured up to give myself an idea of what I need to do with variables:

Code: [Select]



include OBJECT:INORGANIC
select TOKEN:USE_MATERIAL_TEMPLATE:METAL
export IS_STONE


/ it's nessecary to define variables before working with them.
/ avoid defining variables for the first time within loop structures like individual {} whevener possible.
define %rock_value%
define %rock_name%
define %react_chunk%

individual {  / handle each object in the selection individually, because trying to assign a
              / variable from all their contents will not produce the desired result.
  addafter.first ITEMS-SOFT | ITEMS_*   / pretty much everything has the .first, .last, and .all modifiers. These
  addafter.first WAFERS | ITEMS-SOFT    / would add [ITEMS-SOFT] and [WAFERS] after only the first instance of ITEMS_*.
  remove.first ITEMS_*
  replace ITEMS-SOFT | ITEMS_SOFT
  assign %rock_name% { INORGANIC:%rock_name% }        / this assigns the value of %rock_name% to be what goes in the blank.
  assign %rock_value% { TOKEN:VALUE:%rock_value% }    / again, makes the variable to be whatever is in that blank.
  define %react_chunk% {
    [NAME:extrude fiber from %rock_name% bars]
    [REAGENT:%rock_name%:NONE:NONE:NONE]
    [PRODUCT:100:15000:THREAD:NONE:%rock_name%_FIBER]
  }
  local {    / when you don't want to affect the selection, using a local block
             / completely separates whatever is going in terms of selection.
    create REACTION:EXTRUDE_%rock_name%
    append %react_chunk%
  }
}




[madk]

Yea, I'm going to have to stick to single-line strings. I'll figure something else out for what functionality I was wanting it for. Trying to handle a list of strings as one is akin to trying to pet X number of cats (It's never easy to know for sure, you must be blind or something) at once with just your two hands.

[madk]

Alright, I think I've finalized how math is going to work. It's bizarre, but it will be much easier to parse and much more flexible than your typical 2+2=4.

Here's what it looks like, hopefully it's fairly self-explanatory.

Code: [Select]

define %one% { 1 }
define %two% { 2 }
define %three% { [? %one% + %two% ] }
define %twelve% { [& %one% + %two% ] }
define %fifteen% { [? [? %one% + %two% ] + [& %one% + %two% ] ] }

define %was one but became ten% { %one% }
define %was one but became ten% { [& %was one but became ten% + 0 ] }

[? (...) ] performs arithmatic, [& (...) ] combines strings.
Not to worry, I'll be putting in / * - and maybe some trig and other math functions in there, too.

[SethCreiyd]

Posting so I can follow this very cool project.

[madk]

I need someone to answer this question for me, so I can know if I need to add support for floating point integers:

Is there even a single instance of a token in the raws having an argument that is a floating point integer?


And as soon as I've finished support for this arithmatic and some standard console io, I think I'll make a release just so I've got something to show.

[Normandy]

I've never seen a floating point number in the raws, but it might just be better to use floating point numbers as representations for both integers and floating point numbers. Many languages like scheme and lua do this; there are options elsewhere to make numbers integers by default, but for the most part this suffices.

The point is that a double-precision floating point number has greater accuracy than a 32-bit integer, but can do decimal operations as well. Things like chances in reactions don't use floats, but they would be a lot easier to deal with in floats, rounding to integers at the very last step.

[Star Weaver]

Brain barely working today.

? is traditional for what you're suggesting # for, but if ? is already being used # would do. Though yeah, if you've got a regex module in the language, use it instead of wildcards.

Wow, I already forgot my second point. 

[madk]

I apologize, but I'm not familiar with regex or anything.

@Normandy
I see your point. I'll do that, then.

[madk]

Well, the arithmatic will work with 64-bit floating point numbers now.

Also, I just need to verify I haven't got any outstanding bugs going on, then I'll have a release for you to play with.


EDIT: Outstanding bug encountered. Crap. Oh, and I forgot to wrap up nested operations. Aaahhhgk