Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
gggmork

text-file-only script

Recommended Posts

I'm trying to make text file code you can drag/drop into zdoom, like one of these files I guess:
http://cutstuff.net/blog/?page_id=1658

Those are '.wad' but you can open with notepad to see they're code-only that just gets added to the iwad or something.

I tried typing code in notepad, then saving as wad instead of txt, but drag/dropping that into zdoom didn't seem to do anything, even if I copy their code into my own text file then rename as wad. Maybe I have to compile it or something (but I don't currently have doombuilder), or am clueless in some other lame way.

Share this post


Link to post

What's the file's name? A text file named DECORATE.WAD will be interpreted as a DECORATE lump; a text file named MAPINFO.WAD will be interpreted as a MAPINFO lump, and so on.

Share this post


Link to post

I download XinvasionX.wad. I can drop this into zdoom and it works fine. (even though that's apparently not called 'decorate' or 'mapinfo' etc).

So as a test, I just copy all the text inside XinvasionX, and paste it into my own new text file (which I named decorate.wad this time). Now even though decorate.wad seems like it should be the same as XinvastionX (same text code pasted/saved in it), when I drag/drop decorate.wad into zdoom it says:

Execution could not continue.
Failed to allocate -1 bytes from process heap

Which is just computers giving me their usual bullshit because they hate me.
I also tried a test hello world. I typed this in a new txt file:

#include "zcommon.acs"
script 1 ENTER {

print(s:"Hello World!");
} 
then I renamed it decorate.wad. Dropping it in zdoom just said:
Execution could not continue.
Could not find script lump 'zcommon.acs'

But xInvasionX.wad has that same #include "zcommon.acs" line in it, and it works.


edit: (ignore that edit, still get the error if I paste into my own text file)

Share this post


Link to post

#include "zcommon.acs"
script 1 ENTER {

print(s:"Hello World!");
} 
This is an ACS script. You have to compile it with ACC to make it usable.

It will work with any map, if you modify the script to be used as a library.
#library "hello" // this defines the script as a library named hello
#include "zcommon.acs"

script 1 ENTER
{
    print(s:"Hello World!");
} 
Then you should copile it with ACC and name the compiled script lump HELLO. You must put this lump between A_START and A_END markers.

Then you could use the LOADACS lump. You call the library named hello like this:
hello // The library name specified in the script.
Example wad: Download

Share this post


Link to post

I think I get it now, thanks. I just assumed people that made the scripts in the link in the first post just wrote stuff in notepad and it just basically worked like that (but what do I know). So I guess they had to fiddle with xwe and stuff too to put their script in a wad instead of just renaming .txt to .wad lol.
I made the .o file correctly I think, and that wad you made said 'hello world' correctly. I guess I'll hassle with xwe tomorrow since I guess that's a necessary step to put it between the A_START and A_END markers.

Share this post


Link to post
gggmork said:

I think I get it now, thanks. I just assumed people that made the scripts in the link in the first post just wrote stuff in notepad and it just basically worked like that (but what do I know).

It works for everything but ACS. DECORATE, TEXTURES, ANIMDEFS, MAPINFO, TERRAIN... All these lumps and more are text lumps.

Share this post


Link to post

My guess is acs is better than decorate/etc as far as having control/power to do whatever you want? Interesting that decorate can just be a txt file renamed to wad.

Share this post


Link to post

They do different things, really. Depends what you want to do. Altering how a level behaves? ACS. Altering how an object, independently of levels, behave? DECORATE. There aren't that many domains in which you could use either to achieve the same result.

Share this post


Link to post

I've been trying simple decorate experiments, like making the player smaller, which I did like this using notepad in case anyone's interested (using the zdoom wiki to figure out how):

make a text file called decorate.wad with code like this:

ACTOR DoomPlayer2 : doomplayer replaces doomplayer
{
 height 8
 player.viewheight 8
 player.damagescreencolor "purple"
 player.forwardmove .2
 player.sidemove .2
}
make a 2nd text file called keyconf.wad with this code:
clearplayerclasses
addplayerclass doomplayer2
Then drag/drop both of those text 'wads' into zdoom simultaneously.

The player still bobs up and down as if he was normal size though and according to this 2008 thread:
http://forum.zdoom.org/viewtopic.php?f=18&t=17716&start=15
I guess you can't control movebob or whatever with decorate to reduce the bobbing, but can only edit your own zdoom cfg console variable.

I made a a purple low mass cyberdemon (title it decorate.wad too; you don't need any keyconf.wad for this one, then just idclev to a level w/ a cyberdemon):
actor Cyberdemon2 : cyberdemon replaces cyberdemon
{
 spawnid 114
 renderstyle "stencil"
 stencilcolor "purple"
 mass 10
}
I wonder if decorate could do something like make the player gradually grow or shrink over time instead of being one static size, or make the cyber demon only get 'stencil' rendered when it gets hit (normal rendered the rest of the time) and have the color gradually change from light purple to dark purple based on how much life it has left (maybe not a great idea but more an experiment to learn how to control stuff). I kinda doubt decorate can do more intricate things like that but acs might.

Share this post


Link to post
gggmork said:

I wonder if decorate could do something like make the player gradually grow or shrink over time instead of being one static size

No, collision property (height and radius) cannot be changed dynamically (except through morphing). The developers never wanted to deal with the issues arising with actors suddenly becoming too big to stand in their sector.

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×