• Content count

  • Joined

  • Last visited

  1. People stay hooked on WoW because of something called the "sunken costs fallacy". They have invested time, money and effort on their characters. The 'progression' in tiers means that your latest top notch gear and dungeon strategies become dated or even obsolete the moment the next tier patch is released. Meaning, you have to play to keep up or you will lose your investment done so far and end up like a scrub nobody wants to play with. Plus, there's your guild who insists on filling their raid rosters with active members only. With WoW, it's all or nothing. This is a completely different situation as most multiplayer games, as players get to play with the same gear the moment they enter the game. Unlock mechanisms are the company's attempt to add the same kind of hooks.
  2. I like the Cleric for two reasons: the poison cloud bottles that can easily dispose of those annoying centaurs, and the Wraithverge. Also: fuck the Crucible of Steel.
  3. I think it's more or less a given that any cross port stuff ought to be based on the UDMF map format.
  4. True. That's why I don't use the map editor but an ACS script to place 99% of the things that require a TID in the level at map start. Usually these are (interactive) custom mapspots. Only when I absolutely have to (eg. if I want to check if a group of monsters is dead before I open a door) do I need to resort to CLED / ExtraData. And it's not ExtraData that is a drag to use... it really is not. It's the requirement to use CLED to assign a number to a Thing's options flag that represents its tag. CLED works by thing sequence number, so if you delete a Thing in your WIP those sequence numbers change and your CLED script assigns stuff to the wrong Things.
  5. Edmap doesn't clean up your WIP properly during saving, which means you have even less memory space available for development. Plus it is very prone to crashing and mangling your level after the first nodesbuild. This is why I used a copy of a WIP for nodesbuilding and testing, leaving a "pristine" unbuild WIP for further development. A routine I still do to this very day, despite using far better level editors.
  6. Give both linedefs the same id (tag) "A". When either linedef executes your script, use SetLineSpecial in that script to remove the special from any linedefs tagged "A".
  7. Not much progress has been made lately. A heatwave has decided to put up camp here, making it usually too hot to spend time sitting cooped up at home. Haven't even experimented with the new moving linked portals option yet..!


    What little time I did spend was focused on adjusting the facades of buildings in preparation of finishing the main outdoor area of E2M3.

    1. rdwpa


      I hear making progress at a slow pace might get you some kind of award. 

    2. Phade102


      Wait a minute...Mordeth is still being developed? i thought it was some joke that it was still in development O.o

    3. 42PercentHealth


      Can someone explain the Mordeth joke to me now? I've been here for a year, have 400+ posts, so I think I'm qualified to know some of the inside humor around here. Right?

    4. Albertoni


      @42PercentHealth It's simple. Quoting the wiki: Mordeth is a partial conversion by Gaston "Mordeth" Lahaut. The first six levels were released in 1997, while the remaining episodes are still in development.


      Basically, these whole 20 years were... Busy. First Mordeth lost a bunch of work in an incident. A loss of motivation followed, but in the end more time was spent making the Eternity Engine able to handle the features the rest of the Mordeth conversion will need.


      I might be wrong in some details, but that's basically it, a project that's 20 years in constant development.

    5. 42PercentHealth


      @Albertoni, Ah, ok. So it's like Half-Life 3 and Elder Scrolls 6, except that it's been 20 years?

    6. Albertoni


      A bit worse. We have clear, definite proof that Mordeth has been working all this time. But yeah.

  8. If you need to signal that the inactive linedef trigger is now inactive but can be turned active later, you might also want to consider SetResultValue. Standard all scripts set this value to "1", meaning that a successful S1 (W1, etc) activation marks that linedef as done and cannot be used again. int flg = 0; script 1 (void) { if ( !flg ) { SetResultValue(0); //display message "turn on the power first" } else { //power is on //do your stuff here } } script 2 (void) { flg = 1; // do/display stuff } With something like the above, the player can keep pressing the S1 linedef with script 1, and the message that he needs to turn on the power first will be displayed. If he does turn on the power or whatever (using script 2), a flag is set and script 1 will now do the stuff it was supposed to do and finish.
  9. There's currently, at least to my knowledge, no ACS function that would let you select a specific monster without an associated TID, nor target a group of monster based on their type. So, you need to tackle this first. I'd start by altering all types of monsters with decorate. Each type (eg Imp) now calls a script once in its spawn state. This script assigns a free TID within a specified TID range for that type of monster (eg. 100 to 200 for type Imp). A subsequent script can now randomly choose from such a range a specific TID, which you can then use directly for whatever you had in mind. About current health of the actor: you can set this with SetActorProperty.
  10. This better not devolve in yet another zdoom-EE slugfest.
  11. Yes, but you need to visit at least once in your life. Then again, @40oz only has two weeks... you're going to end up with an partial impression regardless, since two weeks is just no time at all to see everything, even if you stick to the highlights only. Best to find out what you really want to get out of this trip, and then find the cities that cater to that most.
  12. As for the "currencies in Europe", so far you've only mentioned cities in the Eurozone with the exception of London. So that's Euro for everything and pounds for the UK. If you're set on the cities already mentioned, I'd suggest London to Paris and Munich, then Barcelona and Rome. You may want to take the plane from Munich to Barcelona instead of train. Customs you will only encounter on your flight to and from Europe due to being part of the Schengen zone, meaning no internal borders. The most strike prone countries currently are Greece and, by some distance, France.
  13. You only have two weeks. Consider how much time you want to spend on actual sightseeing versus the time it will take to travel by public transport and between the number of places you want to visit. You don't want to rush a city in 1-1,5 days and then spend half a day or (much) more just sitting stationary in some (night) train to get to your next 'target'. It's the same as having two weeks to explore the USA, citing a number of cities from East to West coast. Pick a small number of "must-have" destinations. You already know you start with London and must end in Rome because of your flight itinerary. Realize you can't visit eg Prague AND Barcelona without sacrificing a lot of your time merely traveling. You are after all interested in the continent itself and not to become an expert in the various European train systems.
  14. I'm using the 'layers' approach. The entire map geometry is divided into stacking horizontal slices, from a basement layer to ground level to first floor etc. Those layers are usually between 128 to 320 units high, depending on need. Often an indoor part of a room within such a layer can get its own separate private layer. Detailing stuff (with anchored or edge portals) is used on the fly without a pre-determined plan. Each layer has a dummy sector 'anchor' in the same relative position, which you then use to position new geometry in the right places in the adjacent layers. This is important, since every layer has to be precisely positioned to avoid errors. A sector that needs extension into a different layer gets copied there, using the anchor for correct positioning, then adjusted for height. It's not the technique or (lack of) tools itself that makes modding with portals cumbersome. It's the fact that an adjustment in a room might very well affect the geometry of the stuff in the different layer above/below this room and would need adjusting too. Once you put something down, it's that much harder to adjust later. Want to make this room's ceiling higher because it looks better? Too bad, there's already geometry above it that you find very hard to change accordingly. Like, instead of checkers you're now playing 3D chess. Not to mention that you can't preview your new room, if that room depends on another portal area (or two... or three...) to be complete. There's more to 3D then just having nice architecture. There's gameplay that ought to be elevated to 3D as well, both in flow as in combat. And I've found that is the hardest part to get right.
  15. Sure, for some stuff you'll need immediate followup. But for opening a door after a certain group of monsters die? Your door would open even before a player would register that he just killed the last monster. Checking every second or so instead of every tic is plenty. And your player, between different playtroughs, is not going to notice that this door is now opening half a second earlier or later than in his previous session, because he would still be looking at his last victim's corpse falling to the floor. Reason for me to mention is that I see this quite a lot when inpecting scripts. For example a countdown, and you want to do something on every second? Then why loop with increments of 1 tic, or worse: calculating the same amount of remaining seconds every tic, for 35 straight consecutive tics, and then printing that same number 35 times per second to the HUD? The performance hit killed that encounter for me. But yes, offtopic. Rant over; carry on :)