Jump to content
The Dark Mod Forums

I want to learn scripting.


Recommended Posts

I understand boolean logic but have no (aka "zero") background in computer programming languages, and I don't have time left on this planet to learn the whole of c+++ or whatever so that I can introduce basic commands into scripts, most all of which are to do very elementary things. Fidcal's beginner's guide ends at page 2.

I can learn some things by example. e.g. grayman's cinematics tutorial taught me how to make a spline curve for a mover and I used it to create a firefly that only works because I copy/pasted

 

void fly_start()
{
$mover1.time(20);
$mover1.startSpline($spline1);
}
From Arcturus' grass demo.
Arcturus solved the problem of how to keep the flys buzzing by placing a trigger multiple over the entire space, with a wait time == to the mover time. I didn't want to do it that way, because I hate cluttering my map with huge brushes that I have to hide, then forget I hid them, then mess up some maybe copy/paste operation that required them to be visible.
But I can't find any info on how to create an argument that loops the function, perhaps until the player is a certain distance and then switches the scene off.
I've scrolled thru' an eternity of function descriptions, all of which require a certain knowledge about how to use them and so are useless to me.
I figured wtf and appended an order at the end of the above script, to activate the scriptfunction that calls fly_start. TDM hated that sent me a gamestopping "error: event overflow. Possible infinite loop in script" and I think, well yeah, so TDM understands that I'm calling for a looped action. TDM just doesn't like the way I'm doing it.

So where do I start learning this language? Not just for this instance, but there has to be an easier way for person to start learning how to script in TDM, for these extremely basic things, than just banging their head against the wall.
(eta: notice the circuitous way I went to learning how to make a firefly buzz. At all. First thru' a tutorial on cinematics, then a demo of animated grass. Believe me when I say that I spent a long time searching for those sources. Yet, the term "firefly" is often used in an offhand way, with dead end links.)
Edited by The Wheezing Geyser
  • Like 1
Link to comment
Share on other sites

Well, I fear you won't get past learning a great deal about C++, if you want to create scripts for your maps without any help. The (very few) scripts I have created myself, I could also achieve only with help here on the forum. In my experience, the more you try and discuss with other people, the more you learn; and this is most likely the only way without any tutorials. If you are willing to learn more basic stuff, Obsttorte gave me this link about the basics of scripting, that he used to learn scripting and coding.

http://www.willemer.de/informatik/cpp/

However, I myself have not had the endurance to work it through completely...

  • Like 1
Link to comment
Share on other sites

These pages might help a bit:

 

http://wiki.thedarkmod.com/index.php?title=Editing_FAQ_-_Troubleshooting_%26_How-To#Scripting

http://wiki.thedarkmod.com/index.php?title=Scripting_basics

http://wiki.thedarkmod.com/index.php?title=Script_objects

http://wiki.thedarkmod.com/index.php?title=My_first_map_script

 

You don't have to learn all of C++, but maybe just the first two or three chapters in a guidebook (there are free ones online) would be very helpful, just the really core stuff like what are objects and functions and variables, and how you do boolean logic checks and loops, which you do in practically every script.

 

But even without that, since it does use such a common language what you can do is just search the specific problem you have, and almost any C++ tutorial could give you the answer. I do that sometimes. So you can just search "C++ looping".

 

But to address your issue, scripts are objects that get called, act, and then either keep running the rest of the game in a loop, or they get killed at some point and then they're dead forever. What (it sounds like) you did was create a new script object inside another one (when you call a new script, it's now a new script running independent of the script that called it), which then itself called a new object, and so on in an infinite regress of creating new independent objects. You're just calling 10,000s of new objects whose job is to call another one.

 

The kind of loop I think you want is a "while (x)" loop. Just look it up for the syntax. Or here it is: http://www.cprogramming.com/tutorial/lesson3.html

 

In that loop, at the top is the while(x); clause, where X is some variable. As long as X is true, it will keep looping inside the {}'s, and when it's false, it skips over the {}s and continues with the text after the closing curly bracket. Then the next text can just kill the script or have it be another outside loop.

 

If you just put while(1) or while(TRUE), then it will loop forever, which may be fine if it's a lightweight script.

 

If you really want it to stop when the player is out of range, then you have to first decide, is a new script object going to be called every time you want it to start, and killed every time the player is out of range (in which case you'd have to call a new script to start it again). Or would it be easier to just have one script that starts either when the player enters the location (read the location_settings wiki page for how to call a script by entering a location) or at map start (just put it inside of main, which always starts at map start).

 

So then you can make X in the while loop some variable that tracks proximity of the player. You can take the player's XYZ location and the event's XYZ, and subtract the X, Y, & Z parts, get the absolute values, and do Pythagorean's formula to get the distance (or something like that; I'd look it up or draw it on paper to see what I'm doing). If it's less than the value than set your variable to TRUE, and if it's over that value set your variable to FALSE. But the way I'd do it is the script gets called when the player enters a location (the location_system). Then have a function that returns the name of the location the player is in, and then make a check that if it's equal to the location you want. If it is, it makes your x-variable TRUE, and when the player is outside the location, it's not equal and it sets the x to FALSE.

 

Then when the x is FALSE, the loop ends and it goes on with the instructions after the {}s. It can kill the script from there, which ends it forever, and you'd have to call a new one, e.g., on location entry. Or perhaps the easier thing to do is simply put a while loop inside another one. When the player proximity or in-location is TRUE, then the inner loop loops with all the instructions. And when it's FALSE, it skips over all that script text, and then just loops the outside loop, with just the one instruction for it to make a check for whether the player is in proximity.

Or, as I said earlier, you just have the one loop and put while(1) and it loops forever, but if it's only a few lines of instructions the processing load is so minimal that it won't slow anything down.

 

If you keep it looping when the player is outside the location, you need to make sure it can never be called again. Either put a check so location-entry only works once, so if a new one was created it kills itself immediately or the on-entry script is just some script or entity that calls a new script and it's set to one-shot, or something like that. Or you just put the script in main so it's called at game start and loop it forever from there.

  • Like 1

What do you see when you turn out the light? I can't tell you but I know that it's mine.

Link to comment
Share on other sites

You could look at my two maps for plenty of basic scripting, most of it commented. I was in the same situation as you as regards programming and worked my way up by example, first learning how to formulate and initiate an extremely simple script ('trigger this entity'), then gradually trying out new commands and setups as they can be found in other missions and this wiki.

  • Like 1
Link to comment
Share on other sites

As people have mentioned above, the scripting language for idTech4 is pretty similar to C++. However, it and C++ are also close to C#, which I think is an easier language to learn. If you don't mind spending time in another engine, Unity has C# support, plus a ton of video tutorials and a really well-documented set of functions for C#.

 

I mostly say this because the Dark Mod wiki articles are pretty threadbare, and it was easier for me to figure out how scripting for it was different from scripting from other languages. If you want to jump right into TDM scripts, though, I'd be willing to help you through what you specifically want to do, and I'm sure plenty of other people on this site would say the same.

  • Like 1
Link to comment
Share on other sites

Thanks for the quick responses. Exactly what I needed, I've a clear path to go forward now.

demagogue I followed your link to the cprogramming tutorial and installed codeblocks, so I'll follow your advice about learning those basics.

Dragofer I unpacked your missions and looked at the scripts. Quite complicated and covering a lot of ground! Unfortunately I then got diverted and now I'm looting the invernesse. hehe. Hard to find all that loot tho'. Open a chest and there's one lousy gold! Or an old boot!

  • Like 2
Link to comment
Share on other sites

As said before the best approach is to learn the basics of C++ programming. Many concepts are not present in TDM scripting, so you don't have to learn all of those. But the basics are really important.

 

Once you have a general idea of how programming in C++ works, you can use the above mentioned wiki articles to adopt to scripting. The rest is try and error :)

FM's: Builder Roads, Old Habits, Old Habits Rebuild

Mapping and Scripting: Apples and Peaches

Sculptris Models and Tutorials: Obsttortes Models

My wiki articles: Obstipedia

Texture Blending in DR: DR ASE Blend Exporter

Link to comment
Share on other sites

As said before the best approach is to learn the basics of C++ programming. Many concepts are not present in TDM scripting, so you don't have to learn all of those. But the basics are really important.

 

Once you have a general idea of how programming in C++ works, you can use the above mentioned wiki articles to adopt to scripting. The rest is try and error :)

 

Personally I recommend people to start with C instead of C++, imo C is much easier to learn, i also think functional programming is easier to grasp initially than OOP.

 

Btw idScript and in some parts the idtech4 engine itself, imo look more C like than C++ like, the engine is indeed written using C++ and OOP, but i just think that John Carmack was so used to the C ways that he still used it for many things.

 

For example this is how you print to screen:

 

in idScript:


float someNumber = 10;

string someString = "Hello World!!";

sys.println("I'm printing" + someString + "and the number" + someNumber); 

in C.


unsigned int someNumber = 10;

const char* someString = "Hello World!!";

printf("I'm printing %s and the number %d\n", someString, someNumber);

in c++ (if i'm recalling well)


unsigned int someNumber = 10;

const char* someString = "Hello World!!";

cout >> "I'm printing" >> someString >> "and the number" >> someNumber >> endl

in idtech 4 "c++"


unsigned int someNumber = 10;

idStr someString = "Hello World!!";

gameLocal.Printf("I'm printing %s and the number %d", someString, someNumber); 

Btw I don't claim i'm a good coder i started to seriously learn coding only about 6 months now, hardly any time to call my self a real programmer. I learned idtech 4 script before starting to learn c and now i'm learning idtech 4 c++ and i most say, idtech 4 scripting is much more simple, coding in the engine c++ is really not the same. Learning scripting will indeed help you gain a "programmers mind" but will not make you proficient in C or C++ or any other low level language.

 

For example this is what you normally do on idscript to call some function:


someEntity.callFunction("function_name"); 

This is what you do on the c++ side:

const function_t *func;
idThread *Thread;

func = Entity->scriptObject.GetFunction("signalOn");
Thread = new idThread();
Thread->CallFunction(Entity, func, true);
Thread->Start();
Thread->End();

Much more verbose and complex. Without help anyone good at idScript would do the C++ version. So imo learning one is not guaranty that you will immediately fully understand the other, but it certainly helps.

Link to comment
Share on other sites

They actually started writing the code in C and switched to C++ during development. But Carmack and the other programmers weren't that familiar with OOP back in the day, hence you get this strange mixture. It is still well written code imho.

 

In regards to scripting I don't see how beneficial it is to learn functional programming. I mean I am not familiar with it but scripting in idTech4 is based on OOP, so it makes sense to deal with that matter. And as said, only the basic concepts play a role here. You don't have to get into every aspect of OOP to be able to write scripts (like Polymorphism, operator overload etc...). Just the basics.

 

In the end it might be the best if we would have a scripting guide for beginners, I actually thought about writing one several times. But it is a time consuming task, so ... :(

FM's: Builder Roads, Old Habits, Old Habits Rebuild

Mapping and Scripting: Apples and Peaches

Sculptris Models and Tutorials: Obsttortes Models

My wiki articles: Obstipedia

Texture Blending in DR: DR ASE Blend Exporter

Link to comment
Share on other sites

I have the impression that scripting has something of an image problem: on one hand you have Obsttorte- or SteveL-grade compositions with multiple levels of nested functions, written with a background in C++. On the other hand you have the possibility of getting a lot done by stringing together a series of triggers, waits, fades, addItems in a script in combination with all the capabilities of the editor, including Stim/Response, objectives (both are basically graphical scripting interfaces), conversations and all those entities.

 

In that light I'd think it'd worth asking aspiring scripters whether they're aiming mainly to develop their coding or if their focus is on adding scripted events to their maps.

Link to comment
Share on other sites

On the other hand you have the possibility of getting a lot done by stringing together a series of triggers, waits, fades, addItems

The problem with this is that these setups are very error-prone, and if you have several instances of them in your mission and you want to change their behaviour, or add to it, you will probably miss something and will spend a lot of time trouble-shooting.

 

When I started mapping with DR I used triggers etc... too to get the desired effect. But I soon noticed that scripting is a way more handy approach and that it allows you to do things which are very hard if not even impossible to implement with the above mentioned entities.

 

 

I have the impression that scripting has something of an image problem

This is definetely true. People tend to thing of it as something overhelmingly difficult, that can only be understood by the few "involved". It is a bit similar to how people react to maths. However, learning how to write code does not neccessarely take you more time then learning how to use DR, an image manipulation program or anything else. You learn the basics very fast actually. Learning how to write good code is what takes a while. However, if you are mainly aiming to get things to work (even if only in a hacky and ugly way), you'll probably won't have to invest a whole lot of time. :) The rest is a matter of experience.

 

 

In that light I'd think it'd worth asking aspiring scripters whether they're aiming mainly to develop their coding or if their focus is on adding scripted events to their maps.

Good question. People who are mainly aiming on developing their coding are propably going the wrong direction if they start fiddling with scripts. They are much more limited and a lot of aspects that are important for programming don't play a role with them. If you want to get scripted events in your maps, or even if you are only aiming to alter some aspects a bit, scripting is definetely a worthwhile undertaking. Even if it means you have to learn something new (which isn't neccessarely a bad thing ;) ), it will pay out a lot.

 

If you take a look at the existing fms you will actually find quite a few things which were implemented via scripting, a few of them by my own. I mean, you could simply pick one of those and try to implement it without scripts, using triggers, S&R or whatever. You'll probably have a hard time :)

 

 

In the end it might be the best if we would have a scripting guide for beginners, I actually thought about writing one several times. But it is a time consuming task, so ... :(

It would be interesting to know how many members would be actually willingly to learn scripting. If there is a reasonable amount of them around here it might help my motivation :P

  • Like 2

FM's: Builder Roads, Old Habits, Old Habits Rebuild

Mapping and Scripting: Apples and Peaches

Sculptris Models and Tutorials: Obsttortes Models

My wiki articles: Obstipedia

Texture Blending in DR: DR ASE Blend Exporter

Link to comment
Share on other sites

When I started mapping with DR I used triggers etc... too to get the desired effect.

Oh, what I actually intended to say was to use a hybrid of scripts and in-editor possibilities. For example I made my glowing footsteps appear by attaching a stim to the player and letting the footsteps respond by calling a script that faded them in. If you used only scripting or only the editor that might've been more complex to setup. But the fact that you can choose the path of least resistance by combining all the options means it's quite straightforward to achieve diverse scripted effects in TDM, even with beginner's level scripting knowledge.

 

(And certainly, please no trigger_relay chains. Much better overview putting the same functions into a script.)

 

 

It would be interesting to know how many members would be actually willingly to learn scripting. If there is a reasonable amount of them around here it might help my motivation :P

I'd feel quite confident there's an extended audience for this. The problem with much of the scripting wiki is that it assumes existing knowledge (i.e. what is 'data type') which probably makes it difficult for a beginner to take enough away, and Fidcal's more pragmatic guide ends on page 2.

Link to comment
Share on other sites

I would certainly apply for that workshop... Ive been interested in learning scripts ever since my hexen days, I was always amazed by what people could do with them, without having to actually go deep into the game to change things. You could create new weapons, monsters, behaviours, control the environment... Endless possibilites. But I never got around to it. I never really found any resource where I could learn it in a "fun" way. Math was never my forté, so you can see why a bland wall of text telling me what the raw mechanics of a scripting language is was not something that was inviting or effective, really. I guess what Im trying to say is that I feel things like this should be taught in a much more active way. You are guided through a certain path that will introduce you to all the needed features, but with a purpose, you learn as you go. The best scripting tutorial I found in recent years was this GUI tutorial ( http://zehfernando.com/2004/doom-3-gui-scripting-tutorials/ ), that does just that, it takes you through the language in a gradual and illustrative way, starting from zero, stopping to talk about things as they become needed. Of course, the writter knows exactly what is important to learn and in what order, so he tweaks the work example we are supposed to be doing in order to go in the direction he wants.

 

But like Obs say, something like this can take a lot of time and energy. Just look at Springheel's effort with that beginner mapper workshop. I can hardly imagine all the work hes putting into it. But maybe videos are slightly faster, easier to do than writting?

 

PS: That tutorial goes on to 7 steps, but the author posted the rest in DoomWorld and appearently the pages are lost... I have them printed, but I couldnt access them online today.

Edited by RPGista
Link to comment
Share on other sites

RPGista, it's so ironic that you should post a link to a good tutorial, where the links are defunct.
So often I've come across a terrific tutorial illustrated, essentially, with pictures, which are now defunct. So the tutorial is useless. Well, there's nobody to complain to. Nobody owes me anything, in this particular endeavor.

The most dismaying news I heard above, is that I have to learn either "C" or "C+" or "OOPS" or something, before finding out that "id-C" as pertains to TDM editing is different from all of them. And that I banged my head on that wall for nothing and that I still haven't learned the trick.

Link to comment
Share on other sites

Obsttorte, I'm totally interested in any of your tutorials.

 

I think that when looked at reasonably and from any perspective, a TDM mission is very complicated and "scripting" is only one aspect. The same person who's looking to learn something about scripting for TDM will be learning how to set up visportals, how to differentiate between sealing and detail geometry, how to set up an area where the sound is coordinated in a way that motivates the scene, and the lighting, and on and on. This is a huge load to take in at once.
Personally, I don't want to learn "computer programming" generally. Not at all.

I want to know something about the "id-C" that's used to make TDM missions work, so the more nitty gritty and basic the example is, with all work shown so it's idiot proof, the better.

Link to comment
Share on other sites

I finally have a firefly looping, set off by a script attached to an info_location entity by a "call_on_entry" flag.

However, this breaks my entire info_location system as once the thing is looping, the "call_on_exit" flag doesn't work and in fact TDM thinks the player is always in that location, wherever the player goes.


The "call_on_entry/exit" system works properly for a simple

sys.trigger ($entity_name)

argument that calls e.g. a func_emitter activating a particle effect. So the problem is particular to the looping firefly.


My .map has several different locations. A mansion, mansion grounds, canal, tunnels, grotto, pond, etc., all of which are visportaled and partitioned as best I could according as the tutorials outline.

Of course every area of the .map is still very rough and has to be tightened considerably. But sounds play accordingly as I enter/exit locations and all of that works and every area is properly sealed.


To activate/deactivate entities, whether static and/or moving on splines etc., I cloned the same ultra-simple setup into two locations. A static func_emitter (with spawnflags 'start_off 1' and 'cycleTrigger 1') to be triggered on enter/exit , and a func_emitter/func_mover/func_splinemover combo to carry some moving effect.

Following the wiki on location_settings I put flags

call_on_entry fly_start1 (or 2)

call_on_exit fly_start1 (or 2)

on the appropriate info_locations



This is my script (loop copied from dragofer/invernesse):


void fly_start1(entity old_zone)

{

sys.println("script fly_start1 running..");

sys.trigger( $func_emitter_3);

while (1)

{

$mover1.time(20);

$mover1.startSpline($spline1);

sys.waitFor($mover1);

}

}

void fly_start2(entity old_zone)

{

sys.println("script fly_start2 running..");

sys.trigger( $func_emitter_5);

while (1)

{

$mover2.time(20);

$mover2.startSpline($spline2);

sys.waitFor($mover2);

}

}


The script works as advertised as the player enters either location, but that's the end of the show because it will not turn off when the location is exited and the entire location system breaks down.

On the other hand, if I delete

while (1)

{

$mover2.time(20);

$mover2.startSpline($spline2);

sys.waitFor($mover2);

}

from fly_start2, the trigger for func_emitter_5 triggers on/off as I enter/exit the grotto and the location settings work fine, until I enter the pond and trigger fly_start1 with its fly loop, and now TDM won't recognize any exit from pond.

Link to comment
Share on other sites

I found (trial and error) that having the info_location call a script that triggers a func_relay, the func_relay then targeting the static emitters and a target_callscriptfunction which calls the spline mover entities, is a sequence that works and doesn't break anything.

The static emitters (with cycleTrigger 0, default, not 1 as I originally said) toggle on/off as I enter/exit the locations, and the moving emitters are triggered to start their endless loops when I first enter their locations. The spline movers never stop moving even after I exit their locations, but the info_location system isn't broken and TDM continues to switch locations as I move around.

So I guess I'll leave it like that.

Link to comment
Share on other sites

 

It would be interesting to know how many members would be actually willingly to learn scripting. If there is a reasonable amount of them around here it might help my motivation.

 

I'm down for some scripting 101 as well. I don't need it yet for the mission, but even if I did, I wouldn't know how and where to start. It looks even more intimidating than writing materials.

Link to comment
Share on other sites

 

I finally have a firefly looping, set off by a script attached to an info_location entity by a "call_on_entry" flag.
However, this breaks my entire info_location system as once the thing is looping, the "call_on_exit" flag doesn't work and in fact TDM thinks the player is always in that location, wherever the player goes.
The "call_on_entry/exit" system works properly for a simple
sys.trigger ($entity_name)
argument that calls e.g. a func_emitter activating a particle effect. So the problem is particular to the looping firefly.
My .map has several different locations. A mansion, mansion grounds, canal, tunnels, grotto, pond, etc., all of which are visportaled and partitioned as best I could according as the tutorials outline.
Of course every area of the .map is still very rough and has to be tightened considerably. But sounds play accordingly as I enter/exit locations and all of that works and every area is properly sealed.
To activate/deactivate entities, whether static and/or moving on splines etc., I cloned the same ultra-simple setup into two locations. A static func_emitter (with spawnflags 'start_off 1' and 'cycleTrigger 1') to be triggered on enter/exit , and a func_emitter/func_mover/func_splinemover combo to carry some moving effect.
Following the wiki on location_settings I put flags
call_on_entry fly_start1 (or 2)
call_on_exit fly_start1 (or 2)
on the appropriate info_locations
This is my script (loop copied from dragofer/invernesse):
void fly_start1(entity old_zone)
{
sys.println("script fly_start1 running..");
sys.trigger( $func_emitter_3);
while (1)
{
$mover1.time(20);
$mover1.startSpline($spline1);
sys.waitFor($mover1);
}
}
void fly_start2(entity old_zone)
{
sys.println("script fly_start2 running..");
sys.trigger( $func_emitter_5);
while (1)
{
$mover2.time(20);
$mover2.startSpline($spline2);
sys.waitFor($mover2);
}
}
The script works as advertised as the player enters either location, but that's the end of the show because it will not turn off when the location is exited and the entire location system breaks down.
On the other hand, if I delete
while (1)
{
$mover2.time(20);
$mover2.startSpline($spline2);
sys.waitFor($mover2);
}
from fly_start2, the trigger for func_emitter_5 triggers on/off as I enter/exit the grotto and the location settings work fine, until I enter the pond and trigger fly_start1 with its fly loop, and now TDM won't recognize any exit from pond.

 

You are running an infinite loop there. It gets called by the locations script and can't return back as it is "stuck" in the loop. If you are calling something like that you have to make a call from there in a thread.

 

// function used for threading, the naming is your choice
// must be defined before(!) the other script so it "knows" it exists and can be called
void fly_start1_thread(entity old_zone)
{
    // put your code here
}
// function called by the location script
void fly_start1(entity old_zone)
{
    thread fly_start1_thread(old_zone); // this calls the function in its own thread, allowing it to run in "parallel" so it doesn't disturb the location script
}

 

 

I'm down for some scripting 101 as well. I don't need it yet for the mission, but even if I did, I wouldn't know how and where to start. It looks even more intimidating than writing materials.

I didn't know it is possible to intimidate you :D

FM's: Builder Roads, Old Habits, Old Habits Rebuild

Mapping and Scripting: Apples and Peaches

Sculptris Models and Tutorials: Obsttortes Models

My wiki articles: Obstipedia

Texture Blending in DR: DR ASE Blend Exporter

Link to comment
Share on other sites

It's very nice of you to say that :D I remember how I hated writing materials, so I expect more or less the same while learning scripting ;) That said, when the holiday season is over and the temperatures go down to a reasonable levels again, I should have a fresh head and enough patience to go through that ;)

Link to comment
Share on other sites

  • 1 year later...

I used to do some programming. First place to start is to learn how to make an algorithm. This is a very detailed set of english instructions on how to do each

step of the thing you want to do. Once you get that done, the coding is pretty simple once you know the syntax. This is something I need to get into as well

as it's been way too long since I've done any programming.

I have an eclectic YouTube channel making videos on a variety of games. Come and have look here:

https://www.youtube.com/c/NeonsStyleHD

 

Dark Mod Missions: Briarwood Manor - available here or in game

http://forums.thedarkmod.com/topic/18980-fan-mission-briarwood-manor-by-neonsstyle-first-mission-6082017-update-16/

 

 

Link to comment
Share on other sites

Yes Idtech 4 scripting is very easy after you know the basic concepts, like I said above I started with scripting before going into C and then C++ and it helped me a tonne.

 

For those that don't know it, here is a good place to learn some of the basics on idtech 4 scripting:

 

language syntax

 

scripting basics

 

know that idscript is based on OOP (Object Oriented Programing) so learning the basics of that will also help immensely.

  • Like 1
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Recent Status Updates

    • Petike the Taffer  »  DeTeEff

      I've updated the articles for your FMs and your author category at the wiki. Your newer nickname (DeTeEff) now comes first, and the one in parentheses is your older nickname (Fieldmedic). Just to avoid confusing people who played your FMs years ago and remember your older nickname. I've added a wiki article for your latest FM, Who Watches the Watcher?, as part of my current updating efforts. Unless I overlooked something, you have five different FMs so far.
      · 0 replies
    • Petike the Taffer

      I've finally managed to log in to The Dark Mod Wiki. I'm back in the saddle and before the holidays start in full, I'll be adding a few new FM articles and doing other updates. Written in Stone is already done.
      · 4 replies
    • nbohr1more

      TDM 15th Anniversary Contest is now active! Please declare your participation: https://forums.thedarkmod.com/index.php?/topic/22413-the-dark-mod-15th-anniversary-contest-entry-thread/
       
      · 0 replies
    • JackFarmer

      @TheUnbeholden
      You cannot receive PMs. Could you please be so kind and check your mailbox if it is full (or maybe you switched off the function)?
      · 1 reply
    • OrbWeaver

      I like the new frob highlight but it would nice if it was less "flickery" while moving over objects (especially barred metal doors).
      · 4 replies
×
×
  • Create New...