-TDRR-
-
Content count
477 -
Joined
-
Last visited
Posts posted by -TDRR-
-
-
16 hours ago, Hekksy said:The obvious answer is Zandronum because its easier for you to port and the most widely played client server port. However, I personally would love to see this in Odamex because it currently lacks bot support at all and desperately needs them.
Both :)
Ackshually, i went back to working in bots for Odamex. They are the ZCajun bots so expect them to be garbage at first, though they really aren't that hard to improve. Just takes a little bit of patience and a couple hours.
In Odamex, it would be rather hard to use the bots since you would have to open multiple instances, i imagine having them all visible on-screen at the same time. Which is obviously very impractical and not really comfortable at all.
-
21 hours ago, Thfpjct said:Ok for some reason when i Summon the Weapon pickup the game just crashes, maybe i did something wrong?
Here the "pk3" file to take less time.
Well, looking at the zip, you organized everything wrong. Make your project a .pk3 instead, and organize it like this:
Sprites go in a directory of the .pk3 called "sprites", Make sure to not include SS_XXXX markers in this folder.Compiled ACS goes in "acs" (Not LOADACS, only the compiled file, which in this case is named "PICKUP")
After doing this, i got no crashes at all in ZDoom LE or LZDoom, so you just organized everything incorrectly and that was the cause of the crash.
-
56 minutes ago, Thfpjct said:thanks alot!
btw do you know any way that i can make the weapon pickup not instant? like a need to press E on them to pick it up?
You can do this by expanding on the method i gave you above. You will need an ACS script for this, but i'm going to write it for you. Though, you will need to compile it and put it into your mod.
//=====CODE STARTS HERE========
#library "PUTTHENAMEOFTHISFILEWITHOUTEXTENSIONHERE"
#include "zcommon.acs"
Script "Use_Button_Stuff" ENTER
{
int use; = GetPlayerInput(-1, INPUT_BUTTONS);
while(GetActorProperty(0, APROP_HEALTH) > 0)
{
delay(2);
use = GetPlayerInput(-1, INPUT_BUTTONS);
TakeInventory("PickupWeapons",1);
if(use & BT_USE) {GiveInventory("PickupWeapons",1);}
}
}
Script "Use_Button_Stuff2" RESPAWN {ACS_NamedExecuteAlways("Use_Button_Stuff", 0);}
//=====CODE ENDS HERE========
Make a new item called "PickupWeapons" (You can name it whatever you want, but change the name above too)
And on the code of the CustomInventory item do this:
//=====CODE STARTS HERE========
Actor insertsomenamehere : CustomInventory replaces insertreplacedweaponnamehere
{
states
{
Spawn:
//show a sprite here or something
Pickup: //New state, old pickup state was moved to DoPickup
TNT1 A 0 A_JumpIfInventory("PickupWeapons", 1, "DoPickup")
Fail
DoPickup:
TNT1 A 0 A_JumpIfInventory("WeaponLimitCount", 3, "DontPickup") //if the limit has been reached, don't do anything
TNT1 A 0 A_GiveInventory("WeaponLimitCount", 1) //if not, just give the weapon and add to the counter
TNT1 A 0 A_GiveInventory("ActualWeaponNameHere")
Stop
DontPickup:
TNT1 A 0 A_RailWait //does nothing, just stays there
Fail
}
}
//=====CODE ENDS HERE========
-
This better be hosted on Odamex now that it's compatible with it!
Also, really liking the rebalances to the game, in particular the Chainsaw and Baron nerfs.Great job with this update!
-
8 hours ago, Graf Zahl said:It depends on how you look at it. Doom.exe renders directly to video memory, but the texture in its raw form will remain in the regular RAM.
I know that, but that's pretty much useless in the way xttl said it could be used.
7 hours ago, Jon said:The 0-byte limitation @xttl mentioned is pretty significant, if we can't figure out a way around that then it's a show-stopper.
Yeah, i wonder how could it be worked around editing the .exe itself?
8 hours ago, Jon said:You can definitely crash hexen with bad ACS, it's easy to do evne if you aren't trying to. Whether that can be turned into something useful is perhaps worthy of investigation, yep.
If this ever happens, we could maybe get ZDoom ACS power in Vanilla Hexen, which would be extremely cool.
8 hours ago, Jon said:That's almost certainly enough. One just needs to bootstrap enough code so you can load in another lump and read more code from there. 1KB is a lot of machine code for that.
This means that we can basically run entirely different programs using Vanilla Hexen as a startup method? Would be funny to run Doom on it, if nothing else.
8 hours ago, Jon said:But we have the source code for the ports. We can do *anything* in the ports, by changing the source code. We don't need to artificially restrict ourselves to hacks and exploits. The only circumstance where that's interesting, IMHO, is where it's necessary, and that's pushing the boundaries of the original binaries.
I guess. But my issue is that implementing this in a playable manner for both Vanilla and Chocolate is going to be pretty tough, since you would have to recompile Chocolate and put that along your .wad distribution, all of this while making sure it's at least somewhat close behavior between the two. So it's rather impractical.
8 hours ago, Jon said:I saw these and thought "uh oh" but your message was actually interesting.
Yeah, i'm unexpert on all this stuff but i like reading up on hacking console games via exploits, just find it pretty cool. Maybe that's why not everything i said was completely nonsensical stuff.
-
On 6/26/2019 at 11:36 AM, xttl said:Personally, I think the ultimate vanilla mapping/modding trick would actually be finding a way to get arbitrary code execution from any loaded WAD. Preferably early in the game startup, but at map load time, at time of running the first tic, or while rendering the first frame wouldn't be bad either.
I've tried a bit to look into getting this working, but unfortunately I am no hacker extraordinaire after all. ;__; The only thing I've found so far is that the code which handles DMXGUS lumps (inside libDMX) allows you to overwrite stack contents with data from this lump, but obviously this only works if the user has GUS selected as the music card and the game must be able to detect it too. In addition, the first zero byte in the data will always terminate the copying of data from the lump since this is a string function (strcat) copying data to a fixed size buffer, and this zero byte will be replaced by a '.' (0x2E) from ".pat" which is further strcat'ed to the string to form a path to a GUS patch file on disk, which makes it difficult to write any good pointer values (they tend to have zeroes as the most significant byte) to the stack.
Exploitation of any possibly usable overflows or other bugs is also made difficult by the "ASLR" which is in effect. As probably everyone who's interested in Watcom binary hacking/reversing knows by now: you can't really trust DOS4GW to load the sections to same addresses every time... (though this wasn't really meant as a security feature like ASLR nowadays so depending on hardware and software config the addresses aren't guaranteed to always change either)
Perhaps Hexen could be a better candidate for this due to the multiple text-based game definition lumps it loads from WADs and parses, plus the ACS bytecode interpreter?
...now that I think of it, can the CPU execute code from VGA memory in DOS era PCs and DOSBox? Doesn't matter if it's slow as long as it works. That would always be guaranteed to be at the same address (0xA0000) no matter where DOS4GW relocates the LE sections. You could write code there by crafting special graphic patches and textures for the game to draw, then try to trigger a jump to 0xA0000 somehow!
**warning: unexpert talk follows**
I think restricting ourselves to the original .exe is just way too hard and restrictive like to do anything at all with arbitrary code execution.
I'm no programmer, but i think it would be much easier to set up some way to make the .exe just blindly accept whatever the DMXGUS lump says, and if possible force it to load every time.
I think this allows for code execution directly when the game starts since music playback is needed since the title screen appears, and most likely DMXGUS is parsed some time before that. Maybe you could also change the name of the DMXGUS lump to EXCODE or something, so normal DMXGUS lumps don't cause crashes.
Then distribute the .exe modifications as patches, using whatever file patching program is available for DOS.
But Hexen could be interesting, and probably possible without modifying anything. What if you just put complete garbage into a compiled ACS file? I'm pretty sure there's no safeguards since at first it was only intended to be used with the in-house ACC and only by the team.
Though, less than 1KB is given to ACS in Vanilla Hexen so not sure how feasible that is either.
But, we have to remember: This would only work in DOS or DOSBox, both of which are rarely used for Doom-ing nowadays. Shame it's impossible to do something like this in Chocolate Doom.
Also, correct me if i'm wrong but, do the textures ever go through the VGA card? I thought it was all stored in RAM and stuff is rendered by the CPU and then the whole screen is sent to the card.
-
You could make a DECORATE file in your wad with these contents:
//========COPY STARTS HERE===============
Actor IceyPinky : Demon replaces Demon {Translation Ice}Actor IceyImp : DoomImp replaces DoomImp {Translation Ice}
Actor IceyCacodemon : Cacodemon replaces Cacodemon {Translation Ice}
Actor IceyHellKnight : HellKnight replaces HellKnight {Translation Ice}
//========COPY ENDS HERE=================
And that would make Pinkies, Imps, Cacodemons and Hell knights have an icey color. Sorry if it's not that great, but it's something at least.
-
It's kinda weird but in a basic way it goes like this:
Make an inventory item, that has the max amount of weapons you want the player to have. (I mean, if you want 3 max weapons, set Inventory.MaxAmount to 3)
For the purposes of this guide, Let's assume the inventory item i told you above is called WeaponLimitCount, and it's max amount is 3.
Now make a CustomInventory item for each weapon. This CustomInventory item is the actual pickup and works like this:
Actor insertsomenamehere : CustomInventory replaces insertreplacedweaponnamehere{
states
{
Spawn:
//show a sprite here or something
Pickup:
TNT1 A 0 A_JumpIfInventory("WeaponLimitCount", 3, "DontPickup") //if the limit has been reached, don't do anything
TNT1 A 0 A_GiveInventory("WeaponLimitCount", 1) //if not, just give the weapon and add to the counter
TNT1 A 0 A_GiveInventory("ActualWeaponNameHere")
Stop
DontPickup:
TNT1 A 0 A_RailWait //does nothing, just stays there
Fail
}
}
-
52 minutes ago, Noiser said:Nope, It makes liquid animations faster, also a trick regarding blood flats and glowing. I could do it with ANIMATED I guess, but then it would have even more issues since they are not cumulative.
So just keep it then. ZDaemon compatibility is really not worth it anyways since all they play over there is Chillax and the occasional event.
-
1 hour ago, Noiser said:
Thanks a lot! I will try to get it fixed for the next release. Not sure about removing the ANIMDEFS thoughFrom what i saw it literally just redefines animations that are already in Doom 2 so there's zero reason to keep it (In fact i think it may cause issues with some things).
But really, using your pistol in ZDaemon spams "YOU CAN'T USE ACTOR CODEPOINTERS IN WEAPONS!" due to A_BrainPain so i'm not sure if you should even bother.
-
8 hours ago, Linguica said:(this might not even have to be a code pointer frame, I haven't checked)
It's not. Offsets can be set at any time as long as A_WeaponReady is not in effect. So this means by axing the health and armor bonus animations you probably can do this easily.
-
Hey, you should rename MAPINFO to ZMAPINFO to fix compatibility with Odamex. And while we are at it, removing ANIMDEFS fixes compatibility with ZDaemon, though there's inoffensive error messages, but that doesn't matter, Odamex is closer to Vanilla anyways :)
-
Wow, i made a D4T weapon mod for Vanilla a while ago, but this is on a whole other level. I'm speechless, this is just incredible! The amount of enemies you got in is really awesome, and the faithfulness to Doom 2016 is very impressive for a .deh mod. I like the sounds and the look of the enemies too.
Great work, keep it up! Hope to see some other Vanilla mods from you.By the way, is it fine if i make a DECORATE version of this mod? I know it goes against the spirit of the mod, but i really want to make my bots work with this!
EDIT: And the brightmaps blew my mind when i saw them. I really thought you modified Chocolate Doom but seeing it works in DOS too is just far too awesome. You did a great job of getting the most out of Vanilla Doom's states, but maybe this would have been even better with DEH9000?
-
-
Updated! This update is fairly big. Including custom actions and custom class speeds both editable directly from the mod-side itself, Node Studio, support for saving waypoints into .nod files, and updates to the bot movement system.
I have added more waypoints to the first post, so make sure you try them out. I also added information about loading, saving and making nodes on the usage guide, so give that a read too.
Just a friendly reminder: If you want to contribute anything to the mod, be it bug reports, feature suggestions, waypoint files, code submissions, bot chat lines, Youtube videos, or whatever, just go ahead and post them here and i'll gladly put them in the mod or the first post.
Download link in the first post, as always.
There have been more updates, but again, they are over at the ZDoom and Zandronum forums, so if you don't want to miss anything, please follow the TDBots there.
Oh and the TDBots might be coming to a new game that's not on the Doom engine. Let's just say that when they get there they will be the only one of their kind B-)
-
Doom 3. I tried playing it until... Eh i don't even remember, it was not long before the first Hell Knights though.
TNT having certain overly long maps around the last third of it, it just drags on too long with the gigantic maps and sometimes confusing layouts. I never played through all of Plutonia but what i played is quite good.
Doom 2's city levels are very tedious except for MAP15 and 16. I love playing through those two. Never played Master Levels or NRFTL so i can't say anything about them.
Doom 1's episode 3 and 4 are quite boring, but there's a handful of levels that are good.
But Doom 64 is good, and it's quite hard to say that when you are playing with a broken Nunchuck and crappy batteries on the Wiimote which goes to show how good it is. Never felt tedious except for a couple parts where the next thing to do isn't very obvious, like that one time where you had to press a lamp to get a yellow key.
-
On 8/19/2019 at 5:59 AM, ketmar said:yeah. that's why i think that fixing it is almost impossible: there is simply too much code to... let's say "untangle".
Yeah, pretty much. I cleaned up a lot but no dice on it running on K8Vavoom. Most likely i won't be able to do this, far too many errors at startup.
On 8/19/2019 at 5:59 AM, ketmar said:you're welcome, of course! ;-) i strongly believe that there is no "The Only One Right Way" to do things anyway. after all, built-in BDW and Gore mods are done in decorate too -- because it is easier this way. and there is support for code blocks in decorate too, so you can write simple logic there (just take a look at Gore mod, it is full of code blocks that checks some args and cvars).
Wait, so if and else statements work in K8Vavoom's DECORATE? I thought you were aiming for ZDoom 2.8.1 featureset or something like that. That's really cool regardless.
On 8/19/2019 at 5:59 AM, ketmar said:i am still trying to design 2D clipper (Doom clipper is basically 1D), but this is quite hard. yet i added some simple checks, so if the camera cannot see midtexture part of a wall, that wall considered solid. and it does quite aggressive frustum culling too.
i am also thinking about combined BSP/portal rendering. currently, almost any 2S wall is considered "non-clipping", even if its midtext is obscured by other walls, and is impossible to see. this is because clipper is 1D, and this is what makes some complex map unnecessarily slow. i have several ideas of how to solve it, and i hope to find something that will allow me to do fast and efficient 2D (or 3D) clipping.
p.s.: putting non-transparent midtexture helps too. if midtex is not transparent, and has no holes, clipper is usually able to notice that, and it considers such wall "solid". this can be used in huge maps to improve rendering. like, for example, if you have a courtyard with the gates, and you cannot see over its walls, you can put a 2S wall behind those gates, and make its midtex solid. then clipper will be able to clip everything behind the gates (which cannot be clipped if a map is built in "normal" way, because gates doesn't block the view due to their top texture being transparent (usually) to not block the skies).
Good to know. Hopefully i can optimize my K8V-exclusive maps to make use of this info (while it works at least :P) as i'm indeed getting FPS dips in various places.
-
Just now, ketmar said:that would be great.
There you go. (Just in case, this is not the latest version, it's missing some features but first i want to get the core stuff working)
Just now, ketmar said:sorry, i was only joking. my sense of humor is not the best one, i'm afraid. of course, i have nothing against PB running with k8vavoom, i just don't believe that it is possible to fix it. but i may be wrong here. ;-)
Well, it's not so much that, but again, PB Redux is comparatively HUGE vs BDv20. Meaning it's about x4 to x6 times larger, and with many of the same hacks because at the time PA1NKI113R (or however that's spelled) was a bit lazy on cleaning up messes.
1 minute ago, ketmar said:standard doom maps should be playable, i think.
Depends, really, i doubt i will be able to test much of it in this PC. K8Vavoom is reasonably more demanding than ZDoom LE, and even on ZDoom LE i get stuttering and occassional low framerates, so at least for me it's mostly out of the question.
4 minutes ago, ketmar said:it is badly designed. like, the whole thing is missing separators/terminators, so i cannot reliably skip something my parser doesn't know about. also, internal commands (like "wait" or "goto") seems to be carefully choosen to fit 4-char sprite name limit, so you can't have a sprite named "fail", for example. actually, i believe that GZDoom jumps through the hoops to make it work, and i absolutely won't do that.
Yeah, but still, i just grew attached to it ever since i started modding 4 years ago, and there's barely anything i would want to change about the language. So yeah that's the reason i wouldn't use VavoomC to define many actors unless it's something very small.
6 minutes ago, ketmar said:it shows all rendered segs. k8vavoom automap granularity is by seg, not by linedef, so you'll get a quite precise view of what was rendered, it is not an approximation, it is as precise as it can be (because the engine is rendering by segs too).
p.s.: you may also notice that looking at the floor renders almost nothing, for example. yeah, running with your head down can help for huge maps. not that you can play this way, though -- it is impossible to shoot monsters while looking at the floor. ;-)
That's really, really neat. In ZDoom, looking down doesn't help the framerate at all, not even in the GL renderer. Nice to know that K8Vavoom has quite good draw culling.
-
11 hours ago, ketmar said:from the quick look at the code -- it doesn't do anything special. but it may be different somewhere deeper. that's why i wondered too -- because it seems to work with my tests, and with monster mods. i bet nobody (not Janis and me, at least) ever thought that `A_LookEx()` can be used on player pawns. ;-)
ok, now that i know about bots, i'll try to find out what is going on.
I'm probably going to upload the TDBots version i have been used for testing if you need it.
Yeah i know i'm the only guy to come up with such silly ideas.
11 hours ago, ketmar said:NO, GOD NO, PLEASE, GOD, NO!!! ;-) i already have one abomination mostly working (clusterfuck), and another mostly working (doomrl arsenal+doomrl monsters), we don't need the third one! ;-)
("mostly working" means that you can run it, and it is playable, but many non-gameplay-fatal things either doesn't work, or work different/glitchy)
That's quite a bit off-putting though, so maybe i'm just going to keep PB:R on Zandro and ZDoom. Oh well, it was probably going to be too slow to play anyways.
11 hours ago, ketmar said:understandable reason. from the technical point it doesn't really matter anyway which one you'll use, the compiled VM code is the same. tbh, some things aren't even possible to do outside of decorate (like `A_Jump()` or `randompick()` with 255 arguments, or dynamically calculated jumps).
i just HAET decorate syntax, and thought that everybody is like me here. ;-)
Yeah i can see why would you hate it, it's rather lax and not as flexible as most other scripting languages.
11 hours ago, ketmar said:it may be fun to turn on overlay automap and say this in console:
dbg_autoclear_automap 1
this will clear automap before rendering each frame, so you'll basically get "sight beam" effect. useful to check what parts of the map are really rendered, and just fun to look at. ;-)
(also, ask me about consistent naming! ;-)
That's great! I hope that helps with increasing performance in various maps. It shows your exact cone of vision? Would increasing the FOV change anything?
-
Just now, ketmar said:basically, the engine only wants to see PLAYPAL. maybe some other standard lumps too, i don't really remember, but i don't think so. PLAYPAL is required, because it is used to build various translation tables and color cube.
Probably PLAYPAL is the bare minimum required to boot. I'll try a bit later.
Just now, ketmar said:actually, BD21 got a huge code cleanup. it is still a mess, but now it looks slightly less like a vomit. also, i added alot of things since i last tried BD20, so it may "almost work" now.
I hope that it "almost works" because Project Brutality is a big, and i mean BIG mod. It's at minimum 4x times larger than BDv20 and suffers from the exact same issues so i really hope i won't have to manually go through every single actor and try to fix whatever is wrong. If it doesn't, i guess i'm going to just release the K8Vavoom compatibility as a later update because it's most likely quite tedious to do.
Just now, ketmar said:yeah. but you can see it with much less efforts by using "am_cheating" cvar, and "am_show_XXX" cvars. k8vavoom automap can show alot of interesting things! ;-) (basically because i am lazy, and never bothered to write The Real Debug Tool)
Oh, that's even better then! It's basically like having GZDoom Builder's Node View mode but directly in the game, which is for obvious reasons useful and less tedious to work with sometimes.
Just now, ketmar said:that would be a mess, if possible at all. BSP will degrade to almost unusable polygon soup quite fast.
yet i have some other ideas for moving sectors, and renderer. not enough time to do everything i want, as usual, but idea of moving sectors isn't ditched, and i hope to eventually introduce this feature to k8vavoom. ;-)
I'm really hoping this comes to fruition, because i have been wanting proper Build-style moving sectors in Doom ever since i got my hands on Doom Builder :)
Just now, ketmar said:yeah. this, or write your actors directly with VC, it supports creating states too (albeit VC codepointers cannot have arguments yet -- it is possible, i just never bothered to implement that).
Maybe not. I just love DECORATE's simple syntax so much because it makes quick fixes and edits painless (Unless your mod is Brutal Doom lol)
Just now, ketmar said:as usual, small sample will help. i already rewrote the `A_LookEx()` implementation, though (it was a mess anyway).
It happened consistently every single time and now that i made a sample it works fine. But when it's on the TDBots it does not work for some reason, what could be causing this? Could it be that calling A_LookEx on a player actor is not the same as in ZDoom?
Just now, ketmar said:i just don't have enough time. i'm working on k8vavoom 8-10 hours a day usually, and this is somewhere near my limit now. i just cannot code for 20+ hours a day, like i used to do 20 years ago. ;-)
Understandable. Just know that when i get the money, some donations will likely come your way (If i can understand all this Bitcoin business though :P)
Just now, ketmar said:even worse than that: you may end up with completely broken engine. C++ and VC classes and structs should be always in sync. the engine does a very loose job on checking that (C++ sux!), so if i'll swap some fields, or something like that, you won't even notice the change... until everything will blow away. ;-)
but extending classes is almost safe. well, as safe as such things could be.
Oh yeah, the classic "snowball bug". Now i understand, thanks for the clarification.
-
12 hours ago, ketmar said:ah, that's easy. all known games are described in basev/games.txt. its format is awful, though, i'll change it, but the basics will remain the same. when started, the engine just looks for the first suitable iwad from games.txt (if nothing else was specified by user).
I saw that file but i thought some blanks were filled in by the engine, like required lumps or something. At least it's nice to know that there's not much to do there.
12 hours ago, ketmar said:ah, in that case go wild! i'm not against VavoomC (hey, VC was the main reason i started working on Vavoom!), i am only against overusing of VC. of course, total or partial conversion may need to alter game logic in various ways, and here VavoomC is the way to go.
sure, no objections! i'll be proud if other peope will use k8vavoom to create any games they want, free or commercial.
Alrighty then, i'm going to fiddle around with Vavoom C and see if i can get some progress going. If there's anything i don't understand i'll ask you.
12 hours ago, ketmar said:internally decorate compiled to the same VM code as VavoomC (even using the same compiler mostly). so technically when you're writing decorate code, you're using very broken variant of VavoomC. ;-)
also, this is why many mods are not working too. besides unimplemented features, VC compiler is statically typed. and ZDoom was very... careless about argument types. so people tend to pass strings where numbers are expeced, or even forgot about some arguments completely (and ZDoom was happy to compile that nonsense). i added alot of workarounds for decorate, but it still not so careless as ZDoom. ;-)
I suppose this is one of the reasons BDv20 isn't working? BDv21 has added various arguments to codepointers where there weren't any, so i guess that's why BDv21 is easier to get working?
12 hours ago, ketmar said:yeah. when i'll implement JIT compiler, i'm planning to move the rest of collision detection code to VC too.
to make it slightly more clear: the map is loaded into C++ class `VLevel`, which is fully exposed to VavoomC as `Level`. and i mean fully exposed, with all its fields. so VavoomC have access to the same data structures as C++ part, including subsector data, nodes data, and so on.
actually, by adding several API calls (they're not there yet, but it is not hard at all), it is possible to build the map completely with VC code. k8vavoom does internal node building anyway, and it doesn't really matter if lines/sides/sectors data is loaded from some file, or generated by some code. ;-)
That's pretty cool! So you could write something like displaying particles at the center of each subsector to help view how K8Vavoom does it's nodes? Quite nice.
If those are eventually added, a way to only rebuild a few sectors at a time to maximize performance when moving sectors should be done, so we finally get the fabled Duke 3D style cars but much, MUCH more flexible.
12 hours ago, ketmar said:original Vavoom didn't even had any subdirs there! just a flat dump of all source files.
decorate API is somewhat special thing. you can export almost any VC method to decorate, you only need to declare it in basev/common/actors/nativeclasses.txt. parameter list doesn't matter there, the only things that matters are:
action native Name ();
at the start, k8vavoom reads that list, and then using it to find decorate methods.
also, if you'll see ugly code, that prolly was me who added it. i added alot of code without understanding what i am doing when i only started working on the engine. lol).
That's quite cool. So with that i could cut most, if not all ACS calls in DECORATE and greatly speed things up in some cases? That's awesome.
12 hours ago, ketmar said:hm. thank you, i'll check.
i am still suffering from memory corruption bug, so every bug report may be not what it seems to be. the quick look at `A_LookEx()` code doesn't show anything wrong.
I don't think it is the memory corruption bug though, it happens every time, on every map, with every gamemode and every bot setting.
12 hours ago, ketmar said:btw. are you compiling the C++ code yourself, or do you simply using the binary i uploaded? usually, uploaded binary becomes obsolete the day i uploaded it. if you'll look at k8vavoom git repository, you'll see that i am commiting there almost every day. i am really working on k8vavoom full-time (only without guaranteed salary, lol).
Yes i'm using the binary you upload. I just can't compile anything at all in this craptop, first the compiler kept spitting errors, so i upgraded it to MinGW-w64 and now it's slightly better but i still can't compile anything. CMake worked fine, but now it bombs out with "cc0.exe" not working. In fact, the only C++ code i ever compiled is Nintendont for my Wii when i modified it to load multiple controller configs, and even then that's not on this laptop and it was with an already setup toolchain.
So yeah i can't really compile anything.3 hours ago, ketmar said:also, there is another reason to avoid VC API if you can: i give zero guarantees of its stability and backwards compatibility. while i'm not going to break everything just because i can, sometimes implementing some feature require API change. or i can spot a Very Bad Code and decide to refactor it, so it will be better maintainable. most of the time it is not fatal, but still...
Don't worry, i'm perfectly fine with rewriting code, i do it pretty commonly even when not strictly needed just because i want to make it more readable (After all, almost all of my code is MIT licensed so i can't just leave a mess that only i understand) Even when i first got into ACS i kept rewriting my code because even to myself it was very hideous.
4 hours ago, ketmar said:i don't mean "hire me", no! ;-) i mean "watch for VC code changes (they're usually prefixed with "script:" in git log), and check if your code won't break. and contact me if you're not sure."
Not sure if that was sarcasm but we take anyone who knows C# or C++, so if you ever feel like taking the role, PM me ;) We won't ask much from you anyways.
Anyways, sure i'll check it often.4 hours ago, ketmar said:also, it is better to build upon the existing VC code, because some parts of the engine expects to find various things on VC side, and Bad Things can happen if you violate those expectations. that is, most `eventXXX` methods should be retained, for example. and it is always better to extend/extend-replace classes than to copy-paste their code in your project. for obvious reasons, i hope. ;-)
Yeah, i think it is because when copy-pasting i'll probably miss out on most updates and fixes to all those classes, so extending will just allow me to add more or change whatever needed and when the update comes, little to no work is needed.
-
18 hours ago, ketmar said:great, thanks. then i'll prolly push out a new build. maybe i'll implement a limited support for xlat too, it should not be that hard.
p.s.: WaterDoom already fixed, btw, it now correctly colors all sectors.
Cool, and i didn't even have to ask! Thanks.
11 hours ago, ketmar said:i think i don't understand. from k8vavoom's PoV, iwad is not different in any way from any other wad. i.e. pk3/wad can contain/override anything you want, there is no need to make anything special. or i got it wrong?
Defining a custom IWAD means: The source-port automatically loading it without any other file required (except the source-port's files themselves) and it containing it's own content and stuff.
11 hours ago, ketmar said:tbh, i prefer them to stay in decorate+acs. you read my note about ZScript, and i believe the same for VavoomC: unless it is absolutely impossible/very slow in decorate+acs, don't use VC. yeah, VC is even more powerwul than ZScript, but... if it is possible it all -- i really want people to not be locked to k8vavoom. to the extent that i'd prefer separate k8vavoom "extension packages" for mod instead of packing k8vavoom stuff inside a main pk3. of course, it is the authour of the mod who'll decide, and i'm not demanding anything, but i think that using a "core" thing plus port-specific "spicy" addons is the way.
oh, nevermind, i love to talk about barely related things, and too fond of my letters to remove them.
It's a standalone commercial game that would be on a store like Steam. No reason at all to add support for some other sourceport. But i agree this should be the case for mods, no reason to lock it to a single sourceport.
We already use Zandronum, GLOOME and LZDoom as our bases for other games anyways, and i wanted to see if K8Vavoom could have everything needed for a standalone game, if you don't want to do it, it's perfectly fine, we could just continue using Zandronum and use ACS+DECORATE for what we want to do in this game even though it's filled with bugs and quite slow, and barely customizable too.
11 hours ago, ketmar said:actually, VC allows EVERYTHING. you're THE GOD. literally. the whole game except renderer and some very small parts of coldet in written in VavoomC. linedef translation is done with VC. initial map thing spawning is done with VC. all sector effects are done with VC. physics is done with VC. everything. while GZDoom still struggling to move the whole game to ZScript side (sorry, just couldn't resist...), Vavoom already done that more than a decade ago, and almost completely.
Very good! This is exactly what we were looking for. A very powerful scripting (Well, programming now) language that could do everything we needed and even more.
11 hours ago, ketmar said:dirty little secret: many complex things ACS trying to do are done by calling VavoomC code, and optionally passing back its result.
I knew it! I had this suspicion since i knew Vavoom C was as powerful as you said it was. Does DECORATE do this too?
11 hours ago, ketmar said:tbh, you can even move map vertices, but that won't end up in anything good, as you may imagine. but you can, because it is VavoomC. while we're talking about its code as "scripts", technically it is a full-featured OOP programming language, with static typing, and even with such low-level features as pointers.
That's pretty cool. That means i just have complete control over the map structure with Vavoom C? So if theoretically Doom didn't use a static BSP tree i could just transform the whole map on the fly? That's seriously awesome.
11 hours ago, ketmar said:p.s.: as always, with the power comes the responsibility. k8vavoom does not try to "validate" your VC code in any way, neither it tries to restrict you from doing something. so some kind of terrywad can wrek a massive havoc. it cannot access/write files outside of vavoom config directory, tho, and cannot access network directly, but those are prolly the only restrictions. and yes, you can overwrite almost any random memory with VC, and cause a segfault/access violation easily.
p.p.s.: no, i don't have any plans to implement VC safety nets. this will make the engine much slower, more complicated to maintain, and people will find a way to fool the protection anyway. just don't use mods from strangers you see for the first time. ;-)
Don't worry, at least i won't bomb anything at all using Vavoom C (At least not on purpose). Not sure if there will ever be a K8Vavoom terrywad so perhaps we are pretty safe for now at least :P
EDIT: Where's all the DECORATE-related stuff? I'm at the linespec folder and i'm very confused. Where are the codepointers? @_@
EDIT2: I found it. And wow it's very easy to read! I'm able to understand pretty much everything in Actor.Decorate.vc. I'm going to keep experimenting and see if there's any bug i can fix by myself. Maybe then i'll become your official second dev in charge of DECORATE, just remember to keep an eye in what i do so nothing bursts in flames :)
EDIT3: @ketmar WAIT BEFORE POSTING THE NEW BUILD: A_LookEx is broken! The sight check does absolutely nothing at all now, and the sound check doesn't seem to work either. Attacking the monster does make it react again but that's it. -
Hey ketmar, i was wondering, could you add support for defining custom IWADs? VavoomC is getting extremely powerful so the need of editing the source code to make new games with the K8Vavoom engine is none except for defining a custom IWAD.
Unless this is already in, and if that's the case could you tell me how it works? Been looking a bit through the basev progs and i haven't found anything related to defining a custom IWAD yet.
I probably won't switch any of my announced projects to K8Vavoom as they are just too far in development like to have such a large change, but i got one that fits K8Vavoom's advanced abilities perfectly. Does VavoomC allow at least simple map editing? Just raising and lowering floors, retexturing and spawning stuff would be perfect. Even better if it allows ACS-level (or better) editing.
-
Just now, ketmar said:sure. both decorate flag (two flags, actually), and mapinfo's gameinfo flag.
btw, you can use color codes in help strings. like this:
"\cGWARNING: In K8Vavoom, this option sticks even without VD loaded!"
and your warning will be shown in red. color code automaticaly resets on line end.
Nice. Thanks for your help and patience!
Tomorrow i'm going to test some more mods and tell you if there's anything to be fixed.
[v1.5] Doom 64: Retribution
in WAD Releases & Development
Posted · Edited by -TDRR-
If anything happens, i'll try to spread the .pk3 in as many, many pages i can get it so at least your work is preserved. I would hate to see this only be played by the people who got the chance of getting it before it got taken down.
Also, i'm making a Zandronum version (yeah i always say this on many projects and a lot of the time nothing happens) but is it fine if i release it on this thread? It would be pretty cool to see Retribution being played online. EDIT: Nevermind this was already done.
Another question that had me curious for a while, how were Breakdown's sliding doors done in the original?