[Micky C]

Yeah I know floor mirrors will basically have to be coded from scratch, which is why it's probably just better to wait until polymer reflected surfaces are implemented now that I think about it. But the first feature I asked about should be relatively easy (I hope).
Actually didn't lameduke have floor mirrors?

[Helixhorned]

DeeperThought, on 01 September 2011 - 10:53 AM, said:

I have been using updatesectorz since my first attempted workaround. Here is the relevant part of the code (this code is in the rising platform actor that the player rides on).

I inspected your PLATUP actor a bit and managed to modify it to work with TROR. However, the code is based on release 1.2 since I've been lazy at downloading updates (I'm used to pulling new stuff from version control systems). Here's the relevant code:

// PLATUPSPAWNER for reference
useractor notenemy PLATUPSPAWNER 0
	cstat 32768
	sizeat 2 2

	ifcount 130
	{
		ifspritepal 1 cactor 2000
		ifspritepal 2 cactor 2001
		spawn PLATUP
		cactor PLATUPSPAWNER
		resetcount
	}
enda

move PLATUPVEL 0 0 //-128

// a couple of temp vars to prevent clashes
gamevar pk_tmp_z 0 0
gamevar pk_tmp_sect 0 0

useractor notenemy PLATUP 0
	ifmove 0
	{
		move INIT
		cstat 546
		ifspawnedby 2000 sizeat 48 48 else
		ifspawnedby 2001 sizeat 32 32 else
		sizeat 64 64
		break
	}
	ifmove INIT
	{
		ifcount 6 cstat 35
		ifcount 13
		{
			move PLATUPVEL getv
			cstat 289
		}
		break
	}
	// ifcount 130 killit
// ifceilngdistl would use the actual sector's ceiling z:
	//ifceilingdistl 16 killit

	getactor[THISACTOR].z pk_tmp_z
	subvar pk_tmp_z 2048
	setactor[THISACTOR].z pk_tmp_z
	updatesectorz sprite[THISACTOR].x sprite[THISACTOR].y
		pk_tmp_z pk_tmp_sect
	ifvarl pk_tmp_sect 0, killit else
	ifvarvarn pk_tmp_sect sprite[THISACTOR].sectnum
		changespritesect THISACTOR pk_tmp_sect

	ifpdistl 20240
	{
		addvar countvar 1
		ifvare countvar 2
		{
			spawn PLATSMOKE
			setvar countvar 0
		}
	}
enda

edit: spoiler tags eat tabs, so it's [code] again...

As you can see, I changed the PLATUPVEL move to make the actor stay stationary and subtract the z coordinate manually. I think it's the "move" that was interfering with passing through TROR portals because actors have their sector's ceiling/floor bounds cached (actor[].celingz/floorz), and those values don't extent beyond the actual sector. The only problem I found with that code is that falling from above on a platform will make you pass through it.

Tetsuo, on 02 September 2011 - 01:34 PM, said:

I got one more dumb question about the original levels and TROR:
Is there going to be a download that you can stick into the same folder as your other polymer HRP like the maphacks or music pack and have it auto load like those or is it going to have to be a seperate map pack that you have to load up like a third party map pack? I can't imagine that would even be kosher because you could then theoretically run eDuke32 without the original levels and it would be more kosher to have it so there's a file and it loads up the differences. But I'm just guessing here.

Assuming that distributing altered original maps is a no-no, the only way to do this is by providing patches that users who own the game can apply to the maps. Doing this at runtime is infeasible though, because TROR demands that vertically connected sectors be wall-aligned much more strictly than was necessary with the SE7 system. In fact, a lot of original SE7 sector pairs simply won't connect in Mapster without some kind of manual correction, so distributing m32script files to patch the maps is the way to go. Then again, TROR-joining isn't available as an m32script command, so there's no way to make it fully automatic ATM.

Micky C, on 04 September 2011 - 02:14 AM, said:

Are some more effects going to be carried over to TROR? For example, the breakable wall glass texture be made breakable when used as a floor? And although this is a lot more unlikely, but at least possible; floor mirrors?

Right now, game effects are a bit on the back burner due to... stuff, but I certainly consider having breakable window panes. Floor mirrors also could be done -- as you remarked, they were already there in LameDuke BUILD, and Polymer apparently supports reflections off any kind of surface (Polymost could be a bit harder, I think). But again, it's not something that is currently high priority for me.

[Danukem]

@Helixhorned: Thank you for the code. If nothing else, I can use that to come up with a more elegant workaround. You mentioned the problem of the player falling through the platforms. That's bad enough, but I'd also be concerned about the movement not looking smooth, since you have them teleporting up every tic. In my experience, when something uses a move command to go up, it floats up smoothly, while manually setting its z coordinate results in jerky movement.

[Mblackwell]

@DeeperThought
That's really because of the lack of interpolation. And there's very little way to do it correctly in con without getting rounding errors or inconsistencies (and just making a mess of code). It's not usually quite as big of a deal until you get to instances like wanting to use look_ang rather than ang for turning the viewpoint (which gives you a lot of nice neat tricks you can do).

[HellFire]

I'm trying to use this thing but there still is some stuff that i dont understand... First, lets say that i created a house, using 3 layers, with one of them for the roof+sky. Ok it apparently works (i didnt tried to do the internal part of it yet, with connections and stuff) but lets say that i want to create another house near this one. How im suposed to start it? if i draw a sector in the outside area, it will create a red sector that i will be able only to edit its floor ( if in the first layer), nothing ( if in the middle layer) or only the sky(if in the roof layer). This way its impossible, how can i create a void space (white) in there that is shared by all layers?? i tried by creating a red sector and deleting it, but it deletes the whole layer. I found nothing in the wiki as well. If i created both houses at the same time, i know it would work, but this is just impracticable... Also, how im supposed to copy and paste a TROR construction to a new map? When i do that the structure is all corrupted(i used Altgr).

[Micky C]

The way I do it is to clear the extensions, make the shape in the bottom and top layer, then reconnect them. This gives you a floating sector as a roof to work with, and you can make the walls easily afterwards.

Although it's quite annoying, especially when you've made a complicated structure and you want to add more. There needs to be a better way to do it. Sandwiching doesn't work because you need to select ALL of the bunch (this is aimed at Helixhorned. If I could chose any one feature to be added to TROR, it would be this.) The way I see it, there would be an identical sector created in the lower and upper bunch, then the extension is cleared only inside the boundaries of the sector, that should do the trick, and not break anything. If that could be done automatically in one step that'd be simply amazing.
I'll admit I haven't tried drawing the sectors manually and clearing the extension with crtl-u.

[Mike Norvak]

Micky C, on 07 September 2011 - 05:52 AM, said:

The way I do it is to clear the extensions, make the shape in the bottom and top layer, then reconnect them. This gives you a floating sector as a roof to work with, and you can make the walls easily afterwards.

Although it's quite annoying, especially when you've made a complicated structure and you want to add more. There needs to be a better way to do it. Sandwiching doesn't work because you need to select ALL of the bunch (this is aimed at Helixhorned. If I could chose any one feature to be added to TROR, it would be this.) The way I see it, there would be an identical sector created in the lower and upper bunch, then the extension is cleared only inside the boundaries of the sector, that should do the trick, and not break anything. If that could be done automatically in one step that'd be simply amazing.
I'll admit I haven't tried drawing the sectors manually and clearing the extension with crtl-u.

What does crtl-u do? It's hard to keep an eye to every new feature implemented, I still don't understand such terms as "convex portal" , "sandwiching" or "island" at all. I know there's a wiki, but if you have some time I encourage you to do a video or series of videos to show us all the new implementations and the correct way to use them, it would help a lot.

[Mike Norvak]

The TROR portals that before looked like the retained texture of the TROR layer in polymost now looks like hall of mirros

All these compatiblility issues with polymost/polymer are causing me headaches, I assume it looks the same on classic mode. Make the levels zero-glitchy in polymost is almost impossible and that has limited me a lot in terms of design/gameplay so from now I'm gonna make the next WGR2 episode specially designed for Polymer without taking care on other renders (still playable with polymost/classic since most of the maps was created without TROR, anyway you are gonna experiment glitches on some areas)

Attached thumbnail(s)

• 

[Micky C]

Norvak, on 07 September 2011 - 07:09 AM, said:

What does crtl-u do? It's hard to keep an eye to every new feature implemented, I still don't understand such terms as "convex portal" , "sandwiching" or "island" at all. I know there's a wiki, but if you have some time I encourage you to do a video or series of videos to show us all the new implementations and the correct way to use them, it would help a lot.

An island is a normal sector in the middle of a TROR portal such as this one:
That photo was taken in polymost, and it's obvious why it's a no-no (it works fine in polymer.) Basically any normal sectors that get between the bottom and the top of the TROR portal will cause visual glitches, this includes islands, or funky shaped TROR portals that have bits jutting out. That's what he means by convex; no bits jutting out. So breaking up a large TROR portal at corners and jutting out bits should fix all the problems there. Sandwiching basically means extending an already extended sector so it creates a layer between 2 layers. Now eduke32 really does make sandwiches!

I encourage you to continue attempting to make your episode for polymost (while having polymer as recommended) so that when polymost support finally does come around, people will be able to play it with that.

Oh and here are the TROR related keys on the wiki: http://wiki.eduke32....OR_related_keys

I would make a video, except I'm busy for the next one and a half months, and even then, I don't have a good screen recording program. I have a registered fraps version, but it won't record 2D mode. Can anyone recommend a good, free program?

[Danukem]

Micky C, on 07 September 2011 - 02:49 PM, said:

I encourage you to continue attempting to make your episode for polymost (while having polymer as recommended) so that when polymost support finally does come around, people will be able to play it with that.

Yeah, and keep in mind there are still people who can't use Polymer, or won't, and those people will not play the episode if Polymer is a requirement.

As an aside, I want to say that Polymer seems to be gradually getting smoother and better, even without a comprehensive overhaul. There are still problems, but I find WGR2 to be playable with Polymer about 75% of the time, and it used to be more like 25%.

[Mike Norvak]

DeeperThought, on 07 September 2011 - 04:30 PM, said:

Yeah, and keep in mind there are still people who can't use Polymer, or won't, and those people will not play the episode if Polymer is a requirement.

Well the problem here isn't I don't want but I can't, at least not using TROR, I prefer using it even if just few people could play it instead of not using it at all, it is bringing the gameplay and design a very fresh twist. I would like Polymer isn't a strict requirement, so I want you to know that I'm using TROR just in a few crucial places, hope this doesn't make the levels unplayable without polymer, so the only solution I could think is that:

@ Helixhorned/Plagman : If is possible to make the TROR layers don't be rendered at all in polymost/classic when they normaly causes hall of mirros or other glitches, or even make a patch or something that makes TROR not be rendered in any case under polymost it won't hurt any aspect of the gameplay on my maps, for example what makes the map unplayable under polymost is the framerate drops dramatically but when I make masked all the portals is like if there weren't any TROR at all, so I think it could work, we can discuss this on the WGR thread...

Otherwise I don't know what's the best choice

BTW: the first screen shot is how it looks when the player is just below the portal, the second one how it looks when you pass across the sector, and the last shot is when masked, all these under polymost.

EDIT2: In the worst case (or better?) I could make two versions of every map; one for polymer and another for classic/polymost, obviously when all the map is finished, I can break the TROR conections and put SE7 to go though the layers...

Attached thumbnail(s)

• 
• 
• 

[HellFire]

I may be missing something but from my point of view, while TROR is fucking great (thx for creating and working on it helix) its not usable for more complex stuff. I say this mainly for the problem i was having there, micky said some stuff about it but i didnt understand shit. Even from the sounds of it, it should be simpler. My idea is something like this: A new command for drawing sectors in tror layers, it creates a white sector in the current layer, plus red sectors of the same shape in both above and below layers(so it wont fuck everything up, if it created only a white sector in the current layer but nothing on the other layers we would have hall of mirrors effect or whatever in the other layers). If i go to the above layer and delete that red sector, it would turn into a white sector and the above layer(a 4 layer tror in this case) will now have a new red sector of the same shape. The same functionality should be added to Join Sector. If TROR had this kind of functionality it would be a lot more practical... just my random thoughts.

[Fox]

Agree, ROR really need a layer viewing, working all of the time in ortogonal view is impractical.

[The Commander]

ROR would work best, hell even mapster32 would be complete if it had a complete overhaul and used this system.



Wishful thinking, no?

[Mike Norvak]

The Commander, on 08 September 2011 - 08:00 PM, said:

ROR would work best, hell even mapster32 would be complete if it had a complete overhaul and used this system.
Wishful thinking, no?

Yes it would be cool if the mapster window could have an empty workspace to allow multiple views and working with different projects at the same time like other programs.

And even adding menus / shortcuts

Attached thumbnail(s)

• 

[Mike Norvak]

@ The Commander: Anyway make a building like that isn't actually too hard. It took me about 20 min to make it The only shortcomming is that it only works under Polymer, didn't test on Classic. Can't wait to see a new playable map with TROR soon.

Attached thumbnail(s)

• 

Attached File(s)

•  TRORTEST.rar (1.92K)
  Number of downloads: 229

[The Commander]

I never actually made the above screenshot in Hammer, it was just a random screenshot I found on Google.

[Mike Norvak]

I know, I´m just saying make some simple buildings isn't too hard.

[rasmus thorup]

The only thing i really need is the ability to drag vertics. If that could replace the now used slope feature, it would be even better than an optimized TROR. But that's probably not going to happen since most people make indoor areas. Vertic dragging is more for the outdoor nature areas, which i really love.

[Micky C]

Norvak, on 09 September 2011 - 10:47 AM, said:

Can't wait to see a new playable map with TROR soon.

Way to add on the pressure

rasmus thorup, on 09 September 2011 - 11:36 AM, said:

The only thing i really need is the ability to drag vertics. If that could replace the now used slope feature, it would be even better than an optimized TROR. But that's probably not going to happen since most people make indoor areas. Vertic dragging is more for the outdoor nature areas, which i really love.

Ay? You can drag vertices. You can even drag them in orthogonal view. I don't know what you're on about. Do you perhaps mean vertical dragging where by you would drag a wall up or down instead of changing its slope using key presses? Then I suggest you improve your english.

[Tetsuo]

That one screenshot above reminded me of the time I tried out the build editor that came with the game a long time ago and attempted to make a level that started in my house. My house is bi-level though so I only got the bottom floor done... then I moved onto doing the outside rather than trying to do the old trick that is used to fudge having a room over another room Don't have that map anymore.

[Helixhorned]

HellFire, on 08 September 2011 - 07:40 PM, said:

My idea is something like this: A new command for drawing sectors in tror layers, it creates a white sector in the current layer, plus red sectors of the same shape in both above and below layers(so it wont fuck everything up, if it created only a white sector in the current layer but nothing on the other layers we would have hall of mirrors effect or whatever in the other layers). If i go to the above layer and delete that red sector, it would turn into a white sector and the above layer(a 4 layer tror in this case) will now have a new red sector of the same shape. The same functionality should be added to Join Sector. If TROR had this kind of functionality it would be a lot more practical... just my random thoughts.

Creating an inner loop of void space inside an extended sector is possible by inserting some points on a nearby white wall and dragging the new vertices to form a "semi-island" of the void space in the sector. You have to be careful not to intersect the walls of the "current" layer with those in upper or lower layers here. Next, simply make the white walls of choice into red walls by drawing a new sector attached to the "current" one on both sides. Of course, this kind of construction won't look right in classic/Polymost.

[Fox]

I still think it should works based on layer viewing, since it's the best match for a 2.5d mapping.

[rasmus thorup]

Micky C, on 09 September 2011 - 04:52 PM, said:

Way to add on the pressure



Ay? You can drag vertices. You can even drag them in orthogonal view. I don't know what you're on about. Do you perhaps mean vertical dragging where by you would drag a wall up or down instead of changing its slope using key presses? Then I suggest you improve your english.

Yea. The sloping system is really limited. If you were able to drag vertics up and down vertically, then i will be very impressed. Have you every tried making hills with mapster32? Unless you set up the hills in for example triangles, it's very hard to make a realistic looking hill. But still then it is very limited.

[Jimmy]

Fox, on 10 September 2011 - 11:25 AM, said:

I still think it should works based on layer viewing, since it's the best match for a 2.5d mapping.

I agree. I haven't been able to use it since multiple layers all on top of each other just confuse the shit out of me. (I'm an idiot!)

[Mblackwell]

rasmus thorup, on 10 September 2011 - 04:22 PM, said:

Yea. The sloping system is really limited. If you were able to drag vertics up and down vertically, then i will be very impressed. Have you every tried making hills with mapster32? Unless you set up the hills in for example triangles, it's very hard to make a realistic looking hill. But still then it is very limited.

The engine and data structures don't support this. It's not a matter of it not being available, it's just not even possible. IIRC sectors only know Firstwall and Numwalls. Walls only know two coordinates, the second of which is the link to the next wall: X, Y, and Point2 (the aforementioned next wall in the series). There's no Z data in-fact except in the sector struct where you get Ceilingz and Floorz.

[Hendricks266]

Mblackwell, on 10 September 2011 - 10:03 PM, said:

The engine and data structures don't support this. It's not a matter of it not being available, it's just not even possible.

While what you said is true, it could be possible to manipulate the vertices on each end of the slope using some math. If there is a formula to display the slope in 3D mode based on only the floorz/ceilingz, firstwall, and heinum, then there could be one for side-view mode.

[Helixhorned]

There's also the infinitely more trickier issue of what it actually means to be dragging a vertex vertically. Which sectors should be affected, for example? What if one affected point is the firstwall or its point2? I'm sure the feature requests are well-intentioned, but often they can only be easily implemented for corner cases.

[rasmus thorup]

I have seen helixhorned do amazing things. While what i was talking about seems impossible to create, i think you are wrong. I think it is possible, just very hard.
While i have your attention helixhorned. Did you create the mkterrain state? I love it. I have a similiar system with the CON, though the only weakness it has is that it only activates while in-game. I request that you add the option for mkterrain state, to set the walls of the sectors to the same as the floor or the ceiling. You can see the little gap between the 2 sectors, which there is nothing to do about right now. If you could copy the texture and the shade to the wall from the floor/ceiling. Then it wouldn't be as noticeable. I've done it with CON. Should be even easier with mapster.
The biggest problem with sloping/making hills in build/mapster32 right now, is that it requires multiple sectors to do so. And each of those sectors require that you foresee the situation. Some hills are impossible to make.

[Danukem]

rasmus thorup, on 11 September 2011 - 04:34 PM, said:

I have seen helixhorned do amazing things. While what i was talking about seems impossible to create, i think you are wrong. I think it is possible, just very hard.

He didn't say it was impossible, but being very hard is reason enough not to do it, especially when so many other valuable things could be accomplished with that effort instead.